高いカーディナリティをサポートできるのはどの時系列データベースですか？
時系列データベースでページビューやクリックイベントなどを追跡したいのですが、カーディナリティが非常に高いデータの集約グループを取得したい場合、スケーラビリティの問題があります。
私が解決しようとしている問題は次のとおりです。
特定の時間範囲内の上位Nの参照元は何ですか？
特定の時間範囲内の各URLに対して、URLにはいくつのビューがありますか？
特定のURLには常に何回のビューがありますか？
これまでのスキーマは次のとおりです。
timestamp-イベントの時間
domain-レコードのベースURL
uri-一意のリソース。これらのグループ化されたカウントを希望します（数百万の可能な値）
referrer-HTTPリファラー。これらのグループ化された数（数百万の可能な値）
event-イベントのタイプ
これまでInfluxDBを使用してみましたが、uriとreferrerの可能な値が非常に多いために問題が発見されました。私は短い時間範囲内でレコードをスキャンするだけですが、数百万の一意の可能な値でグループ化すると、これは非常に難しくなります。書き込み/クエリの両方の要件をサポートするデータを保存するには、他にどのようなオプションがありますか？
大規模な時系列データに対してリアルタイムで複雑なクエリを実行することは、スケーラブルではありません。ストアに無理な負荷をかけ、使用するデータベースに関係なく、パフォーマンスが低下します。時系列データベースに直接クエリを実行する必要があるのは、個々のイベント（イベントのテーブルや単一のログエントリなど）を見たいときだけです。
クエリに対してスケーラブルな方法でデータにインデックスを付ける必要があります。たとえば、一定期間（分、時間、日、週）のビューを集計したり、他のメトリック（referrer、eventタイプ、またはdomain）でグループ化したりできるため、特定のビューのクエリを実行する必要がある場合1か月のエンティティでは、数百万ではなく数百の行をクエリしています。
負荷とデータサイズははるかに小さいはずなので、インデックスはどこにでも格納できます（たとえば、リレーショナルデータベースに格納します）。インデックスは、ストリーム分析パイプラインによって、またはバッチプロセスによって定期的に作成できます。ストリーミング分析を使用すると、データを（ほぼ）すぐにクエリに使用できるようになりますが、適切に実行するのはより複雑になる可能性があります。バッチ処理では、データがクエリ可能になる前にある程度の待ち時間が発生しますが、実装は簡単です（通常、定期的に実行され、最新のデータにインデックスを付けるcronジョブのみ）。ストリーム分析フレームワークについては、 Apache Spark Streaming をチェックしてください。バッチ処理の場合、 Apache Spark が一般的な選択肢です。