シナリオ:
10.000.000レコード/日
記録:訪問者、訪問日、クラスター(どこに表示されますか)、メタデータ
この情報で知りたいこと:
- 特定の日付範囲の1つ以上のクラスターの一意の訪問者。
- 日ごとのユニークな訪問者
- 特定の範囲(プラットフォーム、ブラウザーなど)のメタデータをグループ化する
この情報を簡単に照会するために私が固執するモデルは次のとおりです。
{
VisitorId:1,
ClusterVisit: [
{clusterId:1, dates:[date1, date2]},
{clusterId:2, dates:[date1, date3]}
]
}
索引:
- VisitorIdによる(一意性を確保するため)
- ClusterVisit.ClusterId-ClusterVisit.dates(検索用)
- IdUser-ClusterVisit.IdCluster(更新用)
また、データへのアクセスをより効率的にするために、クラスターのグループを異なるコレクションに分割する必要があります。
インポート:最初に、VisitorIdとClusterIdの組み合わせを検索し、日付をaddToSetします。
2番目:最初が一致しない場合は、アップサートします。
$addToSet: {VisitorId:1,
ClusterVisit: [{clusterId:1, dates:[date1]}]
}
1番目と2番目のインポートでは、clusterIdが存在しない場合、またはVisitorIdが存在しない場合をカバーします。
問題:コレクションが大きくなると、更新/挿入/アップサートで完全に非効率的(ほぼ不可能)になります。新しい日付を追加するとドキュメントサイズが大きくなるためだと思います。維持が難しい(ほとんどの場合、日付が設定されていない)
50.000.000を超えるコレクションがあり、これ以上成長することはできません。更新されるのは100〜レコード/秒のみです。
私が使用しているモデルは、このサイズの情報には最適ではないと思います。シャーディングを台無しにする前に、より多くのアップサート/秒を取得し、情報をすばやく照会するのが最善だと思います。シャーディングは、学習して自信を持てるようになるまでに時間がかかります。
AWSRAID10に10個のディスクを備えたx1.largeインスタンスがあります