nosql数据库解读.pptx

谁是下一代Nosql？前世解剖比武未来无可奈何花落去，似曾相识燕归来Google发表了三大论文：诞生了Bigtable2008年参考bigtable，Hbase从hadoop中诞生以SAP的HANA为代表的内存计算数据库，以google的spanner为代表的高性能分布式数据库.201020061991BerkeleyDB诞生..Google开源了LevelDB2011NowSSDB，hyperdex，SequoiaDB?,oceanbase…200920072003Redis发布.Amazon Dynamo.Memcached发布.回归本源，最初的目的是什么？目的？高性能！高可用！NOSql：No sql？Not only sql？New Sql？知彼知己,百战不殆BerkeleyDB? BerkeleyDB没有配置文件，纯api，无需DBA? 线程安全的? 支持多种存储格式 1.btree：搜索快，消耗IO 2.hash：大数据量的时候稍微优于btree 3.queue：高并发时选择，提供record级 别的锁。但是记录是定长的 4.recno：可以保存临时文本文件，用于 变长情况，可变记录数情况。适合快速读 写? 限制 数据文件最大256TB，单条key和value最 大4g，不能放在nfs和共享盘上曾经Lucene的BDB directory和Mysql的BDB引擎见证了BerkeleyDB的辉煌曾经的缓存霸主 Memcachememcached由LiveJournal运营人员开发memcached是高性能的分布式内存缓存服务器协议简单基于libevent：epoll/kqueue内置内存存储方式：slab/LRU内存结构图：二维数组链表 slab是一次申请内存的最小单位每个slab都是1MB双向链表key索引表回收空间指针剩余空间指针slab指针列表chunk填充item后会有空间浪费SLAB内存处理机制提前分配大内存slab 1MB，再进行小对象填充chunk避免大量重复的初始化和清理?减轻内存管理器负担避免频繁malloc/free?系统碎片懒惰检测机制不检测item对象是否超时get时检查item对象是否应该删除懒惰删除机制删除item对象时，不释放内存，作删除标记，指针放入slot回收插槽，下次分配的时候直接使用因为优秀，所以不足Can’t dump无法备份，重启无法恢复Can’t iterate over keys无法查询Not persistent没有持久化，重启全部丢失Not redundant单点故障failoverNo Sessions崩溃没法查找原因No security任何机器都可以telnet，需要放在防火墙后内存问题LRU是slab局部，没有全局有空间浪费日志问题没有合理的日志集群问题集群增加机器成本高目前依然有很多的公司在使用FacebookSinaRenrenDiggMixi。。。Google三宝列式存储BigTable/HBaseBigTableHBase存储GFSHDFS处理MapReduceHadoop服务管理chubbyzookeeper高可靠高性能A列存储B可伸缩C廉价集群DBigtable中使用Bloomfilter查询一个 SSTable是否包含了特定行和列的数据。只要少量的、用于存储Bloomfilter的内存，显著减少 的磁盘访问的次数。当应用程序访问不存在的行或列时，大多数时候我们都不需要访问硬盘。HBase中的所有数据文件都存储在Hadoop HDFS文件系统上，主要包括上述提出的两种文件类型：1.HFile， HBase中KeyValue数据的存储格式，HFile是Hadoop的二进制格式文件，实际上StoreFile就是对HFile做了轻量级包装，即StoreFile底层就是HFile2.HLog File，HBase中WAL（Write Ahead Log） 的存储格式，物理上是Hadoop的Sequence FileBigtable之后google发布里以Dremel产品为代表的第二阶段产品，Dremel产品采用了与Bigtable不同的数据结构，立足实时对于海量数据进行分析，据说在秒级可以完成PB级别的数据分析和处理，可以做是分布式数据库实时处理的杰作，其实时处理能力达到令人惊艳的速度。第三阶段以Spanner数据库技术为代表，Spanner数据 库在可以做到多数据表事务一致性管理，利用原子时钟（TrueTime）和Paxos协议解决了分布式数据库多表事务一致性管理的难题，打破的CAP不可 三者兼得的理论神话，使得分布式数据库技术得到了革命性的进步。去中心化的代表Dynamo/Cassandra牺牲了一致性高并发下会取到旧数据需要应用层处理数据合并不提供任