MySQL対PostgreSQL？ Djangoプロジェクトのどちらを選択すればよいですか？
私のDjangoプロジェクトは、数十万のエントリを持つ大規模なデータベースに支えられており、検索をサポートする必要があります（おそらくdjangosearchまたは同様のプロジェクトを使用することになります。）
私のプロジェクトに最適なデータベースバックエンドとその理由は？さらに読むために良いリソースをお勧めできますか？
最近プロジェクトをMySQLからPostgresqlに切り替えた人として、切り替えを後悔していません。
Djangoの観点からの主な違いは、Postgresqlでのより厳密な制約チェックであり、これは良いことです。また、手動でスキーマを変更すること（別名、移行）は少し面倒です。 。
おそらく6つほどありますDjangoそこにデータベース移行アプリケーションがあり、少なくとも1つはPostgresqlをサポートしていません。他の1つを使用するか、それらを手動で（これは私がatmを好むものです）。
MySQLでは、フルテキスト検索がサポートされる可能性があります。 MySQLには、Django内でサポートされているフルテキスト検索が組み込まれていますが、かなり役に立ちません（Wordステミング、フレーズ検索などはありません）。私は Django-sphinx を使用しました= MySQLでの全文検索のより良いオプションとして。
全文検索はPostgresql 8.3に組み込まれています（以前のバージョンにはTSearchモジュールが必要です）。良い説明のブログ投稿を以下に示します。 Django PostgreSQLとtsearch2での全文検索
Djangoの作成者はPostgreSQLをお勧めします。
レガシーシステムに縛られておらず、データベースバックエンドを自由に選択できる場合は、コスト、機能、速度、安定性の微妙なバランスを実現するPostgreSQLをお勧めします。 （The Django Guide to Django、p.15）
数十万のエントリを持つ大規模なデータベース
これは大きなデータベースではなく、非常に小さなデータベースです。
私はPostgreSQLを選択します。それは、それがより多くの機能を持っているからです。最も重要なのはこの場合です。PostgreSQLでは、手続き型言語としてPython=を使用できます。
慣れている方を選んでください。 MySQL対PostgreSQLは無限の戦争です。どちらも優れたデータベースエンジンであり、主要なサイトで使用されています。実際には問題ではありません。
Postgresqlの方が良く見えても、Djangoのパフォーマンスに問題があることがわかりました。
Postgresqlは「長い接続」（接続プーリング、永続的な接続など）を処理するように作られています
MySQLは「短い接続」を処理するように作成されています（接続、クエリを実行、切断、 多くの開いている接続でパフォーマンスの問題があります ）
問題は、Djangoは接続プールまたは永続的な接続をサポートしていないため、ビューを呼び出すたびにデータベースに接続/切断する必要があることです。
Postgresqlで動作しますが、Postgresqlへの接続は、MySQLデータベースへの接続よりも多くのコストがかかります（Postgresqlでは、接続ごとに独自のプロセスがあり、MySQLで新しいスレッドをポップするよりもはるかに遅くなります）。
次に、場合によっては本当に役立つクエリキャッシュなどの機能を利用できます。 （しかし、あなたはPostgreSQLの優れたテキスト検索を失いました）
すべての答えは興味深い情報を表にもたらしますが、いくつかは少し古くなっているので、これが私の塩の粒です。
1.7以降、 migrations はDjangoの統合機能になりました。したがって、彼らはDjango開発者が事前に知りたいかもしれない主な違いを文書化しました。
バックエンドサポート
移行は、Djangoに同梱されているすべてのバックエンドと、スキーマの変更をサポートするようにプログラムされている場合はサードパーティのバックエンド（ SchemaEditor クラスを介して行われる）でサポートされています）。
ただし、スキーマの移行に関しては、一部のデータベースは他のデータベースよりも優れています。警告の一部を以下に示します。
PostgreSQL
PostgreSQLは、スキーマサポートの観点から、ここですべてのデータベースの中で最も能力があります。唯一の注意点は、デフォルト値で列を追加すると、テーブルのサイズに比例した時間、テーブルが完全に書き直されることです。
このため、null = Trueの新しい列を常に作成することをお勧めします。これにより、列がすぐに追加されます。
MySQL
MySQLはスキーマ変更操作に関するトランザクションをサポートしていません。つまり、移行の適用に失敗した場合、変更を手動で解除してから再試行する必要があります（以前の時点にロールバックすることは不可能です）。
さらに、MySQLはほとんどすべてのスキーマ操作のテーブルを完全に書き換え、通常はテーブルの行数に比例した時間をかけて列を追加または削除します。遅いハードウェアでは、これは100万行あたり1分よりも悪い場合があります。数百万行しかないテーブルに数列を追加すると、サイトが10分以上ロックされる可能性があります。
最後に、MySQLには、列、テーブル、およびインデックスの名前の長さに関する合理的な小さな制限と、インデックスがカバーするすべての列の合計サイズに関する制限があります。これは、他のバックエンドで可能なインデックスがMySQLで作成されないことを意味します。
SQLite
SQLiteには組み込みのスキーマ変更サポートがほとんどないため、Djangoは次の方法でエミュレートしようとします。
- 新しいスキーマで新しいテーブルを作成する
- データをコピーする
- 古いテーブルを削除する
- 元の名前と一致するように新しいテーブルの名前を変更する
通常、このプロセスは適切に機能しますが、速度が遅く、バグが発生する場合があります。リスクとその制限を十分に認識していない限り、SQLiteを運用環境で実行および移行することはお勧めしません。サポートDjangoに同梱されているため、開発者はローカルマシンでSQLiteを使用して、完全なデータベースを必要とせずに、それほど複雑ではないDjangoプロジェクトを開発できます。
Django-southで移行が失敗した場合、開発者はMySQLを使用しないことを推奨します。
! The South developers regret this has happened, and would
! like to gently persuade you to consider a slightly
! easier-to-deal-with DBMS (one that supports DDL transactions)
以前の回答に追加するには：
- 「MySQLでは全文検索がサポートされている可能性があります」
MySQLのFULLTEXTインデックスは冗談です。
- MyISAMテーブルでのみ機能するため、ACID、トランザクション、制約、関係、耐久性、同時実行性などが失われます。
- （フォーラム投稿のような）緩やかなTEXT列へのINSERT/UPDATE/DELETEは、インデックスの大部分を再構築します。 myisam_key_bufferに収まらない場合、大きなIOが発生します。1つのフォーラム投稿挿入トリガーが100MB以上IO ...その間、postsテーブルは排他的にロックされます！
- 私はいくつかのベンチマークを行いました（3年前、古くなっている可能性があります...）。これは、大規模なデータセットでは、基本的にpostgresフルテキストがmysqlよりも10〜100倍速く、Xapianがpostgresよりも10〜100倍速いことを示しています（ただし統合されていません）。
言及されていない他の理由は、非常にスマートなクエリオプティマイザー、結合タイプ（マージ、ハッシュなど）の幅広い選択肢、ハッシュ集約、配列のGistインデックス、空間検索などであり、非常に複雑なクエリで非常に高速なプランを作成できます。
このアプリケーションは、独自のサーバーまたはホスティング会社によってホストされますか？ホスティング会社を使用している場合は、選択したデータベースをサポートしていることを確認してください。
2つのdbの間には大きなライセンスの違いがあり、dbを使用してコードを配布する場合に影響します。 MySQLのクライアントライブラリはGPLであり、PostegreSQLはBSDライクなライセンスの下にあり、扱いが簡単な場合があります。
私がそれに慣れていたため（そして適切なインストーラーを見つけ、postgreSQLの遅いWeb "ワークベンチ"インターフェースの簡単なテストを見つけるのに苦労して）、MySQLの使用をやめました。導入から数か月後、バックアップオプションを検討しているときに、MySQLのエンタープライズバック機能に料金を支払わなければならないようです。一番最後にゲッチャ。
Djangoで、醜い怪物の生のSQLクエリをいくつか作成する必要がありました。グループごとの最新のクエリを取得するために、グループごとの個別の選択がないためです。また、postgreSQLの全文検索を見て、postgresSQLを使用したかった。
MySQLに精通している場合でもPostgreSQLをお勧めしますが、マイレージは異なる場合があります。