Recenctly私は、リレーショナルデータベースがスケーリングの問題を抱えており、大きなデータに関しては使いにくいという記事をオンラインで読んでいます。特にデータが大きいクラウドコンピューティングの場合しかし、なぜ私はグーグルでスケーラビリティが高くないのかについての確固たる理由を見つけることができませんでした。スケーラビリティに関してリレーショナルデータベースの限界を教えてください。リレーショナルデータベースにスケーラビリティの問題があるのはなぜですか？
ありがとうございました。
リレーショナルデータベースは、ACIDプロパティに基づいて堅実で成熟したサービスを提供します。トランザクション処理、効率的なロギング、リカバリなどを可能にします。これらは、リレーショナルDBのコアサービスであり、優れたものです。それらはカスタマイズするのが難しく、ボトルネックとみなされることがあります。特に、特定のアプリケーションでそれらを必要としない場合（たとえば、重要度の低いWebサイトコンテンツを提供する場合など）、この場合、広く使用されているMySQLはデフォルトのストレージエンジンとのトランザクション処理であり、したがってACIDを満たさない）。 「ビッグデータ」の問題の多くは、Web解析、Web検索、または移動するオブジェクトの軌跡のような厳密な制約を必要としません。
特定のコンピュータ（メモリ、CPU、ディスク：データが大きすぎる、データ処理が複雑すぎ、コストがかかる）の限界に達すると、サービスを配布することをお勧めします。多くのリレーショナルデータベースとNoSQLデータベースは分散ストレージを提供します。しかしながら、この場合、ACIDは満足することが困難であることが判明している：CAP theoremは幾分類似しており、同時に利用可能性、一貫性及びパーティション許容値を達成することができない。 ACIDをあきらめた場合（例えばBASEを満たす）、スケーラビリティが向上する可能性があります。 this投稿などを参照してください。 CAPに従ってストレージ方法を分類する。
SQL操作では、他のボトルネックは柔軟で賢明な型付きリレーショナル・モデルそのものである可能性があります。単純な操作の単純なモデルでは、型なしのキー値ストアのように十分で効率的です。一般的な行単位の物理ストレージモデルも制限されている可能性があります。たとえば、データ圧縮には最適ではありません。
しかし、リレーショナルデータベースの技術が成熟し、よく研究され、広く普及しているので、VoltDBのような新しいものを含め、高速でスケーラブルなACID準拠のリレーショナルデータベースがあります。我々は、与えられた問題に対して適切な解を選択するだけでよい。
「これらはオフにできません」それは露骨な嘘です。 DB2はジャーナリング（ロギング）をオフにすることができます（他の大きな犬のいずれかが同等の製品を持っていない場合は驚くでしょう）。そして、もしあなたがそうしたら、あなたの更新プログラムは2倍もの速さで動くかもしれません。もちろん、あなたが支払う価格は、そのような更新を実行する前にバックアップをとること、そしてプログラムが失敗した場合に復元にかかる時間です。もちろんこれは典型的には行われていませんが、「**できない**」は単に知識ではなくむしろ無知を表示するだけです。 –
はい、ここでは「できません」が強すぎるかもしれません。私はすべてのDBを知らない。ただし、たとえばOracleのnologging節を使用すると、ログ・サイズは小さくなりますが、ログ・サイズは小さくなりません。トランザクションの処理と書き込みの取り消し情報を確実にオフにすることはできません。オフにすると、DBはもはやACIDに準拠しなくなります。私が間違っている？ もう1つのボトルネック：データモデルとSQL。巧妙なアルゴリズムを備えた柔軟なモデル。多くの場合、単純な操作でより単純なモデルで十分で効率的です（型なしのキー値ストアなど）。 – csaba
最も簡単な例を考えます。生成されたIDを持つ行を挿入します。 IDはテーブル内で一意でなければならないため、データベースは何らかの永続カウンタをロックして、他のINSERTが同じ値を使用しないようにする必要があります。したがって、2つの選択肢があります。1つのインスタンスにデータを書き込むか、分散ロックを許可するかのどちらかです。両方のソリューションは大きなボトルベックです - そして最も簡単な例です！
InstagramがID生成の問題をどのように解決するかについて興味深い[read]（http://instagram-engineering.tumblr.com/post/10853187575/sharding-ids-at-instagram） – Kermit
@Tomasz、...またはちょうど異なるセットを使用する（例えば、別個のプレフィックスコードまたは異なる値の範囲を用いて）異なるインスタンスの識別子の数これはリレーショナルデータベースでは難しい問題ではありません。 – sqlvogel
@Tomasz Nurkiewicz NoSQLがこの問題をどのように扱うことができるかを知りたいだけです。それはデータモデルはこれを行うことができるのですか？ – nathan
私は人々が考えているとは思わないが、SQLの解析にはかなりのオーバーヘッドがあります。
これは、のいずれかであるのいずれかです。しかし、ほとんどのPHPアプリケーションのようなCGIスタイルのアプリケーション（短いランタイム、多くのインスタンス）では、準備された文を一度解析する必要があります。
多くの場合、データベースサーバー自体は実際には十分高速ですが、SQL解析にオーバーヘッドが発生することがあります。 Yoshinori Matsunobuは、handlerSocketを実装することに関して素晴らしいarticleを持っています。これは、MySQL + InnoDB用のnoSQLコネクタで、主キー検索のために毎秒750,000クエリを達成することができます。memcachedについて述べた〜420,000クエリよりも優れています。
2つの異なる種類の交差点を想像してください。
交通機関や警察官が交通規制しています。交差点の動きは限られています。正確にどの車が正確に交差点を走行したか、どの方向に行ったかを正確に記録するウォッチドッグがあります。
他の誰も、彼が運転している速度で交差点に到着したばかりの人はいません。できるだけ早く乗り込みたいと思っています。
前者は従来のデータベースエンジンです。クロスロードはデータそのものです。車はデータにアクセスするトランザクションです。信号機や警察官がDBMSです。ウォッチドッグはログとジャーナルを保持します。
後者はNOACIDタイプのエンジンです。
どちらも飽和点を持っています。その時点で、到着する自動車は、エントリーポイントでキューイングを開始することが強制されます。どちらも最大のスループットを備えています。その閾値は、前者のタイプのクロスロードについては低い値にあり、その理由は明らかでなければならない。
しかし、前者のタイプのクロスロードの利点も明らかであるはずです。事故が起こる機会が少なくなります。第2のタイプのクロスロードでは、交通密度がクロスロードの理論上の最大スループットよりもはるかに低い場合にのみ、事故が起こらないことが期待できます。また、データ管理エンジンの翻訳では、以前のタイプのクロスロード（リレーショナルまたはネットワークまたは階層型の古典的なデータベースエンジン）のみが提供できる一貫性のある一貫した結果が保証されます。
さらに類推することができます。事故が起こったら何が起こるか想像してみてください。2つ目のタイプの交差点では、できるだけ早く道路を清掃することが主な懸念事項であるため、交通が再開され、それが完了したら、誰が事故の原因となったのかを調査するためにまだ利用可能な情報はありますか？全く何もない。それは知られていません。クロスロードは、次の事故が起こるのを待っているだけです。規制された交差点には、起こったことを見て、証言できる交通を規制する警察官がいます。どの車が正確に何時に入ったのか、正確にどの進度でどの車に正確に入ったのかを記録するログがあり、事故の根本的な原因を突き止めるために多くの材料が検査に利用可能です。もちろん、それは無料ではありません。
説明として十分にカラフルですか？
「スケーラビリティがない」と定義します。たくさんのフィッシュとスタックオーバーフローはリレーショナルデータベースを使用しており、毎日何百万回もヒットします。 – Oded
上記の私の主張は、リレーショナルデータベースが拡張できないと言う多くの人々は、それらを効果的に使用する方法を知らない同じ人です。 – Oded
@Odedはい。私はあなたがポイントを持って参照してください。スタックオーバーフローのようなサイトでは、1日に何百万ものヒットが発生し、リレーショナルデータベースにはそれを処理する能力があります。しかし、私は自分自身を明確にしようとしています、ここで問題となるのは効率性であるか、費用などかもしれません...それは私が知りたいことです。私はちょうど開いた心を維持しようとしています;） –