ポジティブな点について始めましょう。 前にも言ったように、C *はUrの主なタスクに対応しています。 これは、高速記録、スケーラビリティ、フォールトトレランスのために作成されたもので、おそらくこれが最高です。私はまだ単純なクラスター管理に遭遇したことがなく、この間ずっと失敗しませんでした。 ただし、C *の最大の問題は、ドキュメントから見える範囲よりもスコープがはるかに狭いことです。 そして、その理由をポイントごとに説明します。
CQLはSQLではありません
正直なところ、C *開発者がCQLを作成することにした理由はわかりません。 それは混乱し、見当識を失い、C *の詳細について誤った印象を与えます。 以下にいくつかの事実を示します。
- CQLがすべての新規参入者にもたらす主な誤解は、あらゆる種類の選択を行えるという幻想です。 そうではありません。 C *はキーと値のストレージです。 テーブル内の行のサブセットを取得することはできません。 1つ（キーによる）、またはすべて。 この制限を回避するために、C *には「幅の広い行」-任意の列を文字列に書き込む機能があります（スキームの独立性、行ごとに最大20億の一意の列）。 ただし、これはデータモデルの計画に対する特別なアプローチでのみ節約できます。
- CQLは、PRIMARY KEY内のパーティションキーとクラスターキーの概念を導入します。 このデータベースの動作原理におけるもう1つの大きな誤解。 実際、C *の文字列はパーティション部分のみで定義されます。 クラスターキーが異なるすべての「レコード」は、同じ行内に次々と単純に収まります。
- 複合パーティションキーはありません。 複合キーの動作を理解する最も簡単な方法は、キーフィールドの値が保存される前に連結されることを想像することです。 また、文字列は、キーの完全な値によってのみ取得できます（たとえば、redisなど）。
- C *のINSERTとUPDATEはまったく同じです。 これからもずっとずっと。
- CQLのコレクションは単なる構文上の砂糖であり、それらのエントリは別々の列に格納されます。
- セカンダリインデックスも単なる構文糖です。 C *は、セカンダリインデックスごとに新しいキーファミリ（テーブル）を作成し、そこにエントリを複製します。
どうやら、CQLは、このデータベースの作業で最も重要な基本概念を隠そうとして、初心者にこのデータベースを普及させるために作成されました。
データ設計機能
C *でデータを設計する際の主な原則は、「SELECT駆動型モデル」です。 後でSELECTを使用して取得できるようにデータを設計します。 キーと値の広い行のリポジトリ内では、これは非常に強力な非正規化を意味します。 リレーショナルデータベースで使用していたように、データを非正規化するだけではなく、 実際にはクエリごとに個別のテーブルを作成します 。 また、多くのプロジェクト（ボリュームごとに大量のデータがある）では、これにより、マップ/削減および集約中に大きなオーバーヘッドが発生するか、保存されるデータ量に関して大きなオーバーヘッドが発生します。
そして、はい、分散集約（Hadoop、Spark、Hiveなど）がなければ、このデータベースは役に立たないという事実にすぐに備える必要があります。 開発者は、CQLでのデータ集約のために次のバージョンのオペレーターを約束しますが、実際にそれらに依存することはできません。 このデータベースのアーキテクチャにより、1つの行内でのみ機能することは明らかです。
カウンター
私はこのデータベースのこのタイプのデータに独自のセクションを設けています。そのため、最初に、プロジェクトにC *を実装し始めたとき、私は非常に満足していました：Webアナリティクスの場合、アトミックカウンターを持つことは非常にクールで、システムを大幅に簡素化します。 しかし、それから私は簡単な真実を理解しました。 C *でカウンターを使用しないでください（少なくとも2.1より前のバージョンでは*包括的）。 実際、このデータ型はこのデータベースのイデオロギー全体と矛盾しており、このために膨大な数の問題があります。 C *スペシャリストにカウンターについて尋ねると、彼はそれに応じて悪質に笑い始めます。
要するに：
- カウンターのある行にカウンター以外の値を入れることはできません
- コレクションにカウンターを配置することはできません（上記の理由により）
- もちろん、クラスターとパーティションキーカウンターを作成し（上記の理由により）、それらを並べ替えてセカンダリインデックスを配置することもできません。
- カウンターをTime To Liveに設定することはできません
- カウンターにはレプリケーションに関する問題があります（まれに、しかし適切に）
- カウンタを削除すると、長い間、再作成できなくなります。
カウンターのイデオロギーとデータベース自体の不一致の本質は、C *のすべての操作がdem等であるということです（つまり、操作を再適用しても結果は変わりません）。 これは、ノード、データセンター、通信の問題などが落ちたときにフェイルセーフアーキテクチャを提供するものです。 カウンターはこの原則に違反しており、内部は「軽いトランザクション」によって作成されます。最初に値を検討してから、値を増やします。 そして、それは多くの問題を引き起こします。 一般に、カウンターが必要な場合は、Redis-layerを使用することをお勧めします。C*では、すでに最終値を追加しています。
今のところすべてです。 ツールを賢く選択してください。 何かが本当であるには余りにもよいようである場合、多分それは本当です。