16

Facebook や Flickr ( http://www.flickr.com/activity ) などで見られるような、他の非リレーショナル データベースがアクティビティ ストリームに適しているかどうか疑問に思っています。 MySQL を使用していますが、かなり負担が大きく (私は数千万のアクティビティ レコードを持っています)、それらは基本的に一度書き込まれると読み取り専用であり、常に時系列で表示されるため、別の DB がうまく機能する可能性があると考えていました。

活動は次のようなものです。

  • 午後6時：ジョンはベーコンがお気に入り
  • 17:30: Jane が Snow Crash についてコメントしました
  • 17:15: ジェーンはベーコンの写真をアルバムに追加しました

問題は、Twitter やその他のシステムとは異なり、アクティビティに関心のある各ユーザーのリストに単にアクティビティを追加することはできないということです。できれば、Redis が(リスト操作で) 適切に機能するように見えます。

次のことができる必要があります。

  • あなたがフォローしているユーザーのセットまたはサブセット("John" と "Jane") のアクティビティを日付の逆順でプルします
  • モノ (「ベーコン」など) のアクティビティを日付の逆順でプルする
  • アクティビティの種類 (「お気に入り」、「コメント」) で絞り込む
  • 少なくとも 3,000 万のアクティビティを保存
  • 理想的には、フォローしているユーザーを追加または削除した場合、アクティビティ ストリームに変更が反映されます。

私はMySQLでこれを行ってきました。私の「アクティビティ」テーブルは可能な限りコンパクトで、キーは可能な限り小さく、適切にインデックスが付けられています。機能しますが、この仕事には不適切なツールのように感じます.

従来の RDBMS 以外で、このようなことを行っている人はいますか?

2009 年 11 月の更新: 私自身の質問に答えるのは時期尚早ですが、私の現在の解決策は、MySQL に固執し、新しいアクティビティ ストリーム データへの高速アクセスのために Redis を強化することです。ここでの私の答えの詳細：ソーシャル ネットワークでアクティビティ ストリームを実装する方法...

2014 年 8 月の更新: 数年後、私はまだ MySQL を記録システムとして使用し、Redis を使用して各ユーザーの最新のアクティビティに非常に高速にアクセスしています。pt-online-schema-change のおかげで、大規模な MySQL テーブルでのスキーマ変更の処理は問題ではなくなりました

4

6 に答える 6

5

状況を完全に理解するまで、MySQL (または RDBMS) を使用することをお勧めします。

どのくらいのパフォーマンスやデータを使用する予定かはわかりませんが、30M 行はそれほど多くありません。

特定の範囲スキャンを最適化する必要がある場合は、(たとえば) InnoDB を使用して、(暗黙的にクラスター化された) 主キーを慎重に選択し、必要に応じて非正規化することでこれを行うことができます。

ただし、ほとんどの場合と同様に、まず動作させてから、運用グレードのハードウェアのパフォーマンス テスト ラボで検出されたパフォーマンスの問題を修正します。

編集：その他のポイント：

  • Cassandra、Voldermort などのキー/値データベースは、通常、セカンダリ インデックスをサポートしていません。
  • したがって、CREATE INDEX を実行することはできません。
  • それらのほとんどは、ハッシュを使用してパーティショニングを実装しているため (メイン インデックスでも) レンジ スキャンを実行しません (ほとんどの場合実行します)。
  • したがって、範囲の有効期限も行いません (DELETE FROM tbl WHERE ts < NOW() - INTERVAL 30 DAYS)
  • アプリケーションは、これらすべてを自分で行うか、アプリケーションなしで管理する必要があります。セカンダリインデックスは本当にキラーです
  • ALTER TABLE ... ADD INDEX は、大きなテーブルを持つ MySQL などではかなり長い時間がかかりますが、少なくともそれを行うために多くのコードを書く必要はありません。「nosql」データベースでも長い時間がかかりますが、新しいセカンダリ インデックスを維持し、それを正しく期限切れにし、それを使用するようにクエリを変更するために、大量のコードを記述する必要があります。

要するに...キー/値データベースをショートカットとして使用して、ALTER TABLEを回避することはできません。

于 2009-08-27T20:25:08.657 に答える
2

あなたがやりたいこと - いくつかの異なる方法で大量のデータセットをクエリし、結果を並べ替える - は、RDBMeS が設計された目的とまったく同じように思えます。

これを行うデータストアや、最新の商用 DBMS (Oracle、SQLServer、DB2 など) や、MySql よりも優れたこれを実現するオープンソース ツールを見つけることができるとは思えません。

Google の BigTable を見ることができます。これは実際にはリレーショナル データベースですが、プログラムに「オブジェクト」の個性を与えることができます。自由形式のテキスト検索や複雑な述語に非常に適しています。全体 (少なくともダウンロードできるバージョン) は Python で実装されているため、クエリ マラソンで MySql に勝るとは思えません。

于 2009-09-07T06:43:18.427 に答える
2

また、SQL からの移行も計画しています。私は有望に見えるCouchDBを見てきました。あなたの要件を見ると、すべて CouchDB ビューとリスト API で実行できると思います。

于 2009-08-27T18:21:30.437 に答える
1

メッセージキューテクノロジーについて学ぶことをお勧めします。利用可能ないくつかのオープンソースオプションがあり、また、小さなスナックとして説明するボリュームを提供する堅牢な商用製品もあります。

于 2009-09-07T05:53:08.153 に答える
1

CouchDBはスキーマがなく、インデックスのみを操作しているため、膨大な量のデータをすばやく簡単に取得できます。毎回データベースを「クエリ」するのではなく、一致するキーのみを取得します（事前にソートされているため、さらに高速になります）。

「ビュー」は、新しいデータがデータベースに入力されるたびに再インデックス化されますが、これはユーザーに対して透過的に行われるため、更新されたビューの生成に遅延が生じる可能性がありますが、結果の取得に遅延が生じることは事実上ありません。

CouchDB を使用して「アクティビティ ストリーム」ソリューションを構築することを検討し始めたばかりですが、パラダイムが異なるため、プロセスに関する私の考え方は SQL の考え方から変更する必要がありました。

必要なデータをクエリしてページ上で処理する方法を理解するのではなく、すべてのドキュメントを日付でキー設定するビューを生成するので、基本的に適切な日付キーを使用するだけで、複数のデータ グループを簡単に作成できます。複数のクエリを同時に実行しますが、パフォーマンスの低下はありません。

これはアクティビティ ストリームに最適で、すべてを日付で分離できます。また、日付の分離とともに、必要に応じてビューを作成することで、特定のサブタイプの結果などをさらにフィルター処理できます。 CouchDB のデータは JSON であるため、事実上すべてをクライアント側で実行してページをレンダリングできます。

于 2009-09-15T20:21:08.323 に答える
1

あるプロジェクトで、ルックアップが高速で、多くのルックアップと時折の書き込みだけを行う単純なデータベースが必要でした。独自のファイル形式を作成することになりました。

これを行うこともできますが、特に Web サーバーからサポートする必要がある場合は、かなり複雑です。Web サーバーでは、少なくともファイルへのすべての書き込みを保護し、複数のスレッドから読み取れるようにする必要があります。このファイル形式の設計は、十分なテストと実験を行って、可能な限り適切に解決する必要があります。このスタイルの Web プロジェクトでは、小さなバグが 1 つでも致命的となる可能性がありますが、うまく機能するようになれば、非常に高速に機能する可能性があります。

しかし、99.999% の状況では、このようなカスタム ソリューションは必要ありません。ハードウェアをアップグレードし、Oracle、SQL Server、または InterBase に移行し、専用データベース サーバーを使用し、より高速なハードディスクを使用し、メモリを増設し、64 ビット システムにアップグレードする方が簡単です。これらは、最小限の労力でパフォーマンスを向上させるためのより一般的なトリックです。

于 2009-08-27T19:31:45.503 に答える