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