私は約1Kの異なる数値属性(つまり列)を持っているという事実を持っています。これを列指向のDBに格納し、キューブ分析を実行したいと思います。
スタースキーマを設計しようとしましたが、これだけ多くの列を処理する方法がわかりません。正規化するのは間違っているように聞こえますが、フラットな列だけを作成することもできません。オプションであるカテゴリ(範囲)に数値を減らしたとしても、属性の組み合わせが多すぎて、このための単純なディメンションテーブルを作成できません。行ごとにXMLまたはJSONとして保存することを考えましたが、それもあまり良くありません。
それが役に立ったら、私はDBにAmazonのredshiftを使用することを計画しています。
注:このデータに対して行う少なくとも他のいくつかの操作に完全に適合するため、RedShiftを強く優先します。したがって、可能であれば、HBaseのような他のテクノロジーは避けたいと思います。
これを行う理由について、顧客の電子メール内のどの単語/短いフレーズが費用のかかる修理に関連しているかを確認し、OLAPを使用してこれを分析できるようにしたいとします。多くのドキュメントをトークン化/グラム化するのはコストがかかる可能性があるため、トークン/グラムをOLAPサーバーが理解できる形式(列)で保存することをお勧めします。
実質的に無制限 列数を許可するMonetDBについて考えてみます。
Redshiftは 1600列 で最大になります。
もう1つのオプションは、 主成分分析 を使用し、上位1600のコンポーネントのみを選択することですが、これにより解釈が困難になる可能性があります。
もう1つのオプションは、Postgresを使用して、トークン化された文字列またはn-gramを文字列配列フィールドに格納することですが、OLAPサーバーはそれをサポートする必要があります。