問題タブ [schemaless]

電話/Webリクエスト/SMS/電子メールなどの結果として多くのイベントを生成するシステムがあります。これらのイベントのそれぞれを保存し、レポート(MI/BIなど)に使用できるようにする必要があります。これらのイベントには多くの変数があり、特定のスキームには適合しません。

イベント ドキュメントの構造は、キーと値のペアのリストです (cdr= 1&name=Paul&duration=123&postcode=l21)。現在、動的に生成されたスパース列を使用して (フラット) ドキュメントを格納する SQL Server システムがあり、そのデータに対して実行されるレポートがあります。さまざまな理由から、他のソリューションを検討しています。

これらのイベントを (スキーマに関係なく) プッシュし、その上でレポートと分析を提供できるシステム (オープンまたはクローズド) の提案を探しています。

私は Pentaho と Jasper を見たことがありますが、ほとんどはシステムに接続してデータを取得し、それについて報告しているようです。ドキュメントをプッシュして、レポートできるようにしたいだけです。

私は CouchDB が大好きですが、データをスキーマなしで送信し、その上でレポートを作成できるシステムを探しています (Pentaho、Jasper、SQL Reporting/Analytics Server などによく似ています)。

いくつかのオブジェクトを監視することに興味があります。15 分ごとに約 10000 のデータ ポイントを取得できると予想しています。（最初はそうではないかもしれませんが、これは「一般的な球場」です）。また、日次、週次、月次、年次の統計を取得できるようにしたいと考えています。データを最高解像度 (15 分) で 2 か月以上維持することは重要ではありません。

私はこのデータを保存するさまざまな方法を検討しており、従来のリレーショナル データベースまたはスキーマレス データベース (SimpleDB など) を検討しています。

私の質問は、これを行うための最良の方法は何ですか? 私は、独自の高価なソリューションよりも、オープンソース (および無料) のソリューションを非常に好みます。

小さなメモ: このアプリケーションは Python で作成しています。

したがって、正直なところ、トランザクションの整合性を実際には必要としないアプリがあります (多くの更新があり、どれも重要ではありません)。そのため、私は今のところ、単にエンティティ グループを脇に置くことを計画していました。しかし、私はまだそれを理解したいと思っています (リレーショナル バックグラウンドから来ています)。

私の見方では、私のアプリに対するすべてのクエリは、ユーザーごとに行われます。したがって、ドキュメントの推奨事項に従って、ユーザー エンティティより上位にグループ化する必要はありません。しかし、私は特定のユーザー エンティティを持つことを計画していませんでした。代わりに、エンティティ自体の UserProperty に依存していました。

私の見方では、(ユーザーごとに) トランザクションが必要な場合、データの階層の一部であるすべてのエンティティの親として、このエンティティがどれほど薄いかに関係なく、ある種のルート ユーザー エンティティが必要になります。つまり、基本的にプロパティはありません。

これは正しいです？

冗長で申し訳ありませんが、今夜は実際にスキーマレスが実際に意味することだけを実際にpingしました...

couchdbについてはよく耳にしますが、それに関するドキュメントをいくつか読んだ後でも、なぜそれをどのように使用するのかがわかりません。

この謎を解いてくれませんか？

私は RDF をいじっています。特に、rdf ストレージに格納されている情報にアクセスする方法を考えています。従来のリレーショナル データベースとの大きな違いは、事前定義されたスキーマがないことです。リレーショナル データベースでは、テーブルにそれらの列があることがわかっており、技術的に各行をクラスのインスタンスにマップできます。このクラスには、明確に定義されたメソッドと、明確に定義された属性があります。

スキーマのないシステムでは、特定の情報にどのデータが関連付けられているかわかりません。これは、事前定義されていない任意の数の列を持つデータベース テーブルを持つようなものであり、すべての行はこれらの列の任意の数にデータを持つことができます。

ObjectRelational マッパーと同様に、オブジェクト RDF マッパーがあります。RDFAlchemy と SuRF は、私が現在プレイしている 2 つです。基本的に、それらは Resource オブジェクトを提供し、そのメソッドと属性は動的に提供されます。それは理にかなっています...しかし、それはそれほど簡単ではありません。多くの場合、適切に定義されたインターフェイスを持ち、モデル オブジェクトでデータを設定および取得するときに何が起こっているかをより詳細に制御することを好みます。このような一般的なアクセス権を持つことは、ある意味で物事を困難にします。

