問題タブ [schemaless]

私は、スキーマのないデータの保存/取得を含む一連の特定の要件を解決する手段として、多数の NoSQL 実装 (現時点では RavenDB と MongoDB) を評価しています。NoSQL が私が検討すべき方向であるかどうか、または他の (より単純な可能性がある) オプションがあるかどうかについて、フィードバックを得たいと考えています。

基本的に、(とりわけ) いくつかの関連するエンティティで構成される基本的なドメイン モデルを定義するソフトウェア製品があり、それぞれがいくつかの属性 (キー/値) を持っています。お客様にリリースするときに、お客様と協力して属性と値を設定します。これは基本的にシステムの構成です。これは非常に簡単で、設計が事前にわかっているため、これを実現して実行するために動的なものは必要ありません (RDBMS を使用します)。属性は前もって知られていませんが、システムのこの部分はほとんど属性モデルを中心に展開しているため、これも問題ではありません。

問題は、さまざまな顧客にとって、コードをコンパイルしてリリースしたとき (および、顧客）。基本的には、格納できる属性マップからデータを生成し (構造は前もってわかりません)、格納されたデータを後で予測できない方法でクエリする必要があります。現在考えていることは、処理中にヒットするフックを作成し、データを作成して保存するライブラリを (おそらく MEF 経由で) プラグインできるようにし、後で必要に応じてクエリを実行できるようにすることです (レポート用ではありません)。通常、追加のデータ/属性を作成します)。

(フックとプラグイン ライブラリの作成は別の問題であり、この質問の一部になることを意図していないことに注意してください。)

一般的なシナリオは、「過去 10 日間に xxx が発生した回数を知りたい」です。そこで、xxx が発生したことを認識するプラグインを作成し、それを日付/時刻とともにデータ ストアに書き込みます。次に、クエリを実行する別のプラグイン (おそらく同じ DLL 内) を作成し、「CountOfxxxInLast10Days」というモデルに属性を追加します。もう 1 つのシナリオは、構成可能なルックアップを作成することです。そのため、起動時に実行して、ある属性値を別の属性値に変換できるルックアップ データのテーブルを作成/更新するプラグイン、または (より可能性が高い) ルックアップ値に変換する値の範囲を作成するプラグインを用意する場合があります。そのため、変換プラグインは、bottom_value、top_value、乗数の列を持つテーブルを追加し、クエリ プラグインは、"

場合によっては、指定した期間が経過すると古いデータが消去されることがあります。上記の最初のシナリオでは、ストア/キャッシュから 10 日より古いデータを削除することが望ましい場合があります。

上記の 2 番目のシナリオのように、データを永続的に保持する必要がある場合もあります。このデータは、永続的なストアに保持されるのではなく、起動時に単純に再作成される可能性があります。

追加要件:

• オンライン中にデータストア/キャッシュをバックアップおよび復元できます
• クラッシュの場合、最後のバックアップから置き換え/回復可能
• データは、マシンの再起動などのイベントに耐えます
• 実証済み/生産テスト済みのテクノロジー

現時点では、.Net プラットフォームにかなり力を入れているため、どのオプションも確実な .Net クライアント/API を備えている必要があります。

MongoDB、CouchDB、SimpleDB などのスキーマレス (多くの場合、分散型) データベース システムについての話をよく耳にします。

それらが何らかの目的で価値があることは理解できますが、ほとんどのアプリケーションでは、特定のタイプの特定の数のフィールドを持つオブジェクトを永続化しようとしており、リレーショナル モデルで自動的に考えます。私は常に、一意の整数 ID、null/not null フィールド、SQL データ型、選択クエリを使用してセットを検索する行の観点から考えています。

私はこれらの新しいシステムの分散型の性質と簡単な JSON/RESTful インターフェイスに惹かれていますが、緩く型付けされたキー/値ハッシュが開発にどのように役立つかはわかりません。型が緩く、スキーマのないシステムが、クリーンなデータ セットを維持するのに適しているのはなぜでしょうか? たとえば、日付がない可能性があるときに、x と y の間の日付を持つすべてのアイテムを見つけるにはどうすればよいですか? 結合の概念はありますか?

多くのシステムには独自の違いと長所があることは理解していますが、パラダイムの違いについて疑問に思っています。これは自由回答形式の質問だと思いますが、おそらくコミュニティの回答と、これらのシステムの利点を個人的に見たコミュニティの方法は、私や他の人がいつこれらの (確かにもっとヒップな) システムを使用したいのかを理解するのに役立つでしょう。従来の RDBMS。

オンライン アプリのカスタム フィールドの複雑な Mysql データ構造の問題に答えようとしています。私はMysqlにかなり慣れていないので、どんな入力でも大歓迎です。

現在のデータベースはリレーショナル データベースであり、サービスの各ユーザーは同じデータベースとテーブルを共有します。

これが私がやろうとしていることの例です。

リストを作成しようとしているとしましょう。このリストには、最大 30 個のカスタム フィールドを含めることができます。ユーザーは 12 の固有の要素から選択でき、各要素は最大 15 のユーザー定義属性を持つことができます。

各リストは、アカウント内だけでなく、アカウント間でも一意にすることができます。アカウントには多数のリストを含めることができ、各リストには要素の数や要素ごとに異なる属性を含めることができます。

要素には、複数の選択肢、ラジオ ボタン、電話番号フィールド、住所、1 行のテキスト、複数行のテキストなど、さまざまなものがあります。

複数選択 (チェックボックス) 要素の属性の例: 赤、緑、青、オレンジ、白、黒

1 行のテキスト要素の例は次のとおりです。名の入力フィールド。

各要素には、アプリの他の機能で参照および使用できるユーザー定義のタイトル フィールドとタグ フィールドも必要です。

セグメンテーションも非常に重要です。ユーザーは、任意の要素に基づいてリストをセグメント化できる必要があります。たとえば、ユーザーは、"red" が複数選択要素 #1 に存在するすべてのレコードに基づいて、リスト "ABC" をセグメント化したい場合があります (リストに複数の複数選択要素がある場合があります)。

この例では、配列、EAV、シリアル化された LOB が正常に機能すると仮定します。ただし、自分の規模で自分のニーズに最適な構造が何であるかはわかりません。

実際には、リストごとに最大 50,000 件のレコードが存在する可能性が高く、実際には 20,000 件以上のアカウントが存在する可能性があり、それぞれに多数のリストがあります。したがって、私は最も効率的で柔軟な構造を探しています。

問題をさらに複雑にするために、いつでも特定のリストに要素を追加/削除する効率的な方法を確保する必要もあります。たとえば、ユーザーがカスタム フィールドの最大許容数 (30) でリストを作成し、3 か月後にフィールドを削除することを決定した場合、そのリストとそのカスタム フィールドに関連付けられているすべての値を見つける方法が必要です。次に、すべての値、要素タイプ、およびその属性を削除します。ユーザーは、このリストに新しい要素を追加できます。

このサイトの EAV 投稿の多くと、このhttp://www.martinfowler.com/eaaCatalog/serializedLOB.htmlを確認しました。回収のデメリット。

また、多次元配列がこの規模でどれだけうまく機能するのだろうか? wordpressはこれをカスタムフィールドに使用していると思います。

この状況でデータベースを構築する最善の方法について、ご意見をお寄せいただければ幸いです。ありがとうございました！

Bret Taylor (FriendFeed の共同作成者、現在 Facebook の CTO) によって書かれた衝撃的な記事、 How FriendFeed uses MySQL to store schema-less data を読んだ後、私は、Oracle などの RDBMS を使用するためのベスト プラクティスがあるかどうか疑問に思い始めました。スキーマレス データの保存とクエリには MySQL と PostgreSQL のどちらを使用しますか?

NoSQL が話題になっているときにリレーショナル データベースを使用していることを認める人はほとんどいないため、このトピックに関する優れた記事を見つけるのは困難です。スキーマレス (または「ドキュメント指向」) データベースをリレーショナル データベース上のレイヤーとして実装するにはどうすればよいですか?

もう 1 つの質問であるUsing a Relational Database for Schema-Less Data を読んだ後、スキーマレス データの保存とクエリにはリレーショナル データベースよりもファイル システムの方が適しているのではないかと考え始めました。

MySQL の上にファイル システムを構築するだけでなく、データを直接ファイル システムに保存しないのはなぜですか? インデックス作成を理解する必要がありますが、最新のファイルシステムは非常に安定しており、レプリケーション、スナップショット、バックアップ機能などの優れた機能を備えており、スキーマのないデータを柔軟に格納できます。

ただし、データベースの代わりにファイルシステムを使用している例は見つかりません。

スキーマレス (または「ドキュメント指向」) データベースをファイルシステム上のレイヤーとして実装する方法に関するその他のリソースはどこにありますか? 最新のファイルシステムをスキーマレス データベースとして使用している人はいますか?

MySQL を使用してスキーマレス データを保存しています ( FriendFeed が MySQL を使用してスキーマレス データを保存する方法に着想を得たソリューションについては、「スキーマレス データにリレーショナル データベースを使用する」を参照してください)。

1 つの大きなテーブルに、アプリケーションのすべてのエンティティが保持されます。

いくつかの詳細:

• 格納されたエンティティの唯一の必須プロパティはid、16 バイトの UUID です。エンティティの残りの部分は、データベースに対して不透明です。に新しいプロパティを格納するだけで、「スキーマ」を変更できますbody。

• このadded_id列が存在するのは、InnoDB が物理的にデータ行を主キーの順序で格納するためです。AUTO_INCREMENT 主キーにより、古いエンティティの後に新しいエンティティがディスクに順次書き込まれることが保証され、読み取り/書き込みの局所性に役立ちます (新しいエンティティは古いエンティティよりも頻繁に読み取られます)。

• 私たちのデータベースは、スキーマレス データを に保存しますbody。<-これがこの質問のトピックです。

• 非同期マテリアライズド ビュー (インデックスはオフラインで構築される単なるテーブルです) を構築するためにデータに「到達」するなど、他にも興味深い詳細がたくさんありbodyますが、現在の議論には関係ありません...

