20

さまざまな種類のデータに対応するオープン ソースのデータ管理 Web アプリケーションを作成することを考えています。

特権ユーザーは、次のことができる必要があります。

  • 新しいエンティティ タイプを追加する (たとえば、「ユーザー」または「家族」)
  • エンティティ タイプに新しいプロパティを追加します (たとえば、「性別」を「ユーザー」に)
  • エンティティとプロパティの削除/変更

これらは、特権ユーザーの一般的なタスクです。彼は、アプリケーションの Web インターフェイスを介してこれを行います。最終的に、すべてのデータは、アプリケーションのすべてのタイプのユーザーが検索およびソートできる必要があります。2つの質問が私を悩ませます:

a) データベースにデータをどのように保存する必要がありますか? 実行時にデータベース テーブルや列を動的に追加/削除する必要がありますか?

私はデータベースの専門家ではありません。私は、リレーショナル データベースに関して、アプリケーションが実行時にテーブル (エンティティ) や列 (プロパティ) を動的に追加/削除できる必要があるという想像にとらわれています。そして、私はこの考えが好きではありません。同様に、そのような動的データを NoSQL データベースで処理する必要があるかどうかを考えています。

とにかく、この種の問題には、これまで見つけられなかった、考えられなかった、インテリジェントな標準的な解決策があると信じています。この種の動的データ管理に最適なアプローチは何ですか?

b) ORM または NoSQL を使用して Python でこれを実装する方法は?

リレーショナル データベース モデルの使用をお勧めする場合は、SQLAlchemy を使用したいと思います。ただし、実行時にORMを使用してテーブル/列を動的に作成する方法がわかりません。これが、実行時にテーブルと列を作成するよりもはるかに優れたアプローチがあることを願っている理由の 1 つです。推奨されるデータベース モデルは、SQLAlchemy で効率的に実装できますか?

NoSQL データベースの使用を推奨する場合、どのデータベースを使用しますか? 私は Redis を使うのが好きです -- Redisに基づく効率的な実装を想像できますか?

ご提案いただきありがとうございます。

いくつかのコメントに応じて編集します。

特定のエンティティ (「テーブル」) のすべてのインスタンス (「行」) が同じプロパティ/属性 (「列」) のセットを共有するという考え方です。ただし、特定のインスタンスが特定のプロパティ/属性に対して空の値を持っている場合、それは完全に有効です。

基本的に、ユーザーは Web サイトの簡単なフォームからデータを検索します。たとえば、プロパティ P が T より大きい値 V を持つエンティティ E のすべてのインスタンスを照会します。結果は、任意のプロパティの値でソートできます。

データセットが大きくなりすぎることはありません。したがって、最もばかげたアプローチでさえ、システムが機能することにつながると思います。しかし、私は愛好家であり、現代的で適切なテクノロジーを適用したいだけでなく、理論上のボトルネックにも気を配りたいと思っています。このプロジェクトを使用して、最先端のスケーラブルで信頼性の高い "Pythonic" の Web アプリケーションを設計する経験を収集したいと考えています。

最初のコメントは、NoSQL アプローチを推奨する傾向があるようです。私は Redis がとても好きですが、Mongo/Couch の Document/Collection モデルを利用しないのはばかげているようです。私はPython用のmongodbとmongoengineを調べてきました。そうすることで、正しい方向に一歩を踏み出すことができますか?

いくつかの回答/コメントに応じて編集2：

あなたの回答のほとんどから、リレーショナル画像でのテーブルと列の動的な作成/削除は適切ではないと結論付けています。これはもう貴重な情報です。また、1 つの意見として、エンティティとプロパティを動的に変更するというアイデア全体が悪い設計である可能性があるというものがあります。

まさにこの動的な性質がアプリケーションの主な目的/機能であるべきなので、私はこれをあきらめません。理論的な観点から、動的データ モデルで操作を実行することは、静的データ モデルで操作を実行するよりも必然的に遅くなることを認めます。これはまったく問題ありません。

抽象的な方法で表現すると、アプリケーションは管理する必要があります

  1. データ レイアウト、つまり、有効なエンティティ タイプの「動的リスト」と、有効なエンティティ タイプごとのプロパティの「動的リスト」
  2. データ自体

これを実装するためのインテリジェントで効率的な方法を探しています。あなたの回答から、NoSQL がここに行く方法のように見えます。これはもう 1 つの重要な結論です。

4

4 に答える 4

20

SQL または NoSQL の選択は問題ではありません。一般的なデータベース設計についてもう少し読む必要があります。あなたが言ったように、あなたはデータベースの専門家ではありません (そしてそうである必要はありません) が、RDBMS パラダイムをもう少し勉強する必要があります。

