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は、非常に重い書き込みシステムが必要であり、その格納されたデータの上に非常に応答性の高いレポートシステムが必要な場合の問題に対するソリューションを提供します。リクエストごとにログデータが保存され、ブラウザ、IPなどによって1時間あたりのヒット数をリアルタイムでカウントする分析プラットフォームを構築するWeb分析の使用例を検討してください。このブログ投稿を参照すると、Cassandraが適合するユースケースの詳細を理解できます。

Cassandraの代わりにRDMSを使用する場合

CassandraはNoSQLデータベースに基づいており、ACIDおよびリレーショナルデータプロパティを提供しません。ACIDプロパティ（財務データなど）に対する強い要件がある場合、Cassandraはその場合には適合しません。明らかに、その回避策を講じることができますが、最終的には、ACIDプロパティをシミュレートするための大量のアプリケーションコードを作成することになり、市場投入までの時間を大幅に失うことになります。また、Cassandraでそのようなシステムを管理することは、複雑で退屈な作業になります。

Cassandraを使用しない場合

上記の説明が理にかなっている場合、答える必要はないと思います。

分散データシステムを評価するときは、CAPの定理を考慮する必要があります。一貫性、可用性、およびパーティションの許容範囲の2つを選択できます。

Cassandraは、結果整合性をサポートする、使用可能なパーティショントレラントシステムです。詳細については、私が作成したこのブログ投稿「Visual SQL to NoSQL Systems」を参照してください。

Cassandraは特定の問題に対する答えです。1つのサーバーに収まらないほど大量のデータがある場合はどうしますか？どのようにしてすべてのデータを多くのサーバーに保存し、銀行口座を破らず、開発者を狂気にしないのですか？Facebookは毎日4テラバイトの新しい圧縮データを取得しています。そして、この数は、おそらく1年以内に2回以上増加するでしょう。

これほど多くのデータがない場合、またはエンタープライズOracle / DB2クラスターのインストールに数百万ドルを支払う必要があり、それをセットアップして維持するのに必要な専門家がいる場合は、SQLデータベースで問題ありません。

しかし、Facebookはもはやcassandraを使用せず、MySQLを使用して、パフォーマンスを高速化し、制御を向上させるために、アプリケーションスタック内のパーティションをほぼ排他的に移動します。

NoSQLの一般的な考え方は、アプリケーションに最適なデータストアを使用することです。財務データのテーブルがある場合は、SQLを使用します。リレーショナルスキーマにマップするために複雑なクエリや遅いクエリが必要になるオブジェクトがある場合は、オブジェクトまたはキー/値ストアを使用します。

もちろん、あなたが遭遇する現実世界の問題のほとんどは、これら2つの両極端の間のどこかにあり、どちらのソリューションも完璧ではありません。各ストアの機能と、一方をもう一方に使用した場合の影響を考慮する必要があります。これは、解決しようとしている問題に非常に特有です。

Cassandraを使用する場合と使用しない場合についての上記の回答に加えて、Cassandraを使用する場合は、Cassandra自体を使用しないことを検討してください。

上記のいくつかの回答は、Cassandraと多くのプロパティを共有するさまざまな「NoSQL」システムをすでに指摘しており、多少の違いはありますが、特定のニーズにはCassandra自体よりも優れている可能性があります。

さらに、最近（この質問が最初に尋ねられてから数年後）、Scylla（https://en.wikipedia.org/wiki/Scylla_ (database）を参照）と呼ばれるCassandraクローンがリリースされました。ScyllaはC ++でのCassandraのオープンソースの再実装です。Cassandraは、元のJava Cassandraよりもスループットが大幅に高く、レイテンシが低いと主張していますが、（機能、API、およびファイル形式において）ほとんど互換性があります。したがって、すでにCassandraを検討している場合は、Scyllaも検討することをお勧めします。

Cassandraをデプロイしている最中に誰かと話していると、多対多をうまく処理できません。彼らは最初のテストを行うためにハックの仕事をしています。私はこれについてカサンドラのコンサルタントと話しました、そしてあなたがこの問題を抱えていたらそれを勧めないと彼は言った。

あなたは自分に次の質問をするべきです：

