水平方向にスケーリングするデータベースをお勧めしますか?[閉まっている]

https://stackoverflow.com/questions/42649

09-06-2019
|

質問

一般にデータベースサーバーは、垂直方向に拡張することが唯一の選択肢であるため、購入しなければならない最大かつ最も高価なボックスです。水平方向に適切に拡張できるデータベースはありますか (つまり、複数の汎用マシンにまたがる)、このアプローチにはどのような制限があるのでしょうか?

解決

心配しないでください。良い解決策が必ず見つかります。

カウチデータベースそしてハイパーテーブルはオープンソースでまだアルファ版ですが、コモディティソフトウェアの拡張を簡単にするように設計されていることは明らかです。これらは非常にうまく機能し、データベースに対する考え方が変わるかもしれません。

また、配布を他の人に任せても良い場合は、 Google アプリエンジンそして Amazon SimpleDB は非常に安価な分散データベースサービスですが、現在は両方ともベータ版であるため、厳しい制限が課されています。

他のヒント

すべての Oracle インスタンスが同じデータストレージを共有するため、Oracle RAC は水平方向にスケーラブルではありません。はい、SAN を使用すると、大きなサイズの DB を取得できますが、まったく拡張性がありません。言い換えれば、Oracle RAC は依然としてスケールアップアプローチです。したがって、スケールアウトまたは水平スケーリングを行うには、データを機能ごとに分割する必要があります。これは、異なるテーブルのグループを異なるデータベースに配置することを意味します。または、テーブルごとにデータを分割します。これは、1 つのテーブルを、同じスキーマを持つ複数のサブテーブルに分割しますが、異なるデータベースに保存することを意味します。このようにして、スケールアウトソリューションが得られます。それに関するリソースはたくさんあります。シャーディングは、Web 2.0 Web サイトアーキテクチャのブログ界でしばらくの間流行語になっています。シャーディングはデータベース自体では直接サポートされていないため、独自のソリューションを構築する必要があります。しかし、先ほども言いましたが、すでに多くの教訓があります。oracleの場合、テーブルのパーティショニングが可能です。mysqlの場合は、チェックしてくださいこの質問

Oracle RAC -- リアルアプリケーションクラスター

これはうまく機能し、クラスターにボックスを追加するだけです。あるボックスから別のボックスにフェイルオーバーできます。これはレプリケーションではなく、すべてのボックスが同じ論理ユニットの一部です。

もちろんかなりの出費です。

JavaSpaces (または Gigaspaces などの商用実装) などのストレージ技術があり、これにより、オブジェクトへの拡張性が高く、高速かつ安全なアクセスが提供されます。

同様のアプローチを提供する memcached などの分散キャッシュシステムもあります。

もちろん、これらはどちらも真のデータベースではありませんが、適切なアーキテクチャがあれば、データベースと連携して大きな水平スケーラビリティを提供できるものです。本当の問題は、データベースに付属する ACID のすべての利点を必要とする場合、避けられないパフォーマンス上のペナルティが存在することです。唯一の方法は、ACID が必要ないビットを特定し、他のテクノロジーを使用してそれらのビットを処理することです。

Oracle RAC はデータベースのロールスロイスであり、追加のハードウェアノードを比較的簡単に追加したり、ハードウェアフェイルオーバーを実行したりできます。

ただし、コモディティハードウェアのコストは、ライセンスのコストに比べれば小さく見えます。

水平方向のスケーリングが必要だと感じたのはなぜですか。40GB RAM と SAN ストレージを備えたマルチ CPU コアサーバーは、非常に大規模な DB のインストールをサポートできます。

問題をより深く理解するために、サイジングと予想されるアクティビティの情報を提供していただけますか?

RAC ルートを採用する場合は、永久に水平方向にスケールするわけではないことを覚えておく価値があります。営業担当者ですら、rac 顧客の 90% が 4 ノード以下であることを認めています。それを超えると、利益は減少します。したがって、rac は役に立つかもしれませんが、それが答えであるという保証はありません。

MySQL: http://www.mysql.com/why-mysql/scaleout.html

制限としては、読み取りがほとんどのワークロードで最適に動作することです。通常、すべての書き込みを受信する 1 つの「マスター」と、書き込みを複製する多数の「スレーブ」があります。次に、読み取りをすべてのデータベースに分散します。

MySQL レプリケーションは非同期であるため、おそらくタイムラグの問題に対処する必要があります (マスターに書き込み、書き込みがレプリケートされる前にスレーブから読み取ります)。

ネテッツァなどのデータウェアハウスアプライアンスはこの方法で拡張できますが、OLTP や Web アプリのワークロードには適していません。

複数のマシンにわたってスケーリングするための Oracle ルートは、Real Application Clusters (Oracle RAC) と呼ばれます。これに関するドキュメントは他にいくらでもあります。から始めてみてはいかがでしょうか http://www.oracle.com/database/rac_home.html.

Oracle Real Application Clusters。最高のものを望むなら、それを見てください。

まともなマルチコアの「Big Iron」ボックスをスケールアウトしたいと真剣に考えている場合は、データのパーティション分割を検討することになります。これは、データベースに依存しないスケールアウトの優れた方法です。

水平方向に展開されるすべてのデータベースには重大なコストがかかります。

問題に対処するための大きな資金がない限り、RAC のことは忘れてください。これは非常に優れていますが、2 ノードを超えると非常に高価になります。

モンゴDBは、水平方向に拡張できる最高のデータベースの 1 つです。

DashDB for OLAP を検討してみてください。IBM はこれを OLTP 用の Cloudant と組み合わせています。https://www.ibm.com/developerworks/community/blogs/5things/entry/5_things_to_know_about_dashdb_placeholder?lang=ja

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow