問題タブ [non-relational-database]

私はしばらくの間、リレーショナル データベースを扱ってきましたが、非リレーショナル データベースには他の種類のデータベースが必要であることに最近気づきました。

非リレーショナル データベースの例と、それらが現実の世界でどこでどのように使用されているかを教えてください。リレーショナル データベースではなく、非リレーショナル データベースを使用する理由は何ですか?

編集：他の2つの同様の質問が回答に記載されています：

• リレーショナルではないデータベース システム。
• リレーショナル データベースを使用しない正当な理由はありますか?

私は従来のリレーショナル データベース ( PostgreSQLを使用) を学習しており、いくつかの新しいタイプのデータベースに出くわしたいくつかの調査を行っています。CouchDB、Drizzle、およびScalarisなどがありますが、次に対処するデータベース テクノロジは何でしょうか?

リレーショナル データベースを使用する代わりに、CouchDB のようなドキュメント ベースのデータベースを使用する必要があるのはなぜですか。ドキュメント ベースのデータベースがリレーショナル データベースよりも適している典型的な種類のアプリケーションまたはドメインはありますか?

I want to experiment/play around with non-relational databases, it'd be best if the solution was:

• portable, meaning it doesn't require an installation. ideally just copy-pasting the directory to someplace would make it work. I don't mind if it requires editing some configuration files or running a configuration tool for first time usage.
• accessible from python
• works on both windows and linux

What can you recommend for me?

Essentially, I would like to be able to install this system on a shared linux server where I have little user privileges.

C++ で実装されている負荷分散された Web 向けアプリケーションのバックエンドとして、GDBM キー値データベースがあります。アプリケーションによって提供されるデータが非常に大きくなったため、管理者は GDBM ファイルを「ローカル」ストレージ (Web サーバー上、またはそのすぐ近く) から大規模な共有のリモート NFS マウント ファイルシステムに移動しました。

これはパフォーマンスに影響を与えました。当社のパフォーマンス テスト (テスト環境) では、ページの読み込み時間が数百ミリ秒 (ローカル ディスクの場合) から数秒 (NFS、ローカル ネットワーク経由) に跳ね上がり、時には 30 秒に達することもあります。問題の大部分は、アプリケーションが GDBM ファイルからランダムな読み取りを大量に行うことであり、NFS ではこれらの読み取りが遅く、本番環境ではさらに悪化すると考えています (フロントエンドとバックエンドでさえそれらの間のより多くのネットワーク ハードウェア) と、データベースがさらに大きくなるにつれて。

これは重要なアプリケーションではありませんが、パフォーマンスを改善し、アプリケーション開発者の時間や Unix 管理者などのリソースを利用できるようにしたいと考えています。私の主な制約は、数週間しかリソースを持てない時間です。

私が見ているように、私のオプションは次のとおりです。

1. パラメータを調整して、NFS のパフォーマンスを向上させます。私の本能は、これから多くを得ることができないということですが、私は以前に間違っていました.NFSのチューニングについてはあまり知りません.

2. memcachedbやTokyo Cabinetなどの別のキー値データベースに移動します。

3. NFS を他のプロトコルに置き換えます (iSCSI について言及されていますが、私はそれに慣れていません)。

この問題にどのようにアプローチすればよいですか？

Perl DBIモジュールを使用すると、さまざまな種類の SQL データベースに透過的に接続できます。非リレーショナル キーと値のペア データベースに対応する Perl モジュールはありますか?

たとえば、BerkeleyDB (または単に Perl ハッシュ?) を使用して開発を開始し、memcachedb や CouchDB などに切り替えたり、Amazon SinmpleDB や Google AppEngine Datastore が提供するようなクラウド データベースに切り替えたりできるインターフェイスです。

(これが Tie::Hash の機能ですか? その場合、実装の概要はどこにありますか?)

（開発中の）MySQLデータベース上で実行されているWebアプリケーションがあります。アプリケーションをGoogleAppEngineに移行することを検討しており、単純なリレーショナルデータベースモデルを非リレーショナルアプローチに変換する方法をよりよく理解したいと思います。

私は長年のリレーショナルデータベース担当者であり、BigTableなどの列ベースのDBの経験はありません。Googleがリレーショナルデータベースの小規模な展開もサポートしている場合に備えて、私の質問は一般的なものであり、Googleに固有のものではないことを述べたいと思います。単純なリレーショナルモデルを非リレーショナルDBで表現する方法を理解したいと思います。

私のデータベース（簡略化）は次のとおりです。

名前とIDが付いたアイテムがたくさんあります。各アイテムには複数のプロパティがあり、各プロパティにはいくつかのパラメータがあります（各プロパティの名前と「重要性」についてのみ説明しましたが、さらに多くのパラメータがあります）。私は数千万のアイテムを持っており、それぞれに数百のプロパティがあります。

