バックエンド システムの負荷の処理に問題がある大企業で働いています。古いレガシー システム/データベースを置き換え、水平方向にスケーラブルな NoSQL データベースに置き換えることを検討しています。NoSQL データベースを検討する理由は、水平方向にスケーラブルなソリューションを使用して将来に備えるためです。
分散型 NoSQL データベースは通常、結果整合性のみを提供します。これがどの程度の問題なのかはまだ調査されていません。この場合、書き込み操作が比較的少なく、読み取り操作が多く、可用性が重要なシステムを扱っています。
非常に多くの NoSQL データベース システム (cassandra、mongoDB、hbase など) があります。どのデータベースシステムがどの場合に適しているかについてのガイドラインや文献はありますか? また、不整合の問題が発生する可能性と、この可能性を減らす方法とコストについても考えています。
文献への情報/ヒント/参照は大歓迎です。
そこにはたくさんの情報があります...Googleはあなたの友達です:)
カサンドラを強くお勧めします。セットアップはかなり簡単で、マスターレス + フォールト トレラントです。データベースごとに必要なレプリケーションの量を指定でき、それが処理されます。また、クロス データ センター レプリケーションも実行できます。調整可能な一貫性があります。必要に応じて、データの特定のビットについて、完全な一貫性を実現できます (たとえば、書き込み中の可用性を犠牲にします)。そのため、必ずしもオールオアナッシングのシナリオではありません。これにはスキーマの概念があり、主キーを持つ行としてテーブルにデータを格納します。これには、SQL に非常になじみのあるクエリ言語 CQL があります (ただし、はるかに制限されています)。親しみやすさ、スキーマ、パフォーマンス、調整可能な一貫性....非常に素晴らしい組み合わせです。
欠点があります。結合はありません。そのため、データ モデリングにもう少し集中し、リアルタイム作業に必要なクエリの種類を知る必要があります。概念的なデータ モデルは、実際の物理的なデータ モデルとは異なる可能性があります。非正規化された物理テーブルのコピーとして、一部の情報 (概念データなど) が存在する可能性があります。これにより、パフォーマンスが非常に高速になりますが、データを少し理解する必要があります。
分析クエリの場合、通常は Spark と組み合わせます。これにより、Hadoop と同様に、データ セットに対してクエリを実行できます。クエリはリアルタイムのものよりも遅くなりますが、総データ量とクエリの柔軟性のバランスが取れています。
Cassandra 自体は全文検索エンジンにはなりません。ただし、Lucene や Solr と組み合わせて検索機能を提供することも珍しくありません。
ユースケースに関しては、Cassandra はさまざまな形で使用できます。最も単純に言えば、各値が順序付けられたキーと値のペアのコレクションであるキーと値のストアです。最上位のキー値は、データのパーティション (シャード) を提供します。これにより、時系列データを非常に効率的に保存できます。「値」は、セット、マップ、およびリストのコレクション列もサポートしており、これらに「完全一致インデックス」を設定できます。これらにより、より柔軟なクエリが可能になります。これらの機能は、Cassandra がさまざまなユースケースに使用できることを意味しますが、明らかにすべてではありません。それは、解決しようとしているユースケースに大きく依存します。単一の「最高の NOSQL」データベースは存在しません。各データ ストアには一連のユース ケースがある傾向があり、すべてのマッピングを一覧表示することは困難です。代わりに、あなたの