アマチュア愛好家が NoSQL ソリューションを選択するのはよくある間違いです。NoSQL が適切なソリューションである場合もありますが、ほとんどの場合はそうではありません。

たとえば、あなたが言及したMongoDBを取り上げます（これは、私が試した優れたNoSQLソリューションの1つです）。スキーマレスですよね？エラー..正確ではありません。何かがスキーマレスであることは、制約や検証などがないことを意味することがわかります。しかし、アプリケーションのモデル/エンティティは、何もないところに立つことはできません! 確かに、ソフトウェア層に実装するいくつかの制約と検証ロジックがあります。だから私はあなたにモンゴキットをあげます！プロジェクトの説明からこの小さな部分を引用します

MongoKit は、優れた pymongo ドライバーの上に構造化されたスキーマと検証レイヤーをもたらします

うーん... 非構造化が構造化になりました。

少なくとも SQL はありませんよね？ええ、私たちはしません。もちろんSQLより劣る別のクエリ言語があります。少なくとも、基本的なクエリのために map/reduce に頼る必要はありません (CouchDB を参照してください)。

誤解しないでほしいのですが、NoSQL (特に MongoDB) には目的がありますが、ほとんどの場合、これらのテクノロジは間違った理由で使用されています。

また、深刻な永続性とデータの整合性に関心がある場合は、NoSQL ソリューションを忘れてください。これらのテクノロジーはすべて実験的すぎて、重要なデータを保持できません。誰が (Google/Amazon を除いて) NoSQL ソリューションを何のために使用しているかを少し調べてみると、重要なデータを保持するために NoSQL ソリューションを使用している人はほとんどいないことがわかります。彼らは主にログ、メッセージ、リアルタイム データに使用します。基本的に、SQL db ストレージから負荷を軽減するためのものです。

私の意見では、Redis はおそらく、NoSQL の急増を無傷で生き残る唯一のプロジェクトです。おそらく、それ自体を NoSQL としてではなく、キー値ストアとして宣伝しているためです。これはまさにそれであり、非常に優れたものです! また、彼らは粘り強さに真剣に取り組んでいるようです。これはスイス アーミー ナイフですが、RDBMS を完全に置き換えるには適したソリューションではありません。

すみません、言い過ぎました(;_;)

だからここに私の提案があります：

1) RDBMS モデルを少し調べます。

2)ほとんどのプロジェクトで RDBMS を使用する場合、Django は優れたフレームワークです。

3) Postgresql は素晴らしい! また、バージョン 9.2 ではネイティブJSONがサポートされることにも注意してください。そこにすべての「動的」プロパティをダンプし、セカンダリ ストレージ/エンジンを使用して、そのプロパティに対してクエリ (マップ/削減) を実行できます。あなたのケーキを持って、それも食べてください！

4) 本格的な検索機能については、solrなどの専用エンジンを検討してください。

編集: 2013 年 4 月 6 日

5) django-ext-hstoreを使用すると、postgresql hstore タイプにアクセスできます。これは Python 辞書に似ており、クエリを実行できますが、ネストされた辞書を値として使用できないという制限があります。また、 key の値は type のみにすることができますstring。

楽しむ

OPのコメントに応じて更新

0) アプリケーションに「データが含まれており」、すでにしばらく使用されていると考えてください

レガシー dbms にデータが含まれているという意味なのか、それとも「DB が空ではないことを想像して、次の点を考慮してください...」と言っているだけなのかはわかりません。前者の場合は移行の問題のようですが（まったく別の質問です）、後者の場合はまあまあです。

1) 管理者はエンティティ「家族」とすべての関連データを削除します

エンティティ(テーブル)を完全に削除する必要があるのはなぜですか? あなたのアプリケーションが家族や家などに関係するか、そうでないかのどちらかです。もちろん、ファミリのインスタンス(行)を削除することは理解できます。

2) 管理者はエンティティ「家」を作成します

#1と同じ。アプリにまったく新しいエンティティを導入すると、ほとんどの場合、セマンティクスとビジネス ロジックがカプセル化され、そのために新しいコードを作成する必要があります。これは、時間の経過とともに進化するすべてのアプリケーションで発生し、もちろん、新しいテーブルの作成、または既存のテーブルのALTERが必要になる場合があります。ただし、このプロセスはアプリケーションの機能の一部ではありません。つまり、めったに発生せず、移行/リファクタリングの問題です。

3) 管理者はプロパティ「フロア」、「年齢」などを追加します。