使用シナリオ：入力としてItemNameを受け取り、itemsテーブルでそのIDを検索し、そのIDですべてのプロパティをフェッチします。次に、（メモリ内の）プロパティのリストに対して分析を実行し、結果を返します。

作業の90％は、パラメーターに基づくルックアップです。パラメーターは、（私が正しく理解していれば）非リレーショナルDBの問題点です。

推奨されるアプローチは何ですか？

BerkeleyDBは、単一のキーに複数の値を格納できることを除いて、RubyハッシュテーブルまたはPythonディクショナリと同等のデータベースです。

私の質問は、複雑なデータ型をこのようなストレージ構造に格納したい場合、どうすればよいでしょうか。

通常のリレーショナルテーブルでは、Personを表す場合は、特定のデータ型の列を含むテーブルを作成します。

このように書き出すと、人がキーと値のペアのセットとしてどのように理解されるかがわかります。

個人を個々のキー/値のペア（name = "john"）に分解するのは簡単です。

ただし、BerkeleyDB形式を使用して個人を表すには、構成要素であるキーと値のペアから個人を再構成する何らかの方法が必要になります。

そのためには、人を1つの単位としてまとめるために、人工的なカプセル化構造を課す必要があります。

これを行う方法はありますか？

編集：Robert Harveyの回答が示すように、BerkeleyDBのJavaエディションにはエンティティ永続化機能があります。残念ながら、 Monetaを使用してRubyアプリケーションからBerkeleyDBに接続するため、このサポートがない場合はカスタムソリューションを作成する必要があると思われるStandardEditionを使用します。

皆さん、DW、DataMart、BI および非リレーショナル モデリングで成功裏に使用したツールをいくつかお勧めしてください。スノーフレーク スキーマ、ディメンション、およびファクト テーブルの自動作成の例。どのツールを使用すると、ダイアグラムとサロゲート キーに慣れることができ、SQL Server 2008 へのエクスポートまたは接続のオプションがあります。

ありがとう

永続的なストアが非常に明確に必要なプロジェクトを開始することを考えていました。CouchDBについて簡単に触れている記事に出くわしたとき、私はしぶしぶRDBMSを決定しようとしていました。私が最後に調べてからDBテクノロジーにいくつかの進歩があったように思われるので、データベースに入る前にここでデータベースについて質問したいと思いました。

これが私の基準です。（最後にもう一度基準をリストしているので、説明をスキップしたい場合は下にスクロールしてください。）

1. プロジェクトはオープンソースであり、私は何も求めないので、データベースはオープンソースで無料であることが望ましいです。さらに、ソフトウェアはLinuxとWindowsの両方で実行する必要があります。

2. プロジェクトには、C++である必要がある部分があります。プロジェクトは、第二言語を使用することを正当化するのに十分なコードの大きさではありません。つまり、基本的にすべてがC++になります。

3. このプロジェクトはWebとは何の関係もないので、データベースがWebライブラリのデトリタスを必要としないことが望ましいです。

4. 保存したいオブジェクトは、基本オブジェクトとコンテナオブジェクトの2つのカテゴリのいずれかに分類されます。コンテナであるオブジェクトの違いは、さらに多くのオブジェクトを含みます。つまり、パーツの一部の問題です。そのような場合をクリーンかつ効率的に処理できるデータベースが必要です。

5. また、少なくとも最初は、スキーマが急速に進化することを期待しています。また、古いデータの一部が新しいスキーマに適合しないのではないかと思います。そのため、さまざまなバージョンのスキーマを保持したいと思います。可能であれば、あるスキーマのデータを別のスキーマに変換できるようにしたいと思います。

6. アプリケーションが意図したとおりに機能するためには、人々はデータベースの大きなチャンクを互いに交換する必要があります。そのため、ある程度自動化できる、データのインポートとエクスポートの簡単な方法が必要です。

7. 最後に、データベースを何らかの方法で単体テストでシミュレートできれば便利です。

これらは私の要件です。人々が答えやすいように、以下にそれらを複製しました。

ありがとうございました

非技術的要件1.オープンソース、できれば無料。2.WindowsおよびLinuxで実行します

1. C++インターフェイスを備えています。
2. Web以外のアプリケーションを、できればRESTなしで処理できます。
3. 「部品の部品」の問題をかなりうまく処理できます。
4. 複数のインデックスを処理できます。
5. ある種のスキーマバージョンの概念があり、複数のスキーマバージョンを処理でき、あるスキーマから別のスキーマにテーブルを移行できます。
6. データベースのあるインスタンスから別のインスタンスにデータを移動するための単純なメカニズムが必要です。
7. できれば、テストのための何らかのメカニズムがあります。