バックグラウンド
私はいくつかのソーシャルネットワーキング機能を含むクライアント向けのアプリに取り組んでいます。私はもともとモバイルフロントエンドを開発していましたが、バックエンドの開発も担当する状況でした。
一般的な背景として、私たちのシステムでは、ソーシャルネットワークから期待されるように、ユーザーが他のユーザーをフォローし、フォローしているユーザーに関する通知を受け取ることができます。注意すべき点は、ほんの数サブセット（せいぜい数百人）のユーザーのみがフォローできることであり、ほとんどのユーザーベースはこれらの個人の少なくとも1人をフォローしていると予想されます。
UI側には、番号が付いた通知ボタンがあり、ボタンをクリックすると通知画面に移動します。
問題
私は、通知を実装するための戦略と、データベースに1つ以上の通知テーブルを作成するために見つけたほとんどのリソースを調査してきました。（私が好む例はここで受け入れられた答えです：https : //stackoverflow.com/questions/9735578/building-a-notification-system）。
私を後押ししているのは、通知に関するほとんどのデータベース駆動型の戦略では、各フォロワーの通知ごとに行を挿入する必要があるということです。したがって、1,000人がSallyをフォローしている場合、対応するテーブルに1,000行を挿入します。それはスケーラブルですか？数万人または数十万人のユーザーがサリーをフォローしていて、彼女が1日に数十の投稿を作成している場合はどうなりますか？
私の元のアイデアはクエリですべてを処理することでした：通知ボタンの数は、最後に通知画面にアクセスしたときより最近投稿されたコンテンツの行数を要求することによって取得され、個々の通知はより詳細なクエリから生成されます通知画面にアクセスしたとき。このアプローチでは、書き込みや追加のストレージは必要ありませんが、柔軟性がなく、サーバーをかなり難しくします。
セットアップ
（前の開発者によって確立された）バックエンドは、CodeIgniterとMySQLデータベースを使用します。現在、くだらないGoDaddy共有ホスティングアカウントで実行されていますが、本稼働に入る前にアップグレードされると思います（希望ですか？）。ホスティングパッケージは、ユーザーの増加に合わせてスケーリングされます。
現在、私たちのフロントエンドはモバイルアプリのみですが、後でウェブサイトも構築する予定です。現時点では、サーバーから通知に関するリアルタイムのプッシュ更新を取得することに関心はありません。
補遺
私はバックエンドに特化しておらず、私はその部門の頭の中にいます。クライアントはそれを知っており、私はこの種のプロジェクトの範囲を説明するために最善を尽くしましたが、現時点では他の誰もプロジェクトに取り組むことを信頼しないことを明確にしています。テスターの追加を開始する前に、あと1か月の作業が必要であり、あらゆる種類のパフォーマンスメトリックを取得できます。ユーザー数や今後5年間に使用するハードウェアを実際に見積もることはできませんが、クライアントは数十万人以上のユーザーを望んでいると思います。
これがここに投稿される問題の具体的な内容であることを願っています。必要に応じて調整できます。ご不明な点がある場合や、重要な詳細を省略している場合は、お問い合わせください。
tl; dr
- すべてのユーザーが同じ数百人の何人かしかフォローしていない場合、データベース主導の通知システムは長期的なスケーラビリティにマイナスの影響を及ぼしますか？
- フォロワーごとに通知ごとに個別の通知行を必要とせずに、通知をデータベース主導にする方法はありますか？
- 完全にクエリ駆動型の通知システムはスケーラブルですか、それともDBにデータを書き込まない以外に利点がありますか？
- 私はこれを早すぎると思いすぎていますか？クライアントが限られた予算であり、最終製品が人気があるかどうかまだわからないので、今のところ機能するものを構築するだけで問題が発生した場合に最適化を検討できますか？