MySQL 与 PostgreSQL? 我应该为我的 Django 项目选择哪一个？

我的 Django 项目将由一个拥有数十万条目的大型数据库支持，并且将需要支持搜索(我可能最终会使用 Django 搜索或类似的项目)

哪个数据库后端最适合我的项目? 为什么? 你能推荐一些好的资源供进一步阅读吗？

40952 次浏览
小开

随便选一个你比较熟悉的。MySQL VS PostgreSQL 是一场无休止的战争。它们都是优秀的数据库引擎，并且都被主要站点使用。实际上这并不重要。

小开

数百个大型数据库 千人参赛,

这个数据库不是很大，而是非常小。

我会选择 PostgreSQL，因为它有更多的特性。最重要的是，在 PostgreSQL 中你可以使用 Python 作为工作语言。

小开
最佳答案

作为一个最近将一个项目从 MySQL 转移到 Postgreql 的人，我并不后悔这个转变。

从 Django 的角度来看，主要的区别在于 Postgresql 的约束检查更加严格，这是一件好事，而且手动更改模式(也就是迁移)也更加单调乏味。

大概有6个左右的 Django 数据库迁移应用程序，至少有一个不支持 Postgreql。但是我不认为这是一个缺点，因为您可以使用其中的一个或手动完成它们(这是我更喜欢的 atm)。

MySQL 更好地支持全文搜索 也许吧。MySQL 在 Django 中支持内置的全文搜索，但是它非常没用(没有词干分析、短语搜索等)。我在 MySQL 中使用 姜戈-斯芬克斯作为全文搜索的一个更好的选项。

全文搜索是内置的 Postgreql 8.3(早期版本需要 TSearch 模块)

小开

这个应用程序是托管在您自己的服务器上还是托管公司？确保如果您使用的是托管公司，他们支持所选择的数据库。

小开

无论如何，Django 的创建者都推荐 PostgreSQL。

如果你没有任何遗产的话 有选择的自由 我们建议使用数据库后端 PostgreSQL，它实现了罚款 成本、功能、速度之间的平衡 (姜戈通用指南，第15页)

小开

即使 Postgreql 看起来更好，我发现它与 Django 有一些性能问题:

Postgreql 用于处理“长连接”(连接池、持久连接等)

MySQL 用于处理“短连接”(连接、查询、断开连接、 有一些性能问题，与很多开放的连接)

问题是 Django 不支持连接池或持久连接，它必须在每次视图调用时连接/断开到数据库。

它可以工作在 Postgreql 上，但是连接到一个 Postgreql 比连接到一个 MySQL 数据库要花费更多的成本(在 Postgreql 上，每个连接都有自己的进程，比在 MySQL 中弹出一个新线程要慢得多)。

然后您会得到一些特性，比如 Query Cache，它们在某些情况下非常有用。(但是您丢失了 PostgreSQL 的优秀文本搜索)

小开

补充以前的答案:

  • “ MySQL 可能更支持全文搜索”

MySQL 中的 FULLTEXT 索引是个笑话。

  • 它只适用于 MyISAM 表，因此会丢失 ACID、事务、约束、关系、耐久性、并发性等。
  • INSERT/UPDATE/DELETE 到较大的 TEXT 列(如论坛帖子)将重新构建大部分索引。如果它不适合 myisam _ key _ buffer，那么将发生大的 IO。我看到一个论坛帖子插入触发100MB 或更多的 IO... 同时帖子表被完全锁定！
  • 我做了一些基准测试(3年前，可能已经过时了...) ，结果显示，在大型数据集上，postgres 全文比 mysql 快10-100倍，Xapian 比 postgres 快10-100倍(但没有整合)。

其他没有被提及的原因包括非常智能的查询优化器、大量的连接类型(合并、散列等)选择、散列聚合、数组的 gist 索引、空间搜索等，这些都可以在非常复杂的查询中产生非常快的计划。

小开

当 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 的客户端库采用 GPL，而 PostegreSQL 采用类似 BSD 的许可证，这可能更容易使用。

小开

所有的答案都给我们带来了有趣的信息，但是有些答案有点过时了，所以我对此持保留态度。

从1.7开始，迁徙现在是 Django 的一个整体特性。因此，他们记录了 Django 开发人员可能希望事先了解的主要差异。

后端支持

Django 提供的所有后端都支持迁移，如 以及任何第三方后端，如果他们已经编程支持 用于模式更改(通过 模式编辑器类完成)。

然而，当涉及到模式迁移时，一些数据库比其他数据库更有能力; 下面将介绍一些注意事项。

PostgreSQL

就模式支持而言，PostgreSQL 是这里所有数据库中最有能力的。

MySQL

MySQL 缺乏对模式更改操作相关事务的支持，这意味着如果迁移未能应用，您将不得不手动取消更改，以便再次尝试(不可能回滚到前一点)。

此外，MySQL 将为几乎每个模式操作完全重写表，并且通常需要与表中的行数成比例的时间来添加或删除列。在较慢的硬件上，这可能比每百万行只有一分钟还要糟糕——向一个只有几百万行的表中添加几列可能会将您的站点锁定十分钟以上。

最后，MySQL 对列、表和索引的名称长度有相对较小的限制，对索引覆盖的所有列的组合大小也有限制。这意味着在其他后端可以创建的索引将无法在 MySQL 下创建。

SQLite

SQLite 几乎没有内置的模式更改支持，等等 姜戈试图效仿它:

  • 使用新架构创建新表
  • 正在复制数据
  • 放下旧桌子
  • 重命名新表以匹配原始名称

这个过程通常工作得很好，但是它可能很慢，偶尔也会出现 不建议您在 生产环境，除非你非常清楚有关的风险及其影响 Django 船的支撑设计允许 开发人员在本地计算机上使用 SQLite 进行较少的开发 复杂的 Django 项目而不需要完整的数据库。

小开

因为我对 MySQL 很熟悉，所以一直沿着它的道路走下去(并且很难找到一个合适的安装程序和快速测试 postgreSQL 缓慢的 web“ workbench”接口，这让我感到厌烦) ，在项目的最后，在部署后的几个月后，在寻找备份选项时，我发现你不得不为 MySQL 的企业备份功能付费。在最后抓到你了。

使用 MySql，我不得不用 Django 编写一些丑陋的原始 SQL 查询，因为在检索最新的每组查询时，没有选择不同的每组查询。还查看了 postgreSQL 的全文搜索，并希望我使用了 postgreSQL。

即使您熟悉 MySQL，我也建议您使用 PostgreSQL，但是您的使用范围可能会有所不同。

更新: DBeaver是一个非常好的 MySql Workbench gui 工具，但与 PostgreSQL 工作得非常好(其他许多工具作为一个通用的数据库工具)。


提交答案