4

Ruby on Rails または Merb で記述された、数十億のレコードを持つデータを処理するアプリケーションのバックエンド ソリューションを探しています。私は分散モデルを使用することになっていると感じていますが、現時点では

HBaseとHadoop

カウチデブ

私が見た HBase ソリューションの問題 -- Ruby のサポートはあまり強力ではなく、Couchdb はまだバージョン 1.0 に達していません。

このような大量のデータに何を使用するかについての提案はありますか?

データは、時には一度に 30 ～ 40Mb のかなり高速なインポートを必要としますが、インポートはチャンクで行われます。そのため、データの約 95% は読み取り専用になります。

4

5 に答える 5

1

実際のデータ使用量にもよりますが、MySQL または Postgres は、適切なハードウェアで数十億のレコードを処理できるはずです。特定の大量のリクエストがある場合は、これらのデータベースの両方を複数のサーバーに複製できます (また、読み取り複製は、(複数のマスター/書き込み複製と比較して) セットアップが非常に簡単です)。

Rails または Merb で RDBMS を使用することの大きな利点は、これらのタイプのデータベースにアクセスするための優れたツール サポートのすべてにアクセスできることです。

私のアドバイスは、これらのシステムのいくつかで実際にデータをプロファイリングし、そこから取得することです.

于 2009-02-01T22:16:19.820 に答える
1

HBase およびその性質の他のプロジェクトに関する警告の言葉 (CouchDB については何も知りません。実際には db ではなく、単なるキー値ストアであると思います):

  1. Hbase は速度に合わせて調整されていません。スケーラビリティに合わせて調整されています。応答速度がまったく問題になる場合は、このパスにコミットする前に、いくつかの概念実証を実行してください。
  2. Hbase は結合をサポートしていません。ActiveRecord を使用していて、複数のリレーションがある場合は、これがどこに向かっているのかがわかります。

同じく Hadoop の上に構築された Hive プロジェクトは、結合をサポートしています。Pigもそうです（しかし、実際にはSQLではありません）。ポイント1は両方に当てはまります。これらは重いデータ処理タスク用であり、Rails で実行する可能性のあるタイプの処理用ではありません。

Web アプリのスケーラビリティが必要な場合、基本的に機能する唯一の戦略は、データをパーティション分割し、パーティションが分離されるようにできる限りのことを行うことです (相互に通信する必要はありません)。Rails では、デフォルトで中央データベースが 1 つあると想定されているため、これは少し注意が必要です。約1年半前にこの問題を見て以来、その面で改善があったかもしれません. データを分割できる場合は、水平方向にかなり広くスケーリングできます。1 台の MySQL マシンで数百万行を処理できます (PostgreSQL はおそらくより多くの行にスケーリングできますが、動作が少し遅くなる可能性があります)。

機能するもう 1 つの戦略は、すべての書き込みがマスターによって行われ、読み取りがスレーブ (および場合によってはマスター) 間で共有される、マスター/スレーブをセットアップすることです。明らかに、これはかなり慎重に行う必要があります。読み取り/書き込み比率が高いと仮定すると、これはかなりうまくスケーリングできます。

組織に潤沢な資金がある場合は、Vertica、AsterData、および Greenplum が提供するものを確認してください。

于 2009-02-01T22:34:51.780 に答える
1

人々が使用してきたさまざまなソリューションが数多くあります。私の経験では、テーブルごとの行数ではなく、そのデータに関連する使用パターンに大きく依存します。

たとえば、「1 秒あたりの挿入/更新の回数」などです。このような質問は、どのバックエンド データベース ソリューションを選択するかを決定する際に役立ちます。

Google を例にとると、彼らのニーズを満たすストレージ/検索ソリューションは実際には存在しなかったため、Map/Reduce モデルに基づいて独自のソリューションを作成しました。

于 2008-11-04T20:13:09.697 に答える
0

CouchDBが1.0になっていないことが、それと何の関係があるのか​​わかりません。それを使っていくつかのテストを行い（10億のランダムなドキュメントを生成するだけ）、それが耐えられるかどうかを確認することをお勧めします。特定のバージョン番号がないにもかかわらず、そうなると思います。

CouchDBデータベースにはスキーマがないため、データのパーティション化/シャーディングなど、プロジェクトに適合する可能性がある場合、特にデータ形式が将来変更される可能性がある場合（フィールドの追加または削除）、CouchDBは非常に役立ちます。 。

CouchDBには、読み取りが多いアプリ向けにも多くの最適化があり、私の経験に基づいて、それが本当に輝いています。

于 2009-02-10T19:35:10.890 に答える
0

バックエンドは、データとデータへのアクセス方法によって異なります。

しかし、ORM については、DataMapper を使用し、カスタム DataObjects アダプターを作成して、選択したバックエンドに到達する可能性が最も高いでしょう。

于 2008-11-12T20:20:03.940 に答える