使用关系数据库/ORM 或文档数据库/ODM 的动机

Question

很久没有从头开始创建项目了，现在document-oriented databases（还有ODM）已经很流行了，所以在盲目走关系路线之前必须考虑一下。

任何人都可以尝试列出可能导致一种或另一种选择的动机/项目标准吗？

Answer 1

ORM/关系数据库/SQL

优点：

• 易于理解的标准方法
• 可以很好地映射到结构一致的数据
• 能够很好地映射到多个实体之间具有多种关系的数据
• 具有广泛的加入功能
• 有交易
• 可扩展到每秒处理大量事务（使用 MySQL 集群、Fusion-IO 等）

缺点：

• 如果性能也是一个问题，很难扩展到海量数据
• 不能很好地映射到具有可变结构（或半结构化）的数据
• 持久化对象需要粘合/翻译层，这可能会成为性能瓶颈（如果操作不当也可能非常冗长）

ODM/文档数据库/NoSQL

优点：

• 可扩展到海量数据和大量相对独立的查询
• 高可用性、分片、多主...
• 很好地映射到半结构化数据
• 可以很好地映射到具有更多可变结构的数据
• 数据模型可以更灵活
• 查询不必转换为 SQL（本机 NoSQL 查询样式可能更适合某些用途，也可能不适合，并且没有来自 SQL 驱动程序/解析/等的开销）
• （对于对象数据库）直接映射到对象，无需对象关系转换

缺点：

• 通常，没有加入（或加入的有限版本）
• 通常没有事务（或事务一致性/原子性的有限版本）

如何决定

基于数据类型和使用模式：

• 数据是否具有统一的结构？ （关系）......还是变量/不一致的结构？ （文件）
• 典型用法是否读/写单一类型的实体？ （文档）......还是由多个实体的属性组成的视图？ （关系）
• 是否需要交易？ （关系）……还是不需要交易？ （文件）

基于扩展/性能要求：

• 海量数据 + 少量、缓慢、复杂的读/写？ （数据仓库类型场景）=> 关系
• 海量数据+海量简单读/写？ （craigslist 后端类型场景）=> 文档
• 海量数据 + 快速、复杂的读/写？ => 这很难；要么使用关系并尝试扩展它，要么使用文档并尝试简化查询
• 中等数据 + 快速事务写入？ （银行类型场景）=> 关系
• 中等数据+中等读/写？ => 根据供应商/工具支持、熟悉程度等选择任何一个

参考

• When to use MongoDB or other document oriented database systems?
• Document-Oriented Databases vs. Relational Databases, Doctrine Blog
• NoSQL: If Only It Was That Easy, BJ Clark
• Relational vs. Non-Relational, Josh Berkus

（背景：我最近在这方面没有做任何事情，但几年前我构建了一个使用复制 MySQL + Sphinx 的大型系统，即关系和文档混合）