1

私は機能に取り組んでおり、この問題を解決するためにどのデータベースを使用すべきかについての意見を使用することができます。

MySQLを使用したRailsアプリケーションがあります。MySQLに問題はなく、正常に動作します。ただし、新機能については、MySQLを使用するかどうかを決定しています。問題を単純化するために、モデルがあるUserと仮定しましょう。Messageユーザーはメッセージを作成できます。メッセージは、投稿者との関連付けに基づいて他のユーザーに配信されます。

明らかに友情に基づく関連付けがありますが、ユーザーのプロファイルに基づく関連付けはもっとたくさんあります。ポスターに関するメタデータをメッセージと一緒に保存する予定です。これにより、メッセージをクエリするたびにメタデータを取得する必要がなくなります。

したがって、メッセージは次のようになります。

{
  id: 1,
  message: "Hi",
  created_at: 1234567890,
  metadata: {
    user_id: 555,
    category_1: null,
    category_2: null,
    category_3: null,
    ...
  }
}

メッセージをクエリするときは、0個以上のメタデータ属性に基づいてクエリできる必要があります。この呼び出しは高速である必要があり、非常に頻繁に発生します。

メタデータ属性の数とクエリに含めることができる数が多いため、ここでSQLインデックスを作成することはお勧めできません。

個人的には、MySQLとMongoDBの経験があります。Cassandra、HBase、Riak、CouchDBの研究を始めました。どのデータベースが私のタスクに適しているかについて調査を行った可能性のある人々の助けを借りることができます。

そして、はい、メッセージテーブルは簡単に数百万または行に成長する可能性があります。

4

6 に答える 6

4

これは非常に自由形式の質問なので、私たちにできることは経験に基づいてアドバイスを与えることだけです。最初に考慮すべきことは、使い慣れたMySQLを使用する代わりに、これまで使用したことのないものを使用することを決定することをお勧めするかどうかです。機会があれば光沢のある新しいものを使わないのは退屈ですが、新しいおもちゃは箱に書かれていることをすべてやってくれるので、隅に自分を描いたときはひどいことだと私は信じています。ブログの投稿に書かれているように機能するものはありません。

私は主にMongoDBの経験があります。さまざまなことを試して、それらが機能しないことに気付くのに多くの時間を費やしたいのでなければ、それはひどい選択です。少しスケールアップすると、基本的に、セカンダリインデックス、更新など、Mongoを他の点では非常に優れたツールにするものを使用できなくなります（これのほとんどは、グローバル書き込みロックとディスク上のデータベース形式に関係しています。基本的に、データを削除すると、同時実行性とフラグメント化が非常に簡単になります）。

HBaseが問題外であり、セカンダリインデックスがないことに同意しませんが、特定のトラフィック負荷を超えると、とにかくそれらを使用できなくなります。同じことがCassandraにも当てはまります（HBaseよりもデプロイと操作が簡単です）。基本的に、どのソリューションを選択しても、独自のインデックスを実装する必要があります。

考慮すべきことは、可用性の一貫性が必要な場合、またはその逆（たとえば、メッセージが失われたり遅延したりした場合の悪さと、ユーザーがメッセージを投稿または読み取れない場合の悪さ）などです。データを更新する場合（たとえば、Riakのデータは不透明なblobです。変更するには、データを読み取って書き戻す必要があります。Cassandra、HBase、MongoDBでは、最初にオブジェクトを読み取らずにプロパティを追加および削除できます）。使いやすさも重要な要素であり、Mongoはプログラマーの観点からは確かに使いやすく、HBaseは恐ろしいものですが、厄介なものをカプセル化する独自のライブラリを作成するのに少し時間をかけるだけで、それだけの価値があります。

最後に、私に耳を傾けないで、それらを試してみて、それらがどのように機能し、どのように感じるかを確認してください。できるだけハードにロードするようにし、実行するすべてのことをテストするようにしてください。私は、MongoDBで大量のデータを削除したときに何が起こるかをテストしないという間違いを犯し、その代償を払っています。

于 2011-08-19T09:58:25.020 に答える
3