の構造化データ (キーと値のペア) をどのようにシリアル化する必要がありbodyますか?

フィールド名が行ごとに繰り返されるため、JSON または BSON は単純です。これにより、柔軟性が向上しますが、スペース効率が大幅に低下します (シリアル化されたデータのフィールド名の行ごとのオーバーヘッド)。物事をメモリに保持しようとしていますが、ここではメモリとネットワークのフットプリントの両方を最小限に抑えることが重要です。同じスペースに収まるレコードが多いほど、クエリは高速になります。私たちは比較的長くてわかりやすいフィールド名を好みますが、データベースを高速化するためにフィールド名を短くするのは間違っています!

最終的に、JSON/BSON は、データベースと対話するアプリケーション ドライバーで、より複雑になり、小さなキーをよりわかりやすいキーにマップしない限り、この目的には使用できません。それは私たちに考えさせました...

私たちのデータベースはスキーマレスですが、実際には: 1) エンティティの種類はそれほど多くありません。2) 同じ種類のエンティティのバージョンが頻繁に変更されることはありません。3) 変更された場合、通常は追加するだけです。別のフィールド。JSON/BSON には、バージョン管理のネイティブ サポートはありません。

Protocol Buffers と Thrift は、バージョン管理とデータ定義の変更に関しては、はるかに洗練されています。Thrift と Protocol Buffers はどちらも、データをデータベースにシリアル化するための優れた候補であり、Thrift はエンコード形式が拡張できるように設計されています。

Protocol Buffers は、スキーマレス データベースでデータをシリアル化するための優れた選択肢のように見えます。

CouchDB と MongoDB (最も人気のある 2 つのスキーマレス データベース?) はそれぞれ JSON と BSON を使用しますが、スキーマレス データを格納するためのシリアル化形式として、Protocol Buffers のようなより高度なものを使用することについては何も見つかりません。特定の言語バージョンのオブジェクトを格納する製品 (つまり、Java の外部化可能オブジェクトをデータグリッドに格納する、または Ruby で MySQL を使用して NoSQL を実行する) がありますが、これらは面倒です (他のプラットフォームから、または MySQL 自体からアクセスしてみてください。バージョン管理は忘れてください）。

相互運用性の高いプロトコル バッファをデータベースに保存したり、他の高度なシリアル化形式をスキーマレス データベースに保存したりする人はいますか? これは、JSON/BSON/XML の単純な行ごとのシリアル化や、特定の言語のオブジェクトのシリアル化以外に、他のオプションがあるかどうかという問題です。それは実現可能ですか？何か不足していますか？意識流のナラティブでごめんなさい！

次のようなXMLスキームがあります。

この情報をクラスに保存し、そのフィールドを指定されたタイプにします。私は一般的なアプローチを考えました

しかし、このアプローチの問題は、ExtraFieldsのリストが必要であり、それぞれがリスト内で異なるタイプを持つ可能性があることです。

これまでのところ、2つのオプションしか考えられません。

1）このフィールドに動的キーワードを使用しますが、このアプローチには制限があるようです

2）フィールドにオブジェクトタイプを使用し、その動的タイプを必要なタイプにキャストします。しかし、とにかく、オブジェクト固有の呼び出しが必要な場合は、静的キャストを行う必要があります。

私はあなたの考え/提案を読んでうれしいです

.csvMongoDBコレクション内のすべてのレコードをファイルにエクスポートするにはどうすればよいですか？

これにより、エクスポートする必要のあるフィールドの名前を指定するように求められます。フィールドの名前を指定せずにすべてのフィールドをエクスポートできますか？

固定フィールドと追加フィールドを持つクライアントを格納するドキュメントがあるとします。次に、クライアントのサンプルクラスを示します。

追加のフィールドクラスには、次のようなものがあります。

シリアル化に標準のドライバーの動作を使用すると、次のようになります。

私はこのようなものが欲しいのですが：

これにより、検索パフォーマンスが向上し、通常はドキュメントの方向付けのポイントになります。

シリアル化をそのような方法にカスタマイズするにはどうすればよいですか？

複数の外部 Web サービスへの統合を作成する必要があります。それらのいくつかはSOAP（WSDLを持っています）、いくつかはかなりアドホックです-HTTP（s）、基本認証またはURLのパラメーターによる認証（！）、実際にはドメインクラスにうまくマップされないXMLのような自然言語..

今のところ、Spring Web 3.0RestTemplateを使用してスパイク統合を行い、JAXB2 を使用してバインディングを行いました ( Jaxb2Marshaller)。ドメイン クラスは XML よりもクリーンである必要があるため、何らかのバインディングが必要です。

効きますが、ちょっと気持ち悪いです。明らかに、これは部分的にサービスがどのように構築されているかという理由によるものです。そして、私が抱えている小さな問題の 1 つはRestTemplate、サービスは REST とは関係がないため、名前を付けることです。これは私が一緒に暮らすことができます。ただし、JAXB2 は少し重く感じます。

だから、私はいくつかの他の選択肢を探しています。アイデア？私は単純な解決策を持ちたいです（RestTemplateで問題ありません）。あまりにもエンタープライズではありません..