常用开源NoSQL原理与应用

常用开源NoSQL原理与应用Agenda•深入理解Redis•Hash算法数据库介绍•LSM算法数据库介绍•HandlerSocket介绍•分布式数据库介绍WhyNoSQL?•关系数据库的问题•大数据的产生•存储需求的多样性•云时代的来临深入理解Redis一个更加强大的Memcachedmemcached场景与局限•只能做cache,不能做storage•没有数据结构支持•数据局部踢出现象•cache与存储资源访问能力落差•不能枚举全数据•访问性能仍有提升空间redis概述adiskbackedin-memorydatabase高性能网络接口+数据结构集合redis特点•key-structure类型存储•支持数据可靠存储及落地•支持复制（cluster版本在开发）•单进程单线程高性能服务器•crashsafe&recoveryslow•缺少内存管理算法，依赖第三方库•单机qps可以达到10W(cpu是瓶颈)redis数据类型•string•hash•list•set•sortedsetredis持久化机制•snapshot•save参数•aof•appendfsync参数•vm•vmisnotthewaytogoforthefuture•diskstore•传统b-treeredis复制•实现机制快照同步•存在的问题无增量复制slave表重建redis缺陷与优化持久化IO机制复制机制内存管理线程模型故障恢复时间持久化问题–bufferio持久化问题-fsyncfsync非常耗时单进程阻塞操作快照与fsync同时进行复制缺陷内存管理缺少高效内存管理额外内存占用过多针对特殊场景做优化开放地址Hashredis使用场景•需要key-structure复杂数据结构•需要数据可靠存储•需要极高的单机qps•usingRAMasthenewdiskHash算法数据库Hash存储结构更合适简单kv存储tokyocabint（tchdb）特点•包含hash/btree等多种存储类型kv•tchdb适合小数据量高速读写访问•tchdb随机磁盘IO次数平均•tchdb使用mmapio•tchdbqps大约在6W左右tchdb存储结构1tchdb存储结构2LSM算法数据库硬件变革推动算法变革leveldb特点•bigtabletablet实现•LSMTree算法•写性能极其出色•读性能依赖数据热度•SSD设备友好，不会写入放大•嵌入式DB，需要自己实现Server•分布式autosharding支持友好•写性能50MB/s,读性能6W/sleveldb存储结构leveldb的问题与场景•读IO次数不确定•查询指定key对应数据不存在的开销非常大•缺少高效内存管理算法•需要根据业务特点平衡merge时间点•投入使用需要一定的开发量•适合有明显时间热点访问规律的系统•配合SSD使用表现极其出色riak(bitcask)特点•存储结构简单•LSMHash算法•全部key存储在内存中•全部查询只有1次磁盘IO•QPS大约在4~5W左右bitcask存储结构bitcask问题与场景•全部key需要存储在内存中•recovery重启需要重新load所有key•merge时机的选择•适合配合SSD使用handlersocket特点•NoSQL接口访问MySQL(Innodb)•解决SQL解析，查询优化等CPU开销•插件安装无数据迁移成本•QPS可以达到8Whandlersocket结构handlersocket问题与场景•配合DDL使用有严重问题•写性能差，比传统SQL接口还要慢•只能支持RowBased复制•性能优势建立在没有磁盘IO瓶颈基础上分布式NoSQL介绍无中心化方案•无中心节点•数据一致性Hash分布•NWR数据多点备份•Readrepair•HintedHandoff•Gossip节点管理中心化方案•中心节点提供路由•中心节点维护节点信息•对外访问代理节点总结•关系数据库是单机存储时代的产物•NoSQL更能满足不同存储需求的多样性•NoSQL是SQL的延伸而不是取代•混合存储方案时代已经来临•架构师要具备不同存储方案选择的能力谢谢大家Q&A邮箱：[e-mail]微博：weibo.com/bachmozart