注：私は少し再フォーマットして、いくつかの追加情報を追加しました。 DSE 5.0と5.1と5.2のために、今年C *サミットで述べた今後の変更で、同じアドバイスが有用であろう - 私はお願いしたいと思いますQuestion_Answer
：
はこれを見てみてください？SOLRとVノードとトークン
使用例は次のとおりです。
プラットフォームは常に利用可能でなければなりません。 （カッサンドラ）
データを検索できる必要があります。 （SOLR/Luceneの）
分析を提供しなければならないプラットフォームでは、/データウェアハウス/ BIなど（グラフ/スパーク）
ことのすべては、DSEに感謝を提供する単一の製品で可能です！ありがとう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要件を設定する場合ただ：
ノード1 - データセンターごとに私たちの4ノードを（私たちは、あなたが成功した単一ノード上で検索を実行して/または単一ノード上でスパークできるかどうかはわかりません出発点としてのみ）と仮定すると、
カサンドラ
ノード2：カサンドラと
ノード3の検索：カサンドラとグラフ
ノード4：カサンドラをして検索が64ギガバイトのRAMを必要とする場合
スパーク - ので、それをすること...しかし、うまくと仕事ができるカサンドラのみノードわずか8または16です。
ワークロードタイプごとにCPUとメモリの面では、DCは1つしかありません。 （冗長性は2ですが、効果的には単一のDCインストール：ミラーリング）
ご協力いただきありがとうございます。
WRT to RF;ラックあたり2つのノードと2つのラックがあり、合計4ノードのデータセンターを提供します。私が何かを見逃していない限り - 私は当然のことかもしれない - 3のRFがここで働くように思われる。 –
ああ、2匹のracsを逃した。 –
5.0.x（またはそれ以前）でDSE Searchでvnodeを使用する場合は、Solrフィルタキャッシュのサイズを微調整してクエリのパフォーマンスを妥当なものに保つ必要があるかもしれないことに注意してください。 （もちろん、OSS Solrキャッシュの実装ではなく、グローバルメモリの使用を制限するDSE SolrFilterCacheを使用する必要があります）。 –