物理的な在庫データをSQLデータベースに保存する最良の方法
私は小売企業で働いており、現在、新しいデータウェアハウスを構築しています。保存する必要がある要素の1つは、特定の場所で特定の時間に利用可能なSKUのユニット数に関する物理的な在庫データです。したがって、調べたい変数は、skus、sites、day、hour、quantityです。
問題は、およそ10万のskusと200の店舗があるということです。 1時間ごとにデータを保存すると、1日あたり100k x 200 x 24 = 480,000,000行になります。すべてのSKUがすべてのサイトで数量> 0を持っているわけではないことを理解しています。スパース性が80％と非常に高く、数量が0の場合は保存しないので、1日あたり96,000,000行が残るとします。さらに、ウェブサイトがあり、販売が夜に止まらない場合でも、夜間の数量の変化はほとんどなく、すべてのSKUが毎時間販売されるとは限りません。 SKUが平均して1日に3時間しか販売されないと仮定しましょう。これにより、12,000,000に減少します。
これは最初に見たものの2.5％ですが、それでもかなりの量です。数か月後、毎日12,000,000行が多くのスペースを占めることになります。問題の部分的な解決策は、Kimballがデータウェアハウスツールキットで提案していることです。これは、過去1か月間は1時間ごとにデータを保存し、最後のnか月間は毎日のみ保存して、古いレコードを削除することです。 1日あたり3つの異なる時間にのみSKUを販売することをすでに想定していることを考慮すると、時間単位のデータから日単位のデータに切り替えると、3分の2しか削減されません。過去6か月の株価データを保存するとします。時間単位で1か月、日単位で5か月（計算を簡単にするために30か月と仮定します）は、（12,000,000 X 30）+（4,000,000 X 150）= 960,000,000行になります。
私はこれを行うためのより良い方法を本当に考えることができません、以前に誰かが物理的な在庫データを操作しなければならなかったのですか？あなたが学んだ有益な教訓はありますか？このデータを保存するより効率的な方法はありますか？
おかげで、
データ・モデル
私が見たデータモデルには、
- ある日付の在庫
- 販売/返品/到着（在庫レベルの変化/在庫のデルタ）
- レポートなどに必要なものに基づいた過去の株価。
日付に基づいてデータのチャンクを削除する必要がある場合は、データを日付で分割する必要があります。これは通常、DATEに基づいて結果を制限するSELECTステートメントのパフォーマンスに役立ちます。
ただし、CREATE TABLEステートメントを記述する前に、エンドユーザーが実行するレポート/クエリのビジネス要件のリストを取得する必要があります。
物理ストレージ
1つのコメントで、データの保存方法を知りたいと述べました。
IMHO-RAID 10ディスクサブシステムに存在するテーブルにデータを保存したい。できれば、SANを使用する必要があります。
前回確認したところ、購入可能な最小サイズのハードドライブは150 GBでした。その量のデータを保存するには、1つまたは2つのハードドライブで十分です。しかし、パフォーマンスと信頼性のために本当にRAID 10を使用したいのです。必要なIOPSを処理するのに十分なハードドライブを取得していることを確認してください。 3TBの追加スペースがあるかもしれませんが、それらのレポートは非常に迅速に生成されます。
SSD vs HDD？独自の要件と独自のベンチマークに基づいて、自分自身を決定する必要があります。 「コスト」はあなたの決定の一部であるべきです。
行数の削減
行数を減らしようとすることを気にする必要はありません。
「私のデータモデルはエンドユーザーが必要とするクエリ/レポートなどをサポートしていますか？」に注意する必要があります。
できることの1つは、品質と在庫の変更を保存する別のテーブルを作成して、テーブルの幅を制限できるようにすることです。たとえば、次の列を持つテーブルがあるとします。
Store
SKU
Current Stock
Change In Stock
Change Source (Sales/Restock/Other Change Sources)
このテーブルが更新されると、同じ在庫レベルのアイテムが更新されないように、数量が変更されたレコードのみが含まれます。それでも多くのレコードが取得されますが、ディスク使用量は最小限に抑える必要があります。
パフォーマンスのもう1つの可能性は、テーブルデザインでパーティションを使用して、必要なデータにすばやくアクセスできるようにすることです。
あなたは主にSKUと店舗の組み合わせについて、時間とともに変化する在庫レベルに関心があるように思われるので、 時系列データベース をお勧めします。たくさんあります。正当なものもあれば、オープンソースのものもあります。多くは既存のストレージエンジン上に構築されており、多くの場合 SQLプログラミングインターフェイス が使用されています。
それらは、株価を上場するため、および測定値を収集するための科学のために、金融で広く展開されています。これらの業界とそれらが生み出すことができるデータ量を知ることで、このテクノロジーがユースケースを処理できると確信しています（IOPSとRAMを提供できる場合）。 KDB（最も確立されたものの1つ）には、特定の 小売 ソリューションがあります。
値が変更されたときにのみ行を格納します。在庫が次の1時間と変わらない場合は、行を書き込まないでください。それを念頭に置いてクエリを作成してください。