0

いくつかのビジネスエンティティにサービスを提供するサービスを設計しています。論理的には、次の 2 つの部分に分割されます。

  1. フロントエンド - Wiki、価格設定、ランディング ページ、場合によってはアカウント情報 (請求、アカウント ステータスなど) などの付属品。
  2. ビジネスエンティティの雇用者が自分の仕事をするサービス自体。

play 2.x フレームワークで、heroku でホストする予定です。インスタンスと DB のものを分解する方法は今のところ明確ではありません。

クライアントの DB を分解する必要があります: ビジネス エンティティ - 1 つのデータベース? または、すべてのデータを 1 つのデータベースに保存する必要がありますが、行を所有するビジネス エンティティのすべてのテーブル ID を追加する必要がありますか? この決定により、どのような問題 (パフォーマンス、管理、スケーリング) が発生する可能性がありますか?

データベースを分割する場合、どのようにすればよいですか? そのためには、インスタンスが属するクライアントの DB を使用してアプリ インスタンスを起動する必要があります。したがって、スケーリングの障害になる可能性のある不均一なインスタンスがあります。私が知っているように、heroku は不均一な (Web) インスタンスをサポートしていません。

助けてください、私はここで完全に立ち往生しています。

期待されるスタック:

  • スカラ
  • プレイ2.0
  • アノーム
  • JDBC
  • PostgreSQL
  • ヘロク

これはすべて (Scala を除き、Play 2.0 の場合もあります) 交換可能です。

4

1 に答える 1

1

これはかなり古典的な問題です。多くのクライアントがあり、クライアントごとに個別のデータベースを作成する必要があるのか​​、それともデータベースを共有する必要があるのか​​疑問に思います。

1つの共有データベースから始めて、それを拡張するまで使用することをお勧めします。各クライアントに独自のデータベースインスタンスを設定することの欠点をいくつか考えてみてください。

  1. おっしゃるように、スキーマ管理は難しい場合があります。すべてのサーバーにわたってすべてのデータベースを維持するためのツールを作成する必要があります。

  2. システムをこのように構成したことをクライアントに伝えると、一部のクライアントがデータベースをフォークするようにプッシュする可能性があります。言い換えれば、彼らは「私は自分のデータベースを持っています！私のためだけに新しいテーブルが欲しい」と主張するかもしれません。

  3. サーバー/データベース間でクエリを実行するのは少し難しいです。すべてのクライアントが持っているアイテムの数を数えたい場合は、それについて少し考える必要があります。

ただし、クライアント（ http://en.wikipedia.org/wiki/Shard_(database_architecture） ）に基づいてシャーディングを開始する場合は、次のことを検討してください。

  1. 前述のように、クライアントの新しいデータベースインスタンスを起動するには、いくつかのツール/スクリプトが必要です。多くの場合、これらのツールは、データベースに構成情報を「シード」する必要があります。たとえば、住所の状態テーブルにデータを入力する必要があります。

  2. データベースを監視/保守するためのツールが必要になります。1つを開始し、もう1つを停止し、CPU使用率が高いかどうかを確認します。

  3. すべてのクライアントの統計を集約するには、ある種のシステムが必要です。

  4. スキーマの変更をロールアウトするためのツールと、Webアプリケーションの実行中にデータベースを適切にアップグレードする方法に関する計画が必要になります。

全体として、私は小さくて単純なものから始めて、そこに着いたときにのみ規模について心配し始めることをお勧めします。

于 2013-02-24T19:06:50.437 に答える