1

次の機能をサポートするデータベースを探しています。

1）データベース内のレコードは、Python辞書やPerlハッシュのようなものです。たとえば、「購入」レコードは次のようになります。

<purchase 5436> = { product: "BMX Bike", price: 99.50, city: "Springfield" }

2）レコードは可変長の配列に格納されます。データベースには、これらのアレイが多数含まれています。たとえば、購入テーブルは次のようになります。

purchase array 1: [ <purchase 5436>, <purchase 54>, <purchase 112> ]
purchase array 2: [ <purchase 76>, <purchase 5984>, <purchase 1102>, <purchase 12> ]
...
purchase array 658: [ <purchase 10142>, <purchase 35>, <purchase 6458>, <purchase 23> ]

3）このデータベースで2種類のクエリを実行できるようにしたい：

3a）さまざまな基準に一致するレコードの数を数えます。たとえば、50を超える値で何回購入されましたか？私はこれをサポートするデータベースをたくさん知っています。

3b）レコードが特定の順序で表示される回数をカウントします。たとえば、50を超える購入が行われた後、「Springfield」で購入されたアレイはいくつありますか。これを行うためにどのような種類のデータベースを使用するかわかりません。

編集：Steve Haighへの応答：速度が重要であり、このデータベースはギガバイトのデータをサポートする必要があることを述べておかなければなりません。たとえば、1,000,000,000の購入アレイがあり、「Springfield」で購入した後、「Hometown」で購入したアレイの数を数えたいと思います（順序が重要であることに注意してください）。私は間違っているかもしれませんが、リレーショナルDBはこの目的には遅すぎると思います。

4

5 に答える 5

2

たとえば、1,000,000,000の購入アレイがあり、「Springfield」で購入した後、「Hometown」で購入したアレイの数を数えたいと思います（順序が重要であることに注意してください）。私は間違っているかもしれませんが、リレーショナルDBはこの目的には遅すぎると思います。

あなたが説明するのは典型的なデータウェアハウスクエリであり、AFAIKは通常、リレーショナルDBを使用して実装されますが、同時トランザクション処理ではなくレポート用に最適化されています。ただし、「通常の」RDBMSを使用する場合、速度の違いは極端ではないと思います。もちろん、十分なお金があれば、特別なデータウェアハウスDBMSを利用することもできます。

速度への最も重要な影響は、1）大規模なディスクベースのデータセットを検索するために最適化されたテクノロジーであり、これはまさにすべての「実際の」DMBSが提供するものであり、2）データは正しい方法で編成されます。

3b）レコードが特定の順序で表示される回数をカウントします。たとえば、50を超える購入が行われた後、「Springfield」で購入されたアレイはいくつありますか。これを行うためにどのような種類のデータベースを使用するかわかりません。

その種のクエリをサポートするように設計されたスキーマを持つリレーショナルDBを使用します。データをどのように表現するかという先入観をあきらめる必要があります。

于 2009-05-10T08:24:58.063 に答える
2

リンクまたはジャンクションテーブルを使用してリレーショナルDBでこれを行うことはできませんか？

注文の列、製品の列、および注文ごとのすべての製品の行を持つテーブルorder-productsがあります。

この記事はおそらく私よりもうまく表現されていると思います。

于 2009-04-22T17:54:17.887 に答える
1

キーと値のペアがコレクションにグループ化されているだけなので、リレーショナルデータベースは実際には必要ありません。コレクション内のレコードを反復処理するには、2つのテーブル（1つはレコード用、もう1つはコレクション用）間の結合が必要になります。あなたのケースはコストの価値がありません。

パフォーマンス要件については、構造全体がメモリに収まり、ディスクへのアクセスを必要としないことを確認する必要があります。これを行うには複数のサーバーが必要になる場合があり、ルックアップを他のサーバーにディスパッチするマスターが必要になる場合があります（構造のサイズが最新のサーバーが処理できる適切なメモリ量よりも大きく、速度要件がそうであると仮定します）ディスクのページネーションを行う余裕がないほど大きい。

あなたが言及する種類のクエリの場合、最善のオプションは、データの冗長性を少し持つことです。挿入時に、それらのカウントを追跡します。名前を読むだけで人々を驚かせるデータ冗長テントですが、必要な場合もあります。実装には細心の注意を払い、ここで大量の単体テストを投資してください。

ただし、ある種のクエリでは、ミリ秒単位でリアルタイムに実行することはできず、ある条件での購入の後に別の条件での購入を見つけるというクエリは次のようになります。挿入/削除/変更中にこの番号のライブ追跡を維持する方法を見つけるか、実際に数百万のアレイを反復する必要がありますが、それを回避する方法はありません。データの最新性を検討する必要があります。また、数時間ごとに事前計算してこれらの統計を生成し、ルックアップキーを使用してO（1）でそれらにアクセスできるようにする必要があります。

一言で言えば、あなたの問題はあなたがそれを解決するために使用することを決定した技術をはるかに超えています。

于 2009-05-15T20:57:18.667 に答える
0

あなたが探しているものを完全に理解しているのかわかりませんが、couchdbを見たことがありますか？。そのドキュメント指向でスキーマフリー

于 2009-04-22T17:49:55.057 に答える
0

あなたが説明していることは、配列内の「レコード」の順序が可能なクエリを定義する機能について疑問がある場合でも、MUMPSと非常によく似ています。

リンクを見てください、あなたが見るようにこれの現在の商用バージョンもあります。

于 2010-02-09T14:39:06.390 に答える