关系数据库和NoSQL结合使用:MySQL + MongoDB

Home Page

作者使用一个案例来说明MySQL+MongoDB结合使用,发挥各自所长,并且认为他们互补性很强。

当然,这其中不可避免引入DDD中的编程设计模式 Repository仓储模式,通过它能够将数据存储方式和应用分离开来,这样,我们的程序就不受限于任何存储方式,无论是NoSQL或关系数据库。

这个案例是一个按效果付费Pay-for-use的分析案例,类似 Google Analytics软件。

该应用有如下特点:
1.授权支付交易: 需要收集支付的信用卡并保存他们的交易记录。
2.大量唯一访问量和页访问量数据: 这个数据量是非常巨大。
3.高性能插入: 支持以每秒插入频率记录访问量
4.实时报告: 能够实时分析唯一访问量和页访问量的状况。
5.高可用性:在线时间99.99%

第一种支付交易实现:
由于支付交易几乎和唯一访问量之间没有什么直接联系,这是一个shared-nothing架构,所以,可以分为两个过程实现:
1.使用MonggoDB记录唯一访问量,每个月把过去一个月的唯一访问量进行计数。
2.根据MongoDB技术数据,将相应支付数据插入MySQL。

对于后面4个需求,作者认为NoSQL的MongpDB都胜于MySQL。

个人点评:

使用仓储Repository模式将数据库和应用程序分离这是DDD一个主要优点,也是我以前曾经建议的,如果说,以前存储方式只有关系数据库,那么这种模式优点可能不显著,那么有了NoSQL这样另外一种非关系数据库的选择,我们的应用程序就不能再依赖数据库数据表了。

而国内现况是大多数中大型系统都依赖关系数据库,当用户规模扩展以后,关系数据库显然不再满足需求,这时的应用程序就必须重写了,无论对于国家还是对于用户都是巨大损失。

该文从MySQL和MongoDB两个角度来展示案例实现,在实际中,个人以为完全可以DDD等对象化设计建模,而不是一开始就陷入哪些使用NoSQL哪些使用关系数据库的细节讨论,这两种都是怎么做问题,我们关键是要通过类建模,首先找出做什么这个方向问题。

如果我们遵循松耦合 高内聚等原则,我们就能自然地将这个案例分别用不同的领域模型来表达,至于这些领域模型如何存储持久化,是Repository层的事情,与我们的业务核心领域层几乎无关,这样保证了我们的建模投资。

如果说,一个行业软件公司有什么技术核心竞争力?那么这个行业的领域模型建模经验和抽象结果应该是其核心竞争力,这些应该和技术平台发展没有太大关系,随着技术发展和淘汰也不会过时,相反,现实是很多企业核心模型都是建立在关系数据库这个底层技术上,今天是企业发展动力,明天就是企业发展阻力。


在做技术项目的时候,,对于语言的选择,,可能有一个公司的传承/习惯因素..

但是对于选择具体的存储方案,数据库,KV引擎,,应该先将这些都放在一边,仔细深入的分析数据的特点,以及访问的特点, 在这些都确定好之后, 分析所有可能的存储工具(Oracle/MySQL/还是NoSQL工具),选择一个合适的方案,甚至根据业务的特点选择一个组合的方案来进行处理..

2010年08月09日 10:03 "jametong"的内容
根据业务的特点选择一个组合的方案来进行处理 ...

楼上说得很好,但是一定要在设计上将你选择的具体实现(也就是怎么做的问题)和我们业务目标(做什么问题)实现分离,不要让具体选择的方案来绑架我们的业务,就象不要让房地产来绑架整个国民经济一样,这就是设计的大智慧,大学问,也是我们研究的重点。

我是个初学者,希望有MySQL + MongoDB + DDD的Demo可以直接下载学习。
如果是教程也可以。

看看 学学