最近、Cassandra と DataStax が CQL3 をさらに推進していることに気付きました。新しい Java ドライバーもリリースされましたが、これは Thrift をまったく使用していません。また、「コンパクト ストレージ」を使用しない場合、アプリケーションで Thrift を使用することはできません。したがって、Thrift は Cassandra からフェードアウトしていると思います。
私の質問は、新しいアプリケーションの場合、CQL3 を使用する必要がありますか? しかし、私は今でも倹約を好みます。なぜなら、その下で何が起こっているのかを知りたいからです。一方で、衰退して遺産になりつつあるものを使いたくないからです。おすすめは何ですか？
私の会社は最近、同じ思考プロセスを経て、倹約よりも CQL3 を使用することになりました。
CQL3 で行われている追加の抽象化レイヤーにより、透明性がわずかに欠けていますが、SQL スタイルのステートメントを書きやすく親しみやすいため、コードがはるかに読みやすく、直感的になっていると思います。さらに、cqlsh インターフェイスは、デバッグや一般的なデータベース メンテナンスに関して、cassandra-cli よりもはるかにユーザー フレンドリーであることがわかりました (cqlsh のオートコンプリート機能は素晴らしいです!)。
基礎となるデータ構造と CQL3 がそのデータをどのように表現するかを理解すると、抽象化の余分なレイヤーは実際には取るに足らないものになります。
Datastax は、開発者が新しいアプリケーションに cql3 を使用することを奨励しています。Thrift to CQL3 Guideから:
…CQL3 は、thrift API よりもシンプルで全体的に優れた Cassandra の API であると考えています。したがって、新しいプロジェクト/アプリケーションでは CQL3 を使用することをお勧めします (ただし、CQL3 はまだ最終版ではないため、このステートメントは Cassandra 1.2 でのみ完全に有効になります)。しかし、thrift API はどこにも行きません。
Thrift に新しい機能が追加されることはありません (多くのリクエストがない限り) ので、新しいアプリには CQL3 の方が適していると言っても過言ではありません (もちろん、例外もあります…低レベルが必要な場合は、thrift が必要です)。私の唯一の苦痛は、datastax のドライバーがまだ SSL をサポートしていないことですが、それはパイプラインにあり、うまくいけばすぐにコミットされた機能になるでしょう。