1. （ボリューム、速度）大量の情報を書き込んだり読み取ったりすることになるため、1台のコンピューターで書き込みを処理できないほどの情報。
2. （グローバル）世界のある部分での書き込みに世界の別の部分でアクセスできるように、世界中でこの書き込みおよび読み取り機能が必要ですか？
3. （信頼性）このデータベースが常に稼働している必要があり、どのクラウド、どの国、それがVM、コンテナー、またはベアメタルであるかに関わらず、決してダウンしないようにしますか？
4. （拡張性）このデータベースは、簡単に成長し続け、線形に拡張できるようにする必要がありますか？
5. （一貫性）一部の書き込みが非同期で発生し、他の書き込みが認証される必要がある場合、TUNABLEの一貫性が必要ですか？
6. （スキル）このテクノロジーと、誰でもどこでも高速で実行できるグローバルに分散されたデータベースの作成に伴うデータモデリングを学習するために必要なことを実行しますか？

これらの質問のいずれかについて「たぶん」または「いいえ」と思った場合は、別の何かを使用する必要があります。それらすべてに対する答えとして「地獄はい」があった場合は、Cassandraを使用する必要があります。

1つのボックスですべてを実行できる場合は、RDBMSを使用します。それはおそらくほとんどの人よりも簡単で、だれでもそれを扱うことができます。

ここで他の回答に加えて、重い単一クエリとgazillion軽いクエリ負荷は、考慮すべきもう1つのポイントです。NoSqlスタイルのDBで単一のクエリを自動的に最適化することは本質的に困難です。私はMongoDBを使用していて、複雑なクエリを計算しようとしたときにパフォーマンスの問題に遭遇しました。私はCassandraを使用していませんが、同じ問題があると思います。

一方、負荷が非常に多くの小さなクエリの負荷であることが予想され、簡単にスケールアウトできるようにしたい場合は、ほとんどのNoSql DBが提供する結果整合性を利用できます。結果整合性は実際には非リレーショナルデータモデルの機能ではありませんが、NoSqlベースのシステムで実装および設定する方がはるかに簡単です。

単一の非常に重いクエリの場合、最新のRDBMSエンジンは、クエリの一部を並列化してまともなジョブを実行し、（単一のマシンで）クエリに投入したのと同じだけのCPUとメモリを利用できます。NoSqlデータベースには、大きなクエリの真にインテリジェントな並列化を可能にする仮定を立てるために、データの構造に関する十分な情報がありません。これらを使用すると、より多くのサーバー（またはコア）を簡単にスケールアウトできますが、クエリが複雑度レベルに達すると、NoSqlエンジンがインテリジェントに処理する方法を知っている部分に手動で分割する必要があります。

MongoDBでの私の経験では、最終的にはクエリが複雑なため、Mongoがクエリを最適化して複数のデータでその一部を実行するためにできることはほとんどありませんでした。Mongoは複数のクエリを並列化しますが、単一のクエリの最適化はあまり得意ではありません。

実際のケースをいくつか読んでみましょう。

http://planetcassandra.org/apache-cassandra-use-cases/

この記事の内容：http : //planetcassandra.org/blog/post/agentis-energy-stores-over-15-billion-records-of-time-series-usage-data-in-apache-cassandra

MySqlを選択しなかった理由は、dbの同期が遅すぎるためです。

（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を使用してクラシックカサンドラを置き換えることをお勧めします。

Postgres kvプラグインは、cassandraよりも高速です。マルチインスタンスのスケーラビリティがありません。

ここでは、Cassandraが本当に必要かどうかを判断するのに役立つ重要な側面のいくつかに焦点を当てます。リストは完全ではありませんが、私が頭に浮かんだポイントのいくつかだけです-

• （データセット全体の）関係に厳しい要件がある場合は、Cassandraを最初の選択肢と見なさないでください。

• Cassandraはデフォルトで（CAPの）APシステムです。ただし、調整可能な整合性をサポートしているため、CPとしてもサポートするように構成できます。したがって、APであるとどこかで読んでいて、CPシステムを探しているという理由だけで、それを無視しないでください。Cassandraは、より正確には「調整可能な一貫性」と呼ばれます。つまり、必要な一貫性のレベルを、可用性のレベルとバランスよく簡単に決定できます。

