Cassandraを使用しない場合
最近、 Cassandra に関連する多くの話がありました。
Twitter、Digg、Facebookなどがすべて使用しています。
次の場合に意味があります：
- cassandraを使用し、
- cassandraを使用しない
- cassandraの代わりにRDMSを使用します。
特効薬のようなものはありません。すべてが特定の問題を解決するために構築されており、独自の長所と短所があります。それはあなた次第です、あなたが持っている問題の声明とその問題に最適な解決策は何ですか。
私はあなたが質問したのと同じ順序であなたの質問に一つ一つ答えようとします。 CassandraはデータベースのNoSQLファミリに基づいているため、質問に答える前にNoSQLデータベースを使用する理由を理解することが重要です。
NoSQLを使用する理由
RDBMSの場合、このカテゴリのMySQL、Oracle、MS SQL、PostgreSQLなどのすべてのデータベースは、ACIDプロパティを指向したほぼ同じ種類のソリューションを提供するため、選択は非常に簡単です。 NoSQLに関しては、すべてのNoSQLデータベースが異なるソリューションを提供し、アプリ/システム要件に最適なソリューションを理解する必要があるため、決定が困難になります。たとえば、MongoDBは、システムでスキーマレスのドキュメントストアが必要なユースケースに適しています。 HBaseは、検索エンジン、ログデータの分析、または巨大な2次元の結合のないテーブルのスキャンが必要な場所に適しています。 Redisは、ツリー、キュー、リンクリストなどのさまざまなデータ構造のインメモリ検索を提供するように構築されており、リアルタイムリーダーボード、pub-sub系のシステムの作成に適しています。同様に、このカテゴリには他のデータベース（Cassandraを含む）があり、さまざまな問題ステートメントに適合しています。元の質問に移動して、1つずつ答えてみましょう。
Cassandraを使用する場合
NoSQLファミリーの一部であるCassandraは、要件の1つが非常に重い書き込みシステムを持つことであり、その保存されたデータの上に非常に応答性の高いレポートシステムを持ちたいという問題に対するソリューションを提供します。リクエストごとにログデータが保存されているWebアナリティクスのユースケースを考えてみてください。1時間あたり、ブラウザごと、IPごとなどのリアルタイムでヒットをカウントする分析プラットフォームを構築する必要があります。 Cassandraが適合するユースケースの詳細については、 this ブログ投稿を参照してください。
Cassandraの代わりにRDMSを使用する場合
CassandraはNoSQLデータベースに基づいており、ACIDおよびリレーショナルデータプロパティを提供しません。 ACIDプロパティ（たとえば、財務データ）に強い要件がある場合、Cassandraはその場合に適合しません。明らかに、回避策を講じることはできますが、ACIDプロパティをシミュレートするために大量のアプリケーションコードを書くことになり、市場投入までの時間を大幅に失うことになります。また、そのようなシステムをCassandraで管理するのは複雑で面倒です。
Cassandraを使用しない場合
上記の説明が理にかなっている場合、答える必要はないと思います。
分散データシステムを評価するときは、CAP定理を考慮する必要があります。一貫性、可用性、パーティション許容度の2つを選択できます。
Cassandraは、結果整合性をサポートする、使用可能なパーティショントレラントシステムです。詳細については、私が書いた次のブログ投稿を参照してください： NoSQLシステムのビジュアルガイド 。
Cassandraは特定の問題に対する答えです。1つのサーバーに収まらないほど大量のデータがある場合はどうしますか？どのようにしてすべてのデータを多くのサーバーに保存し、銀行口座を壊さず、開発者を狂わせないのですか？ Facebookは、毎日4テラバイトの新しい圧縮データを取得します。そして、この数はおそらく1年以内に2倍以上に増加するでしょう。
これほど多くのデータがない場合、またはエンタープライズOracle/DB2クラスターのインストールに数百万を支払う必要があり、そのセットアップと保守に専門家が必要な場合は、SQLデータベースで十分です。
ただし、Facebookはcassandraを使用しなくなり、MySQLを使用して、アプリケーションスタックのパーティションをほぼ排他的に移動して、パフォーマンスの向上と制御の向上を図っています。
NoSQLの一般的な考え方は、アプリケーションに最適なデータストアを使用することです。財務データのテーブルがある場合は、SQLを使用します。リレーショナルスキーマにマップするために複雑/遅いクエリを必要とするオブジェクトがある場合は、オブジェクトまたはキー/値ストアを使用します。
もちろん、実際に発生する問題は、これら2つの極端な問題の中間にあり、どちらの解決策も完璧ではありません。各ストアの機能と、他のストアを使用した結果を考慮する必要があります。これは、解決しようとしている問題に非常に固有のものです。
Cassandraを使用する場合と使用しない場合について上記の回答に加えて、Cassandraを使用することにした場合は、Cassandra自体を使用せずに、多くのいとこがいます。
上記のいくつかの答えは、Cassandraと多くのプロパティを共有するさまざまな「NoSQL」システムをすでに示していますが、多少の違いはありますが、特定のニーズに対してCassandra自体よりも優れている場合があります。
さらに、最近（この質問が最初に尋ねられてから数年後）、Cassandraクローンと呼ばれるScylla（ https://en.wikipedia.org/wiki/Scylla_（database） を参照） ） 解放された。 Scyllaは、C++でのCassandraのオープンソースの再実装であり、元のJava Cassandraよりも大幅に高いスループットと低いレイテンシを持っていると主張していますが、機能、API、およびファイル形式）。したがって、すでにCassandraを検討している場合は、Scyllaも検討することをお勧めします。
Cassandraを展開している最中に誰かと話すと、多対多をうまく処理できません。彼らは最初のテストを行うためにハックをしています。私はCassandraコンサルタントとこのことについて話しましたが、彼はあなたがこの問題を抱えていたらそれを勧めないだろうと言いました。
次の質問を自問する必要があります。
- （Volume、Velocity）膨大な量の情報を書き込み、読み取りますか？.
- （Global）世界のある部分の書き込みが世界の別の部分でアクセスできるように、世界中でこの書き込みおよび読み取り機能が必要になりますか？
- （Reliability）このデータベースは常に稼働している必要があり、どのクラウド、どの国、VM、コンテナ、またはベアメタルに関係なくダウンすることはありません？
- （Scale-ability）このデータベースを簡単に拡張し、線形に拡張できるようにする必要がありますか
- （Consistency）他の認証が必要な書き込みが非同期的に発生する可能性があるTUNABLE整合性が必要ですか？
- （スキル）このテクノロジーと、あらゆる場所で誰でも高速に実行できるグローバルに分散されたデータベースの作成に伴うデータモデリングを習得するために必要なことを実行してもよろしいですか？
これらの質問のいずれかで「多分」または「いいえ」と思った場合は、別のものを使用する必要があります。それらすべての答えとして「はい」と答えた場合は、Cassandraを使用する必要があります。
1つのボックスですべてを実行できる場合は、RDBMSを使用します。それはおそらくほとんどの人よりも簡単で、誰でも使用できます。
@Pacoバブルを崩壊させて申し訳ありませんが、特に財務データでは、トランザクションの一貫性が重要です。 Cassandraなどのデータベースで強調されているように、失敗したスクリプトは副作用を残す場合があり、1つのテーブルが更新され、別のテーブルが更新されない場合があります。一例：£100は、ユーザー1のアカウントからユーザー2のアカウントへの移動です。各アカウントに対してトランザクションが記録され、一方から削除され、もう一方に追加されたことが示されます。もちろん、それはあなたのデザインに依存します。別のシナリオでは、銀行に支払いが行われます。資金は、1つのアカウントから削除し、別のアカウントに追加する必要があります。一貫性がないと、お金がシステムから「失われ」たり、二重にカウントされたりする可能性があります。いずれにせよ、銀行は問題を抱えています。
トランザクションの一貫性がビジネスにとって重要であるようなケースが多くあります。安全で効果的な方法でアプリによって処理されるか、データベースがそれ自体を完全に処理する必要があります。後者は「安全な」オプションです。
cassandraを介した参加サポートの欠如は、適切な他のアプリが使用されない限り、その使用も制限します。その点については、トリガー機能、外部キーなどの欠如も同様です。最終的にはすべて、必要なものになります。たとえば、検索プロバイダーであり、巨大な顧客ベースがある場合は、Cassandraが最適かもしれません。 OLTP、および一部の報告ケース、または負荷量が少ない場合、要件に対する完全な不一致になる可能性があります。
ヘビーシングルクエリとガジリオンライトクエリ負荷は、ここでの他の答えに加えて、考慮すべきもう1つのポイントです。 NoSqlスタイルのDBで単一のクエリを自動的に最適化することは本質的に困難です。 MongoDBを使用していて、複雑なクエリを計算しようとしたときにパフォーマンスの問題が発生しました。 Cassandraを使用したことはありませんが、同じ問題があると予想されます。
一方、非常に多くの小さなクエリの負荷が予想され、簡単にスケールアウトできるようにしたい場合は、ほとんどのNoSql DBが提供する結果整合性を活用できます。結果整合性は、実際には非リレーショナルデータモデルの機能ではありませんが、NoSqlベースのシステムで実装およびセットアップする方がはるかに簡単です。
単一の非常に重いクエリの場合、最新のRDBMSエンジンは、クエリの一部を並列化して適切なジョブを実行し、（単一のマシン上で）大量のCPUとメモリを利用できます。 NoSqlデータベースには、大きなクエリの真にインテリジェントな並列化を可能にする仮定を立てるのに十分なデータの構造に関する情報がありません。より多くのサーバー（またはコア）を簡単にスケールアウトできますが、クエリが複雑なレベルに達すると、基本的にNoSqlエンジンがインテリジェントに処理する方法を知っている部分に手動で分割することを強制されます。
私のMongoDBでの経験では、結局、クエリが複雑であるため、Mongoが最適化して複数のデータでその一部を実行するためにできることはあまりありませんでした。 Mongoは複数のクエリを並列化します しかし、単一のクエリの最適化はあまり得意ではありません。
いくつかの実際のケースを読みましょう。
http://planetcassandra.org/Apache-cassandra-use-cases/
彼らは、MySQLを選択しなかった理由を詳しく説明しました。これは、データベースの同期が遅すぎるためです。
（2フレーズコミット、FK、PKも原因）
CassandraはAmazon Dynamoの論文に基づいています
特徴：
安定
高可用性
バックアップがうまく機能する
読み取りおよび書き込みは、HBaseよりも優れています（JavaのBigTableクローン）。
wiki http://en.wikipedia.org/wiki/Apache_Cassandra
彼らの結論は：
We looked at HBase, Dynamo, Mongo and Cassandra.
Cassandra was simply the best storage solution for the majority of our data.
2018年現在、
バックサポートが必要な場合は、ScyllaDBを使用して従来のcassandraを置き換えることをお勧めします。
Postgres kvプラグインは、cassandraよりも高速です。どのようにマルチインスタンスのスケーラビリティがありません。
選択を容易にする別の状況は、sum、min、maxなどの集約関数と複雑なクエリ（上記の金融システムのような）を使用したい場合です。その後、両方ともnosqlデータベースよりもリレーショナルデータベースのほうがおそらく便利です。本当に多くの逆索引を使用しない限り、nosqlデータベースでは不可能です。 nosqlを使用する場合は、コード内で集計関数を実行するか、独自のcolumnfamilyに個別に格納する必要がありますが、これによりすべてが非常に複雑になり、nosqlを使用して得られるパフォーマンスが低下します。
ここでは、Cassandraが本当に必要かどうかを判断するのに役立つ重要な側面に焦点を当てます。このリストは網羅的なものではなく、頭に浮かんだいくつかのポイントだけです。
（データセット全体で）関係に厳しい要件がある場合は、Cassandraを最初の選択肢と見なさないでください。
Cassandraはデフォルトで（CAPの）APシステムです。ただし、調整可能な一貫性をサポートしているため、CPとしてもサポートするように構成できます。 だから、それがAPでありCPシステムを探しているということを読んだからといって無視しないでください。 Cassandraはより正確に「調整可能な一貫性」と呼ばれます。可用性のレベルとのバランスで、必要な一貫性のレベルを簡単に決定できます。
規模がそれほど大きくない場合、または非分散DBを扱うことができる場合は、Cassandraを使用しないでください。
Cassandraのような分散DBを使用すると、すべての問題が解決されるとチームが考えている場合は、より深く考えてください。これらのDBを開始するには、多くのデフォルトが用意されているため非常に簡単ですが、特定の問題を解決するために最適化してマスターするには、かなりの量のエンジニアリング作業が必要になります。
Cassandraは列指向ですが、同時に各行にも一意のキーがあります。そのため、インデックス付きの行指向ストアと考えると役立つ場合があります。 ドキュメントストアとして使用することもできます。
Cassandraは、事前にフィールドを定義することを強制しません。そのため、スタートアップモードの場合、または機能が（アジャイルのように）進化している場合-Cassandraはそれを受け入れます。 最初にクエリについて考え、次にそれらに答えるためにデータについて考えてください。
Cassandraは、書き込みのスループットが非常に高くなるように最適化されています。 ユースケースが（キャッシュのように）読み取りが多い場合、Cassandraは理想的な選択ではないかもしれません。
Cassandraは次の場合に適しています。
DBのACIDプロパティは必要ありません。
DBには大量の書き込みがあります。
ビッグデータ、Hadoop、Hive、およびSparkと統合するための要件があります。
リアルタイムのデータ分析とレポート生成が必要です。
印象的なフォールトトレラントメカニズムの要件があります。
均質システムの要件があります。
チューニングには多くのカスタマイズが必要です。
SQLセマンティクスを備えた完全に一貫したデータベースが必要な場合、Cassandraはあなたのためのソリューションではありません。 Cassandraは、キーと値のルックアップをサポートします。 SQLクエリはサポートしていません。 Cassandraのデータは「結果的に一貫性があります」。データの同時ルックアップは一貫していない場合がありますが、最終的にルックアップは一貫しています。
厳密なセマンティクスが必要で、SQLクエリのサポートが必要な場合は、MySQL、PostGresなどの別のソリューションを選択するか、CassandraをSolrと組み合わせて使用します。
- テーブル全体の完全なトランザクション管理はサポートしていません。
- セカンダリインデックスはサポートされていません。
- セカンダリインデックスをElastic search/Solrに依存する必要があり、カスタム同期コンポーネントを作成する必要があります。
- ACIDに準拠していないシステム。
- クエリのサポートは制限されています。
Apache cassandraは、多くのコモディティサーバー全体で大量の構造化データを管理するための分散データベースであり、可用性の高いサービスを提供し、単一障害点はありません。
アーキテクチャは、純粋にキャップの定理、つまり可用性とパーティション許容度に基づいており、興味深いことに一貫性があります。
クラスターのラック全体に大量のデータを保存しない場合は使用しないでください。時系列データを保存しない場合は使用しないでください。サーバーにパーティションを作成しない場合は使用しないでください。強い整合性が必要な場合は使用しないでください。
Mongodbには、非常に強力な集約関数と表現力豊かな集約フレームワークがあります。開発者がリレーショナルデータベースの世界から使用することに慣れている多くの機能を備えています。たとえば、ドキュメントデータ/ストレージ構造により、Cassandraよりも複雑なデータモデルが可能になります。
もちろん、これにはトレードオフが伴います。したがって、データベース（NoSQL、NewSQL、またはRDBMS）を選択するときは、解決しようとしている問題とスケーラビリティのニーズを確認してください。すべてのことを行うデータベースはありません。
DataStaxによると、Cassandraは、
1-ハイエンドハードウェアデバイス。 2- ACID準拠、ロールバックなし（銀行取引）