サードパーティ ツール
Overview
このページでは、PyMongo を操作するための一般的なサードパーティ ライブラリについて説明します。 Motor を除くすべてのライブラリはコミュニティによって管理されています。 このリストを最新に保つために、最近更新されていないプロジェクトは時々リストから削除されるか、末尾に移動されます。
Tip
これらのライブラリは役立つ場合がありますが、新しい PyMongo ユーザーは、ドライバーを直接操作することで開始することをお勧めします。 PyMongo のみがほとんどのユーザーのニーズを満たします。PyMongo との連携は MongoDB の動作に影響します。
ORM のようなレイヤー
ORM のような(オブジェクト関係のマッピングのような)レイヤーは、PyMongo にモデルや検証などの機能を追加します。
MincePy は、任意のPythonオブジェクトをMongoDBデータベースに保存およびクエリ可能にするように設計されたオブジェクト ドキュメント マッパー(ODM)です。これは、機械学習と大規模な計算および実験的なアプリケーションを念頭に置いて設計されています。 ただし、これは完全に一般的なものであり、現在のワークフローを可能な限り変更せずに大量のデータを整理、共有、または処理したいユーザーには役立ちます。
Ming は、Python アプリケーションの MongoDB database にスキーマを強制できるライブラリです。SourceForge によって開発されました MongoDB への移行の過程で。紹介ブログ記事 をご覧ください 詳細については、「 」を参照してください。
MongoEngine では、Diango ORM に影響された構文を使用して、ドキュメントとクエリ コレクションのスキーマを定義できます。Githubで利用可能なコード。
MotorEngine は MongoEngine to Motor のポートであり、Tornado との非同期アクセスが可能です。同じモデリング API をデータ互換性のある方法で実装しているため、MongoEngine で定義されたモデルは MotorEngine で読み取ることができます。 ソースはGithub で利用可能です。
uMongo は、非同期 ODM がないこと、および他の ODM でドキュメントを直列化するのが困難であるという 2 つのニーズを満たすために作成された Python MongoDB ODM です。uMongo は、PyMongo、TxMongo、 Motor_asyncio、mongomock などの複数のドライバーで動作します。 ソースはGithub で利用可能です。
フレームワーク ツール
このセクションでは、さまざまな Python フレームワークとライブラリで動作するように設計されたツールとアダプターを一覧表示します。
Django
Diango バックエンドがなくても、Dhango が提供するほとんどの MongoDB と PyMongo を使用できます。 管理、認証、セッションなど、 django.db
を必要とする Dlango の特定の機能は、MongoDB のみを使用している場合は動作しません。
Diango MongoDB エンジン は、Dpango の MongoDB データベース バックエンドであり、Diango 集計、アトミック アップデート、埋め込みオブジェクト、map/reduce、GridFS をサポートしています。これを使用すると、ORM、管理、認証、サイトとセッションのフレームワーク、キャッシュなど、Diango の組み込み機能のほとんどを使用できます。 詳細については、「 Diango MongoDB Engine 」のチュートリアルを参照してください。
Diango MongoEngine は、Diango の MongoDB バックエンドです。リポジトリには サンプル アプリケーション も含まれています 。詳細については、 Dpango MongoEngine に関するドキュメント を参照してください。
Djongo は、MongoDB をデータベース バックエンドとして Dlango を使用するためのコネクターです。Djongo では、 Diango Admin GUI を使用して MongoDB 内のドキュメントを追加および変更できます。 Dmongo ソースコード Githubと Djongo パッケージ でホストされている は PyPI 上にあります。
Mango は、Diango セッションと認証用の MongoDB バックエンドを提供します(
django.db
を完全にバイパスします)。
Flask
[Flask-MongoAlchemy] は、MongoAlchemy による MongoDB の Flusk サポートを追加します。
[Flask-MongoKit] は、MongoKit を Flusk により適切に統合するための Flusk 拡張機能です。
[Flask-PyMongo] は、Flask と PyMongo をブリッジします。
その他のツール
フルスタック FastAPI アプリ ジェネレーターを使用すると、FastAPI、 React、 MongoDBを統合するフルスタックアプリケーションをすばやく起動できます。
Log4mongo は、通常のコレクションとPython MongoDBCapped コレクションを使用して にログを保存できる柔軟な ロギング ハンドラーです。
mongobox は、Python アプリ内からサンドボックス化された MongoDB インスタンスを実行するためのツールです。
mongodb_beater により、MongoDB を Bearer の バックエンドとして使用できます キャッシュとセッション システム。ソースはGithub にあります。
MongoLog は、Capped コレクションを使用して MongoDB にログを保存する Python ロギング ハンドラーです。
rust . レプリカセット は、 ビルドアウトです MongoDB をダウンロードしてインストールするためのレシピです。
相互運用性ツール
このセクションでは、他のツールとの相互作用をサポートするツールを一覧にしています。
gevent
PyMongo は Python 標準ライブラリのスレッド関数とソケット関数を使用します。 getevent を使用することで 、PyMongo は非ブロッキングソケットを使用して非同期 I/O を実行し、 greenlets に対して スケジュール操作を実行できます スレッドではなく、
PyMongo で getevent を使用するには、次の例に示すように、他のモジュールをロードする前に、getent のmonkey.patch_all()
メソッドを呼び出します。
# You must call patch_all() *before* importing any other modules from gevent import monkey _ = monkey.patch_all() from pymongo import MongoClient client = MongoClient()
重要
ブロッキングを回避するために MongoClient を閉じます
アプリケーションの起動時にmonkey.patch_all()
を呼び出すと、 MongoClient
はスレッドではなく「greenlets」を使用してサーバーの健全性を監視します。 シャットダウン時に、アプリケーションが最初にこれらのgreenlets を終了せずに~gevent.hub.Hub.join()
メソッドを呼び出すと、 ~gevent.hub.Hub.join()
メソッドへの呼び出しは無期限にブロックされます。
これを回避するには、アプリケーションを終了する前に、アクティブなMongoClient
オブジェクトを閉じるか、廃止します。 一部のアプリケーション フレームワークでは、次の例に示すように、アプリケーションがSIGHUP
を受信したときに シグナル ハンドラーを使用してバックグラウンド グレットを終了できます。
import signal def graceful_reload(signum, traceback): """Explicitly close some global MongoClient object.""" client.close() signal.signal(signal.SIGHUP, graceful_reload)
この問題は、 1.9.16より前の null バージョン、または-gevent-wait-for-hub
オプションを持つそれ以降の u 詳しくは、「 uAWSI の変更ログ 」を参照してください。
Mod_wsgi
Mod_wsgi パッケージは、Apache ウェブサーバー上で Python ベースのウェブアプリケーションをホストするための AWSGUI 準拠のインターフェースを実装する Apache モジュールを提供します。
Mod_wsgi で PyMongo アプリケーションを実行するには、次のガイドラインに従います。
Mod_wsgi をデーモン モードで実行するには、
WSGIDaemonProcess
ディレクティブを使用します。 Mod_wsgi 構成にWSGIScriptAlias
ディレクティブのみが含まれている場合は、埋め込みモードで実行されます。WSGIApplicationGroup %{GLOBAL}
ディレクティブを使用して、アプリケーションがサブインタープリターではなく、デーモンのメインの Python インタープリターで実行されるようにします。 これにより、サブインタープリターで BSON をデコードする際に発生するわずかなコストを回避できます。WSGIProcessGroup
ディレクティブを使用して、各アプリケーションを個別のデーモンに割り当てます。 これにより、アプリケーションは相互の状態に影響を与えないようになります。
以下の Mod_wsgi 構成は、前述のディレクティブを使用して PyMongo アプリケーションを実行する方法を示しています。
<VirtualHost *> WSGIDaemonProcess my_process WSGIScriptAlias /my_app /path/to/app.wsgi WSGIProcessGroup my_process WSGIApplicationGroup %{GLOBAL} </VirtualHost>
PyMongo アプリケーションが複数ある場合は、それぞれをグローバル アプリケーション グループの個別のデーモンに配置します。
<VirtualHost *> WSGIDaemonProcess my_process WSGIScriptAlias /my_app /path/to/app.wsgi <Location /my_app> WSGIProcessGroup my_process </Location> WSGIDaemonProcess my_other_process WSGIScriptAlias /my_other_app /path/to/other_app.wsgi <Location /my_other_app> WSGIProcessGroup my_other_process </Location> WSGIApplicationGroup %{GLOBAL} </VirtualHost>
注意
多くの Python C 拡張機能は、複数の Python サブインタープリタで実行する際に問題があります。 これらの問題は、 Py_NewInterpreter のドキュメントで説明されています。 複数の Python サブ インタプリタ での と Mod_wsgi ドキュメントの「」セクションを参照してください。
代替の Python ドライバー
このセクションでは、PyMongo の代替手段を一覧表示します。