腾讯云
开发者社区
文档
建议反馈
控制台
首页
学习
活动
专区
工具
TVP
最新优惠活动
文章/答案/技术大牛
搜索
搜索
关闭
发布
登录/注册
首页
学习
活动
专区
工具
TVP
最新优惠活动
返回腾讯云官网
物流IT圈
专栏作者
举报
280
文章
501216
阅读量
97
订阅数
订阅专栏
申请加入专栏
全部文章
微服务
数据库
sql
编程算法
api
电商
企业
分布式
it
大数据
java
物联网
费用中心
网站
http
缓存
运维
云数据库 SQL Server
云数据库 Redis
打包
存储
开源
网络安全
数据分析
spring
https
系统架构
供应链
神经网络
容器
erp
rpc
数据挖掘
机器学习
nosql
github
深度学习
消息队列 CMQ 版
腾讯云测试服务
uml
安全
机器人
架构设计
产品
产品经理
管理
系统
其他
硬件开发
git
apache
nginx
文件存储
devops
压力测试
jvm
sql server
微信
数据可视化
信息流
云计算
kafka
app
excel
系统设计
需求分析
php
python
javascript
go
html
嵌入式
mvc
jar
搜索引擎
linux
unix
访问管理
短信
图像处理
金融
数据安全
工业物联
serverless
数据迁移
hadoop
mybatis
tcp/ip
socket编程
windows
5g
验证码
数据集成
gsp
产品设计
软件
负载均衡
人脸识别
比特币
数字货币
自动驾驶
tensorflow
ios
xcode
c 语言
bash
servlet
vue.js
react
node.js
xml
css
jquery
json
单片机
symfony
oracle
access
flask
sqlalchemy
ide
lucene/solr
负载均衡缓存
apt-get
tornado
laravel
批量计算
云直播
短视频
API 网关
SSL 证书
数据加密服务
物联网通信
mongodb
人工智能
微服务与微计算
日志数据
智慧物流
codeigniter
自动化
黑客
爬虫
spark
无人驾驶
hive
面向对象编程
spring boot
推荐系统
seo
自动化测试
cdn
aop
dubbo
spring cloud
数据处理
数据结构
hbase
腾讯云开发者社区
任务调度
虚拟化
mvcc
utf8
测试策略
es
数据库管理
应用安全开发
Elasticsearch Service
智能推荐平台
项目管理
adapter
axure
bug
dashboard
ddd
device
frequency
host
layer
ps
saas
sap
sh
usb
表单
产品运营
工作
基础
监控
解决方案
开发
连接
模型
配置
设计
数据
算法
同步
效率
异常
异常处理
原型
搜索文章
搜索
搜索
关闭
为什么大部分NoSQL不提供分布式事务?
数据库
hbase
mongodb
nosql
sql
像MongoDB, Cassandra, HBase, DynamoDB, 和 Riak这些NoSQL缺乏传统的原子事务机制,所谓原子事务机制是可以保证一系列写操作要么全部完成,要么全部不会完成,不会发生只完成一系列中一两个写操作;因为数据库不提供这种事务机制支持,开发者需要自己编写代码来确保一系列写操作的事务机制,比较复杂和测试。 这些NoSQL数据库不提供事务机制原因在于其分布式特点,一系列写操作中访问的数据可能位于不同的分区服务器,这样的事务就变成分布式事务,在分布式事务中实现原子性需要彼此协调,而协调是耗费时间的,每台机器在一个大事务过程中必须依次确认,这就需要一种协议确保一个事务中没有任何一台机器写操作失败。 这种协调是昂贵的,会增加延迟时间,关键问题是,当协调没有完成时,其他操作是不能读取事务中写操作结果的,这是因为事务的all-or-nothing原理导致,万一协调过程发现某个写操作不能完成,那么需要将其他写操作成功的进行回滚。针对分布式事务的分布式协调对整体数据库性能有严重影响,不只是吞吐量还包括延迟时间,这样大部分NoSQL数据库因为性能问题就选择不提供分布式事务。 MongoDB, Riak, HBase, 和 Cassandra提供基于单一键的事务,这是因为所有信息都和一个键key有关,这个键是存储在单个服务器上,这样基于单键的事务不会带来复杂的分布式协调。 那么看来扩展性性能和分布式事务是一对矛盾,总要有取舍?实际上是不完全是,现在完全有可能提供高扩展的性能同时提供分布式原子事务。 FIT是这样一个在分布式系统提供原子事务的策略,在fairness公平性, isolation隔离性, 和throughput吞吐量(简称FIT)可以权衡。 一个支持分布式事务的可伸缩分布式系统能够完成这三个属性中两个,公平是事务之间不会相互影响造成延迟;隔离性提供一种幻觉好像整个数据库只有它自己一个事务,隔离性保证当任何同时发生的事务发生冲突时,能够保证彼此能看到彼此的写操作结果,因此减轻了程序员为避免事务读写冲突的强逻辑推理要求;吞吐量是指每单元时间数据库能够并发处理多少事务。 FIT是如下进行权衡: 1.保证公平性fairness 和隔离性isolation, 但是牺牲吞吐量 2.保证公平性fairness和吞吐量, 牺牲隔离性isolation 3.保证隔离性isolation和吞吐量throughput, 但是牺牲公平性fairness. 牺牲公平性:放弃公平性,数据库能有更多机会降低分布式事务的成本,主要成本是分布式协调带来的,也就是说,不需要在每个事务过程内对每个机器都依次确认事务完成,这样排队式的确认commit事务是很浪费时间的,放弃公平性,意味着可以在事务外面进行协调,这样就只是增加了协调时间,不会增加互相冲突事务因为彼此冲突而不能运行所耽搁的时间,当系统不需要公平性时,需要根据事务的优先级或延迟等标准进行指定先后执行顺序,这样就能够获得很好的吞吐量。 G-Store是一种放弃公平性的 Isolation-Throughput 的分布式key-value存储,支持多键事务(multi-key transactions),MongoDB 和 HBase在键key在同样分区上也支持多键事务,但是不支持跨分区的事务。 总之:传统分布式事务性能不佳的原因是确保原子性(分布式协调)和隔离性同时重叠,创建一个高吞吐量分布式事务的关键是分离这两种关注,这种分离原子性和隔离性的视角将导致两种类型的系统,第一种选择是弱隔离性能让冲突事务并行执行和确认提交;第二个选择重新排序原子性和隔离性机制保证它们不会某个时间重叠,这是一种放弃公平的事务执行,所谓放弃公平就是不再同时照顾原子性和隔离性了,有所倾斜,放弃高标准道德要求就会带来高自由高效率。
物流IT圈
2019-07-16
1.7K
0
没有更多了
社区活动
腾讯技术创作狂欢月
“码”上创作 21 天,分 10000 元奖品池!
立即发文
Python精品学习库
代码在线跑,知识轻松学
立即查看
博客搬家 | 分享价值百万资源包
自行/邀约他人一键搬运博客,速成社区影响力并领取好礼
立即体验
技术创作特训营·精选知识专栏
往期视频·千货材料·成员作品 最新动态
立即查看
领券
问题归档
专栏文章
快讯文章归档
关键词归档
开发者手册归档
开发者手册 Section 归档