ハイブリッドDBシステム：データ用のNoSQL、リレーションシップ用のSQLベストプラクティス？

Question

DBシステムが重要なアプリケーションを構築しており、すべての値がデータに格納されるため、スケーラビリティが必要です。

私はライブ投票システムを作っています。

私はSQLやMongoDBのに慣れていますので、（私はより多くのこれらの時間をMongoDBの構造やJSを好む傾向にあるものの:)）それはほとんどの決定の要因ではありません

しかし、私は、ウェブ上で読んだすべてのものから、私はまだ私の決定に不快感を感じる。

• オブジェクト（ユーザー、アイテム、コメントなど）
• （関係をSQLテーブルを有するテーブルのユーザー項目についてのNoSQLドキュメントを持つ：私は何をしたいか

  は、両方の利点を組み合わせることです、ユーザーのコメントなど）

票があるたびのNoSQL文書に投票結果を複製
• か、一定の間隔（投票結果の表示にもスピードを得るために）

グレートアドバ中私が見るntagesは以下の通りです：

1. ユーザーは自分のプロファイルを表示するために）、NoSQLのすべての利点（スピード、すべての場所、スキーマの柔軟性など）を持っています
2. SQLの利点をすべて持っていれば
3. 並列化：私はSQLに投票を取得することができますし、非同期モードでドキュメント
4. は、高速な読み取りslowish書き込み（と、それは私の場合には関係ありません）
5. 関係の整合性が常に

私の質問に保存されています以下のとおりです。

• そうするのが良い方法ですか？ウェブはそれについてかなり恥ずかしそうに見えます
• DB負荷が高いのにピーナッツを最適化していますか？ （完全なSQLへのドキュメントの取得とselect *のようなselect *のようなクエリは、primary_key = XXXのテーブルから比較します）

Answer 1

RDBMSと共にNoSQLデータベースを使用する唯一の理由が、代わりにキャッシュサーバーを使用することをお勧めします（Memcacheなど）。 SQL文を使用してドキュメント/結果を作成し、後で取り出すためにmemcacheに単一のキー値を使用して格納することができます。 MongoDBより実装がはるかに簡単です。しかし、実際には、文書をより複雑なクエリを使用するためのキーまたは計画を使用して文書の参照のみを行う場合は、要件にもよります。

Answer 2

私は、拡大縮小するオブジェクトと関係をモデリングするための別の提案を捨てたいと思います。

思考のためのいくつかの食べ物：

1. あなたが言ったように、MongoDBのような文書データベース内のモデルのエンティティ/オブジェクト。
2. TitanまたはNeo4jのようなグラフデータベースに関係を格納します。これらのシステムは、私の考えでは複雑な関係を格納するのに適しています。多くの複雑な関係で簡単にトラバーサルを行うことができます。そして、グラフ内の宛先ノード/頂点を見つけたら、Mongoからドキュメントをロードすることができます。
3. には文書間のリンク（リレーションシップ）があるNoSQLドキュメントストアであるRiakを検討してください。彼らは関係を複雑にしないことを推奨しますが、別のシステムを必要とせずにドキュメントをリンクすることは可能です。

Answer 3

「ベストプラクティス」はひどい用語です。「慣行」は、しばしば腸の本能を正当化するために使用されます。「これはいつも行ってきたことです」などの偏見です。

しかし、説明しているソリューションにはいくつかの利点がありますが、いくつかの重大な欠点もあります。これは主に、問題のドメインの知識を2つの互換性のないデータストアに分割しているためです。重複の機会を与えるだけでなく、矛盾も招く。

たとえば、特定のユーザーが特定の識別子で識別されるという知識は、NoSQLシステムとデータベースで共有されます。一方のシステムがそのユーザーを削除すると、他方のシステムは矛盾した状態になります。所与のユーザのプロファイルは2つのシステムに分割され、いずれも完全な画像を持たない。ハウスキーピング同期コードがたくさん必要になります。

プラットフォームに取り組んでいる開発者は、両方のテクノロジスタックの専門知識が必要です。特定のユーザーのコメント数が間違っているように見える理由をデバッグしようとしているとします。

これで、NoSQLまたはSQLデータベースのいずれかが失敗した場合、システム全体が壊れます。また、障害とは、パフォーマンスの問題、アップグレードの問題、バックアップの問題など、クラッシュを意味するものではありません。

ソフトウェアソリューションではデータの一部を所有する複数のシステムを持つことは珍しくありません。通常、分割はビジネスドメインの行に沿って行われます（CRMシステムではプロファイル、クレジットカードの詳細な支払いシステム、eコマースシステムではあなたが注文したもの）;テクニカルラインに沿って部門を分割すると、複数の障害点を持つ複雑なアーキテクチャが作成されます。

私はこれらの欠点を上回る利点はないと思います。