- 快召唤伙伴们来围观吧
- 微博 QQ QQ空间 贴吧
- 视频嵌入链接 文档嵌入链接
- 复制
- 微信扫一扫分享
- 已成功复制到剪贴板
原生分布式内存数据库VOLT特性与生态- 李军
VOLTDB是由ACM图灵奖得主Michael Stonebraker博士领导的世界一流数据库专家团队所创建的开源产品,它是一款性能出色的分布式内存数据库和数据处理引擎。得益于原生分布式的架构设计,以及基于JVM的分布式协调组件,VOLTDB具备优秀的扩容能力、丰富的生态支持能力。
李军-VOLT中国数据库内核架构师,VOLT开源社区贡献者,有丰富的通信网络系统和互联网平台研发和架构经验。早年毕业于国防科技大学,曾在华为、爱立信等企业担任研发及系统架构设计工作,近些年兴趣爱好转向分布式数据库系统,开源产品和开源技术开发者和重度用户。
展开查看详情
1 .VOLT ACTIVE DATA 关键特性与⽣态
2 .内容 01 我们关注什么 02 为什么有这些特性 03 产品与⽣态 04 设计实现
3 .VOLT ACTIVE DATA 简介
4 . VOLT ACTIVE DATA(VOLTDB)是唯⼀⽀持完整事务、云原⽣并开源的分布式内存数据库 VOLTDB是由2014图灵奖得主、 冯诺依曼奖获得者 、 美 国国家⼯程院院⼠ 、Postgres和Vertica等产品的联合创始⼈ Mike Stonebraker博⼠领导开发的下⼀代关系型、内存数据库管 原⽣虚拟化和开源社区 理系统,⾯向毫秒级实时事务处理、实时数据分析、边缘计算和 复杂流处理计算等应⽤。 VOLTDB⼤幅降低了服务器资源开销,⾸先实现在廉价 完整事务和ACID x86服务器集群或虚拟环境上实现每秒数百万次数据处理。单节 点每秒数据处理远远⾼于其它数据库管理系统。 VOLTDB提供开源版本和商业发⾏版本。 原⽣分布式数据库 VOLTDB于2017年官⽅正式进⼊中国市场,已经建⽴了本 ⼟团队,包括销售、研发、售前售后和市场推⼴等职能。国内团 内存数据库 队⽬前分布在北京、上海、南京、成都。VOLTDB承诺可为国内 商业客户提供7X24的远程和现场售后⽀持服务。 4
5 .技术探索 Mike Stonebraker博⼠的研究团队通过对传统数据 库进⾏分析,发现数据只有12%左右的CPU时间在 做真 正有意义的数据操作,⽽其他绝⼤部分时间都被缓存,并 发控制等消耗了。 传统数据库有约88%的CPU时间都消耗在这些对于 实际操作⽆意义的步骤上,要提升数据库性能,只有从根 本上减少这些冗余的步骤,集中进⾏数据运算,才能完全 利⽤ CPU。 https://www.voltdb.com/wp-content/uploads/2018/10/VoltDB_LookingGlass_WP.pdf
6 . VOLT的定位和关注点 6
7 . ACID ⼀个⾮标准答案的理解⻆度: ACID,是指数据库管理系统(DBMS)在写⼊或更新资料的过 程中,为保证事务(transaction)是正确可靠的,所必须具备的 重要的不是标准答案,⽽是明确业务场景、系统设计的构想,在客观 四个特性 条件和构想之间做恰如其分的取舍和折衷 Atomicity(原⼦性):⼀个事务(transaction)中的所有操作,要么全部完成,要么全 ACID是⼤家(业务⽅、系统提供⽅)对DBMS的共同的预期 部不完成,不会结束在中间某个环节。事务在执⾏过程中发⽣错误,会被恢复 • 从使⽤者⻆度,希望这个系统的机制、配套⼯具,能提供ACID⽀持⼿段并满⾜需要 (Rollback)到事务开始前的状态,就像这个事务从来没有执⾏过⼀样。 • 从DBMS设计者⻆度,是⽤系统来表达ACID、并对系统机制施加约束以满⾜业务需要 Consistency(⼀致性):在事务开始之前和事务结束以后,数据库的完整性没有被破 Atomicity(事务视⻆):不⼤有理解偏差,提交机制、失败回滚是对应机制 坏。这表示写⼊的资料必须完全符合所有的预设规则,这包含资料的精确度、串联性以 Isolation(并发事务管理的视⻆):重要性弱于Atomicity,更像是⼀种特征、灵 及后续数据库可以⾃发性地完成预定的⼯作。 活性。在不同的隔离级别下,设计者可以在性能vs.正确之间做不同的折衷 Isolation(隔离性):数据库允许多个并发事务同时对其数据进⾏读写和修改的能⼒, Durability(系统功能视⻆):是基本功能,业界理解偏差也不⼤。不过在系统 隔离性可以防⽌多个事务并发执⾏时由于交叉执⾏⽽导致数据的不⼀致。事务隔离分为 实现时,仍然在介质、频度⽅⾯有性能vs.正确的取舍 不同级别,包括读未提交(Read uncommitted)、读提交(read committed)、可重复 Consistency在ACID四个特性中鹤⽴鸡群 读(repeatable read)和串⾏化(Serializable)。 • 对C的需求贯穿AID,⼏乎是AID的出发点本身 Durability(持久性):事务处理结束后,对数据的修改就是永久的,即便系统故障也不 • C不是DBMS系统⽅闭⻔造⻋就能提供的。约束什么、怎么表达约束、怎么使⽤? 会丢失。 • 使⽤者能容忍的不⼀致 vs 系统能容忍的不⼀致 • 如何评价⼀个DBMS对C的⽀持的完善程度? VoltDB对ACID都有对应的机制保证 The value of ACID transactions is argued in the seminal Google F1 paper: The system must provide ACID transactions, and must always present applications with consistent and correct data. Designing applications to cope with concurrency anomalies in their data is very error-prone, time-consuming, and ultimately not worth the performance gains. 7
8 . 事务隔离级别 隔离级别 脏读 不可重复读 幻读 隔离级别的程度,与对数据的⼀致性要求的严格程度相关。 READ UNCOMMITTED(读未提交) √ √ √ 更严格的隔离级别,削弱并发性。 READ COMMITTED(读提交) × √ √ REPEATABLE READ(可重复读) × × √ VoltDB采⽤的是最严格的SERIALIZABLE。 SERIALIZABLE(序列化) × × × 8
9 . CAP CAP原则⼜称CAP定理,指的是在⼀个分布式系统中,C、A、P这三 ⼀个理解⻆度: 个基本需求,最多只能同时满⾜其中的2个 CAP不是你能做什么,⽽是做不到什么?如何选择取舍? 常⻅理解: • ⼀致性:同⼀份数据的多个副本在整个分布式系统内保持⼀致 • Consistency(⼀致性): • 可⽤性:分布式系统所有活跃的⼦节点都能处理请求并正确响应 数据在多个副本之间能够保持⼀致的特性 • 分区容错性:分布式系统的副本互联、外联建⽴在不能假设为可靠 • Availability(可⽤性): 的⽹络上。分区容错性可以包括: 系统提供的服务⼀直处于可⽤的状态,每次请求都能获得正确的响应 部分副本崩溃的情况下的应对策略(如:活跃的副本提供服务) 多副本活跃但同步失效情况下的应对策略(如:VoltDB提供brain-split侦测) • Partition tolerance(分区容错性): 分布式系统在遇到任何⽹络分区故障的时候,仍然能够对外提供满⾜ • 当探讨异常情况的时候,想同时要求C+A是不可能的,因为活跃的 ⼀致性和可⽤性的服务 副本(局部)的可⽤就意味着整体的不⼀致 CAP is a tool to explain trade-offs in distributed systems. It was presented as a conjecture by Eric Brewer at the 2000 Symposium on Principles of Distributed Computing and formalized and proven by Gilbert and Lynch in 2002. 9
10 . Lock&Latch 传统RDBMS⼤约有30%的CPU开销在Lock&Latch上 Lock Latch 持续时间 整个事务过程 临界资源 实现 保存在lock表中,通过哈希表定位 位于它们保护的资源附近的内存中,并通过直接寻址进⾏访问 跟踪 Lock是有跟踪的,有lock table,随事务创建、清除 Latch闩是⽆跟踪的,如果出错,可能⽆法释放 死锁 Lock允许死锁,辅以检测机制并通过重启事务来解决死锁 内部实现差异 机制 内部实现 ⼀般⽤原⼦硬件指令实现,极端情况下⽤OS机制 效率 ⼏百个CPU周期 ⼏⼗个CPU周期 10
11 . 并发Concurrent vs. 并⾏Parallel VoltDB⽤分区并⾏策略与事务队列串⾏化策略相辅相成,实现了惊⼈的 TPS吞吐能⼒ • 不同的单分区事务,在不同的CPU上并⾏完成,同时满⾜了事务并 ⾏的需要和串⾏的事务隔离级别 • 通过单分区事务的机制,⼏乎避免了Lock&Latch的开销 11
12 . 设计思路的落地 12
13 . VOLTDB技术架构 分布式集群 VoltDB的技术特点 VoltDB 节点1 VoltDB节点2 VoltDB节点N ● 全内存计算 计算引擎 计算引擎 计算引擎 ● ⽆锁化设计 表/索引数据 表/索引数据 表/索引数据 ● 按CPU内核分区 数据库模式 数据库模式 数据库模式 ● 多分区并⾏计算 分区1 分区2 分区5 分区6 分区7 分区8 ● 数据库内事务控制 分区3 分区4 分区7’ 分区1’ 分区9 分区4’ ● ⽆共享设计 分区9’ 分区8’ 分区2’ 分区3’ 分区5’ 分区6’ 13
14 . 逻辑架构 VOLT是完全分布式内存数据库,每个 节点-a 节点-c 节点都是逻辑对等的,没有主节点的概念, 分区-1 也就避免了主节点瓶颈和单点故障⻛险。 分区-2 物化视图 VOLT节点内部数据存储和处理分成逻 分区-n 辑分区(对应物理分区),逻辑分区间采⽤ 优化MPP⽅式,独⽴运⾏处理计算。 事务处理 业务逻辑 每个节点都可以接受客户端的请求, 数据表 并负责解析执⾏计划并分发对应的任务给本 节点-b 节点或者其他节点的执⾏层。 数据落盘 数据落盘等持久化任务在每个节点并 ⾏执⾏,集群间同步在对应分区间并⾏完 import streams database calls export/migrate streams ML models 成,实现性能的最⼤化。 Kafka, JDBC, Language SDKs, Hadoop, RabbitMQ, Elastic, PMML, … 数据管道 14
15 . 性能测试⽐较 VoltDB经过和传统数据库进⾏的性能对⽐,实测结果如下表,VoltDB单节点即带来⽐传统数据库数⼗倍性能的优势。 测试环境:Dell R610, 2x 2.66Ghz Quad-Core Xeon 5550 with 12x 4GB (48GB) DDR3-1333 Registered ECC DIMMs, 3x 72GB 15K RPM 2.5in Enterprise SAS 6GBPS Drives. 15
16 . 线性扩容 VOLT线性扩容测试 VOLT性能会随着集群节点数量的增加⽽线性 • 16核CPU, 64G内存 增⻓,随着应⽤端性能需求的增⻓,VOLT集群可以 • 320万TPS/集群/27节点 简单地增加节点数量来解决。 • 延迟<5ms •性能线性增⻓ •横向+纵向扩展 •⼀键⽆痛扩容 •数据⾃动均衡 •对应⽤⽆影响 16
17 . VOLTDB关键特性 VOLT、NoSQL和传统关系型数据库的对⽐如下所示: 17
18 .产品与⽣态
19 .VOLTDB - 统⼀的实时流数据处理平台 Stream Real Time Datastore Ingestion Processing VOLTDB同时兼备流式加载、实时计算、数据存储的功能,⼀站式解决结合 上下⽂的实时流处理应⽤需求,避免了多种⼯具组合带来的延迟和⻛险。 19
20 .VOLTDB TOPIC • 消息中间件,⽀持消息发布订阅 • 提供兼容Kafka的API调⽤ Topic A Producer IIIIIIII IIIIIIII IIIIIIII IIIIIIII IIIIIII> Topic B IIIIIIII > Topic C IIIIIIII > Procedure Topic D Topic D SQL IIIIIIII > INSERT IIIIIIII > Consumer Topic A= Opaque topic Topic B= Output topic Topic C= Input topic Topic D= Input/Output Topics Stream 20
21 .VOLTDB 智能流计算框架 流数据实时智能决策引擎 存储过程 ⾃定义函数 窗⼝函数 应⽤服务 流数据 符合ACID的实时运营 连接外部数据存储平 分析平台 台 单集群实现每秒数百万事件并结合上下⽂的实时决策 机器学习模型 (PMML等) 21
22 . 热数仓场景与周边⽣态 ● ⼤数据量的实时复杂处理 应⽤ 流数据 ● 性能线性扩展 API 消息队列 ● 加速Hadoop的计算 合并数据流 逻辑预测 即席/ 历史 复杂计算 事务处理 查询 模型、规则 运算结果 引⽤数据 Hadoop, MPP, RDBMS 22
23 . 云化部署 <VOLTDB已经⼊选CNCF Landscape云原⽣数据库全景图> VOLTDB!"#$%&'(%)*+ ,-./01#$%234 23 33
24 .云部署⽀持 Kubernetes创建的虚拟机集群中的每个Pod都充当⼀ 个VOLT的节点。对于VOLT主体组件来说,运⾏于Native 还是Pod是⽆缝兼容的。 为了使Pod的启停与VOLT节点的状态达成⼀致, VOLT提供了⼀个额外的服务,即VOLT Operator,它管理 VOLT集群和Kubernetes基础设施之间的交互。 为了进⼀步简化流程,VOLT使⽤开源管理产品 Helm 提供 Kubernetes、Docker 和 VOLT的⼀体化管理界 ⾯。 24
25 .实现机制
26 . 原⽣的基于分区的分布式设计 分布式集群 Site VoltDB 节点1 VoltDB节点N 分布式集群的基本运⾏单位,逻辑上与 Partition⼀⼀对应。 Site1 分区1 分区2 分区7 分区8 SPI1 ZK1 SPI Single Partition Initiator。负责本Partition的 事务执⾏。 Site3 分区3 分区4 分区9 分区4’ SPI3 ZK3 ZK Zookeeper node。每个SPI都对应⼀个ZK Site9’ 分区9’ 分区8’ 分区5’ 分区6’ node。运⽤ZooKeeper的分布式协调功能,实现 SPI9’ ZK9’ Partition的多个副本的Leader选举、监控等。 26
27 . Frontend主要分布式组件 RealVoltDB <<接⼝>> BaseInitiator m_MPI //Multi Partition Initiator Initiator m_executionSite m_iv2Initiators //SPIs m_zkMailboxNode m_messenger n Partitions m_partitionId MPInitiator SPInitiator m_scheduler <<接⼝>> m_scheduler m_scheduler Runnable Site VoltZK m_siteId MailBox m_numberOfPartitions SpScheduler m_ee // Execution Engine m_pendingSiteTasks(join/shutdown...) SiteMailBox m_pendingTasks run() //setAffinity, consume tasks initializeEE() //初始化Execution Engine 27
28 . SQL执⾏过程对⽐:1-MYSQL 28
29 . SQL执⾏过程对⽐: 2-ADHOC OF VOLT Client SPI Backend SpProcedureT ProcedureRun Execution SQLCommand Client SiteMailBox SpScheduler Site ask ner Engine callProcedure Iv2InitiateTaskMessage poll forward processInitiateTask getProcedureRunner call coreCall voltExecuteSQL fast_path executePlanFragments executePlanFragments 29