2

大規模なデータベースに基づいて、かなり大規模なRubyonRailsアプリケーションを作成する必要があります。このデータベースは毎日更新され、各テーブルには約500 000レコード（またはそれ以上）があり、この数は時間の経過とともに増加します。また、参照整合性とともに、すべてのデータの適切なバージョン管理を提供する必要があります。ユーザーがバージョン間を移動できる必要があります。これは、さまざまな時点でのメインデータベースの一種の「スナップショット」です。さらに、データの一部は、APIを使用して他の外部アプリケーションに提供する必要があります。

大量のデータを考慮して、データベースを分割することを考えました。

  1. 現時点でのデータの状態

  2. 各テーブルのバージョン管理された属性

  3. 特定の過去の時点での最初のデータベースのスナップショット

それらのそれぞれに独自のアプリケーションがあり、データと対話するためのAPIを使用してサービスを作成します。複数のデータベースに直接接続する複数のアプリケーションを作成したくないため、これが必要です。

問題は、これが適切なアプローチですか？そうでない場合、あなたは何を提案しますか？

私たちはこれほどの規模のプロジェクトを経験したことがなく、可能な限り最良の解決策を見つけようとしています。この種のデータ分離に意味があるかどうかはわかりません。もしそうなら、これも必要になるので、個々のサービスと、そしてサービス自体の間で異なるアプリケーションの適切な通信を提供する方法。

4

1 に答える 1

1

一般に、テーブル内のデータの量を最初に気にする必要はありません。PostgreSQLには、大きなテーブルに対するクエリを最適化するための非常に多くのオプションがあります。より大きな質問は、正確に何を、いつ、そしてなぜ照会しているのかと関係があります。クエリの読み込みは、データの量よりも常に大きな懸念事項です。10年間の財務データが400万行になるのは1つのことです。当座預金口座の残高を判断するために、これらの10年間のデータを集計する必要があるのは別のことです。

一般的に、あなたはそのような集合体に依存するシステムを作成しようとしているように私には聞こえます。その場合、私は次のアプローチをお勧めします。これをlog-aggregate-snapshotと呼びます。これには、基本的に3つの補完的なモデルがあり、これらが連携して最新の高性能ソリューションを提供します。ただし、これに関する制限は、認識して理解することが重要です。

  1. イベントモデル。これは追加のみで、更新はありません。このモデルでは、挿入が発生し、一部のメタデータの更新は、絶対に必要な場合にのみ一部のクエリに使用されます。金融アプリケーションの場合、これはジャーナルエントリと行を表すテーブルになります。

  2. 骨材クロージングモデル。これは追加のみです（ただし、期間を再開する目的で削除は許可されています）。これにより、特定の目的のためのロールフォワード情報が提供されます。クロージングエントリが入力されると、クローズされた期間はエントリを作成できなくなります。財務アプリケーションでは、これは決算残高を表します。新しい残高は、集計ポイントから開始してロールフォワードすることで計算できます。部分インデックスを使用して、必要なデータだけを簡単に取得することもできます。

  3. 補助データモデル。これは、他のモデルへの整合性が妨げられない限り、更新、挿入、および削除を許可する小さなテーブルで構成されます。金融アプリケーションでは、これは顧客またはベンダーのデータ、従業員のデータなどのようなものである可能性があります。

于 2013-04-06T03:43:48.500 に答える