ElasticSearch を使用して Cassandra データベースのインデックスを作成する予定です。ElasticSearch の実際的な限界を見た人がいるかどうか疑問に思っています。ペタバイトの範囲で物事は遅くなりますか? また、ElasticSearch を使用して Cassandra のインデックスを作成する際に問題が発生した人はいますか?
4 に答える
2011 年のこのスレッドを参照してください。このスレッドでは、それぞれ 200 GB の 1700 シャードを持つ ElasticSearch 構成について言及されており、これは 1/3 ペタバイトの範囲になります。各シャード インデックスは他のすべてのシャードとは別個に機能するため、ElasticSearch のアーキテクチャはほぼ無限の水平方向のスケーラビリティをサポートすると予想されます。
実際の制限 (他のソリューションにも適用されます) には、最初に大量のデータを実際にロードするのに必要な時間が含まれます。そのサイズの Cassandra クラスター (またはその他の分散データストア) を管理するには、メンテナンスや負荷分散などのためだけにかなりの作業負荷がかかります。
ソニアンは、そのスレッドでキムチがほのめかしている会社です。AWS では、複数の ES クラスターにわたって 1 ペタバイトを超えています。ES をどこまで水平方向にスケーリングできるかについて技術的な制限はありませんが、DNA が述べたように、実際的な問題があります。最大のものはネットワークです。これは、すべての分散データ ストレージに適用されます。一度にワイヤーを横切って移動できる量は限られています。ES が障害から回復する必要がある場合、データを移動する必要があります。最良のオプションは、より多くのノードでより小さなシャードを使用すること (より多くの同時転送) ですが、失敗率が高くなり、バイトあたりの法外なコストが発生するリスクがあります。