コンピューター プログラミングのエバンジェリストがクラウド コンピューティングの未来を非常に明るいと予測している一方で、リレーショナル データベースが消えていく可能性はありますか?
クラウド コンピューティングにより適した DB は何ですか?
リレーショナル データベース モデルには、リレーショナル代数の確固たる数学的基礎があります。これにより、推論、拡張、および適切な使用 (理論上) が容易になります。これらの新しい API と使用の結果としてデータベース アクセス パターンが大幅に変化したとしても、リレーショナル データベースがこの理由で基盤となる実装を形成する可能性があります。
これは、あなたの質問のいくつかに答える良い記事です。RDBMS システムと、クラウド ストレージ インフラストラクチャに通常使用されるシステムとの適切な比較が特徴です。
http://www.readwriteweb.com/enterprise/2009/02/is-the-relational-database-doomed.php
いいえ、RDBMS はその機能により常に場所を持っています。単独で使用するだけでなく、他のシステム (OODBMS など) のバックボーンとして使用することもできます。
私が見たクラウド コンピューティング プラットフォームには、それぞれリレーショナル データベースが用意されています。したがって、使用されているデータベースの種類に関して、クラウド コンピューティングが状況を実際に変えるとは思えません。
しかし、最終的には、私たちが慣れ親しんできたデータベースが何かに取って代わられるでしょう。問題は、それが RDB の上位バージョンになるのか、それとも別のものになるのかということです。その質問のもう 1 つの側面は、現在の RDB の収穫が消えるのにどれくらいの時間がかかるかということです。(どちらも答えはありません。)
クラウド コンピューティングが RDBMS を殺すとは思いません。しかし、何か他のものかもしれません。
まず、特定のアプリケーションが使用するストレージ エンジンのタイプは、アプリケーションが実行されている場所 (クラウドまたは特定のサーバー) に依存せず (またはすべきではありません)、データをどのように格納する必要があるかに依存します。
第 2 に、私が知る限り、人々が RDBMS が消えつつあると考えている唯一の理由は、より簡単に分散できる非リレーショナル DBMS (CouchDB のようなドキュメント指向の DBMS など) ほどスケールしないからです。クラウド。ただし、将来的に RDBMS がよりクラウドに適したものにならないという理由はありません。初期の例として、Drizzleを見てください:
Drizzle プロジェクトは、クラウドおよびネット アプリケーション用に最適化されたデータベースを構築しています。最新のマルチ CPU/コア アーキテクチャで大規模な同時実行を実現するように設計されています。
いいえ、クラウド コンピューティングが RDBMS を殺すとは思いません。彼らは適応を余儀なくされるだけです。ただし、既存の代替品または新しい代替品が RDBMS と同じくらい堅牢で使いやすいものになると、それらが台無しになる可能性があります。私が言いたいのは、完全に安定したソフトウェア (ベータ版は許可されていません) と、プログラマーが簡単に切り替えられるソリューションの両方です。RDBMS を理解している人に学位を授与します。すべての支援ソフトウェア (ActiveRecord、SQLAlchemy などの ORM、および私が想定している .NET の人々が使用するものなど) のおかげで、RDBMS の使用は、最初の正規形が何であるかを知らない人でも簡単になりました。したがって、人々が (たとえば) DODBMS を同じように簡単に使用できるようになるまでは、RDBMS が支配的であり続けると思います。また、それが必ずしも悪いと言っているわけではありません。また、
リレーショナル データベースは、ローカライズされたストレージ (アプリケーション固有のストレージなど) とサーバー ストレージの両方に関連しています。
より構造化されたデータを照会する必要があるアプリケーション用のリレーショナル データベースには何の問題もありません (たとえば、「この日に製品 XYZ を購入し、100 ドル以上 150 ドル未満で購入した人は何人ですか?」)。これらのシステムが拡張および成長するにつれて、対処する必要がある重大なアーキテクチャ上の問題が潜在的に存在します。DB が開始した 1 台のマシンを超えたり、トラフィック/リクエストが利用可能なリソースを過負荷にし始めたりすると、(リレーショナル データベースを保持したい場合は) レイヤーの追加を開始する必要があります。ありがたいことに、今日では、キャッシング、マップ アンド リデュース、その他の機能など、以前よりも多くのオプションを利用できますが、これらのアドオン レイヤーは複雑さとメンテナンス オーバーヘッドを追加します。ある意味で、私はこれらの人工的な「バンドエイド」を考えます。今日のリレーショナル DB のスケーラビリティと分散の問題を解決する可能性が最も高いのはどれですか? 知るか。今日、これらの人気のあるレイヤーも見ます。これらはすべて、基本的にオブジェクト DB で既に利用可能な機能をエミュレートしようとしており、開発者がオブジェクト言語で使用できる「仮想オブジェクト DB」レイヤーを提供して、物事をより迅速かつ効率的に実行できるようにします。成長とパフォーマンスの障害を乗り越えます。したがって、私の全体的な意見は、リレーショナル DB がデファクト DB になったのは、おそらく、データベースにクエリを実行し、それを使用して 1 つのクライアント/アプリに結果を返すのが (比較的) 簡単だったためだと思います。しかし、ボリュームが増加し、アプリケーションの複雑さが指数関数的に大きくなっている今日、より多くの開発者が弾丸を噛むことを決定すると思います。オブジェクト DB (現在、リレーショナル DB とほぼ同じくらい標準化されています) の構文を学び、OODBMS でネイティブに取得できる機能のみをエミュレートするすべてのミドルウェアとレイヤーをスキップします。任意の数のサーバーに簡単にインストールされ、必要に応じてデータを自動的に分散し、開発者に任意のサイズのデータベース連合の単一ビューを提供する OODB を見てきました。ネイティブ分散アーキテクチャを持つことができる DB を取得します。とにかく、ただの考えです。そして、開発者にデータベースの任意のサイズのフェデレーションの単一のビューを提供します...システムがより分散されるにつれて、ネイティブの分散アーキテクチャを持つことができるDBを取得するための最良のソリューションのように思えます。とにかく、ただの考えです。そして、開発者にデータベースの任意のサイズのフェデレーションの単一のビューを提供します...システムがより分散されるにつれて、ネイティブの分散アーキテクチャを持つことができるDBを取得するための最良のソリューションのように思えます。とにかく、ただの考えです。
最近は雲が静かなので、すぐにそうなるとは思いません。