nosql - 従来の RDBMS での水平スケーリング

Question

私は、天からの利点をすべて備えた NoSQL システムに出くわしました。それらの 1 つは、楽な水平方向のスケーリングのようです。私の質問は、MySQL や SQL Server のような古典的な RDBMS が水平方向のスケーリングに対応していないのはなぜですか? または、NoSQL システムと同程度にそれを行うことができませんか?

Answer 1

@joews とは別のスタブを使用します。

一部のシナリオでは、全文検索が必要です。または、大量のキー値データを保存します。たとえば、Lucene などの一部の NoSQL システムには、並行してスキャンできるいくつかのタイプのインデックスがあります (考えてみてください)。一度に 1 つのインデックスを使用する従来の RDBMS 検索では、高価な全テーブル スキャンがデフォルトで使用される場合もあります。

Facebook などの一部の企業は、ライブ コンテンツを提供するために MySQL インスタンスをシャーディングしています。しかし、これを可能にするには、MySQL のソース コードを変更したり、その上にシステムを構築したりする必要があるかもしれません。あなたはこれの準備ができていますか？

他のユース ケースではデータが非常に多く、従来の RDBMS のクエリ モデルには適合しません。これが、Dremel、Apache Drill、Presto などのあらゆる種類のシステムが登場する理由です。

とはいえ、NoSQL システムは、有名な CAP 定理に対処する方法に応じてバケットにグループ化されるという事実を思い出してください。私の好みの最も簡単な説明は、Martin Fowler によるものです。分散システムのネットワーク パーティショニングが存在する場合、データの一貫性 (システムとのさまざまなユーザー インタラクション間の競合がないこと) またはシステムの可用性 (システムが検索可能であるか、データが受け入れられる) のいずれかを保証できます。など）。Martin による NoSQL の紹介を見ることを強くお勧めします: http://www.youtube.com/watch?v=qI_g07C_Q5I

対照的に、RDBMS はトランザクショナルです。つまり、ATM マシンのようにすべての機能を提供するか、まったく機能を提供しません。あなたのユースケースと使用量/データ量で許容できるものであれば、それを使用してください! そうでない場合は、NoSQL に目を向けますが、状況を調べて最適なオプションを見つけてください。

Answer 2

水平方向のスケーリングには 2 つの視点があります。

1) データが多すぎて、単一の RDBMS ノードでは余裕がない => シャーディング

2) 多くの同時ユーザーにスケールしたい => レプリケーション

ケース1)は従来のJOINが動かないので難しい

ケース 2) はそれほど難しくありません。クラスタリング オプションがあるか、JTA を使用して Java で独自の「クラスタリング」アプローチを作成できます。この記事を参照してください。これはJEPLayerに基づいていますが、代わりに他の永続的な ORM を使用できます。

もちろん、あなたの問題は1）と2）の合計である可能性があります