なんで？House床があることを事前に知りませんか？User性別がありますか？このタイプの属性を動的に追加および削除することは機能ではなく、設計上の欠陥です。エンティティとそれぞれのプロパティを識別するのは、分析/設計フェーズの一部です。

4) 特権ユーザーがいくつかの家を追加します。

はい、彼はインスタンス（行）を既存のエンティティ（テーブル）に追加していますHouse。

5) ユーザーは、少なくとも 5 階建てが 100 ドルよりも安いすべての家を検索します。

SQL または NoSQL ソリューションで実現できる完全に有効なクエリ。django では、次のようになります。

House.objects.filter(floors__gte=5, price__lt=100)

House属性floorsとを持っている場合price。しかし、テキストベースのクエリを実行する必要がある場合、SQL も NoSQL も十分に満足できるものではありません。自分でファセットやステミングを実装したくないからです。すでに説明したソリューション (Solr、ElasticSearch など) のいくつかを使用します。

より一般的な注意事項:

についてあなたが示した例とそのプロパティはHouses、Users動的スキーマを保証しません。要点を説明するために例を単純化したのかもしれませんが、追加/削除についてEntities(tables)は、データベース内の行であるかのように話します。エンティティは、アプリケーションで重要な役割を果たします。それらは、アプリケーションの目的とその機能を定義します。そのため、毎分変更することはできません。

また、あなたは言いました：

The idea is that all instances ("rows") of a certain entity ("table") share the same set of properties/attributes ("columns"). However, it will be perfectly valid if certain instances have an empty value for certain properties/attributes.

これは、属性が を持つ一般的なケースのようですnull=True。

そして最後に、あなたのキャリアがこのプロジェクトに依存しているようには見えないので、両方のアプローチ (SQL と NoSQL) を試すことをお勧めします。それぞれのアプローチの長所と短所を直接理解できるので、有益な経験になるでしょう。または、これらのアプローチをどのように「ブレンド」するかについても説明します。

于 2012-05-23T01:18:49.370 に答える
4

おそらく、モデル オブジェクトの永続化エンジン (RDBMS、NoSQL など) は関係ありません。あなたが探しているテクノロジーは、オブジェクトを検索して見つけるためのインデックスです。

スキーマを使用してオブジェクトを見つける必要があると思います。そのため、スキーマが動的に定義され、データベースに永続化されている場合、動的検索フォームなどを作成できます。実際のオブジェクトへのエンティティと属性の何らかの参照が必要です。

Entity-Attribute-Model パターン (EAV)を見てください。これを SQLAlchemy に実装して、RDBMS データベースを使用して、スキーマとデータを垂直に格納し、それらを関連付けることができます。

あなたはセマンティック Web プログラミングの分野に足を踏み入れています。おそらく、この本の最初の章を少しでも読む必要があります。

セマンティック Web のプログラミング

それはあなたの問題の全容を物語っています: 固定スキーマから動的スキーマまで、最初にキー値ストアとして実装され、その後リレーショナル モデルを介したグラフの永続性に改善されました。

私の意見では、これの最良の実装はグラフ データベースで達成でき、現在の実装の非常に良い例は Berkeley DB です (一部の LDAP 実装では、このインデックス作成の問題に対する技術的な実装として Berkeley DB を使用しています)。

グラフモデルに入ると、グラフである種の「推論」を行うことができ、ある種の「インテリジェンス」を備えたDBを表示できます。その例が本に書かれています。

于 2012-05-23T23:05:24.603 に答える
3

したがって、エンティティを「ドキュメント」として概念化すると、この問題全体が SQL を使用しないソリューションにうまく対応します。コメントしたように、ドキュメント ストアの上に位置し、検証などのタスクを実行し、おそらくある種のスキーマを強制 (または奨励) する、ある種のモデル レイヤーが必要になります。同じコレクション (テーブルに平行) 共有スキーマ。

特権ユーザーがスキーマの概念を変更できるようにする (個々のドキュメントにフィールドを追加するだけではなく、サポートが簡単です) と、少し問題が生じます。新しいスキーマに自動的に一致するように既存のデータを移行する必要があります。

編集内容を読み取ると、Mongo は探している種類の検索/順序付けをサポートし、必要な「空のセル」(特定のキーがないドキュメント) をサポートします。

もし私があなただったら (そして、私はたまたま似たようなシンプルな製品に取り組んでいます)、Mongo を使い続けて、Flask のような軽量の Web フレームワークを調べて、フロントエンドを提供します。モデルを提供するのは自分自身ですが、フレームワークの暗黙のモデリングの選択と戦うことはありません。

于 2012-05-22T17:56:50.040 に答える