nosql支持事务吗,进行数据管理的nosql

如何搞定NoSQL事务机制

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

创新互联专注于企业成都全网营销、网站重做改版、槐荫网站定制设计、自适应品牌网站建设、HTML5建站、成都商城网站开发、集团公司官网建设、外贸网站建设、高端网站制作、响应式网页设计等建站业务，价格优惠性价比高，为槐荫等各大城市提供网站开发制作服务。

NoSQL和MySQL的区别大吗？

即非关系型数据库和关系型数据库。

MySQL的优点：事务处理—保持数据的一致性；由于以标准化为前提，数据更新的开销很小（相同的字段基本上只有一处）；可以进行Join等复杂查询

NoSQL的优点：首先它是基于内存的，也就是数据放在内存中，而不是像数据库那样把数据放在磁盘上，而内存的读取速度是磁盘读取速度的几十倍到上百倍，所以NoSQL工具的速度远比数据库读取速度要快得多，满足了高响应的要求。即使NoSQL将数据放在磁盘中，它也是一种半结构化的数据 格式，读取到解析的复杂度远比MySQL要简单，这是因为MySQL存储的是经过结构化、多范式等有复杂规则的数据，还原为内存结构的速度较慢。NoSQL在很大程度上满足了高并发、快速读/和响应的要求，所以它也是Java互联网系统的利器。

简单的扩展：典型例子是Cassandra，由于其架构是类似于经典的P2P，所以能通过轻松地添加新的节点来扩展这个集群;

低廉的成本：这是大多数分布式数据库共有的特点，因为主要都是开源软件，没有昂贵的License成本;

NoSQL的缺点：大多数NoSQL数据库都不支持事务，也不像 SQL Server和Oracle那样能提供各种附加功能，比如BI和报表等; 不提供对SQL的支持

那么该如何选择？

如果规模和性能比24小时的数据一致性更重要，那NoSQL是一个理想的选择 （NoSQL依赖于BASE模型——基本可用、软状态、最终一致性）。

但如果要保证到“始终一致”，尤其是对于机密信息和财务信息，那么MySQL很可能是最优的选择（MySQL依赖于ACID模型——原子性、一致性、独立性和耐久性）。

如果关系数据库在你的应用场景中，完全能够很好的工作，而你又是非常善于使用和维护关系数据库的，那么我觉得你完全没有必要迁移到NoSQL上面，除非你是个喜欢折腾的人。如果你是在金融，电信等以数据为王的关键领域，目前使用的是Oracle数据库来提供高可靠性的，除非遇到特别大的瓶颈，不然也别贸然尝试NoSQL。

然而，在WEB2.0的网站中，关系数据库大部分都出现了瓶颈。在磁盘IO、数据库可扩展上都花费了开发人员相当多的精力来优化，比如做分表分库（database sharding）、主从复制、异构复制等等，然而，这些工作需要的技术能力越来越高，也越来越具有挑战性。如果你正在经历这些场合，那么我觉得你应该尝试一下NoSQL了。

具体问题具体分析

MySQL体积小、速度快、成本低、结构稳定、便于查询，可以保证数据的一致性，但缺乏灵活性。

NoSQL高性能、高扩展、高可用，不用局限于固定的结构，减少了时间和空间上的开销，却又很难保证数据一致性。

————————————————

版权声明：本文为CSDN博主「蒟蒻熊」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：

newsql数据库支持结构化数据吗?

首先，来谈一下对数据库市场的看法，关系型数据库会一直占有主导地位。第一个原因是它的历史最久，有庞大的用户基础，根深。第二，SQL 的 query 在场景上依然是占主体的，尤其在数据分析上。 NoSQL的产生的是SQL对某些非关系为场景（KV点读)上的scalability 不好导致的。那个时候，主要问题是无法横向 scale，也就是没有分布式的支持，所以NoSQL 诞生了。而且KV， document 使用 normalized 数据结构也不利于理解和编程，所以可以看做是NoSQL 从SQL中抢了一些自己更适合的场景，所以它是在特定的时间和环境出现的一个产品。随着Distributed SQL 的出现， NoSQL 和 Distributed SQL 变得越来越像。未来几年有可能和 Distributed SQL 合并作为了一个产品类型。 NoSQL 在市场份额上不会超过或取代SQL， 在一些场景上会继续成长，尤其是用关系型数据集不好表达的，比如图。

今天 NewSQL 和 Distributed SQL 这2个名词在业界有一定的混淆。NewSQL 出现的早，可以被认为是Distributed SQL 的子集。以后还是以 Distributed SQL 为定义好。 所以你的问题其实是在 传统SQL，Distributed SQL 和 noSQL 之间如何选择。

答案是，最重要的指标是看用户的数据access的场景，和对应的数据结构。满足以下条件，更多考虑NoSQL：

数据之间没有关系，或者关系不强烈；每个row独立，row 之间不存在大规模的一对多，多对多的关系。

数据本身适合KV， 或者自我包含的hierachy关系。 比如个人profile, 完全自我contain, 人很人之间不需要query。

Access 数据的方式主要以 ID (primary key) 为主的点读，和顺序access (按顺序iterate）。

需要支持大规模的读写，低延时。

如果需要事务特性，范围限于一个或几个row, 没有关系型的事务。

使用 SQL 主要是因为 row 和 row 之间有关系； 存在一对多、多对多的关系。同时在关系的前提下，支持事务。支持table join的语法。对一致性要求高（强一致)。 Distributed SQL 提供了跨节点的分布式事务，query 等。但它是建立在牺牲性能的前提下的，延时大大价高。所以 NoSQL 是分布式+无关系，传统SQL 是 有关系+无分布式， Distributed SQL 是 分布式 + 有关系 + 性能取舍。

NewSQL 现在已经消退了，目前在国外退化为Distributed SQL原因如下：

卡耐基梅隆大学数据库教授Andy Pavlo，在文中系统地分析了NewSQL兴起到消亡的过程，给出了他认为NewSQL消亡的一些原因，比如：

1）没有开源。

2）没有拥抱公有云，在成本与技术上难与跟公有云厂商抗衡。

3）已有的关系型数据库MySQL,PostgreSQL做的不错，而且在不断改进，大部分客户数据并不多，单节点存储就能装下。

4）销售困难：客户担心切换风险，而且面临NoSQL在易用性方面的夹击。

另外，在谈到数据库发展趋势时，也提到NoSQL开始普遍支持SQL,joins和事务功能。到2021年后NewSQL概念除了中国的数据库创业公司，国外较少提了，更多地转向Distributed SQL。

NoSQL 和 关系型数据库，OLAP和OLTP的边界目前和未来会进一步模糊。市场的主要NoSQL产品开始普遍支持SQL,joins和事务功能，就我个人观点而言，NoSQL未来应该还是坚守初心——高并发，低延时，高伸缩性，对于关系型数据库擅长的 跨表Join, 跨机事务，AP等能力扩展应该谨慎些。产品选型时，最好也从这些方面多考虑些。

为什么大部分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在同样分区上也支持多键事务，但是不支持跨分区的事务。

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

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

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