2

一連の単純な2Dデータセットへの非常に高速な列ベースのアクセスをサポートするデータベースソリューションを実装しようとしています。つまり、このデータセットを検討してください

==========================================================
                     SOME DATASET1
==========================================================
   ENTRY     |    Col1   |   Col2  |    Col3    ... Coln
----------------------------------------------------------
   ENTRY A        1.1        0.2         5.5       6.2
   ENTRY B        2.3        6.4         1.5       1.1
   ENTRY C        2.2        4.2         9.5       3.4
   ENTRY D        2.3        1.1         5.5       2.9
   ENTRY E        9.1        3.6         7.5       2.6

必要なのは、ソート順を維持しながら、column1、column2、またはcolumnnのすべての値を選択する方法です。私の最初のアイデアは、次のキースペースデザインでredisを使用することでした。

   SOMEDS1/COLUMNS/           =>     Col1, Col2, Col3 ... Coln
   SOMEDS1/ENTRIES/           =>     A, B, C, D, E
   SOMEDS1/Col1/              =>     1.1, 2.3, 2.2, 2.3, 9.1
   SOMEDS1/Coln/              =>     ......

この設計の背後にある原則は、各リストのエントリ数は多くなく、おそらく10,000未満ですが、列が多数ある可能性があり、特定の時間に必要なのは選択された列のみであるということです。

私の質問は、誰かがすでにこのようなものを実装していることです。もしそうなら、最も適切なタイプのデータベースについてアドバイスできますか。私の最初の考えはredisを使うことでしたが、私は提案を受け入れています。

4

2 に答える 2

1

データストアへのローカルアクセスとリモートアクセスのどちらが必要かを指定しませんでした。リモートアクセスが必要な場合は、Redisがおそらく非常に優れたソリューションです。アクセスが純粋にローカルである場合は、組み込みデータベース（BerkeleyDBなど）の方がおそらく効率的です。

重要な点は、データの維持方法を定義することです。新しいエントリは、データ構造の最後にのみ追加できるかどうか。はいの場合、Redisリストが飛んで列を保存します。そうでない場合は、列ごとのハッシュオブジェクト（関連付けられたエントリと値）でデータを並べ替えないでおく方がおそらく良いでしょう。エントリ数が少ない場合は、とにかくクライアント側で取得した後のデータの並べ替えは安価です。

この設計は、一部の列型データベースに見られる実装に似ています。このアプローチの主な利点は、システムが特定の列の値を高い圧縮率で圧縮できることです。これは、データの量が多い場合に興味深いことです。欠点は、データのリアルタイムの保守が難しいことです。MySQLの例では、InfobrightまたはCalpont製品を確認することをお勧めします。

あなたの場合、データの量が限られている場合は、Redisが最適です。ただし、エントリの数が重要になる（つまり、ここで説明するしきい値を超える）場合、メモリ内のこれらのデータの表現は特にコンパクトではないことに注意してください（ポインタ、二重リンクリスト、および/またはハッシュテーブルを含む）。

于 2012-09-11T10:18:06.887 に答える
1

次のように Redis にデータを保存します。

文字列:

Entry:A:Col1 => 1.1
Entry:A:Col2 => 0.2
Entry:A:Col3 => 5.5
...
Entry:A:ColN => 6.2

無制限の数の列を使用できます（物理メモリによって制限されます）

于 2012-09-11T16:02:43.760 に答える