私が指摘したもう 1 つの (そして最も重要な) ことは、たとえ一般的に 、スキーマのないデータは、リソースに関する任意の情報を提供することが期待されています。実際には、一緒になる傾向がある「情報のクラス」を多かれ少なかれ知っています。もちろん、追加情報の存在を排除することはできませんが、これは場合によっては標準ではなく例外ですが、例外は厳密なスキーマにとっては混乱を招くほど十分に賢明ですが. 記事の rdf 表現 (たとえば、RSS/ATOM フィードなど) では、記述されたリソースの用語を知っており、それらを明確に定義されたオブジェクトにマップできます。追加情報を提供する場合は、拡張オブジェクト (基本オブジェクトから継承) を定義して、拡張情報へのアクセサーを提供できます。したがって、ある意味では、拡張可能な「スキーマ指向オブジェクト」を使用して、スキーマのないデータを処理します。関心のある特定の追加情報を見たい場合。

私の質問は、スキーマレス データ ストレージの実際の使用方法に関するあなたの経験に関連しています。それらをオブジェクト指向の世界にどのようにマッピングして、スキーマレス ストレージの「ベア メタル」に近づきすぎずに上手に使用できるようにするのでしょうか? (RelDB 用語では、あまり SQL を使用せず、テーブル構造を直接いじることはありません)

アクセスは非常に一般的なものになる運命にあるのでしょうか (たとえば、SuRF の「プラグイン属性」は、データにアクセスするために必要な最高の、最も特殊化されたレベルです)、または合意された特定の便利なスキーマに特化したクラスを持つことも良いアプローチですが、新しい予期しない関連データにアクセスするためのクラスが急増するリスクはありますか?

私はこのチュートリアルに従っています：http：//friendlyorm.com/

私はInstantRailsを使用してMySQLをローカルで実行しています。RubyとRailsを実行するために、私は通常のWindowsインストールを使用しています。

実行するFriendly.create_tables!と、空の配列のみが返さ=> []れます。「friendly_development」データベースにテーブルは作成されません。

既存のモデルにActiveRecordを使用し、新しいモデルにFriendlyを使用できますか？

基本的に、スキーマレスにしたいモデルと、「古い」スタイルにしたいモデルを決定したいと思います。

これまでのところ、Django はいくつかの RDBMS とうまく統合されています。NoSQL、スキーマレス、ドキュメント指向の DBMS が台頭しています。流行りのファッショナブルな DBMS を Django に統合する状況はどうですか? Django 用の本番環境対応または少なくともすぐに使用できるライブラリはありますか?

これまでのところ、私はこれらを手元に持っています：

• http://github.com/lethain/comfy-django-example
• http://nosql.mypopescu.com/post/276069660/nosql-libraries#mongodb-python

免責事項：この質問がserverfault.comに適しているかどうかをお知らせください

特に音楽に関する情報を保存したい：

• ジャンル
• アーティスト
• アルバム
• 曲

この情報はWebアプリケーションで使用され、アルバムに関連付けられているすべての曲、アーティストに関連付けられているアルバム、およびジャンルに関連付けられているアーティストを表示できるようにしたいと思います。

現在MySQLを使用していますが、切り替える前に知りたいことがあります。

1. 水平方向のスケーリングはどのくらい簡単ですか？
2. SQLベースのソリューションよりも管理が簡単ですか？
3. 保存したい上記のデータは、スキーマフリーで実行するには難しすぎるでしょうか？
4. アソシエーションを考えるとき、私はすぐにRDBMSを思います。データはCouchDBのようなものに保存できますが、それでも上記のような何らかの関連付けがありますか？
5. 私のWebアプリケーションにはレプリケーションが必要ですが、CouchDBまたは他のユーザーはこれをどの程度うまく処理できますか？

この質問は、この質問に対する実用的な解決策を見つける試みです。

SQL データベースのセミスキーマレス設計が必要です。ただし、柔軟性を制限して、SQL パラダイム全体に押し込むことはできます。スキーマのないデータベースへの移行は、将来の選択肢になるかもしれませんが、今のところ、私は SQL にこだわっています。

SQL データベースにテーブルがあります ( と呼びましょうFoo)。これに行が追加されると、これに任意の数の「メタ」フィールドを格納できる必要があります。例としては、タグ、コラボレーターなどの任意のメタデータを添付する機能があります。すべてのフィールドはオプションですが、問題はそれらが異なるタイプであることです。数値の場合もあれば、テキストの場合もあります。

、、、などのフィールドFooを持つテーブルにリンクするシンプルなデザインは直接的に見えますが、アレックスが最後の回答で言及した EAV モデル全体に​​降りかかり、かなり無駄に見えます。また、これが大きくなったときのクエリはかなり遅くなると思います。ただし、このテーブルで何かを検索したり並べ替えたりすることは期待していません。必要なのは、 から行を取得するときに、これらの追加の属性も取得できるようにすることだけです。OptionalValuesnamevalue_typevalue_stringvalue_intvalue_dateFoo

この種のセットアップを SQL データベースに実装するためのベスト プラクティスはありますか、それとも単に全体を見誤っているのでしょうか。