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
  - 索引管理

围绕内存的引擎设计（所有工作围绕如何降低指令数展开）
- 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消耗
  - 差量方式存储数据