传统数据库与新型数据库的优缺点

一：传统数据库

陈仓网站制作公司哪家好，找成都创新互联公司！从网页设计、网站建设、微信开发、APP开发、成都响应式网站建设公司等网站项目制作，到程序开发，运营维护。成都创新互联公司成立于2013年到现在10年的时间，我们拥有了丰富的建站经验和运维经验，来保证我们的工作的顺利进行。专注于网站建设就选成都创新互联公司。

(1）传统索引不适于海量数据    

传统行存数据库索引需要手工设定，对应用不完全透明，随场景和需求的变化需要不断调整，人工维护成本很高。并且传统索引占用存储空间很大，甚至高于数据本身，造成查询效率的下降。

（2）数据装载速度慢

因为索引需要重新创建，加载性能会变的很糟糕。分析型架构系统要解决这些个问题，必须最大限度地减少磁盘 I/O ，提升查询效率，减小人工维护成本。南大通用分析型数据库GBase8a (以下简称GBase 8a)通过列存储模式、数据压缩、智能化的索引、并行处理、并发控制、高效的查询优化器等技术，使得上述问题得到有效解决。以下各节将描述 GBase 8a 的创新架构如何实现这些目标。

二：新型数据库

新型数据库采用分布式并行计算架构，部署于X86通用服务器，满足大数据实时交易需求，成本低、扩展性高，突破了传统数据库性能瓶颈。

分布式非关系型数据库技术创新

非关系型数据库即NoSQL，抛弃了关系数据库复杂的关系操作、事务处理等功能，仅提供简单的键值对(Key, Value)数据的存储与查询，换取高扩展性和高性能，满足论坛、博客、SNS、微博等互联网类应用场景下针对海量数据的简单操作需求。主要技术创新为:

(1) 简单的数据操作换取高效响应。NoSQL仅支持按照Key(关键字)来存储和查询Value(数据)，不支持对非关键字数据列的高效查询;因数据操作简单、数据间一般不需要关联操作，故系统可支持高并发和较快的响应速度。

(2) 多种一致性策略满足业务需求。不同于传统关系型数据库仅支持强一致性策略，NoSQL还支持弱一致性和最终一致性等多种策略，可根据应用场景进行对应配置。例如，对写入操作频繁，但数据读取最新版本要求并不严格的应用，如互联网网页数据的存储和分析应用，可以采用最终一致性策略;而对订购关系存储的应用，则必须用强一致性策略，保证总是读取最新版本数据

为什么大部分NoSQL不提供分布式事务

像MongoDB, Cassandra, HBase, DynamoDB, 和

Riak这些NoSQL缺乏传统的原子事务机制，所谓原子事务机制是可以保证一系列写操作要么全部完成，要么全部不会完成，不会发生只完成一系列中一两个

写操作;因为数据库不提供这种事务机制支持，开发者需要自己编写代码来确保一系列写操作的事务机制，比较复杂和测试。

这些NoSQL数据库不提供事务机制原因在于其分布式特点，一系列写操作中访问的数据可能位于不同的分区服务器，这样的事务就变成分布式事务，在分

布式事务中实现原子性需要彼此协调，而协调是耗费时间的，每台机器在一个大事务过程中必须依次确认，这就需要一种协议确保一个事务中没有任何一台机器写操

作失败。

这种协调是昂贵的，会增加延迟时间，关键问题是，当协调没有完成时，其他操作是不能读取事务中写操作结果的，这是因为事务的all-or-

nothing原理导致，万一协调过程发现某个写操作不能完成，那么需要将其他写操作成功的进行回滚。针对分布式事务的分布式协调对整体数据库性能有严重

影响，不只是吞吐量还包括延迟时间，这样大部分NoSQL数据库因为性能问题就选择不提供分布式事务。

MongoDB, Riak, HBase, 和 Cassandra提供基于单一键的事务，这是因为所有信息都和一个键key有关，这个键是存储在单个服务器上，这样基于单键的事务不会带来复杂的分布式协调。

那么看来扩展性性能和分布式事务是一对矛盾，总要有取舍?实际上是不完全是，现在完全有可能提供高扩展的性能同时提供分布式原子事务。

FIT是这样一个在分布式系统提供原子事务的策略，在fairness公平性, isolation隔离性, 和throughput吞吐量(简称FIT)可以权衡。

一个支持分布式事务的可伸缩分布式系统能够完成这三个属性中两个，公平是事务之间不会相互影响造成延迟;隔离性提供一种幻觉好像整个数据库只有它自

己一个事务，隔离性保证当任何同时发生的事务发生冲突时，能够保证彼此能看到彼此的写操作结果，因此减轻了程序员为避免事务读写冲突的强逻辑推理要求;吞

吐量是指每单元时间数据库能够并发处理多少事务。

FIT是如下进行权衡：

保证公平性fairness 和隔离性isolation, 但是牺牲吞吐量

保证公平性fairness和吞吐量, 牺牲隔离性isolation

保证隔离性isolation和吞吐量throughput, 但是牺牲公平性fairness.

牺牲公平性：放弃公平性，数据库能有更多机会降低分布式事务的成本，主要成本是分布式协调带来的，也就是说，不需要在每个事务过程内对每个机器都依

次确认事务完成，这样排队式的确认commit事务是很浪费时间的，放弃公平性，意味着可以在事务外面进行协调，这样就只是增加了协调时间，不会增加互相

冲突事务因为彼此冲突而不能运行所耽搁的时间，当系统不需要公平性时，需要根据事务的优先级或延迟等标准进行指定先后执行顺序，这样就能够获得很好的吞吐

量。

G-Store是一种放弃公平性的 Isolation-Throughput

的分布式key-value存储，支持多键事务(multi-key transactions)，MongoDB 和

HBase在键key在同样分区上也支持多键事务，但是不支持跨分区的事务。

总之：传统分布式事务性能不佳的原因是确保原子性(分布式协调)和隔离性同时重叠，创建一个高吞吐量分布式事务的关键是分离这两种关注，这种分离原

子性和隔离性的视角将导致两种类型的系统，第一种选择是弱隔离性能让冲突事务并行执行和确认提交;第二个选择重新排序原子性和隔离性机制保证它们不会某个

时间重叠，这是一种放弃公平的事务执行，所谓放弃公平就是不再同时照顾原子性和隔离性了，有所倾斜，放弃高标准道德要求就会带来高自由高效率。

如何搞定NoSQL事务机制

在SequoiaDB巨杉数据库联合创始人兼CTO王涛看来，目前只有少量的NoSQL数据库支持事务机制，如VoltDB、RavenDB、SequoiaDB、MarkLogic。并且，“NoSQL支持事务（ACID）是未来的趋势，不支持事务的NoSQL会大大缩小其应用场景。”对于ACID来说，是指数据库事务机制正确执行的四大基本要素，包含了：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。

什么是New SQL?分析NewSQL是如何融合NoSQL和RDBMS两者的优势

NewSQL是对一类现代关系型数据库的统称，这类数据库对于一般的OLTP读写请求提供可横向扩展的性能，同时支持事务的ACID保证。这些系统既拥有NoSQL数据库的扩展性，又保持传统数据库的事务特性。NewSQL重新将“应用程序逻辑与数据操作逻辑应该分离”的理念带回到现代数据库的世界，这也验证了历史的发展总是呈现出螺旋上升的形式。

在21世纪00年代中，出现了许多数据仓库系统 (如 Vertica，Greeplum 和AsterData)，这些以处理OLAP 请求为设计目标的系统并不在本文定义的NewSQL范围内。OLAP 数据库更关注针对海量数据的大型、复杂、只读的查询，查询时间可能持续秒级、分钟级甚至更长。

NoSQL的拥趸普遍认为阻碍传统数据库横向扩容、提高可用性的原因在于ACID保证和关系模型，因此NoSQL运动的核心就是放弃事务强一致性以及关系模型，拥抱最终一致性和其它数据模型 (如 key/value，graphs 和Documents)。

两个最著名的NoSQL数据库就是Google的BigTable和Amazon的Dynamo，由于二者都未开源，其它组织就开始推出类似的开源替代项目，包括Facebook的 Cassandra (基于BigTable和Dynamo)、PowerSet的 Hbase(基于BigTable)。有一些创业公司也加入到这场NoSQL运动中，它们不一定是受BigTable和Dynamo的启发，但都响应了NoSQL的哲学，其中最出名的就是MongoDB。

在21世纪00年代末，市面上已经有许多供用户选择的分布式数据库产品。使用NoSQL的优势在于应用开发者可以更关注应用逻辑本身，而非数据库的扩展性问题；但与此同时许多应用，如金融系统、订单处理系统，由于无法放弃事务的一致性要求被拒之门外。

一些组织，如Google，已经发现他们的许多工程师将过多的精力放在处理数据一致性上，这既暴露了数据库的抽象、又提高了代码的复杂度，这时候要么选择回到传统DBMS时代，用更高的机器配置纵向扩容，要么选择回到中间件时代，开发支持分布式事务的中间件。这两种方案成本都很高，于是NewSQL运动开始酝酿。

NewSQL数据库设计针对的读写事务有以下特点：

1、耗时短。

2、使用索引查询，涉及少量数据。

3、重复度高，通常使用相同的查询语句和不同的查询参考。

也有一些学者认为NewSQL系统是特指实现上使用Lock-free并发控制技术和share-nothing架构的数据库。所有我们认为是NewSQL的数据库系统确实都有这样的特点。

当前名称：nosql支持事务处理,什么事nosql
URL标题：http://kswjz.com/article/hocjoo.html