nosql-intro-original.pdf-Martin Fowler(中文翻译)

来源:互联网 发布:新网域名转出 慢 编辑:程序博客网 时间:2024/06/08 07:43

第一页:未来不只是NoSQL数据库,而是混合持久化

关于企业数据存储的未来-主要写给参与企业应用开发管理的人

Martin Fowler,Pramod Sadalage  2012.11.26

第二页:SQL已统治了二十年

存储持久化数据

存储着大量的数据在磁盘,应用程序通过查询获取少量数据

应用程序集成

很多企业应用需要数据共享,全部的应用使用同一个数据库,我们必须保证获取的是一致的、最新的数据

主要标准

关系模型被人们广泛使用和了解,通过SQL语言与数据库进行交互,这几乎已经是一种标准语言,标准化的程度使得人们已非常熟悉,而不需要去学习新的东西

并发控制

在同一时间里有许多用户访问同一个信息,处理这种并发程序是困难的,所以数据库提供了事务,来帮助确保交互的一致性

报表

众多的报表工具是基于SQL的简单数据模型和标准化而建立的
--所有这些,是由大数据库厂商和职业DBA分别提供

第三页:但是,SQL的支配地位正在崩溃

关系数据库是被设计为运行在一台机器上,所以按照数据比例,你需要买一个更大的规模的大型机器微笑

然而,通过购买大量的并行小型机器,其实更为便宜和有效难过

机器在这些大型集群中,单个来说,是不可靠的;不过即使单个机器死了,整体集群可以继续保持工作,所以整个集群来说,是可靠的。“云”正是这种集群,这意味着关系数据库在云上并不能很好的运行。Web服务的兴起,提供了一个对共享数据库进行应用集成的有效选择,使得更容易为不同的应用程序选择他们各自的数据存储

谷歌和亚马逊都是在早期就开始避开关系据库而使用大集群的企业。

谷歌->Bigtable

亚马逊->Dynamo

他们的努力使得NoSQL社区获得了重大的启示

第四页:于是,就有了NoSQL数据库

NoSQL没有一个标准的定义。这个术语诞生在2009年的一个讨论会,但是对于什么样的数据库可以正真的称为NoSQL还具有争议

虽然还没有正式的定义,但是NoSQL仍然有一些共同的特征:

  • 它们不使用关系型数据模型,因此也不使用SQL语言
  • 它们往往运行在集群上
  • 它们倾向于开源
  • 它们没有一个固定的模式,允许你在任何记录上存储任何数据
例子有:mongoDB、CouchDB、Cassandra、riak、HBASE、redis

我们应该还记得Google的Bigtable和亚马逊的SimpleDB,被尝试用于他们云机的云服务时,是必然符合一般的操作特性的

第五页:所以,这表示我们可以

减少开发阻力

应用开发中大量的精力用于处理关系数据库。尽管已经有关系-对象映射框架来帮助减轻开发量,数据库依然是占据开发者工作量的主要来源。通常我们可以使用更适合解决领域问题的非传统数据库来减轻开发工作量。
我们经常遇到关系型数据库的项目,并不是因为它是最好的,而仅仅因为它是一个默认的选择而已。通常它们开发者把开发时间耗费在一些无用的功能上。

拥抱大数据

集群可以支持NoSQL,可以让我们处理更大量的数据。非传统的数据模型可以让我们更有效的处理更多任务,和一些如果只使用关系模型无法处理的问题。

Guardian

新的功能倾向使用MongoDB而不是关系型数据库,他们发现Mongo的文档数据模型和他们的应用更容易交互。

DNC

在关系模型里,想通过地址、电邮、电话号码在3亿的选民信息中查找其中一个选民是很困难的,mongoDB曾经使用文档(document)来保存个人信息。

Danish Health Care

药品记录通常集中存储在MySQL数据库中,但由于响应时间和可用性的关系,已迁移到Riak数据库。

McLaren

遥测数据流进入MongoDB延迟设计,大量的订单比关系数据库(SQL Server)更快。

第六页:但这不意味关系数据库已死

关系模型依然具有重要意义

表格模型对很多类型的数据都非常适合,特别是当你需要把数据拆分再通过另一种方式重新组合。

ACID事务

为了更有效的在及集群中运行,大部分NoSQL数据库对事务作了限制,一般是足够使用了,但并不总是。

工具

SQL长期的统治地位使得很多的工具都用基于SQL来编写的,这样,非关系型的工具就非常有限。

熟悉性

NoSQL系统还比较新,所以大家对他的使用还不太熟悉,所以我们不应该在一些实用性的系统中使用它,因为这样它的优势会受到影响。

第七页:这将带领我们走向混合持久化

使用多种数据存储技术,建立在各个应用的数据存储上。既然有更好的数据存储系统,为什么还要使用关系数据库来保存二进制图片呢?

第八页:混合持久化是什么样的

零售商的Web应用

用户会话:Redis(快速读写,不需要持久)

财务数据:RDBMS(需要事务更新,使用表格结构来适应数据)

购物车:Riak(多location高可用性,合并不一致的写入)

客户建议:Neo4J(快速链接朋友、产品购买、评价)

产品目录:MongoDB(大量的读,极少的写)

报表:RDBMS(报表工具中SQL的接口更适用)

分析系统:Cassandra(大量集群中大数据分析)

用户行为日志:Canssandra(在多个节点中大量写操作)

这只是一个假设性的例子,在没有任何调研之前我们不做任何的建议。

第九页:混合持久化为企业提供了更多的机遇与挑战

抉择

我们需要进行选择,而不是想以前一样直接使用关系型数据库

组织变革

如何把数据组织为新的技术模型

不成熟

NoSQL的工具都是新出不久,还有很多缺陷。而且我们对这些工具也没有很多的使用经验,不知道如何使用,什么才是更好的使用模式,也不知道哪里有陷阱等着我们

一致性范式的处理

企业应用中不同的数据存储者之间如果处理不同步的数据?如何执行系统间的数据同步?

第十页:什么样的系统可以选择混合持久化

策略

大部分的软件项目都是实用性项目,也就是说它们并不是企业的集中竞争优势点。

快速进入市场

如果你需要快速进入市场,那么你需要让你的开发团队最大化生产力。如果适当,混合持久化可以显著的消除阻力。

数据加强

可以有多种形式:

1、大量数据

2、高可用性

3、大量读写

4、复杂的数据关系

任何一点我们建议使用非关系型数据。

第十一页:更多的信息...

网上

咨询

0 0