之內存爲中心的數據庫設計考慮

「本文已參與好文召集令活動，點擊查看：後端、大前端雙賽道投稿，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 等...