ホストされたWebアプリケーションを設計する方法は？

Question

ホストされたWebアプリケーションをどのように設計しますか？ユーザーがオンラインでサインアップでき、アプリケーションがホストされているBasecamp、Campaign Monitor、Freshbooksなどのアプリケーションを探しています。

1. 1つの大きなデータベースを使用して顧客のすべてのデータを保存しますか、それともデータを異なる方法で処理しますか？複数のデータベースを使用しますか？顧客ごとにデータベースを作成しますか？
2. サインアップ/顧客ごとにコードベースを複製しますか、それとも1つのコードベースを使用してすべての顧客を処理しますか？
3. 他に考慮すべき設計要素はありますか？
4. これについて語るウェブサイトや本はありますか？

編集： マルチテナントのデータアーキテクチャについて説明したMSDNの記事を見つけました。 http://msdn.microsoft.com/en-us/library/ aa479086.aspx＃mlttntda_topic4

Answer 1

37signalsを参照してください-彼らはこの分野の専門家であり、コミュニティの質問に答える多くの記事を持っています（あなたのようなものが出てくるはずです）。

高いスケーラビリティ= 37signalsアーキテクチャ

質問37signals：方法クレジットカードを処理しますか？

データベースの数に関しては、David Heinemeier Hanssonの何を知りたいですか？

  

いくつかの技術的な回答＆＃8230;

     

ランス、すべてのスケジュール済み請求   操作は自動化されています。何でも   それは私たちを狂気に駆り立てるでしょう。   確認することは特に重要です   緊急時対応が整っていること   失敗したクレジットカード。最後の私   見て、私たちの請求の5％を信じています   クレジットカードのおかげで跳ね返った   期限切れ、制限を超えた、または   閉まっている。それを処理するようにしてください   優雅に。

     

Authorize.netと   個別のクレジットカードアプリケーション（小さな   Railsで開発され、   内部ネットワーク上の他のアプリ   RESTを介して）   安全。

     

ウォーレン、無料アカウントと有料アカウントを実行しています   同じデータベース上。それは一つです   アプリケーションごとのデータベース。 1つのデータベース   通常、アカウントごとに本当に、   本当に悪い考え。通常、データは   かなり正規化されていますが、私たちは   絶対に宗教的ではありません。私   一般に、ソースコードを   スキーマ。だから私が得ることができれば   曲げることによるより良い/きれいなソースコード   スキーマ、私は通常それを行います。しかし   正規化から始まり、非正規化する   パフォーマンスまたはコード構造として   それを要求します。

     

ジェイソン、SMSにはメールを使用します。すべて米国   キャリアは   phone@carrier-gateway.comゲートウェイ。

     

ジェイク・グッド、ああ、いいオール＆＃8217; ＆＃8220;しかし   スケーリング＆＃8221;質問。私はそれに答えました   数年前。何もありません   それ以来、私たちのために変わった。管理します   数百万のダイナミック   さえなく毎日要求   多くのキャッシング（ほとんど   ほとんどのアプリケーションの画面   ユーザーごとに異なるため、   従来のキャッシングスキームは難しい   適用する）。

     

他にも多くのRailsがあります   数十を管理するアプリケーション   毎日何百万ものリクエストがあります。すべて   ほぼ同じ共有に従ってください   何もアプローチしません。すべてのテクニック   高さと高さをスケーリングするために   そこ。それはほとんどターンキーではありません   ソリューション、しかし約束するもの   それであることが通常はそれでいっぱいです。

Answer 2

数千の顧客（数十万または数百万）についてのみ話している場合、顧客ごとに数千行以上のテーブルがあることがわかっている場合を除き、違いはごくわずかです。その後、デザインが変更される可能性があります。

リレーショナルデータベースベースのデータストアの通常のセットアップでは、ほとんどのテーブルに customer_id 外部キーが配置されます。次に、そのデータをその顧客以外には見せないでください（または、何らかの方法で明示的な許可が他の誰かに与えられていることを示した場合）。

1つのテーブルに数百万の行があるように見えるまで、RDBMSスケーリングの問題についてあまり心配しないでください。次に、分散キー/値ストアを調査する時間になるかもしれません。しかし、その種の問題は、あなたがたくさんの現金を作っていることを意味するため、この種の問題は持つべき良い種類の問題であることに留意してください。

i.e。スケーリングブリッジを通過すると、そこを通過します。現在の能力を最大限に活用して設計しますが、早すぎる最適化はすべての悪の根源です。

Answer 3

私は多くのSaaSアプリのコンサルタントとして働いているので、さまざまなアーキテクチャを見てきました。お勧め：

1. すべての顧客用の1つのデータベース。独自の一意のIDであるユーザーの主キーを持つように、dbを適切に設計してください。私は、デザインが効果的に（実際にはそうではありませんが、そうであったかもしれませんが）電子メール、電話番号などを主キーとして作成した混乱を見てきました。また、すべてを巨大なユーザーテーブルに投げ込まないでください。

   1. ある時点で、多くのユーザーインタラクション動作の追跡を開始する必要があります。そのためには、NoSQLの名前と値のストアを使用して、後で分析するためにイベントをスローするだけです。または、MixPanelやKISSmetricsなどを使用します。

   2. KPIテーブルに行を書き込むことで毎日のKPIを追跡します。これにより、時間の経過とともに起こったことを簡単に照会できます。そうしないと、最終的にデータベースの質問をしたいと思うようになり、それが巨大なクエリであることがわかります。

単一のSQLデータベースを持つことの主な利点は、マーケティング担当者がSQLを知っている場合（推奨！）、直接クエリできることです。 NoSQLルートに進むと、それははるかに難しくなり、マーケティングは通常間違った仮定を立て始め、それらの仮定に基づいて間違った道をたどるのに多くの時間を浪費します。