database - リレーショナル データベースにスケーラビリティの問題があるのはなぜですか?

Question

最近、リレーショナル データベースにはスケーリングの問題があり、ビッグ データに関しては使用に適していないことを示す記事をオンラインで読みました。特に、データが大きいクラウド コンピューティングでは。しかし、グーグルで調べても、スケーラブルではない理由を明確に見つけることができませんでした。スケーラビリティに関するリレーショナル データベースの制限について説明していただけますか?

ありがとう。

Answer 1

2 種類の交差点を想像してください。

信号機や警察官が交通を規制し、交差点では速度が制限されており、交差点でどの車がいつ、どの方向に進んだかを正確に記録するウォッチドッグがあります。

他の人にはそれがなく、交差点に到着した人は誰でも、運転している速度に関係なく、ただ飛び込み、できるだけ早く通過したいと考えています.

前者は従来のデータベース エンジンです。交差点はデータそのものです。車は、データにアクセスしたいトランザクションです。信号機や警察官が DBMS です。ウォッチドッグはログとジャーナルを保持します。

後者はNOACIDタイプのエンジンです。

どちらにも飽和点があり、その時点で到着した車は入り口で列を作り始めることを余儀なくされます。どちらも最大のスループットを持っています。そのしきい値は、前者のタイプの交差点ではより低い値にあり、その理由は明らかです。

ただし、前者のタイプのクロスロードの利点も明らかです。事故の可能性がぐっと減ります。2 番目のタイプの交差点では、交通密度が交差点の理論上の最大スループットよりもはるかに低いポイントにある場合にのみ、事故が発生しないことが期待できます。そして、データ管理エンジンに変換すると、一貫性のある首尾一貫した結果の保証に変換されます。これは、以前のタイプの交差点 (リレーショナル、ネットワーク化、または階層化された従来のデータベース エンジン) のみが提供できるものです。

このアナロジーはさらに拡張できます。もし事故が起きたらどうなるか想像してみてください。2 番目のタイプの交差点では、交通を再開できるように、できるだけ早く道路を片付けることが主な関心事であり、それが完了したときに、誰がどのように事故を引き起こしたのかを調査するためにまだ利用できる情報は何ですか? 何もありません。それは知られていないでしょう。次の事故が起こるのを待っているだけで交差点が開いています。規制された交差点では、何が起こったのかを見て証言できる、交通を規制している警察官がいます。どの車が正確に何時に侵入したか、正確にどの進入地点に正確にどの速度で侵入したかを示すログがあり、事故の根本原因を特定するための検査に利用できる多くの資料があります。しかしもちろん、それは無料ではありません。

説明として十分にカラフルですか？

Answer 2

リレーショナル データベースは、 ACIDの特性に従って、堅固で成熟したサービスを提供します。トランザクション処理、リカバリを可能にする効率的なログなどを取得します。これらはリレーショナル データベースのコア サービスであり、リレーショナル データベースが得意とするサービスです。それらはカスタマイズが難しく、特に特定のアプリケーションでそれらを必要としない場合は、ボトルネックと見なされる可能性があります (たとえば、重要度の低い Web サイトコンテンツを提供する場合。この場合、たとえば、広く使用されている MySQL はトランザクションを提供しません)。デフォルトのストレージ エンジンで処理するため、ACID を満たしていません)。多くの「ビッグデータ」の問題では、本質的に不確実性がすでに含まれているため、Web 分析、Web 検索、移動オブジェクトの軌跡の処理など、これらの厳密な制約は必要ありません。

特定のコンピューター (メモリ、CPU、ディスク: データが大きすぎる、またはデータ処理が複雑でコストがかかりすぎる) の限界に達した場合は、サービスを分散することをお勧めします。多くのリレーショナル データベースと NoSQL データベースが分散ストレージを提供しています。ただし、この場合、ACID を満たすのは難しいことがわかります。CAP の定理は、可用性、一貫性、分断耐性を同時に達成することはできないと述べています。ACID を放棄した場合 (たとえば、BASE を満たす場合)、スケーラビリティが向上する可能性があります。この投稿を参照してください。CAPによる保管方法の分類について。

もう 1 つのボトルネックは、SQL 操作を使用した柔軟で巧妙な型付きリレーショナル モデル自体である可能性があります。多くの場合、より単純な操作を備えた単純なモデルで十分であり、より効率的です (型指定されていないキー値ストアなど)。一般的な行単位の物理ストレージ モデルも制限している可能性があります。たとえば、データ圧縮には最適ではありません。

ただし、リレーショナル データベースのテクノロジは成熟し、十分に研究され、普及しているため、VoltDBなどの新しいものを含む、高速でスケーラブルな ACID 準拠のリレーショナル データベースがあります。与えられた問題に対して適切な解決策を選択するだけです。

Answer 3

最も単純な例を見てみましょう。生成された ID を持つ行を挿入します。ID はテーブル内で一意である必要があるため、データベースはなんらかの永続カウンターをロックして、他の INSERT が同じ値を使用しないようにする必要があります。したがって、1 つのインスタンスのみにデータの書き込みを許可するか、分散ロックを使用するかの 2 つの選択肢があります。どちらのソリューションも主要なボトルネックであり、最も単純な例です!