MySQL上でNoSQLデータベースを使用する

「NoSQL」の丁寧な解釈はNot Only SQLになりました。本当にリレーショナルなデータがある場合、または機能が結合やACIDityなどに依存している場合は、そのデータをリレーショナルな方法で保存する必要があります。この投稿では、MySQLを2つと一緒に使用する方法について説明します。 NoSQLデータストア。最新のWebスケールのデータストレージとは、仕事に最適なツールを選択する方法を理解することです。

とは言うものの、NoSQLは、リレーショナルメソッドと考え方が、実際にはあまり適合しない問題（通常、数千万行以上の巨大なテーブル）に適用されているという事実に対する反応です。テーブルがこれほど大きくなると、一般的なSQLの「ベストプラクティス」は手動でシャードすることです。データ-つまり、レコード1から10,000,000をテーブルAに、10,000,001から20,000,001をテーブルBに配置します。次に、通常、アプリケーションモデルレイヤーで、このスキームに従ってルックアップが実行されます。これは、application-awareと呼ばれるものです。スケーリング。時間とエラーが発生しやすくなりますが、長いテーブルストア用にMySQLを維持しながら何かをスケールアップするために、多かれ少なかれ標準的なMOになりました。 NoSQLは、私にとって、application-unawareを表します代替案。

キー値

MySQLプロトタイプが大きくなりすぎて自分の利益にならないようになったとき、私は個人的にできるだけ多くのデータを超高速のMembaseに移動しました。、Memcachedを上回り、永続性を追加します。 Membaseは分散型Key-Valueストアであり、クラスターにコモディティサーバーを追加することで、ほぼ直線的にスケーリングします（たとえば、Zyngaはこれを使用して1秒あたり50万回の操作を処理します）。したがって、これはすばらしい AmazonEC2 のクラウド時代に適合、 Joyent 、など。

分散キー値ストアが巨大な線形スケールを取得するための最良の方法であることはよく知られています。キー値の弱点は、クエリ可能性とインデックス作成です。ただし、リレーショナルの世界でも、スケーラビリティのベストプラクティスは、アプリケーションサーバーにできるだけ多くの労力をオフロードし、中央のRDBクラスターにすべてのロジックを処理するように依頼するのではなく、コモディティアプリサーバーのメモリで結合を行うことです。 simple selectなので、プラスapplication logic でも大規模なスケールを達成するための本当に最良の方法です MySQL、Membase（または Riak などの競合他社）への移行）それほど悪くはありません。

ドキュメントストア

多くの人が考えるほど頻繁には議論しませんが、アプリケーションの設計には本質的にセカンダリインデックス、範囲クエリ機能などが必要な場合があります。これに対するNoSQLのアプローチは、document storeを使用します。 MongoDB のように。 Membaseのように、Mongoは、application-unawareのように、リレーショナルデータベースが特に弱いいくつかの領域で非常に優れています。スケーリング、auto-sharding 、およびmaintaining flat response times even as dataset size balloons 。 Membaseよりも大幅に遅く、純粋な水平スケールを実行するのは少し難しいですが、クエリが非常に簡単であるという利点があります。パラメータと範囲をリアルタイムでクエリすることも、Map/Reduceを使用して本当に膨大なデータセットに対して複雑なバッチ操作を実行することもできます。

Membaseを使用して大量のライブプレーヤーデータを提供する上記の同じプロジェクトでは、MongoDBを使用して分析/メトリクスデータを保存します。これは、MongoDBが本当に優れているところです。

SQLで物事を維持する理由

「真にリレーショナルな」情報はリレーショナルデータベースにとどまる必要があるという事実に簡単に触れました。コメント提供者のDanK.が指摘しているように、RDBMSを離れること、または少なくともRDBMSを完全に離れることの不利な点について説明する部分を見逃しました。

まず、SQL自体があります。 SQLはよく知られており、長い間業界標準でした。 Googleの AppEngine などの一部の「NoSQL」データベースデータストア（Big Table上に構築）は、独自のSQLのような言語を実装します（Googleは、Google Query LanguageのGQLと呼ばれています。）。 MongoDBは、楽しいJSONクエリオブジェクトを使用してクエリの問題に新たなアプローチを取ります。。それでも、SQL自体は、データから情報を取得するための強力なツールです。これは、多くの場合、データベースの最初のポイントです。

RDBMSを使用する最も重要な理由は、ACID です。、またはAtomicity, Consistency, Isolation, Durability 。この投稿 SOで。 OracleのRDBMS には合理的な理由があります。巨大な市場があり、どこにも行きません。一部のデータには純粋なACID準拠が必要です 。あなたのデータがそうなら（そしてもしそうなら、あなたはおそらくその事実をよく知っているでしょう）、そしてあなたのデータベースもそうです。 pH を維持します低！

編集： Aaronaughtの投稿こちらをご覧ください。彼は、私がキャリア全体を消費者の分野で過ごしてきたという理由もあり、私ができるよりもはるかに優れた企業間取引の視点を表しています。