对比MySQL，你究竟在什么时候更需要MongoDB（转）

原文链接： When Should I Use MongoDB rather than MySQL (or other RDBMS): The Billing Example（编译/仲浩审校/毛梦琪）

【编者按】随着数据的爆发性增长，NoSQL得到的关注已越来越多，然而你的用例真正需要使用NoSQL数据库吗？又真的适合使用NoSQL吗？近日，Bright Aqua研发副总裁Moshe Kaplan以BillRun系统为例，分析了MongoDB的优势和使用场景：

以下为译文：

NoSQL已经流行了很长一段时间，那么究竟是什么场景下你才更需要用到这些“新兴事物”，就比如MongoDB？下面是一些总结：

你期望一个更高的写负载

默认情况下，对比事务安全，MongoDB更关注高的插入速度。如果你需要加载大量低价值的业务数据，那么MongoDB将很适合你的用例。但是必须避免在要求高事务安全的情景下使用MongoDB，比如一个1000万美元的交易。

不可靠环境保证高可用性

设置副本集（主-从服务器设置）不仅方便而且很快，此外，使用MongoDB还可以快速、安全及自动化的实现节点（或数据中心）故障转移。

未来会有一个很大的规模

数据库扩展是非常有挑战性的，当单表格大小达到5-10GB时，MySQL表格性能会毫无疑问的降低。如果你需要分片并且分割你的数据库，MongoDB将很容易实现这一点。

使用基于位置的数据查询

MongoDB支持二维空间索引，因此可以快速及精确的从指定位置获取数据。

非结构化数据的爆发增长

给RDBMS增加列在有些情况下可能锁定整个数据库，或者增加负载从而导致性能下降，这个问题通常发生在表格大于1GB（更是下文提到BillRun系统中的痛点——单表格动辄几GB）的情况下。鉴于MongoDB的弱数据结构模式，添加1个新字段不会对旧表格有任何影响，整个过程会非常快速；因此，在应用程序发生改变时，你不需要专门的1个DBA去修改数据库模式。

缺少专业的数据库管理员

如果你没有专业的DBA，同时你也不需要结构化你的数据及做join查询，MongoDB将会是你的首选。MongoDB非常适合类的持久化，类可以被序列化成JSON并储存在MongoDB。需要注意的是，如果期望获得一个更大的规模，你必须要了解一些最佳实践来避免走入误区。

BillRun——使用MongoDB的账单系统|2014年2月MUG IL（来自oc666）

现实用例学习：账单

在上一次的ILMUG上，Ofer Cohen提出了BillRun，一个下一代基于MongoDB的开源账单解决方案。这个账单系统已被增速最快的以色列移动电话运营商采用，每月处理超过5亿的CDR（通讯记录），Ofer分享了该系统如何利用MongoDB的优势：

PPT请访问Slide Share

弱数据结构模式允许系统快速引入新的CDR类型，BillRun负责托管所有的数据。
BillRun系统已经管理了TB级的表格，I/O性能受限于新字段的增加及数据体积的增长。
快速副本集允许更简单地设置多数据中心DRP和HA方案。
分片允许I/O超预算时的线性横向扩展。
在CDR插入达到2000个每秒时，MongoDB非常适用于高写入系统。同时，你完全可以使用findAndModify（会影响性能）以及2阶段提交（应用程序级别）来解决事务问题。
面向开发者的查询允许优雅查询的编写。
基于位置允许更好的分析用户使用情况，从而更好地制定移动电话基础设施的投入点。

总结

MongoDB是个非常不错的工具，但是只有在适合的场景下才能爆发出压倒性优势，BillRun就是一个不错的用例。