web-dev-qa-db-ja.com

ソーシャルネットワーク通知システム

バックグラウンド

私はいくつかのソーシャルネットワーキング機能を含むクライアント用のアプリに取り組んでいます。私はもともとモバイルフロントエンドを開発していましたが、バックエンドの開発も担当する状況でした。

一般的な背景として、私たちのシステムでは、ソーシャルネットワークから期待されるように、ユーザーが他のユーザーをフォローし、フォローしているユーザーに関する通知を受け取ることができます。注意すべき点は、ほとんどのユーザーベースがこれらの個人の少なくとも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にデータを書き込まない以外に利点がありますか？
  • 私はこれを早すぎると思いすぎていますか？クライアントが限られた予算であり、最終的な製品が人気があるかどうかまだわからないので、今のところ機能するものを構築するだけで問題が発生した場合に最適化を検討できますか？
designphpmysqlsocial-networks
10
user45623

したがって、1,000人がSallyをフォローしている場合、対応するテーブルに1,000行を挿入します。それはスケーラブルですか？

はい、データベーステーブルが適切にインデックス付けされている場合に限ります。

数万人または数十万人のユーザーがサリーをフォローしていて、彼女が1日に数十の投稿を作成している場合はどうなりますか？

Sallyの1日あたり数十万から数十万の通知レコードを生成します。これは、すべての通知を永続的に追跡することを前提としています。その種類のトラフィックを持つサリーのようなユーザーの割合は常に非常に小さいです。

私の元のアイデアはすべてクエリで処理することでした：通知ボタンの数は、最後に通知画面にアクセスしたときよりも最近投稿されたコンテンツの行数を要求することによって取得され、個々の通知はより詳細なクエリから生成されます通知画面にアクセスしたとき。

これは不必要に複雑に思えます。通知に関する詳細な統計情報が必要な場合は、通知を保存してください。

すべてのユーザーが同じ数百人の一部しかフォローしていない場合、データベース主導の通知システムは長期的なスケーラビリティに悪影響を及ぼしますか？

それが機能する理由です...少数の人々が常にトラフィックの大部分を生成します。

各フォロワーの通知ごとに個別の通知行を必要とせずに、通知をデータベース主導にする方法はありますか？

はい...通知を保存しないでください。通知メールをファイアアンドフォーゲット形式で送信するだけです。または、通知を一定期間保存してから破棄します。または、各通知を読んだ後に破棄します。

完全にクエリ駆動型の通知システムはスケーラブルですか、それともDBにデータを書き込まない以外に利点がありますか？

どういう意味かわかりません。通知を照会したい場合は、それらをデータベースに保存する必要があります。それ以外の場合、照会するものはありません。

私はこれを早すぎると思いすぎていますか？

正しいテーブルを含む、適切に正規化されたインデックス付きデータベースの設計を手伝ってくれる人に相談してください。そのようなデータベースが、あなたが説明したシナリオを効果的に処理できなかった理由は私にはわかりません。

実際の例

私の知る限り、Stack Exchangeはすべての通知を含め、すべてを永続的に格納します。 MySqlに似たデータベーステクノロジーといくつかのキャッシングテクノロジーを使用しています。それらのハードウェアとストレージスペースはかなりのものですが、それらが取得するトラフィック量は良い問題です

10
Robert Harvey