Transcript Document
Hekaton 初探 PASS Beijing Local Chapter Session 宋沄剑 01/26/2013 由一个类比开始 硬盘作为辅助存储，如果大量的操作，每次只取少量的数据的话，就好 像你需要喝水，出家门的超市买一瓶好了，而你却坐飞机去上海买…… 你也许或说，这个类比不太恰当…… 如果说传统的硬盘作为辅助存储，那么每次缓存到Buffer中不也是只访问内存 吗？ 但请想一想并发问题，就像去即使同样是去附近的超市买水，只有一个收银 台，10个人同时买也需要等待，使用Hekaton的内存优化表就像是增开了10个 收银台 而Native Compile存储过程就像是你出门去超市原来是一路小跑，而现在是开 车去，速度大大提升。此外我们还可以看出，你家离超市越远，开车去越合 适，就像Native Complie存储过程，存储过程中逻辑越多越长性能提升越明显 2 Hekaton的两大部分 • 内存优化表 • 本地编译存储过程 3 OLTP面临大量并发时会遇到的瓶颈 • CPU • Hekaton通过本地编译存储过程来减少CPU周期 • IO • 通过内存优化表，大量减少IO • 内存 • Hekaton并不能减少内存使用，相反由于多版本并发控制(MVCC)的出现，反而会增 加内存使用 • 网络 • 4 Hekaton对于网络方面没有影响 议程 • Hekaton 出现的硬件背景 • Hekaton使用的Hash-Index与传统B-Tree Index的比对 • 实现隔离的不同方式 • 日志写入的不同方式 • Hekaton的兼容性和适用场景 • 读性能并发测试DEMO 5 硬件背景 • TB级的主存不再是遥不可及的事了。 • CPU主频增长已经基本停滞，而CPU核数的增长会越来越 多，Tilera曾在2008年预测，嵌入式系统市场在2017年 将出现4096核的芯片，Sun在2008年时曾经预测，在 2018年，普通服务器将采用32到128核芯片。 • NUMA构架的成熟消除了大量CPU和主存之间通路的瓶 颈，并且Windows和SQL Server OS都原生支持NUMA 6 NUMA节点的概念 7 SQL Server OS在SMP硬件 8 SQL Server OS在NUMA硬件 9 议程 • Hekaton 出现的硬件背景 • Hekaton使用的Hash-Index与传统B-Tree Index的比对 • 实现隔离的不同方式 • 日志写入的不同方式 • Hekaton的兼容性和适用场景 • 读性能并发测试DEMO 1 0 硬盘结构 1 1 B-Tree Index 5 3 1 1 2 7 4 6 8 B-Tree Index • 面对以磁盘作为辅助存储的数据结构。 • 由于磁盘存在旋转延迟和寻道时间，所以磁盘单点查 找很慢，但顺序读非常快。B-Tree的结构使得尽量减 少查找，数据几何级的增长也只可能导致B树高度只 增加一层。并且叶子节点之间通过双链表连接，使得 在没有外部碎片的情况下，和硬盘磁道顺序保持一 致，所以顺序读非常快。 1 3 Hash-Index G1 G3 G M G2 Hash Function G4 G Hash Bucket M1 M3 M2 M Hash Bucket 1 4 Hash Index • 以内存作为辅助存储的数据结构。 • 内存没有寻道时间，对于所有内存单位的访问时间是一样 的，因此Hash对于所有的行查找都是通过LOOK UP进行的 • 对于大量的随机读写，性能提升显著，尤其是where a=a1 and b=b1 and c=c1….这类情况 • 对于大量的顺序读，性能提升非常有限 1 5 议程 • Hekaton 出现的硬件背景 • Hekaton使用的Hash-Index与传统B-Tree Index的比对 • 实现隔离的不同方式 • 日志写入的不同方式 • Hekaton的兼容性和适用场景 • 读性能并发测试DEMO 1 6 SQL Server实现隔离的方法 • 悲观并发控制 让事务以独占的方式占有某些资源。也就是通过所谓的“锁”来实现隔离。 不同的隔离等级，锁的行为也不同。 • 乐观并发控制 快照隔离 1 7 Hekaton实现隔离的方法和基本原理 • 多版本并发控制(MVCC) 所谓多版本指的是，同一行数据可能存在多个版本。 开始时 间戳 结束时 间戳 行数据 1 无限 行数据 事务B将结束时间改为4 第一次插入,事务 A（时间1） 同一个数据，不 同版本 4 无限 行数据 第二次修改,事务 B（时间4） 逻辑时间严格递增，每个事务都有一个对应的逻辑时间，只有行数据的逻辑时间 小于事务的逻辑时间的行(也就是在事务开始前被Commit的行)对于事务可见。 1 8 Hekaton垃圾回收机制 • 只插入更新 由于是只插入更新，导致同一行数据可能存在多个版本，因此随着逻辑时间的前移，很 多事务提交后，有一些行再也不被需要。 • 垃圾回收 如果一行对于所有的事务都不可见，则这行会被后台线程垃圾回收以释放内存。 1 9 议程 • Hekaton 出现的硬件背景 • Hekaton使用的Hash-Index与传统B-Tree Index的比对 • 实现隔离的不同方式 • 日志写入的不同方式 • Hekaton的兼容性和适用场景 • 读性能并发测试DEMO 2 0 SQL Server的日志写入方式 • 随着“事务”的引入，催生了事务的ACID这个理念 • 其中的D,也就是持久性催生了WAL 持久性(Durability),意味着要保证每一个事务所做的修改都会被持久化，这就 需要Write-Ahead-Log来保证。 传统的事务，SQL Server当日志写入磁盘步骤完成后，就会给客户端程序返回 确认信息了，而被修改的脏页数据会等Checkpoint或Lazy Writer持久化到磁盘。 2 1 一次Update过程 2 2 Hekaton日志写入方式 • 独立于SQL Server的CheckPoint线程,Hekaton Checkpoint线程异步将日志写入Checkpoint文件。 • 不再需要WAL,而是批量日志写入，因此可能导致断电后 内存数据的丢失。 • 非常频繁的日志批量写入，将内存数据丢失减少到最 小。 • 内存优化表如果选择了非持久化表,则日志写入部分都会 省略,但内存崩溃会导致内存优化表中的数据将会全部丢失, 作为ETL的中间结果非常合适。 2 3 议程 • Hekaton 出现的硬件背景 • Hekaton使用的Hash-Index与传统B-Tree Index的比对 • 实现隔离的不同方式 • 日志写入的不同方式 • Hekaton的兼容性和适用场景 • 读性能并发测试DEMO 2 4 Hekaton适用场景 • Scale Up 消除锁，使得可以通过增加硬件提升的性能增加。而不会被卡在“锁”这个性能瓶颈 上。 • Read Scale Out 使用本地编译存储过程，大大减少CPU周期。在读负载上使用Hekaton可以减少所需 的读缓存服务器。 • 需要低延迟的业务场景 Hekaton内存优化表和本地编译存储过程相比较传统的表和存储过程而言，延迟更 低。 • ETL中间结果集 适用非持久化内存优化表,数据加载速度将会得到几何级提升。 2 5 Scale Up 可扩展性 性能提升 3.5 3 3 2.5 2 2 1.5 1 1 0.5 0 0 1 2 3 可扩展性 2 6 4 硬件投入 Read Scale-out Read Cache Read Cache Read Cache Centeral Update 在Read Cache上使 用Hekaton 2 7 Hekaton所不适用的场景 • 大量顺序读的情况（大多是OLAP） • 对于小的存储过程，Native Compiled的性能提升不太明 显。 • 对于内存表，性能提升主要在消除锁争用上。 2 8 议程 • Hekaton 出现的硬件背景 • Hekaton使用的Hash-Index与传统B-Tree Index的比对 • 实现隔离的不同方式 • 日志写入的不同方式 • Hekaton的兼容性和适用场景 • 读性能并发测试DEMO 2 9 谢谢 3 0