7

ampq または xmpp (rabbitmq または ejabbered、バックエンドとしてカウチデータベースを持つことができる) を使用することは、更新が小さいが頻繁に行われるソーシャル ゲーム プラットフォームでフレンドの状態に関するリアルタイムの更新を配信するのに適しているように思えますが、なぜそうなるのか考えずにはいられません。そのような更新を配信するのに、couchdb は良いプラットフォームではないでしょうか?

私が考えることができる主な利点は、友人と変更APIの可用性に基づいて更新をフィルタリングする機能です。これにより、そのようなアプリケーションの開発とその管理（レプリケーションを含む）が、方法を考える必要があるampqやxmppと比較して非常に簡単になります。 pubsub ノードを管理し、いつでも誰がサブスクライブしているかを管理します。

しかし、これはうますぎると思わずにはいられません。couchdb の欠点に関する情報が見つかりません。どういうわけか、メッセージ パッシングに MySQL を使用しているように感じます。

そのようなアプリケーションにcouchdbを使用した経験のある人はいますか? 使用する別のプラットフォームをお勧めしますか?

4

3 に答える 3

6

「小さいが頻繁な」更新とCouchDBで発生する問題がいくつかあります。

CouchDBには、ドキュメント更新用の優れたMVCCシステムがあります。更新するたびにリビジョンが変更され、更新するリビジョンを渡さずにドキュメントを更新することはできません。これは、複数のクライアントが同じドキュメントを非常に頻繁に更新している場合、変更フィードを使用しても更新後のネットワーク遅延がわずかになるため、この機能が邪魔になることも意味します。

フィルタされた変更を使用する場合のもう1つの問題は、フィルタ関数がリクエストオブジェクトを取得することです。つまり、ドキュメントごとにビューサーバーを個別に呼び出し、接続数を掛けたものになります。代わりに、node.jsまたはerlangサーバーを使用して、フィルタリングを変更するための「チャネル」アプローチを実装し、フィルタリングされていない単一の変更フィードに配置することをお勧めします。

要約すると、同じドキュメントを高頻度で更新しようとする複数のクライアントがなく、データベースが多い非常に多数の同時クライアントで変更フィルターを使用しない場合、実行したいことはうまく機能します。更新頻度。それ以外は、うまくいくでしょう。@jchrisは、ベアチェンジフィードを使用するだけで大​​量のリアルタイムアプリケーションを実行しており、それらはうまく機能します。

于 2010-05-27T05:41:13.333 に答える
2

しかし、私は仕方がないのですが、これはあまりにも良すぎて真実ではないと思います。couchdbの欠点についての情報を見つけることができません。どういうわけか、メッセージパッシングにMySQLを使用しているように感じます。そのため、私はMySQLを使用することを躊躇しています。

データベースがメッセージングプレゼンテーションを嫌う理由を見てみてください。これは主にMySQLなどのデータベースを対象としていますが、このトピックに関する全体像を把握することができます。

于 2011-08-18T07:11:49.260 に答える
1

非常に単純な理由が 1 つ考えられます...データベースはこれを行うように設計されていないからです!

メッセージ キューはまさにこの種のワークフローに必要なものです。AMQP ベースの製品やサービスを見たことがありますか? これらには、RabbitMQ (ローカルにインストール) と StormMQ (クラウド ベースのサービス) が含まれます。詳細はこちら: http://www.amqp.org

于 2011-08-18T06:54:32.193 に答える