以内存为中心的数据库设计考虑「建议收藏」

以内存为中心的数据库设计考虑「建议收藏」MemSQL的纯内存设计理念MemSQL使用RAM作为Primary Storage。传统数据库使用磁盘作为Primary Storage。内存

欢迎大家来到IT世界,在知识的湖畔探索吧!

MemSQL的纯内存设计理念

  • MemSQL使用RAM作为Primary Storage。
  • 传统数据库使用磁盘作为Primary Storage。内存只做缓存用。
  • MemSQL通过lock-free skip lists and hash table来优化读。传统的缓存无法实现这种优化。
  • 内存不够,拒绝写请求。
  • 数据默认是异步批量顺序写log,结合定时快照以实现持久化。

以内存为中心就是要最大程度的发挥内存介质的性能,而不是仅仅把内存当成cache来用

-围绕内存设计数据组织格式

  • 比如MemTable的无锁跳表
  • 内存数据如何更好的支持持久化和恢复(比如Ignite围绕page的内存数据组织方式)
  • Optimization of T-Tree Index of Main Memory Database in Critical Application
  • 内存数据库中的索引技术
  • 内存数据库索引研究
  • 新型存储介质对数据管理的影响

– 围绕内存设计并发访问控制

  • An Empirical Evaluation of In-Memory Multi-Version Concurrency Control
  • High-Performance Concurrency Control Mechanisms for Main-Memory Databases
  • Haketon的高性能并发控制算法
  • 一文详解分布式数据库并发控制
  • 不同MVCC实现优缺点
  • Fast Serializable Multi-Version Concurrency Control for Main-Memory Database Systems
  • Concurrent Programming Without Locks

– 围绕内存的引擎设计(所有工作围绕如何降低指令数展开)

  • 优化索引实现

> B-Tree的一次索引查询至少要执行上千条指令

> 传统的围绕磁盘的设计需要考虑复杂的buffer实现

> Hekaton数据全部放内存,通过log和快照进行持久化

> Hekaton不持久化索引,重启时通过快照和log重建索引

  • 清除所有的锁

> memory allocators, hash and range indexes, and transaction map, are entirely latch-free (lock-free).

> There are no latches or spinlocks on any performance-critical paths in the system.

> uses a new optimistic multiversion concurrency control to provide transaction isolation semantics, no locks and no lock table.

  • 将请求编译成native code

> 大部分DBMS都是基于解释器方式来执行用户的查询请求,这会导致非常多的指令消耗。

  • 不分区

> HyPer, Dora, H-store, and VoltDB是采用分区方式,将CPU和分区数据进行绑定来提高性能。

> 分区的性能提升只对那些可分区的workload有效,对于无法分区的请求会导致严重的性能损耗。

> 一个无法分区的请求,需要将请求分发到所有分区上执行,然后再汇聚结果,这中间的开销非常高。(这一点会导致yugabyte的读请求无法提前执行)

> Hekaton经过多方评估,最终选择了No Partitioning模式。

  • 持久化

> transaction log + checkpoint

> 顺序写:客户把钱花到内存上而不是SSD上

> 把时间消耗推迟到恢复阶段而不是事务执行阶段

> 在恢复阶段并行化,以提高IO和CPU利用率

> transaction log

> 采用Group Commit来提高吞吐

> 不采用WAL

> 多并发的log stream来解决日志尾部的扩展瓶颈(tail of the transaction log is typically a bottleneck)

  • checkpoint

> 目的是提高恢复效率

> 增量方式持续进行(以解决定时方式导致的系统性能不稳定问题)

> Streaming I/O:规避随机IO(即使SSD)带来的性能和CPU消耗

> 差量方式存储数据

对于实时读写请求来说,内存是数据的终点

  • 数据写到内存之后,就应该通知客户写成功
  • 数据写到内存之后,就应该可见
  • 数据的持久化需要尽量小的影响性能

初步结论

  • 目前大部分的HTAP系统都仅仅是即支持TP又支持AP;并且针对AP的设计也主要围绕海量数据分析场景;
  • OLAP场景和HTAP中的AP场景不同,一个是低频的海量数据分析场景,一个是为TP过程提供的快速AP能力。我们应该是重点关注后者,同时支持前者;
  • 以内存为中心就需要最大化的发挥内存的性能优势。

MemFire Cloud是基于MemFireDB云原生和线性扩展能力而打造的数据库云服务,致力于为互联网用户提供一站式数据库自助服务,实现按需使用,随用随取,最大化的节约成本,加速用户的业务创新。

免责声明:本站所有文章内容,图片,视频等均是来源于用户投稿和互联网及文摘转载整编而成,不代表本站观点,不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益,请在线联系站长,一经查实,本站将立刻删除。 本文来自网络,若有侵权,请联系删除,如若转载,请注明出处:https://itzsg.com/17604.html

(0)

相关推荐

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

联系我们YX

mu99908888

在线咨询: 微信交谈

邮件:itzsgw@126.com

工作时间:时刻准备着!

关注微信