73

我的 Django 项目将由一个包含数十万条目的大型数据库支持，并且需要支持搜索（我可能最终会使用 djangosearch 或类似项目。）

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

4

11 回答 11

66

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

如果您不受任何遗留系统的束缚并且可以自由选择数据库后端，我们推荐 PostgreSQL，它可以在成本、功能、速度和稳定性之间取得良好的平衡。（Django 权威指南，第 15 页）

于 2010-05-11T09:18:44.163 回答
48

作为最近将项目从 MySQL 切换到 Postgresql 的人，我不后悔切换。

从 Django 的角度来看，主要区别在于 Postgresql 中更严格的约束检查，这是一件好事，而且手动更改模式（又名迁移）也有点乏味。

那里可能有 6 个左右的 Django 数据库迁移应用程序，并且至少有一个不支持 Postgresql。不过，我不认为这是一个缺点，因为您可以使用其中一个或手动执行它们（这是我更喜欢 atm 的）。

MySQL可能会更好地支持全文搜索。MySQL 在 Django 中支持内置的全文搜索，但它非常无用（没有词干、短语搜索等）。我使用django-sphinx作为在 MySQL 中进行全文搜索的更好选择。

Postgresql 8.3 内置全文搜索（早期版本需要 TSearch 模块）。这是一篇很好的指导性博客文章：使用 PostgreSQL 和 tsearch2 在 Django 中进行全文搜索

于 2009-02-25T11:29:19.767 回答
42

拥有数十万条目的大型数据库，

这不是大型数据库，它非常小。

我会选择 PostgreSQL，因为它有更多的特性。在这种情况下最重要的是：在 PostgreSQL 中，您可以使用 Python 作为过程语言。

于 2009-02-25T11:00:07.010 回答
11

选择你更熟悉的那个。MySQL 与 PostgreSQL 是一场无休止的战争。它们都是优秀的数据库引擎，并且都被主要站点使用。在实践中真的没关系。

于 2009-02-25T10:59:58.230 回答
8

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

Postgresql 用于处理“长连接”（连接池、持久连接等）

MySQL 用于处理“短连接”（连接、查询、断开连接、大量打开的连接存在一些性能问题）

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

它可以与 Postgresql 一起使用，但连接到 Postgresql 的成本要比连接到 MySQL 数据库高很多（在 Postgresql 上，每个连接都有自己的进程，这比在 MySQL 中弹出一个新线程要慢得多）。

然后你会得到一些在某些情况下非常有用的特性，比如查询缓存。（但你失去了 PostgreSQL 精湛的文本搜索）

于 2011-05-08T10:11:18.220 回答
8

所有的答案都带来了有趣的信息，但有些有点过时了，所以这是我的一粒盐。

从 1.7 开始，迁移现在是 Django 的一个组成部分。因此，他们记录了 Django 开发人员可能事先想知道的主要区别。

后端支持

Django 附带的所有后端以及任何第三方后端都支持迁移，如果它们已编程支持模式更改（通过SchemaEditor类完成）。

但是，在模式迁移方面，一些数据库比其他数据库更有能力；下面介绍了一些注意事项。

PostgreSQL

就模式支持而言，PostgreSQL 是这里所有数据库中能力最强的；唯一需要注意的是，添加具有默认值的列将导致表的完全重写，时间与其大小成正比。

因此，建议您始终使用 null=True 创建新列，因为这样会立即添加它们。

MySQL

MySQL 不支持围绕模式更改操作的事务，这意味着如果迁移无法应用，您将不得不手动取消选择更改才能重试（不可能回滚到更早的点）。

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

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

SQLite

SQLite 几乎没有内置的模式更改支持，因此 Django 尝试通过以下方式模拟它：

  • 使用新架构创建新表
  • 跨数据复制
  • 删除旧表
  • 重命名新表以匹配原始名称

此过程通常运行良好，但它可能会很慢并且偶尔会出现错误。除非您非常了解风险及其局限性，否则不建议您在生产环境中运行和迁移 SQLite；Django 附带的支持旨在允许开发人员在其本地计算机上使用 SQLite 来开发不太复杂的 Django 项目，而无需完整的数据库。

于 2015-06-02T18:36:06.157 回答
4

当 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)
于 2012-06-05T10:28:00.200 回答
3

因为我熟悉它而走上了 MySQL 的道路（并且努力寻找合适的安装程序并快速测试 postgreSQL 的慢速网络“工作台”界面让我失望），在项目结束时，经过几次部署几个月后，在研究备份选项时，我发现您必须为 MySQL 的企业备份功能付费。就在最后。

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

即使您熟悉 MySQL，我也推荐 PostgreSQL，但您的里程可能会有所不同。

更新：DBeaver是MySql Workbenchgui 工具的一个很好的等价物，但可以很好地与 PostgreSQL 一起工作（以及许多其他的通用数据库工具）。

于 2019-07-15T18:39:58.447 回答
2

要添加到以前的答案：

  • “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 索引、空间搜索等，这些都可以在非常复杂的查询上产生极快的计划。

于 2011-05-08T10:29:00.070 回答
1

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

于 2009-02-25T15:27:35.700 回答
0

如果您打算使用 db 分发代码，这两个 db 之间存在主要的许可差异，这将影响您。MySQL 的客户端库是 GPL，而 PostegreSQL 是在类似 BSD 的许可证下，这可能更容易使用。

于 2013-11-13T11:17:40.580 回答