SQLからNoSQLに移行すると、どのサイズのデータでメリットがありますか？
リレーショナルデータベースプログラマーとして（ほとんどの場合）、リレーショナルデータベースのスケーリング方法に関する記事と、MongoDBなどのNoSQLソリューションのスケーリングに関する記事を読んでいます。これまでに開発したデータベースのほとんどは小規模から中規模であるため、インデックス付け、クエリの最適化、スキーマの再設計によって解決されない問題は一度もありませんでした。
MySQLが苦労するのはどのようなサイズになると思いますか。行はいくつありますか？
（これはアプリケーションと保存されているデータの種類に依存することはわかっています。基本的には遺伝学データベースでしたので、3つまたは4つのルックアップテーブルを持つ1つのメインテーブルがあります。メインテーブルにはその他、染色体参照、位置座標など、染色体の2つの部分の間のエントリ数を照会して、そこに何が格納されているかを確認する場合があります。
データの大きさは？
2つの重要なしきい値があります。
- データ全体がRAMに収まる
- インデックスデータ全体がRAMに収まる
高速SSDを使用すると、狂った高いトラフィックがない限り、最初のしきい値の問題は少し少なくなります。
酸度
RDBMSのスケーリングに関する問題の1つは、設計上、それらがACIDであることです。これは、トランザクションと行レベルのロック（または一部の古い/単純なRDBMSではテーブルレベル）を意味します。同時に実行する大量のデータを変更する多くのクエリがある場合、これは制限要因になる可能性があります。 NoSQLソリューションは通常 結果整合性 モデルに適しています。
RDBMSはデータサイズをどのようにスケーリングしますか？
RDBMSがデータサイズでスケーリングできないことは完全に真実ではありません。2つの選択肢があります： 垂直分割と水平分割 （別名シャーディング）。
垂直分割とは、基本的には無関係なテーブルを別々のDBサーバーに保持することで、それぞれのサイズを上記のしきい値未満に保ちます。これにより、プレーンSQLを使用してこれらのテーブルを結合することは簡単ではなくなり、効率も低下します。
シャーディングとは、特定のキーに基づいて、さまざまなサーバー間で1つのテーブルからデータを分散することを意味します。つまり、ルックアップでは、そのキーに基づいてクエリするサーバーがわかります。ただし、これにより、シャーディングキーのルックアップではないクエリが複雑になります。
両方の種類のパーティショニングの場合、極端に行くと、基本的にNoSQLデータベースと同じ状況になります。
データのサイズだけが要因だとは思いません。 「データモデル」も非常に重要な部分です。
Eコマースのカタログページ（Solr、ElasticSearch）、ウェブ分析データ（Riak、Cassandra）、株価（Redis）、ソーシャルネットワークでの関係の接続（Neo4J、FleetDB）は、NoSQLソリューションが本当に優れている例の1つにすぎません。
IMHO、NoSQLソリューションまたはRDBMSを検討する場合、データモデルはデータのサイズよりも重要な役割を果たします。
リレーショナルデータベースがスケーリングしない場合、何もスケーリングしません。スケーリングの問題を心配する必要はありません。
SQLにはある種の分析に関する問題がありますが、問題を引き起こすのにそれほど多くのデータを必要としません。たとえば、一意のキーに基づいて他の行を参照する列を持つ単一のテーブルについて考えます。通常、これはツリー構造を作成するために使用されます。関連する行を参照する高速SQLステートメントを記述できます。または、関連する行の関連する行。実際、特定の数のジャンプを行うことができます。ただし、各行について、ある基準を満たすチェーンの最初の関連行のフィールドを選択する場合は、複雑になります。
国、州/州、郡、町、村のレベルでのオフィスの場所の表を考えてみてください。各オフィスはそれが報告するオフィスを参照しています。 no各オフィスの報告オフィスが1つ上のレベルであることを保証します。すべてが1つのレベルにあるのではなく、選択されたオフィスのセットについて、各オフィスに関連付けられている全国オフィスをリストする必要があります。これにはSQLステートメントのループが必要で、今日でも長い時間がかかります。 （以前は30のオフィスを選択して30秒を取得していましたが、それはlong時間前です-ストアドプロシージャに切り替えると少し役立ちました。）
したがって、代わりに、構造全体を1つの大きなデータブロックに入れ、ラベルを付けて保存します。データを分析する場合は、一度にすべてをメモリに読み込んで、ポインタを設定して構造を追跡すると、数百万のオフィスを瞬く間に処理できます。
これはデータ量とは関係ありません。重要なのは、データの編成の性質です。リレーショナルレイアウトが役立つ場合は、RDBMSが必要です。そうでない場合、ある種の大容量ストレージは、わずか数倍から数千億倍も高速になります。
これらのデータセットのいずれかがメモリに収まらないほど大きくなると、SQL以外のデータベースは機能しなくなります。もう1つの問題は、一度に複数のブロックのデータが必要な場合です。 ifおよびonlyの場合、すべてのブロックが一度にメモリに収まります。そして、それらをロードする間、ユーザーは待たなければなりません。
リレーショナルデータベースで問題が発生する場合は、大量のデータを入力する前に問題が発生します。考えられる唯一のスケーリングの問題は、nosql DB用にアセンブルしているデータのブロック（使用する必要がある場合）が大きすぎる場合のプログラムにあります。 （メモリ不足エラーを確認してください。新しい言語では、メモリで奇妙なことが行われることがあります。）
NoSQLまたは分散ソリューションに移行する最初の理由は、すべてのデータのサイズではなく、テーブルのサイズだと思います。分散ソリューションがうまく機能するのは、テーブルを異なるノードに分割することです。テーブルをクエリする必要がある場合、各ノードがテーブルの一部を処理します。
RDBMSはこれを行うことができますが、これを行うためにNoSQLデータベースの新しい波が構築されています。 Oracle、MSSQL、MySQLは集中型モデルを採用し、分散環境で機能するように調整しました。ただし、新しいデータベースの一部は結果整合性を使用するなどの厳密なルールに準拠していませんが、それらは依然として厳しいACIDルールに準拠しています。
どちらか一方を選択する必要があるデータの量は決まっていません。考慮に入れる必要があるのは、データベースのニーズとそれが受け取る使用量です。 NoSQLデータベースは、より大きなデータセットをより迅速に処理できますが、リレーショナルデータベースは、ACIDの原則に従ってデータが正しいことを確信できます。
Mongoは、多数のコンピューター/ノードにインストールできます。 PostgreSQLはシャーディング用の組み込みツールを提供していませんが、 citus が使用されています。
MongoDBは、最大64テラバイトのデータベースをサポートし、ドキュメントサイズは16メガバイトです。
MySQLのデータベース制限は256テラバイト、テーブルの最大サイズは64テラバイト、レコード制限は4ギガバイトです。
PostgreSQLはデータベースに制限がなく（テスト用のどこかに4テラバイトが存在します）、1つのフィールドのサイズに1ギガバイトの制限があります。テーブルと、テーブルの最大サイズの64テラバイト。
データモデルが物事に大きな影響を与えることについて言及することも価値があります。何らかの形のツリー構造を作成する必要がある場合（つまり、複合主キーにその外部キーを含むテーブルに自己参照外部キーがある場合）、おそらくそれらを処理するデータベースのある形式でそれを行うことを検討する必要があります。データの種類（mongodbやcouchdbなど）.
他の人々が言ったように、あなたもあなたのアプリケーションで何が起こっているかを考慮に入れるべきです。複数のテーブル間で本当にACIDが必要な場合は、RDBMSにこだわる必要がありますが、少し古いデータがあり、NoSQLスキーマの柔軟性が必要な場合は（必要に応じてスキーマレスと呼びます）暗黙のスキーマの形式がまだあります）次に、NoSQLストア（ http://www.10gen.com/customers/craigslist を取得することを検討してください）は、craigslistが切り替えられた理由の例です...確かに、それらは10 TBまでのデータをアーカイブしていますが、これは、中小規模のデータベースサイズにはまったく適合しないことを知っています。ただし、ユースケースが役立つ場合があります）。
NoSQLシステムは必ずしもRDMSを置き換える必要はありませんが、多くの場合、Polyglot Persistenceの概念を通じてRDBMSを補完でき、ほとんどのデータをRDBMSに保存できますが、特定のニッチインスタンスでは、何らかの形式のNoSQLストアへのデータ。