内存数据库MemSQL ——基于内存，MVCC+哈希表、跳表

本周数据库业界探讨最火热的话题就是MemSQL，究竟是不是“旧瓶装新酒”引发了诸多的辩论，同时也引发了究竟是产品技术重要还是DBA重要的疑问。网络中有一些关于MemSQL的介绍，基本上都是来自官方文档。在本文中，数据库行业的著名独立分析师Curt Monash也发表了他对MemSQL的看法。 　　

MemSQL到底是什么？
内存关系型数据库
QL-92的子集 兼容MySQL（SQL覆盖问题除外） 　　

MemSQL的性能
读性能比memcached差10%左右
写性能比memcached强20%左右
一台64核、1/2 TB的机器上能跑到120万条插入每秒
同样条件下，20分钟之内能加载5亿条记录 　　

关于MemSQL的讨论主要集中在性能方面，包括： 数据通过哈希表和跳转表（skip lists）进行组织。MemSQL认为跳转表在多核上的扩展性非常好 查询模式可以编译成C++ MVCC/无读锁 轻量级写锁 可调整持久性，你可以fully durable的跑MemSQL，也可以设一个buffer size来限定可承受的交易数据量
其实将查询进行预编译很难说是一个创新，也不是业内的独一份。此前包括QlikTech、StreamBase以及ParAccel都做过类似的尝试。而MemSQL的特色在于： 编译成只要你想读就可以读的C++ 参数化，如果一个查询中包括一系列的参数，那么它会存储起来以备将来运行更多其它参数 持久性，如果服务器宕机，存储的编译查询不会丢失每个查询只占几KB的空间，在早期MemSQL的客户中，他们最多存储不会超过几千个查询模式。因此MemSQL对于编译这些查询会造成的影响还是表示非常乐观的，而使用LRU算法来释放空间的方式可能不会去考虑。 　　

MemSQL的持久性使用预写入日志到一个磁盘（传统或固态硬盘），同时发送快照到其他磁盘的方式。持久性的设计是连续的，但是在full-durability场景中是否也是就不清楚了。 　　

其他一些值得注意的技术细节包括： MemSQL可以运行在多温度环境下，通过DDL手动控制。也就是说，较新的数据会放到MemSQL中，旧数据放入到MySQL中 有一点我认为是最佳实践，MemSQL团队也秉承了这一理念，就是在两个或者多个服务器RAM中得到确认后，要第一时间提交写入 并行Group By，这个MemSQL的团队引以为豪 MemSQL不进行数据压缩，他们认为OLAP负载中才需要数据压缩 MemSQL的插入性能非常高，所以它们的目标客户群是那些存在频繁交易的系统用户

TechTarget中国原创内容，原文链接： http://www.searchdatabase.com.cn/showcontent_62951.htm