ホストされた Web アプリケーションをどのように設計しますか? Basecamp、Campaign Monitor、Freshbooks など、ユーザーがオンラインでサインアップでき、アプリケーションがホストされているアプリケーションを検討しています。
編集: マルチテナント データ アーキテクチャについて説明している MSDN の記事を見つけました: http://msdn.microsoft.com/en-us/library/aa479086.aspx#mlttntda_topic4
37signals を参照してください。彼らはこの分野の専門家であり、コミュニティの質問に答える記事がたくさんあります (あなたのような多くの記事が出てくるはずです)。
Ask 37signals: クレジットカードはどのように処理しますか?
データベースの数に関しては、David Heinemeier Hansson のWhat do you want to know? から。
いくつかの技術的な回答…</p>
ランス、スケジュールされた請求業務はすべて自動化されています。そのようなものは何でも私たちを狂わせます。不測の事態に備えて、クレジット カードの不履行に対応できるようにすることが特に重要です。最後に調べたところ、クレジット カードの有効期限が切れているか、限度額を超えているか、閉鎖されていることが原因で、請求の 5% が返送されたようです。丁寧に扱ってください。
Authorize.net と別のクレジット カード アプリケーション (Rails で開発され、REST を介して内部ネットワーク上の他のアプリで使用される小さなアプリ) を使用して、番号を安全に保ちます。
ウォーレン、私たちは同じデータベースで無料アカウントと有料アカウントを運営しています。アプリケーションごとに 1 つのデータベースです。通常、アカウントごとに 1 つのデータベースを使用するのは、非常に悪い考えです。通常、データはかなり正規化されていますが、私たちはそれについて宗教的ではありません. 私は通常、スキーマよりもソース コードを重視します。したがって、スキーマを曲げることでより優れた/よりきれいなソース コードを取得できる場合は、通常はそうします。ただし、正規化から始めて、パフォーマンスまたはコード構造が必要とする場合は非正規化します。
ジェイソン、私たちは SMS に電子メールを使用します。米国のすべての通信事業者には、phone@carrier-gateway.com ゲートウェイがあります。
ジェイク・グッド、ああ、古き良き「しかし、それはスケールしますか」という質問。私は数年前にそう答えました。それ以来、私たちにとって何も変わっていません。私たちは毎日何百万もの動的リクエストを管理しており、多くのキャッシングに頼ることさえありません (ほとんどのアプリケーションのほとんどの画面はユーザーごとに異なるため、従来のキャッシング スキームを適用するのは困難です)。
日々何千万件ものリクエストを管理している Rails アプリケーションは他にもたくさんあります。すべてが多かれ少なかれ同じシェアード ナッシング アプローチに従います。高くて高くスケーリングするためのすべてのテクニックがそこにあります。それはほとんどターンキー ソリューションではありませんが、それを約束するものは通常、それでいっぱいです。
数千の顧客 (対数十万または数百万) についてのみ話している場合、顧客ごとに数千またはそれ以上の行がある可能性があるテーブルがあることを知っていない限り、違いはごくわずかです。その後、デザインが変更される場合があります。
リレーショナル データベース ベースのデータストアの通常のセットアップでは、customer_idほとんどのテーブルに外部キーを配置します。次に、そのデータをその顧客以外の誰にも見せないでください (または、明示的なアクセス許可が他の誰かに付与されていることを顧客が何らかの形で示している場合)。
1 つのテーブルに数百万の行が含まれるようになるまでは、RDBMS のスケーリングの問題についてあまり心配する必要はありません。次に、分散キー/値ストアを調査する時期かもしれません。しかし、その種の問題は、おそらくあなたが大量の現金を稼いでいることを意味するので、持つべき良い種類の問題であることを覚えておいてください.
つまり、スケーリング ブリッジに来たら渡ってください。現在の能力を最大限に発揮して設計しますが、それ以外の場合は、時期尚早の最適化が諸悪の根源です。
私は多くの SaaS アプリのコンサルタントとして働いているため、さまざまなアーキテクチャを見てきました。私はお勧めします：
すべての顧客に 1 つのデータベース。独自の一意の ID であるユーザーの主キーを持つように、データベースを適切に設計してください。私は、設計が効果的に（実際にはそうではありませんが、そうかもしれませんが）電子メール、電話番号などを主キーとして作成した混乱を見てきました）。また、巨大なユーザー テーブルにすべてを投げ込まないでください。
ある時点で、多くのユーザー インタラクション行動の追跡を開始する必要があります。そのために、NoSQL の名前と値のストアを使用して、後で分析するためにイベントをスローし始めることができます。または、MixPanel や KISSmetrics などを使用します。
KPI テーブルに行を書き込むことで、毎日の KPI を追跡し、時間の経過とともに何が起こったかを簡単にクエリできるようにします。そうしないと、データベースに質問したくなり、そのための巨大なクエリであることがわかります。
単一の SQL データベースを持つ主な利点は、マーケティング担当者が SQL を知っている場合 (推奨!)、直接クエリを実行できることです。NoSQL ルートに進むと、それははるかに難しくなり、マーケティングは通常間違った仮定を立て始め、それらの仮定に基づいて間違った道をたどることに多くの時間を無駄にします。