SQLからNoSQLに移行すると、どのサイズのデータ​​で有益になりますか？

リレーショナルデータベースプログラマーとして（ほとんどの場合）、リレーショナルデータベースがどのようにスケールしないか、MongoDBなどのNoSQLソリューションがどのようにスケールするかについての記事を読みました。これまでに開発したデータベースのほとんどは小規模から中規模であったため、インデックス作成、クエリの最適化、またはスキーマの再設計によって解決されなかった問題は一度もありませんでした。

MySQLはどのようなサイズに苦しんでいると予想されますか。何行ですか？

（これはアプリケーションと保存されるデータの種類に依存することを知っています。基本的には遺伝学データベースだったので、3つまたは4つのルックアップテーブルを持つ1つのメインテーブルがあります。メインテーブルには、他のもの、染色体参照、および位置座標。おそらく、そこに保存されているものを確認するために、染色体上の2つのポーション間の多くのエントリを照会されます。

どのくらいのデータですか？

2つの重要なしきい値があります。

1. データ全体がRAMに収まる
2. インデックスデータ全体がRAMに収まる

高速SSDを使用すると、トラフィックが非常に多い場合を除き、最初のしきい値の問題が少し少なくなります。

酸度

RDBMSのスケーリングに関する問題の1つは、それらが設計上ACIDであるということです。これは、トランザクションと行レベルのロック（または、一部の古い/単純なRDBMSのテーブルレベル）を意味します。同時に実行する多くのデータを変更する多くのクエリがある場合、制限要因になる可能性があります。通常、NoSQLソリューションは結果整合性モデルに適しています。

RDBMSはデータサイズをどのようにスケーリングしますか？

RDBMSがデータサイズをスケーリングできないことは完全に真実ではありません。2つの選択肢があります。垂直分割と水平分割（別名、シャーディング）です。

垂直分割では、基本的には無関係のテーブルを別々のDBサーバーに保持するため、各テーブルのサイズは上記のしきい値を下回っています。これにより、プレーンSQLを使用したこれらのテーブルの結合が単純でなくなり、効率が低下します。

シャーディングとは、特定のキーに基づいて、さまざまなサーバー間で1つのテーブルからデータを配布することです。これは、ルックアップのために、そのキーに基づいてどのサーバーを照会するかを知っていることを意味します。ただし、これにより、シャーディングキーのルックアップではないクエリが複雑になります。

両方の種類のパーティションの場合、極端に進んだ場合、基本的にNoSQLデータベースと同じ状況になります。

データのサイズが唯一の要因だとは思いません。「データモデル」も非常に重要な部分です。

Eコマースカタログページ（Solr、ElasticSearch）、Web分析データ（Riak、Cassandra）、株価（Redis）、ソーシャルネットワーク（Neo4J、FleetDB）のリレーションシップ接続は、NoSQLソリューションが本当に輝いている場合のほんの一例です。

私見、NoSQLソリューションまたはRDBMSを検討する場合、データモデルはデータのサイズよりも重要な役割を果たします。

リレーショナルデータベースが拡張されない場合、何も拡張されません。スケーリングの問題を心配する必要はありません。

SQLにはある種の分析に関する問題がありますが、問題を引き起こすのに多くのデータを必要としません。たとえば、一意のキーに基づいて他の行を参照する列を持つ単一のテーブルを考えます。通常、これはツリー構造を作成するために使用されます。関連する行を参照する高速SQLステートメントを作成できます。または、関連する行の関連する行。実際、特定の数のジャンプを行うことができます。ただし、各行に対して、チェーンの最初の関連する行で、ある基準を満たすフィールドを選択する場合、複雑になります。

国、州/州、郡、町、村のレベルでオフィスの場所のテーブルを考えてみましょう。各オフィスは、報告先のオフィスを参照します。各オフィスのレポートオフィスが1レベル上にあるという保証はありません。すべてが1つのレベルにあるわけではない、選択されたオフィスのセットについて、各オフィスに関連付けられているナショナルオフィスをリストする必要があります。これにはSQLステートメントのループが必要であり、今日でも長い時間がかかります。（以前は30のオフィスを選択して30秒を取得していましたが、それはかなり前のことであり、ストアドプロシージャへの切り替えは少し役立ちました。）

