リレーショナルデータベースがビッグデータのスケールに対応できないのはなぜですか？
ビッグデータの問題は、リレーショナルデータベースが現在作成されている大量のデータを処理するように拡張できないことであることがよく繰り返されます。
しかし、Hadoopのようなビッグデータソリューションが拘束されないこれらのスケーラビリティの制限は何ですか？ Oracle RAC、MySQLシャーディング、Teradata（など）のようなMPP RDBMSがこれらの偉業を達成できないのはなぜですか？
技術的な制限に興味があります-RDBMSをクラスタリングすることの財務コストは法外に高くなる可能性があることを認識しています。
MSは、オランダで tech talk を開催したばかりで、このことについていくつか話し合いました。ゆっくりと始まりますが、20分を過ぎるとHadoopの肉に食い込みます。
その要点は「依存する」ということです。 （少なくともある程度）均質であるデータのセットを（少なくともある程度）合理的に整理し、（少なくともある程度）分割しやすい場合、RDBMSを使用して、それらの大量のデータにかなり簡単にスケーリングできます。 。
HadoopとMRは、特にそれらのデータが必ずしもRDBMSの世界で見られるものほど均質であるか、または構造化されていない場合に、データの大規模な分散スキャンを強制される状況に、より適合しているようです。
ビッグデータソリューションにはどのような制限がありませんか？私にとって、彼らが拘束されない最大の制限は、事前に厳密なスキーマを作成する必要があることです。ビッグデータソリューションを使用すると、大量のデータを「ボックス」に押し込み、後でクエリにロジックを追加して、データの均一性の欠如に対処します。開発者の視点から見たトレードオフは、プロジェクトのフロントエンドでの実装の容易さと柔軟性であり、クエリの複雑さと即時のデータ整合性の低下です。
データベースのパイオニアであり研究者であるマイケルストーンブレイカーは、従来のデータベースアーキテクチャの制限について議論する paper を共同執筆しました。一般的に、それらはより高価なハードウェアでスケールアップしますが、より多くの市販のハードウェアで並行してスケールアウトすることが困難であり、古い時代のために設計されたレガシーソフトウェアアーキテクチャによって制限されます。彼は、BigData時代には、最新のインフラストラクチャを利用して特定のワークロードに最適化する複数の新しいデータベースアーキテクチャが必要であると主張します。この例としては、商用データベースVertica SystemsにつながったCストアプロジェクト、VoltDB、メモリ内のOLTP高速用に設計されたSQLデータベースにつながったHストアプロジェクトがあります。 BigDataワークロード（完全な開示、私はVoltDBで働いています）。
このトピックでは、これが webinar で興味深いと感じるかもしれません。これは、NoSQLデータベースの成功で生じたいくつかの神話に対応しています。基本的に、彼はSQLは問題ではなかったと主張し、パフォーマンスを得るために一貫性などの従来のデータベース機能を放棄する必要はないはずです。
RDBMSがスケーリングできないことは完全に真実ではありません。ただし、ステートメントの部分的な真実はアーキテクチャによって異なります。あなたが挙げたリストでは、Oracle RACは他のOracle RACとは異なります（分割されたMySQLおよびTeradata）。主な違いは、共有ディスクと共有なしのアーキテクチャです。
Oracle RACのような共有ディスクアーキテクチャは、ある時点で、または実行中のすべてのマシンがデータの一部で同期する必要があるため、スケーリングの影響を受けます。例えばグローバルロックマネージャーはキラーです。ある程度は微調整を続けることができますが、最終的には壁にぶつかります。マシンを簡単に追加できない場合は、ポケットを焼く可能性のある非常に強力なマシンは少なくなります。シェアードナッシングアーキテクチャ（または分割されたデータ）の場合、各マシンは一部のデータの所有権を取得します。一部のデータを更新する場合は、他のマシンと同期する必要はありません。
次に、NoSQLデータベースの種類が登場します。私はそれらを従来のRDBMSデータベースのサブセットとして扱います。この世界のすべてのアプリケーションがRDBMSが提供するすべての機能を必要とするわけではありません。データベースをキャッシュとして使用する場合、耐久性は気にしません。場合によっては、一貫性についても気にしません。すべてのデータ参照がキーに基づいている場合、範囲クエリのサポートは必要ありません。セカンダリインデックスは必要ないかもしれません。すべての従来のデータベースにあるクエリ処理/クエリ最適化レイヤー全体は必要ありません。