17

MongoDB/NoSQL スキーマを学ぶ機会として、MongoDB プロジェクトを開始しています。これはライブ チャット アプリで、スタックには Rails 3、Ruby 1.9.2、Devise、Mongoid/MongoDB、CarrierWave、Redis、JQuery が含まれます。

ライブ チャットのポーリングとメッセージのキューイングを別々に処理します。Node.js、APE、またはカスタム EventMachine アプリのいずれかです。しかし、Mongo に関しては、アプリ内の他のすべて、特にチャット ログと履歴トランスクリプトに使用することを考えています。

私の質問は、私の以前の経験はすべて MySQL とリレーショナル DB スキーマであったため、どのようにスキーマを設計するのが最善かということです。サブ質問として、埋め込みドキュメントと関連ドキュメントのどちらが最適かという質問があります。

アプリには次のものがあります。

  • 複数の部屋を持つ複数のアカウント
  • 複数の部屋
  • 部屋ごとに複数のユーザー
  • ユーザーが入ることを許可されているルームのリスト
  • ルームごとに複数のユーザー チャット
  • 部屋ごと、ユーザーごとに検索可能なチャットログ
  • 特定のチャットのオプションの添付ファイル

Mongo (少なくとも最後に確認したとき) には 4MB のドキュメント制限があるため、ルームのコレクションを作成し、すべてのルーム チャットを埋め込みドキュメントとして保存することはうまくいかないと思います。

これまで考えてきたことから、次のようなことを考えています。

  • アカウントのコレクション
  • 部屋のコレクション
    • 各部屋はアカウントに関連付けられています
    • ルーム内のすべてのチャット メッセージのチャット コレクション内の関連ドキュメント
    • 現在ルームにいるすべてのユーザーを一覧表示する埋め込みドキュメント
  • ユーザーのためのコレクション
    • ユーザーが現在いるすべてのルームを一覧表示する埋め込みドキュメント
    • ユーザーが入ることを許可されているすべての部屋を一覧表示する埋め込みドキュメント
  • チャットのコレクション
    • 各チャットはルーム コレクション内のルームに関連付けられます
    • 各チャットはユーザー コレクション内のユーザーに関連付けられます
    • オプションのアップロードされた添付ファイルに関する情報を含む埋め込みドキュメント。

私の主な関心事は、これが最終的にリレーショナル スキーマのように見えて目的を破るまで、どこまで行くかということです。埋め込みよりも関連性が高いことは間違いありません。

もう 1 つの懸念事項は、関連ドキュメントの参照は、私が聞いた埋め込みドキュメントへのアクセスよりもはるかに遅いということです。

次のような一般的なクエリを作成したい:

  • アカウントのすべての部屋をくれ
  • ルーム内のすべてのチャットを教えてください (または日付範囲でフィルター処理)
  • 特定のユーザーからのすべてのチャットを受け取る
  • 特定の会議室または特定の組織にアップロードされたすべてのファイルを提供する
  • 等

スケールする方法でスキーマを効率的に構造化する方法について何か提案はありますか? みんな、ありがとう。

4

2 に答える 2

5

あなたはかなり正しい軌道に乗っていると思います。チャット ラインにはキャップ付きのコレクションを使用し、各ラインにはユーザー ID、ルーム ID、タイムスタンプ、発言内容が含まれます。このデータは、上限付きコレクションの「終了」に達すると期限切れになるため、履歴ログが必要な場合は、上限付きコレクションから定期的にデータを「ログ」コレクションにコピーする必要がありますが、上限付きコレクションはロギング用に特別に設計されています-ドキュメントを削除しないスタイルのアプリケーションで、挿入順序が重要です。チャットの場合は相性バッチリです。

私が提案する他の唯一の変更は、アップロードを別のコレクションにも維持することです。

于 2010-09-07T05:58:32.133 に答える
2

私は、ドキュメント データベースとしての mongodb の大ファンでもあります。しかし、正しい理由でmongodbを使用していると確信していますか? mongodb は何が強力ですか?

これは主観的な質問ですが、私にとってはドキュメントのインプレース (アトミック) 更新が mongodb を強力なものにしています。そして、私はあなたがそれをそんなに使っているのを見ることができません。それに加えて、ドキュメントサイズの制限の問題にも直面しています（経験上、ファイルをmongodbに埋め込むことはお勧めできません）。データベースの上にもライブチャットアプリケーションが必要です。

ドキュメント スキーマは論理的に見えます。しかし、アプリケーションが挿入に大きく依存しているこの種のプロジェクトでは、mongodb を使用しません。私はCouchDBに行きます。

CouchDB を使用すると、添付ファイルの問題を心配する必要がなくなり、簡単に埋め込むことができます。"_changes" を使用すると、ライブ チャット アプリケーション / ロング プーリング / フィード検索エンジン (実装したい場合) を構築するのがずっと簡単になります。

そして、couchone でオープンソースのショーケース プロジェクトを見ました。それはあなたの目標といくつかの類似点があります: Anologue。あなたはそれをチェックアウトする必要があります。

PS : 申し訳ありませんが、トピックから少し外れましたが、我慢できませんでした。

于 2011-03-01T22:45:19.560 に答える