Cassandra列キーの自動インクリメント
Cassandraと私の列ファミリー（CF）の構造を理解しようとしていますが、リレーショナルデータベースに慣れているのでかなり難しいです。
たとえば、単純なusers CFを作成し、新しい行を挿入しようとした場合、MySQLのようにインクリメンタルキーを作成するにはどうすればよいですか？
一意のIDの代わりにユーザー名を入力するだけで少し意味がある例をたくさん見ましたが、ユーザーに重複したユーザー名を持たせたい場合はどうすればよいですか？
また、私が理解していることからcassandraが>演算子をサポートしていないため、select * from users where something > something2のようなものが機能しない場合、どのように検索を行うことができますか？.
そして、おそらく最も重要な質問は、グループ化についてはどうですか？すべてのデータを取得してから、使用している言語でフィルタリングする必要がありますか？それは私のシステムをかなり遅くすると思います。
したがって、基本的に、Cassandaの使用を開始する方法について簡単に説明する必要があります。
あなたの質問は非常に一般的ですが、私はそれを突き刺します。まず、クエリの観点からデータをモデル化する必要があります。 RDBMSを使用すると、データを正規化された形式でモデル化し、後で特定のクエリ用に最適化できます。 Cassandraではこれを行うことはできません。あなたはそれを読むつもりの方法であなたのデータを書かなければなりません。多くの場合、これは複数の方法で書くことを意味します。一般に、Cassandraを効果的に使用したい場合は、RDBMSの考え方を完全に排除するのに役立ちます。
キーについて：
これらはCassandraでリング全体の分散の単位として使用されます。したがって、キーはハッシュされ、リング内の「所有者」が割り当てられます。RandomPartitionerを使用して、均等な分散を保証します。
RandomPartitionerを使用していると仮定すると（そうすべきです）、キーはソートされません。これは、キーの範囲を要求できないことを意味します。ただし、1回のクエリでキーのリストを要求することはできます。
キーは一部のモデルに関連し、他のモデルには関連しません。モデルでキーによるクエリが必要な場合は、アプリケーションが認識している任意の一意の値（UUIDなど）を使用できます。 1日の始まりを表すUnixエポックなど、キーが番兵の値である場合があります。これにより、Cassandra一連の既知のキーを渡して、列でソートされたデータの範囲を取得できます（以下を参照）。
クエリ述語について：
クエリに答えるために正しくモデル化したと仮定して、データの範囲を取得できます。
列はソートされた順序で書き込まれるため、スライスクエリを使用して列Aから列nまでの範囲をクエリできます（これは非常に高速です）。複合列を使用して、このメカニズムを少し抽象化することもできます。
カーディナリティが低い列でセカンダリインデックスを使用できます。これにより、値によるクエリ機能が提供されます。
データが必要な方法でソートされる独自のインデックスを作成できます。
グループ化について：
集計の作成について言及していると思います。リアルタイムでデータが必要な場合は、外部メカニズム（ Storm など）を使用してデータを追跡し、関連する集計をCFに絶えず更新する必要があります。バッチプロセスの一部として集計を作成する場合、CassandraはHadoopとの優れた統合を備えており、Pig、Hive、または選択した言語で直接map/reduceジョブを記述できます。
あなたの最初の質問に：
mysqlのようにインクリメンタルキーを作成できますか
いいえ、そうではありません-カサンドラ原産ではありません。 Cassandraで自動インクリメントIDを作成する方法 -詳細については、こちらを確認してください： http://srinathsview.blogspot.ch/2012/04/generate-distributed-sequence-number .html
2番目の質問は、Cassandraデータをどのように保存およびモデル化するかについてです。
Stackoverflowの検索オプションを確認してください。面白い質問がたくさん！
- MySQLからCassandra --Pros/Cons？ への切り替え
- Cassandraデータモデル
- Cassandra/NoSQL初心者：モデル化する正しい方法？
- Apache Cassandraスキーマ設計
- Apache Cassandraのナレッジソース
最も重要なことは、 Cassandraを使用しない場合は？
PlayOrmをチェックすることをお勧めします。私はあなたがRDBMSから抜け出す必要があることに同意しますが、ユーザーIDとして主キーを持つことは間違った選択である場合があると考えています。時々それは正しい選択です（あなたの要件に依存します）。
PlayOrmは、noSQLとリレーショナルの両方の概念を組み合わせたものであり、両方が必要であり、結合などを使用してスケーラブルSQLを実行できます。数十億/数兆行に成長すると思われるテーブルをパーティション化するだけで、それらのパーティションにクエリを実行できます。 CQLを使用する場合でも、テーブルをパーティション分割する必要があります。何でパーティション分割できますか？時間はいくつかのユースケースに適しています。各クライアントは実際にはnoSQLクラスター内のミニデータベースであるため、その他はクライアントによってパーティション化できます。
キーに関する限り、PlayOrmはhostname-uniqueidinThatHostである一意の「クラスター」キーを生成します。これは基本的にTimeUUIDに似ていますが、a1、a2、a3などのクラスターでホスト名を使用するため、かなり短くて読みやすくなります。