注: 少し再フォーマットを行い、追加情報を追加しました。
これを見てください: Question_Answer 質問
したい - DSE 5.0 と、今年の C* Summit で言及された 5.1 と 5.2 の今後の変更について、同じアドバイスが役に立ちますか?
私たちのユースケースは次のとおりです。
プラットフォームは常に利用可能でなければなりません。(Cassandra)
データは検索可能でなければなりません。(SOLR / Lucene)
プラットフォームは、分析 / データ ウェアハウス / BI など (Graph / Spark) を提供する必要があります。
DSE のおかげで、これらすべてが 1 つの製品で可能になります。ありがとうDataStax！
しかし、保存されているデータの量とトランザクション数は非常に控えめです。
私たちの仕様は、アプリケーション内で 100 の同時セッションを対象としています。もちろん、これは 100 の同時 DB リクエスト / 操作には変換されません。
ほとんどの場合、私たちのアプリケーションは日常のエンタープライズ CRUD アプリケーションに似ています。
ばかげているわけではありませんが、AWS インスタンスは完全に無料というわけではありません。
ワークロードごとに個別のクラスターを用意する (継続的な可用性のために十分なレプリケーションを行う) ことは、コストの問題になります。
私は理解していますが、概念実証はいくつかの助けを提供できますが、実際のワークロード/実際のユーザーがサービス/アプリケーションを通過することなく、「本番」システムと悪意のあるユーザーのみが実際に洞察を提供できる方法で提供できます。あなたができる最善のことは、「ロードされた」機能テストです。
要するに、プラットフォームの観点からは、ここで少し立ち往生しています。
地理的に分離するための 2 つのデータ センター
DC ごとに 2 つのラック ラックごとに
2 つのノード
local_quorum
の 3
CL のRF
パフォーマンスの問題が発生していることがわかった場合は、スケール アウトできます - 追加のラックを追加するか、最初の 2 つのラックに追加のノード。
V ノードやトークンの数については、わかりません。
DSE Search のドキュメントには、V ノードによって 30% のオーバーヘッドが追加されると記載されているため、V ノードを使用すべきではないように思えますが、ドキュメントの表では、16 または 32 を使用するようにも記載されています。
すべてのワークロードを 1 つのノードで正常に実行できる場合 (要件は本当に最小限です)、V ノード (16 または 32) で実行しますか、それとも単一のトークンを実行しますか?
最後に、別の代替手段はありますか？
同じデータセンターに異なるワークロードを持つノードを配置できますか? 特定のワークロードの RAM/CPU 要件を使用して個々のノードが設定されている場所は?
データセンターごとに 4 つのノードがあると仮定します (出発点としてのみ - 単一ノードで Search を正常に実行できるかどうか、または単一ノードで Spark を実行できるかどうかはわかりません)
ノード 1: Cassandraのみ
ノード 2 : Cassandra と検索
ノード 3 : Cassandra とグラフ
ノード 4 : Cassandra と Spark
検索に 64 GB の RAM が必要な場合 - それでいいのですが、Cassandra のみのノードはわずか 8 または 16 で十分に機能します
。ワークロードの種類ごとの CPU とメモリの条件 - ただし、DC は 1 つしかありません。(冗長性のために 2 つ用意しますが、実質的には単一の DC インストールです: ミラー化されます)
よろしくお願いします。