• 規模があまり大きくない場合、または分散していないDBを処理できる場合は、Cassandraを使用しないでください。

• Cassandraのような分散DBを使用すれば、すべての問題が解決されるとチームが考えている場合は、より深く考えてください。これらのDBには多くのデフォルトが付属しているため、最初は非常に簡単ですが、特定の問題を解決するために最適化して習得するには、かなりの量のエンジニアリング作業が必要です。

• Cassandraは列指向ですが、同時に各行には一意のキーもあります。したがって、それをインデックス付きの行指向のストアと考えると役立つ場合があります。ドキュメントストアとしても使用できます。

• Cassandraは、事前にフィールドを定義することを強制しません。したがって、起動モードであるか、機能が進化している場合（アジャイルなど）-Cassandraはそれを採用しています。より良いのは、まずクエリについて考え、次にそれらに答えるためのデータについて考えます。

• Cassandraは、書き込みで本当に高いスループットが得られるように最適化されています。ユースケースが（キャッシュのように）読み取りが多い場合、Cassandraは理想的な選択肢ではない可能性があります。

選択を容易にするもう1つの状況は、合計、最小、最大などの集約関数と複雑なクエリ（上記の金融システムなど）を使用する場合です。リレーショナルデータベースの方が、おそらくnosqlデータベースよりも便利です。実際に多くの反転インデックスを使用しない限り、nosqlデータベースでは不可能です。nosqlを使用する場合、集計関数をコードで実行するか、独自の列ファミリーに個別に格納する必要がありますが、これによりすべてが非常に複雑になり、nosqlを使用することで得られるパフォーマンスが低下します。

SQLセマンティクスで完全に一貫したデータベースが必要な場合、Cassandraはソリューションではありません。Cassandraはキーと値のルックアップをサポートしています。SQLクエリはサポートしていません。Cassandraのデータは「結果的に整合性があります」。データの同時ルックアップには一貫性がない場合がありますが、最終的にはルックアップに一貫性があります。

厳密なセマンティクスが必要で、SQLクエリのサポートが必要な場合は、MySQL、PostGresなどの別のソリューションを選択するか、CassandraとSolrを組み合わせて使用​​します。

Cassandraは、次の場合に適しています。

1. DBからのACIDプロパティは必要ありません。

2. DBには膨大な数の書き込みがあります。

3. ビッグデータ、Hadoop、Hive、Sparkと統合する必要があります。

4. リアルタイムのデータ分析とレポート生成が必要です。

5. 印象的なフォールトトレラントメカニズムの要件があります。

6. 均質なシステムの要件があります。

7. チューニングには多くのカスタマイズが必要です。

Mongodbには非常に強力な集約関数と表現力豊かな集約フレームワークがあります。リレーショナルデータベースの世界で開発者が慣れている機能の多くを備えています。たとえば、ドキュメントデータ/ストレージ構造により、Cassandraよりも複雑なデータモデルが可能になります。

もちろんこれにはトレードオフが伴います。したがって、データベース（NoSQL、NewSQL、またはRDBMS）を選択するときは、解決しようとしている問題と、スケーラビリティーのニーズを確認してください。1つのデータベースですべてを行うことはできません。

DataStaxによると、Cassandraは、

1-ハイエンドハードウェアデバイス。2-ロールバックなしのACID準拠（銀行取引）

• テーブル全体の完全なトランザクション管理はサポートしていません。
• セカンダリインデックスはサポートされていません。
• セカンダリインデックスはElastic search / Solrに依存する必要があり、カスタム同期コンポーネントを作成する必要があります。
• ACID準拠システムではありません。
• クエリのサポートは制限されています。

Apache cassandraは、高可用性サービスを提供し、単一障害点をなくしながら、多くの汎用サーバーにわたって大量の構造化データを管理するための分散データベースです。

アーキテクチャは、純粋に可用性と分割許容度であるキャップ定理に純粋に基づいており、興味深いことに結果的に一貫しています。

クラスタのラック全体に大量のデータを保存しない場合は使用しないでください。時系列データを保存しない場合は使用しないでください。サーバーにパティションを適用しない場合は使用しないでください。強い整合性が必要な場合は使用しないでください。