Mongodb w/mongoengineを試してみたいです。私はDjangoとデータベースに不慣れで、外部キー、結合、循環インポート（名前を付けます）に慣れています。私は最終的にこれらの問題を解決できることを知っていますが、Mongoは私がしていることに対するより簡単な解決策のように思えます。私の質問は、プラグイン可能なアプリ（Imagekit、Haystack、Registrationなど）をたくさん使用していて、切り替えてもこれらのアプリが引き続き機能するかどうかを知りたいということです。私が遭遇する既知の頭痛はありますか？もしそうなら、MySQLで頭を叩き続けるかもしれません。
質問する
2752 次
6 に答える
9
すべての標準Djangoアプリに標準RDBMSのいずれかを使用できず、アプリにMongoを使用できない理由はありません。Django ORMからのものを処理するすべての標準的な方法を、Mongoの方法に置き換える必要があります。
したがって、urls.pyとそのきちんとしたパターンマッチングを維持でき、ビューは引き続きパラメーターを取得し、テンプレートは引き続きオブジェクトを取得できます。
クエリセットはRDBMSモデルと密接に関連していると思われるため、失われますが、実際には遅延評価されたリストにすぎません。models.pyの記述に関するDjangoのドキュメントを無視し、Mongoパラダイムでデータベースビジネスロジックをコーディングしてください。
ああ、データに簡単にアクセスするためのDjango管理インターフェースはありません。
于 2011-01-17T23:16:06.527 に答える
3
django-nonrelをチェックすることをお勧めします。これは、DjangoのNoSQLバックエンドでの若いが有望な試みです。現時点ではドキュメントが不足していますが、それを解決するだけでうまく機能します。
于 2011-01-31T12:42:45.153 に答える
1
私はdjangoでmongoengineを使用しましたが、たとえばmongo_models.pyのようなファイルを作成する必要があります。そのファイルで、Mongoドキュメントを定義します。次に、各Mongoドキュメントに一致するフォームを作成します。各フォームには、Mongoに保存されているものを挿入または更新するsaveメソッドがあります。Djangoフォームは、任意のデータバックエンドにプラグインするように設計されています（少し手間がかかります）
注意：ドキュメントやモデルで記述できる非常に明確に定義され構造化されたデータがある場合は、Mongoを使用しないでください。そのために設計されたものではなく、PostGreSQLのようなものの方がはるかにうまく機能します。
- 私はPostGreSQLをリレーショナルデータまたは適切に構造化されたデータに使用しています。小さなメモリフットプリントと良好な応答。
- 私はRedisを使用して、メモリキュー/リストをキャッシュまたは操作します。これは、Redisに非常に適しているためです。あなたがそれに対処するためのメモリを持っていることを提供する素晴らしいパフォーマンス。
- 私はMongoを使用して大きなJSONドキュメントを保存し、Mapを実行して（必要に応じて）それらを削減します。これは非常に優れているためです。ルックアップを高速化できる場合は、必ず特定の列にインデックスを使用してください。
四角い穴を埋めるために丸を付けないでください。それはそれを埋めません。
Mongoは流行語であるため、誰かがリレーショナルDBをMongoに交換したいと思った投稿をたくさん見ました。誤解しないでください、Mongoは本当に素晴らしいです...適切に使用すると。Mongoを適切に使用するのが大好きです
于 2012-04-18T07:25:33.020 に答える
0
前もって、モデルを出荷する既存のDjangoアプリでは機能しません。現時点では、 Djangoのモデルデータをmongodbまたは他のNoSQLストレージに保存するためのバックエンドはありません。データベースのバックエンドは別として、モデルdjango.contribテンプレートを出荷する誰かのアプリ（アプリを含む）を使用するようになると、モデル自体はやや議論の余地があります。-トライアドを表示します。目的に応じてわずかに異なるモデルが必要な場合は、アプリケーションコードを編集する（わかりにくい）、実行時にインポートされたPythonモジュールのコンテンツを動的に編集する（魔法の）、アプリケーションソースを完全にフォークする（面倒）、または追加の設定を提供します（良いですが、まれな出会いです。django.contrib.authおそらく、設定を通じてユーザープロファイルモデルの場合のように、使用するモデルを動的に指定できるアプリケーションの唯一の広く知られている例ですAUTH_PROFILE_MODULE）。
これは悪いことのように聞こえるかもしれませんが、実際には、SQLデータベースとNoSQLデータベースを並行してデプロイし、Spacedmanが提案したように、アプリごとに移行する必要があります。特定のアプリ、地獄、あなた自身のカスタムアプリを転がすだけです。
NoSQLストレージを頭に入れている素晴らしいDjangonautsがたくさんいます。過去のDjangoconプレゼンテーションのストリームをたどった場合、毎年、DjangoがNoSQLストレージをどのように活用すべきかについて重要な議論がありました。今年か来年には、誰かがアプリとモデルAPIをリファクタリングして、Djangoコアの一部としてNoSQLストレージのすべての異なるフレーバーを最終的に統合できるクリーンな設計への道を開くと確信しています。
于 2011-01-17T23:47:19.790 に答える
0
私は最近これを試しました（ただし、Mongoengineはありません）。落とし穴はたくさんあります、私見：
- 管理インターフェースはありません。
- Authdjango.contrib.authはDBインターフェースに依存していません。
- 多くのものがdjango.contrib.auth.Userに依存しています。たとえば、RequestContextクラス。これは大きな障害です。
- 登録なし（DBインターフェースとdjango.contrib.authに依存）
基本的に、djangoインターフェースでdjango.contrib.authへの参照を検索すると、壊れているものがいくつあるかがわかります。
とは言うものの、MongoEngineがdjango.contrib.authをより良いものに置き換え/拡張するためのサポートを提供する可能性はありますが、それに依存するものが非常に多いため、モンキーパッチをどのように適用するかはわかりません。
于 2011-01-18T20:07:54.467 に答える
-1
主な落とし穴（私にとって）：参加しないでください！
于 2011-01-18T00:30:23.607 に答える