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

Question

很久没有从头开始创建项目了，现在document-oriented databases (以及 ODM)已经变得相当流行，所以在盲目地走关系路线之前我必须考虑它们。

谁能尝试列出可能导致一种选择或另一种选择的动机/项目标准？

Answer 1

ORM/关系数据库/SQL

优点:

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

缺点:

• 难以扩展到大量数据，如果性能也是一个问题的话
• 不能很好地映射到具有可变结构(或半结构化)的数据
• 持久对象需要胶水/翻译层，这可能是性能瓶颈(如果做错了也会非常冗长)

ODM/文档数据库/NoSQL

优点:

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

缺点:

• 经常，不加入(或有限版本的加入)
• 通常，没有事务(或事务一致性/原子性的有限版本)

如何决定

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

• 数据是否具有统一的结构？ (关系)......或可变/不一致的结构？ (文件)
• 典型用法是否读取/写入单一类型的实体？ (文档)......或由多个实体的属性组成的 View ？ (关系)
• 是否需要交易？ (关系)......或者不需要交易？ (文件)

基于扩展/性能要求:

• 海量数据 + 少量、缓慢、复杂的读/写？ (数据仓库类型场景)=>关系型
• 海量数据 + 海量的简单读/写？ (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，即关系和文档混合)