さまざまな企業が、「いいね」/「ビュー」/「リツイート」などの数をカウント/インクリメントする方法、または同様のものを大規模に解決する方法について、いくつかの洞察を得たいと思います。
月間アクティブ ユーザーが 5,000 万人を超えるユーザーベースでは、Redis と Cassandra の両方が userId のセットを格納して、セットのカーディナリティ (たとえば、ビューアーの数) をすばやく取得するために使用されているのを見てきました。これらのソリューションには欠点がありますが、うまく機能し、スケールアウトできます。ただ、この場合、他のお店は何を使っているのか気になります。
具体的には、次のソリューションを実行します。
セット、またはその他のデータ構造を使用しますか、それとも単純なキーと値だけを使用しますか?
HyperLogLog は、いくつかの概算を提供することで、わずかな容量のストレージで一意のユーザー/ビューの数を提供できる強力なアルゴリズムです。
正確な数か、おおよその数か?
このスケールでは、正確な数は役に立たず、意味がありません。結局、ユーザーが 5000 万人いる場合、2% のエラー マージンで 134 万人のユニーク ビジターがアイテムにいることを知っていれば十分です。
インメモリのみですか、それともハイブリッドですか?
レイテンシーに関しては、要件によって異なります。インメモリでは非常に高速なアクセスが許可されますが、データ損失のリスクがあります。永続的なストレージバッキングでメモリ内で使用できます
オープンソース ソリューションですか、それとも自家製ですか?
車輪を再発明しないでください。実績があり、戦場で実績のあるツールを使用する
その上にハイパーログログの推定を備えた軽量のセットのみのストレージシステムを構築した人はいますか?
私の知る限り、Redis は HyperLogLog をデータ構造として提供しているので、そのまま使用できます。ディスク永続性を使用して、ハイパーログ ログ データ構造を頻繁にディスクにチェックポイントし、ノードがダウンしたときに失われないようにします。
それ以外の場合は、Cassandra が解決ルールとして使用するという事実を利用して、Cassandra に HyperLogLog アルゴリズムを実装することもできます。そのmax(timestamp)ため、データベースをだまして HyperLogLog バケット値をタイムスタンプとして保存するだけです。
ただし、バグの可能性があるため、自分で実装する必要があることを意味します。