之内存为中心的数据库设计考虑

「本文已参与好文召集令活动，点击查看：后端、大前端双赛道投稿，2万元奖池等你挑战！」

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

    • 并发控制协议：MVTO、MVOCC、MV2PL、Serialization Certifier
    • 多版本数据存储方案：Append-only Storage、Time-Travel Storage、Delta Storage
    • 垃圾回收策略：Tuple-level GC、Transaction-level GC
    • 索引管理

  • 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

• 围绕内存的引擎设计（全部工做围绕如何下降指令数展开）

  • Hekaton: SQL Server’s Memory-Optimized OLTP Engine

    • 优化索引实现

      • 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消耗
      • 差量方式存储数据 

  • SQL Server Internals: In-Memory OLTP

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

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

初步结论

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

参考资料

Optimization of T-Tree Index of Main Memory Database in Critical Application
An Empirical Evaluation of In-Memory Multi-Version Concurrency Control
SQL Server Internals: In-Memory OLTP
Hekaton: SQL Server’s Memory-Optimized OLTP Engine
www.memfiredb.com 等...