そのため、別の方法は、構造全体を1つの大きなデータブロックに入れ、ラベルを付けて保存することです。データを分析する場合は、一度にすべてのデータをメモリに読み込み、構造を追跡するためのポインターを設定すれば、瞬く間に数百万のオフィスを処理できます。

これはどれもデータの量とは関係ありません。キーは、データの組織の性質です。リレーショナルレイアウトが役立つ場合は、RDBMSが必要です。そうでない場合、ある種のバルクストレージは、わずかに1倍から1兆倍高速になります。

これらのデータセットの1つが大きすぎてメモリに収まらない場合、SQL以外のデータベースは機能しなくなることに注意してください。別の問題は、一度に複数のブロックからのデータが必要な場合です。あなたはこれを行うことができた場合、およびのみ場合、すべてのブロックを一度にメモリに収まります。そして、ユーザーはそれらをロードするまで待つ必要があります。

リレーショナルデータベースが問題を引き起こす場合、大量のデータを入れる前にそれを行います。唯一のスケーリングの問題は、nosql DBにアセンブルしているデータのブロック（使用する必要がある場合）が大きすぎる場合のプログラムの問題です。（メモリ不足エラーについて調べてください。新しい言語では、メモリに関して奇妙なことをすることがあります。）

NoSQLまたは分散ソリューションに移行する最初の理由は、すべてのデータのサイズではなく、テーブルのサイズだと思います。分散ソリューションが優れているのは、テーブルを異なるノードに分割し、テーブルを照会する必要がある場合、各ノードがテーブルの一部を処理することです。

RDBMSはこれを行うことができますが、これを行うためにNoSQLデータベースの新しい波が構築されました。Oracle、MSSQL、MySQLは、集中型モデルを採用し、分散環境で動作するように調整しました。ただし、一部の新しいデータベースは結果整合性を使用するなどの厳格なルールを順守していませんが、それらは依然として厳格なACIDルールを順守しています。

どちらか一方を選択する必要があるデータの量は決まっていない。考慮に入れる必要があるのは、データベースのニーズとそれが受け取る使用量です。NoSQLデータベースは、より大きなデータセットをより迅速に処理できますが、リレーショナルデータベースは、ACIDの原則によりデータが正しいことを確信できます。

また、データモデルが物事に大きな影響を与えることに言及する価値があるかもしれません。何らかの形式のツリー構造を作成する必要がある場合（つまり、複合主キーに外部キーを含むテーブルに自己参照外部キーがある場合）、おそらくそれらを処理するデータベースの何らかの形でそれを行う必要がありますデータの種類（mongodbやcouchdbなど）。

他の人が言ったように、あなたはあなたのアプリケーションで何が起こっているのかも考慮に入れるべきです。複数のテーブルにまたがるACIDが本当に必要な場合は、RDBMSに固執する必要がありますが、少し古いデータがあり、NoSQLスキーマの柔軟性が必要な場合（必要に応じてスキーマレスと呼びます）まだ何らかの形式の暗黙的なスキーマがあります）、NoSQLストアを取得することを検討するかもしれません（http://www.10gen.com/customers/craigslistは、craigslistが切り替えられた理由の例ですが...小規模から中規模のデータベースサイズには収まらないデータですが、ユースケースが役立つ場合があります）。

RDMSを置き換えるためにNoSQLシステムが必ずしも存在するわけではないことに注意してください何らかの形式のNoSQLストアへのデータ。

Mongo多数のコンピューター/ノードにインストールできます。PostgreSQLシャーディング用の組み込みツールは提供していませんが、citusは存在します。

MongoDBは最大64テラバイトのデータベースをサポートし、ドキュメントサイズは16メガバイトです。

MySQLのデータベースの制限は256テラバイト、テーブルの最大サイズは64テラバイト、レコードの制限は4ギガバイトです。

PostgreSQLはデータベースに制限がなく（テスト用に4テラバイトが存在します）、テーブル内の1つのフィールドのサイズに1ギガバイト、テーブルの最大サイズに64テラバイトの制限があります。