メッセージングにMySQLなどのデータベースを使用すべきではないという事実に主に焦点を当てた、データベースがメッセージングを嫌う理由についてのプレゼンテーションを確認することをお勧めします。

このシナリオでは、CouchDBの変更フィードが非常に便利な場合がありますが、メッセージメタデータのクエリに基づいてより複雑なビューを作成する必要があるかもしれません。速度が重要な場合は、redisも調べてみてください。これは非常に高速で、 pub/sub機能が付属しています。アドホッククエリをサポートするMongoDBも、このユースケースに適したソリューションになる可能性があります。

于 2011-08-19T08:25:52.480 に答える
3

あなたは各メッセージと一緒にメタデータを保存することにスポットを当てていると思います！取得時間を短縮するためにストレージを犠牲にすることは、おそらく進むべき道です。ユーザーのメタデータを変更し、それをすべてのメッセージに伝達する必要がある場合は、複雑になる可能性があることに注意してください。それが発生する可能性のある頻度、実際にすべてのメッセージレコードを更新する必要があるかどうか、それに基づいて、クエリを減らすために料金を支払う価値があるかどうかを検討する必要があります（おそらくそれだけの価値がありますが、それはシステムの詳細）。

@Andrej_Lは、Hbaseがこの問題の適切な解決策ではないことに同意します。カサンドラも同じ理由でそれに陥ります。

CouchDBで問題を解決することはできますが、クエリするメタデータのビュー（マテリアライズドインデックス）を定義する必要があります。ここでMySQLを使用しないことの全体的なポイントが、すべてのインデックス作成を回避することである場合、Couchもおそらく適切なソリューションではありません。

Riakは、map-reduceを使用してデータをクエリするため、はるかに優れたオプションです。これにより、ソファのようにすべてのデータに事前にインデックスを付ける必要なしに、好きなクエリを作成できます。何百万もの行はRiakにとって問題ではありません-そこに心配はありません。必要が生じた場合は、ノードを追加するだけで非常に適切に拡張できます（また、それ自体のバランスを取ることもできるため、これは実際には問題になりません）。

ですから、私自身の経験に基づいて、Riakをお勧めします。ただし、あなたとは異なり、私はMongoDBを直接経験したことがないので、Riakに対して自分で判断する必要があります（または、ここにいる他の誰かがそれに答えることができます）。

于 2011-08-19T08:29:11.147 に答える
2

私のHbaseの経験から、アプリケーションに適したソリューションではありません。なぜなら：

  1. デフォルトではセカンダリインデックスは含まれていません（プラグインなどをインストールする必要があります）。したがって、主キーのみで効果的に検索できます。hbaseと追加のテーブルを使用してセカンダリインデックスを実装しました。したがって、結果を取得するにはmap / reduceジョブを実行する必要があり、数百万のデータに対して多くの時間がかかるため、これをオンラインアプリケーションで使用することはできません。

  2. このデータベースをサポートおよび調整することは非常に困難です。効果的な作業を行うには、HadoopでHBAseを使用します。これには、強力なコンピューターまたは複数のコンピューターが必要です。

  3. Hbaseは、大量のデータに関する集計レポートを作成する必要がある場合に非常に役立ちます。必要ないようです。

于 2011-08-19T08:02:44.957 に答える
1

メタデータ属性の数とクエリに含めることができる数が多いため、ここでSQLインデックスを作成することはお勧めできません。

参加が必要なようです。そのため、作業中のマルチビューコードを整理するまで、CouchDBのことをほとんど忘れることができます（実際にはまだ作業中かどうかはわかりません）。

于 2011-08-19T11:54:40.157 に答える
1

Riakは、ノードに応じて、作成するのと同じ速さでクエリを実行できます

Mongoを使用すると、配列であっても、任意のフィールドにインデックスを作成できます。

CouchDBは非常に異なり、「ビュー」と呼ばれる保存されたMap-Reduce（ただしreduceなし）を使用してインデックスを構築します。

RethinkDBを使用するとSQLを使用できますが、TokuDBも少し高速になります

Redisはすべての速度で殺しますが、完全にRAMに保存されます

単一レベルの関係はそれらすべてで行うことができますが、それぞれで異なります。

于 2011-12-06T05:51:12.793 に答える