Fixstars は最近、Cassandra と GridDB の比較のため、Microsoft Azure 上で 1,8,16,32 ノードのクラスタと同じ数の YCSB クライアントを使い、インメモリーデータセット(ノードあたり 4M レコード)とメモリーに乗り切らないデータセット(ノード当たり 12M レコード)を使ったベンチマークを実行しました。
次のグラフに示すように、インメモリー指向の GridDB のハイブリッド・ストレージ・アーキテクチャーは、インメモリーと、メモリー外のストレージを必要とするオペレーションの両方において Cassandra を上回ります。GridDB はこれを達成しながら、24 時間連続動作中も変わらず信頼性と一貫性を維持します。
GridDB のノード間通信は、少なくとも 32 ノードまでは Cassandra の分散型ピアツーピアシステムよりも大幅に優れています。GridDB のパフォーマンスは、追加されたノードの数とほぼ同じ程度に向上します。その点 Cassandra は、この特定の Azure インスタンスタイプにおいて、同じ要素の 50% でしか向上しません。
ワークロード A のような更新集中型のワークロードでは、ログベースのアーキテクチャでロウをすばやく削除済みとしてマークし、ログの最後に新しい値を追加できるため、Cassandra の初期結果は非常に有利です。しかし Fixstars は、Cassandra が時間が経つにつれて減速し始めたことに気づきました。
Fixstars は、8 ノードのクラスタを構成し、ノードあたり 4M と 12M のレコードをロードし、operationcount を 2^32-1 に設定し、24 時間にわたってテストを実行しました。その結果どちらのテストにおいても、Cassandra の 24 時間目のスループットは、最初の 1 時間目の 50% 以下でした。一方、GridDB のパフォーマンスは、インメモリ操作の実行中とメモリー外操作の実行中の両方において安定していました。
ブログの内容について疑問や質問がある場合は Q&A サイトである Stack Overflow に質問を投稿しましょう。 GridDB 開発者やエンジニアから速やかな回答が得られるようにするためにも "griddb" タグをつけることをお忘れなく。 https://stackoverflow.com/questions/ask?tags=griddb