データ量は非常に多いが、データ構造は非常に単純化されたシステムを開発しました。 cellX
、cellY
、timeStamp
、value
列のみがありました。
操作は次のとおりです。
cellX
、cellY
、およびtimeStamp
の範囲フィルターを使用したクエリデータが大きすぎてクエリにインデックスが必要なため、次のスキームを使用しました。
cellX
、cellY
、timeStamp
のクラスター化インデックス。timeStamp
にはカスタム形式を使用します。年をスキップし、月、日付、時間のみを保持します。 16ビットint以内に保つことができました。これは今のところうまく機能しています。データの準備ができたらユーザーに通知しますが、クエリが適切である限り、遅延は数秒以下です。
しかし、最近、より正確なデータを取得する機会を得て、データ量が68倍に増加しました!。したがって、次のようになります。
これにより、1〜2年でより正確なデータを受け取ることができる可能性があります。そのため、データ量が大幅に増加する可能性があります。
問題は、この方式で持続を使用するかどうかです。または、別のスキームに移行する必要があります。SQLServerを離れる別のデータベースシステムである可能性がありますか?
3次元の列cellX
、cellY
およびtimeStamp
は、本質的に非常に規則的です。これらのすべてをf(x) = mx + c
で定義できます。ある整数x
レンジング(0, 1, 2, ..., X
)。
私は、ページ圧縮と10年の歴史を持つ、300億以上の月次パーティションテーブルを使用してきました。テーブルスキーマは、varchar列と2つの非インデックス列にdatetime2(2)のクラスター化インデックスと3つの非クラスター化インデックスがあり、かなりシンプルでした。ストレージは約2TBで、かなり良好に機能しました。 SqlBulkCopyは、ほぼリアルタイムでデータが必要なため、1日を通して約1500万行を継続的に挿入するために使用されました。
この逸話に基づいて、適切なサイズのハードウェアでSQL Serverが予想されるボリュームを処理できると確信しています。とはいえ、あなたのアプリケーションは遅延に対する耐性があるため、コストのかからないNoSQLソリューションの優れた候補であるという@DamianoVerzulliに完全に同意します。
そのクラスター化インデックスの断片化が急速に進んでいませんか?これは挿入と選択に悪影響を及ぼします。
別のインデックスを検討する
毎日データを読み込んでいます-当日または前日と想定します
PK cellX、cellY、timeStamp
それが最大の断片化です
検討する
PK timeStamp、cellX、cellY
そして、その順序でソートされたデータをロードします
並べ替えのためにステージングテーブルにロードする必要がある場合でも
これが最小の断片化です
クエリのパフォーマンスのために本当にcellX、cellYインデックスが必要な場合は、フィルファクタ<1の別のパーティションの別のインデックスにそれを配置し、インデックスのメンテナンスを実行します。これが営業時間外に行われる場合は、インデックスを無効にして挿入し、インデックスを再構築する方が速い場合があります(この場合、FILL FACTORまたは1を使用できます)。