数十億のレコードアプリのフロントエンドとしてのRuby On Rails / Merb

Question

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

HBase と Hadoop

Couchdb

HBaseソリューションに問題があるようです。ルビーのサポートはそれほど強くなく、Couchdbはまだ1.0バージョンに達していません。

このような大量のデータに何を使用するか提案がありますか？

データには、一度に30〜40 MBのかなり速いインポートが必要になることがありますが、インポートは大量に行われます。したがって、データの約95％が読み取り専用になります。

Answer 1

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

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

これらのシステムのいくつかでデータを実際にプロファイルし、そこからデータを取得することをお勧めします。

Answer 2

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

たとえば、「1秒間に発生する挿入/更新の数」。このような質問は、選択するバックエンドデータベースソリューションの決定に影響します。

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

Answer 3

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が提供するものを確認してください。

Answer 4

バックエンドはデータとデータへのアクセス方法に依存します。

しかし、ORMの場合は、DataMapperを使用し、カスタムDataObjectsアダプターを作成して、選択したバックエンドにアクセスできるようにします。

Answer 5

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

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

CouchDBには、読み取りが多いアプリケーション向けの最適化も数多くあります。私の経験に基づいて、CouchDBは非常に優れています。