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

Question

我已经很长时间没有从头开始创建一个项目,现在面向文档的数据库(以及ODM)已经变得非常流行,所以我必须在盲目地走向关系路线之前考虑它们.

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

Answer 1

ORM /关系数据库/ SQL

优点:

• 众所周知的标准方法
• 很好地映射到具有一致结构的数据
• 很好地映射到多个实体之间具有多个关系的数据
• 具有广泛的连接功能
• 有交易
• 可扩展到每秒大量事务(使用MySQL Cluster,Fusion-IO等)

缺点:

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

ODM /文档数据库/ NoSQL

优点:

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

缺点:

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

怎么决定

根据数据类型和使用模式:

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

根据扩展/性能要求:

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

参考

• 何时使用MongoDB或其他面向文档的数据库系统？
• 面向文档的数据库与关系数据库,Doctrine Blog
• NoSQL:如果只是那么容易,BJ Clark
• 关系与非关系,Josh Berkus

(背景:我最近没有在这方面做过任何事情,但几年前我建立了一个使用复制MySQL + Sphinx的大型系统,即关系和文档混合)