私は、電子メール サービスとソーシャル ネットワークの間のどこかにある Web アプリに取り組んでいます。今後かなり大きくなる可能性を感じているので、スケーラビリティが気になります。
集中化された 1 つの MySQL/InnoDB データベースを使用し、その時が来たらそれを分割する代わりに、アクティブなユーザーごとに個別の SQLite データベースを作成することにしました。つまり、「シャード」ごとに 1 つのアクティブなユーザーです。
そうすれば、データベースのバックアップは、各ユーザーの小さなデータベース ファイルをリモートの場所に 1 日に 1 回コピーするのと同じくらい簡単になります。
スケールアップは、新しいファイルを保存するためにハードディスクを追加するのと同じくらい簡単です。
アプリが単一のサーバーを超えて成長した場合、GlusterFS を使用してファイルシステム レベルでサーバーをリンクし、アプリを変更せずに実行するか、各サーバーが隣接するサーバーの sqlite ファイルを操作できるようにする単純な SQLite プロキシ システムを装備できます。
各 HTTP リクエストは一度に 1 つまたは 2 つのデータベース ファイルにしかアクセスせず、SQLite は読み取り時にのみブロックするため、同時実行の問題は最小限に抑えられます。
このアプローチにより、アプリを適切にスケーリングし、多くのクールでユニークな機能をサポートできると確信しています。私は間違った賭けですか？何か不足していますか？
更新これまでのところ問題なく機能している、それほど極端ではないソリューションを使用することにしました。私は一定数のシャードを使用しています - 正確には256個のsqliteデータベースです。各ユーザーは、単純なハッシュ関数によってランダムなシャードに割り当てられ、バインドされます。
私のアプリのほとんどの機能では、1 回のリクエストで 1 つまたは 2 つのシャードにアクセスする必要がありますが、ユーザーによっては、256 個の異なるシャードのうち 10 ～ 100 個の異なるシャードに対して単純なクエリを実行する必要があるものがあります。テストでは、すべてのデータが RAM にキャッシュされている場合、約 0.02 秒以下かかることが示されています。私はそれで生きていけると思います！
UPDATE 2.0アプリを MySQL/InnoDB に移植し、通常のリクエストではほぼ同じパフォーマンスを得ることができましたが、シャード ウォーキングを必要とするその 1 つのリクエストでは、innodb が 4 ～ 5 倍高速です。この理由とその他の理由で、私はこのアーキテクチャを削除しますが、どこかで誰かがその用途を見つけてくれることを願っています...ありがとう。