常用开源NoSQL原理与应用田琪（摇摆巴赫）Agenda深入理解RedisHash算法数据库介绍LSM算法数据库介绍HandlerSocket介绍分布式数据库介绍Why NoSQL?关系数据库的问题大数据的产生存储需求的多样性云时代的来临深入理解Redis一个更加强大的Memcachedmemcached场景与局限只能做cache,不能做storage没有数据结构支持数据局部踢出现象cache与存储资源访问能力落差不能枚举全数据访问性能仍有提升空间redis 概述 a disk backed in-memory database 高性能网络接口 + 数据结构集合redis 特点key - structure 类型存储支持数据可靠存储及落地支持复制（cluster版本在开发）单进程单线程高性能服务器crash safe & recovery slow缺少内存管理算法，依赖第三方库单机qps可以达到 10W (cpu是瓶颈)redis 数据类型stringhashlistsetsorted setredis 持久化机制snapshotsave 参数 aofappendfsync 参数vm vm is not the way to go for the futurediskstore传统b-tree redis 复制实现机制 快照同步存在的问题 无增量复制 slave表重建 redis缺陷与优化持久化IO机制复制机制内存管理线程模型故障恢复时间 持久化问题 buffer io 持久化问题 - fsyncfsync非常耗时单进程阻塞操作快照与fsync同时进行 复制缺陷 内存管理缺少高效内存管理额外内存占用过多针对特殊场景做优化开放地址Hashredis 使用场景需要key - structure复杂数据结构需要数据可靠存储需要极高的单机qpsusing RAM as the new diskHash算法数据库Hash存储结构更合适简单kv存储tokyocabint（tchdb） 特点包含hash/btree等多种存储类型kvtchdb适合小数据量高速读写访问tchdb随机磁盘IO次数平均tchdb使用mmap iotchdb qps 大约在6W左右tchdb存储结构1tchdb存储结构2LSM算法数据库硬件变革推动算法变革leveldb特点bigtable tablet实现LSM Tree算法写性能极其出色读性能依赖数据热度SSD设备友好，不会写入放大嵌入式DB，需要自己实现Server分布式auto sharding支持友好写性能 50MB/s,读性能 6W/sleveldb 存储结构leveldb 的问题与场景读IO次数不确定查询指定key对应数据不存在的开销非常大缺少高效内存管理算法需要根据业务特点平衡merge时间点投入使用需要一定的开发量适合有明显时间热点访问规律的系统配合SSD使用表现极其出色riak(bitcask) 特点存储结构简单LSM Hash算法全部key存储在内存中全部查询只有1次磁盘IOQPS 大约在45W左右bitcask 存储结构bitcask 问题与场景全部key需要存储在内存中recovery重启需要重新load所有keymerge时机的选择适合配合SSD使用handlersocket特点NoSQL接口访问MySQL(Innodb)解决SQL解析，查询优化等CPU开销插件安装无数据迁移成本QPS 可以达到8Whandlersocket结构handlersocket问题与场景配合DDL使用有严重问题写性能差，比传统SQL接口还要慢只能支持Row Based复制性能优势建立在没有磁盘IO瓶颈基础上分布式NoSQL介绍无中心化方案无中心节点数据一致性Hash分布NWR数据多点备份Read repairHinted HandoffGossip节点管理中心化方案中心节点提供路由中心节点维护节点信息对外访问代理节点总结关系数据库是单机存储时代的产物NoSQL更能满足不同存储需求的多样性NoSQL是SQL的延伸而不是取代混合存储方案时代已经来临架构师要具备不同存储方案选择的能力谢谢大家 Q&A邮箱：swingbachgmail.com微博：weibo.com/bachmozart