nosql数据库解读

谁是下一代Nosql？前世解剖比武未来无可奈何花落去，似曾相识燕归来NowSSDB，hyperdex，SequoiaDB,oceanbase…回归本源，最初的目的是什么？目的？高性能！高可用！NOSql：Nosql？Notonlysql？NewSql？知彼知己,百战不殆BerkeleyDB・BerkeleyDB没有配置文件，纯api，无需DBA・线程安全的・支持多种存储格式1.btree：搜索快，消耗IO2.hash：大数据量的时候稍微优于btree3.queue：高并发时选择，提供record级别的锁。但是记录是定长的4.recno：可以保存临时文本文件，用于变长情况，可变记录数情况。适合快速读写・限制数据文件最大256TB，单条key和value最大4g，不能放在nfs和共享盘上曾经Lucene的BDBdirectory和Mysql的BDB引擎见证了BerkeleyDB的辉煌曾经的缓存霸主Memcache•memcached由LiveJournal运营人员开发•memcached是高性能的分布式内存缓存服务器1.协议简单2.基于libevent：epoll/kqueue3.内置内存存储方式：slab/LRU内存结构图：二维数组链表slab是一次申请内存的最小单位每个slab都是1MBchunk填充item后会有空间浪费双向链表key索引表剩余空间指针回收空间指针SLAB内存处理机制提前分配大内存slab1MB，再进行小对象填充chunk避免大量重复的初始化和清理减轻内存管理器负担避免频繁malloc/free系统碎片懒惰检测机制不检测item对象是否超时get时检查item对象是否应该删除懒惰删除机制删除item对象时，不释放内存，作删除标记，指针放入slot回收插槽，下次分配的时候直接使用因为优秀，所以不足•Can’tdump•无法备份，重启无法恢复•Can’titerateoverkeys•无法查询•Notpersistent•没有持久化，重启全部丢失•Notredundant•单点故障failover•NoSessions•崩溃没法查找原因•Nosecurity•任何机器都可以telnet，需要放在防火墙后•内存问题•LRU是slab局部，没有全局•有空间浪费•日志问题•没有合理的日志•集群问题•集群增加机器成本高目前依然有很多的公司在使用FacebookSinaRenrenDiggMixi。。。Google三宝列式存储BigTable/HBaseBigTableHBase存储GFSHDFS处理MapReduceHadoop服务管理chubbyzookeeperABCDBigtable中使用Bloomfilter查询一个SSTable是否包含了特定行和列的数据。只要少量的、用于存储Bloomfilter的内存，显著减少的磁盘访问的次数。当应用程序访问不存在的行或列时，大多数时候我们都不需要访问硬盘。HBase中的所有数据文件都存储在HadoopHDFS文件系统上，主要包括上述提出的两种文件类型：1.HFile，HBase中KeyValue数据的存储格式，HFile是Hadoop的二进制格式文件，实际上StoreFile就是对HFile做了轻量级包装，即StoreFile底层就是HFile2.HLogFile，HBase中WAL（WriteAheadLog）的存储格式，物理上是Hadoop的SequenceFileBigtable之后google发布里以Dremel产品为代表的第二阶段产品，Dremel产品采用了与Bigtable不同的数据结构，立足实时对于海量数据进行分析，据说在秒级可以完成PB级别的数据分析和处理，可以做是分布式数据库实时处理的杰作，其实时处理能力达到令人惊艳的速度。第三阶段以Spanner数据库技术为代表，Spanner数据库在可以做到多数据表事务一致性管理，利用原子时钟（TrueTime）和Paxos协议解决了分布式数据库多表事务一致性管理的难题，打破的CAP不可三者兼得的理论神话，使得分布式数据库技术得到了革命性的进步。去中心化的代表Dynamo/CassandraCAP:1、可用性完全去中心化，无单点，永远可写。2、伸缩性带虚拟机节点的一致性hash：一致性hash解决扩容/缩容问题，虚拟节点解决机器异质性问题。3、可靠性数据复制多份副本，用向量时钟（vectorclock）解决版本合并问题。（Cassandra采用的是客户端timestamp，取最新的timestamp数据）4、可配置平衡性可调，即根据（N,W,R）模型平衡可用性和一致性（W+RN），建议模型参数为（3,2,2）。牺牲了一致性高并发下会取到旧数据需要应用层处理数据合并不提供任何的数据隔离，只允许单一的key更新client12345610987三种风格的Gossip数据同步texttexttexttexttexttextCassandra继承了Dynamo的架构,数据模型是BigTable的ColumnFamilyDocument存储：Mongodb•高性能、易部署、易使用，存储数据非常方便。•面向集合存储，易存储对象类型的数据。•模式自由。•支持动态查询。•支持完全索引，包含内部对象。•支持查询。•支持复制和故障恢复。•使用高效的二进制数据存储，包括大型对象（如视频等）。•自动处理碎片，以支持云计算层次的扩展性•Autosharding•支持Python，PHP，Ruby，Java，C，C#，Javascript，Perl及C++语言的驱动程序,•社区中也提供了对Erlang及.NET等平台的驱动程序。•文件存储格式为BSON（一种JSON的扩展）33注：1.该测试数据为单台数据节点的测试结果2.将Mysql作为最简单的Key-value数据库使用与实际差别较大3.MongoDB的分片优势在该测试中无法体现出来4.相对于插入，数据更新性能更能体现出差异，不过未在上图中体现性能测试图：1、在集群分片中的数据分布不均匀2、单机可靠性比较差3、大数据量持续插入，写入性能有较大波动4、磁盘空间占用比较大5、不负责内存管理，通过mmap依赖操作系统管理MongoDB核心贡献者：不是MongoDB不行，而是你不懂！图存储neo4jRDMSKey-valuedocument•完整的ACID支持•高可用性•单台服务器轻易扩展到上亿级别的节点和关系•通过遍历工具高速检索数据：每秒上亿级别的检索（目前在实现与Lucene集成，内置最短路径，Dijkstra，A＊算法等多种算法）•可以实现多种数据模型属性图形模型（PropertyGraphModel）：•节点（即顶点）•关系（即边）-具有方向和类型（标记和标向）•节点和关系上面的属性（即特性）后起之秀LevelDB/LMDB•bigtabletablet实现•LSMTree算法•内部排序，支持range遍历•写性能极其出色(写为顺序IO，读为随机IO)•读性能依赖数据热度•SSD设备友好，不会写入放大（通过操作系统的TRIM回收page）•嵌入式DB，需要自己实现Server•写性能50MB/s,读性能6W/s问题与场景读IO次数不确定查询指定key对应数据不存在的开销非常大(我认为可以通过bloomfilter辅助)缺少高效内存管理算法投入使用需要一定的开发量适合有明显时间热点访问规律的系统配合SSD使用表现极其出色memtablelogfileImmutablememtablelogfile内存硬盘sstableLevel0Level1Level2dumpcompactSk1：v1Sk1：v1Sk5：v5Sk7：v7Sk8：v8Sk11：v11logmanifestcurrentMemtabelLevel0compact当某个level下的SSTable文件数目超过一定设置值后，levelDb会从这个level的SSTable中选择一个文件（level0），将其和高一层级的level+1的SSTable文件合并Level0Level1compactLevel1Level2compact•Ordered-mapinterface(keysarealwayssorted,supportsrangelookups)•Fullytransactional,fullACIDsemanticswithMVCC.•Reader/writertransactions:readersdon'tblockwritersandwritersdon'tblockreaders.Writersarefullyserialized,sowritesarealwaysdeadlock-free.•Readtransactionsareextremelycheap,andcanbeperformedusingnomallocsoranyotherblockingcalls.•Supportsmulti-threadandmulti-processconcurrency,environmentsmaybeopenedbymultipleprocessesonthesamehost.•Multiplesub-databasesmaybecreatedwithtransactionscoveringallsub-databases.•Memory-mapped,allowingforzero-copylookupanditeration.•Maintenance-free,noexternalprocessorbackgroundcleanup/compactionrequired.•Noapplication-levelcaching.LMDBfullyexploitstheoperatingsystem'sbuffercache.•32KBofobjectcodeand6KLOCofC.LMDB:LightningMemory-MappedDatabase,是openLDAP项目的产物，基于Btree结构，接口类似于BerkerleyDBLMDBBDBLevelDBACIDTransactionsxxNestedTransactionsxxMultipleNamespacesxxSortedKeysxxxSortedDuplicateKeysxxMulti-threadconcurrencyxxxMulti-processconcurrencyxxNocachetuning:zero-configxInstantaneouscrashrecoveryxZero-copyreadsxZero-copywritesxAtomichotbackupxCrashVulnerabilityCrash-proofSilentDataLoss,CorruptionSilentDataLoss,SilentCorruptionHyperdex：Thenextgenerationofnosql？•使用hyperspace算法•号称高吞吐低延时•强一致性•支持搜素•可扩展性强•易用当数据有多个属性的时候，Hyperdex的思想是将每个属性看作是多维空间的一个轴，每个轴映射到一个物理节点，一次查询涉及到的多个属性组成一个平面，只有这些节点参与到查询中。当属性特别多的情况，将属性拆分成多个组，映射到不同的集群中分布式海量数据库的冲击：OceanBaseOceanBase可以划分为四个模块：•主控服务器RootServer：管理集群中的所有服务器，Tablet数据分布以及副本管理。•更新服务器UpdateServer：存储OceanBase系统的增量更新数据•基准数据服务器ChunkServer：存储OceanBase系统的基准数据。基准数据一般存储两份或者三份•合并服务器MergeServer：接收并解析用户的SQL请求，经过词法分析、语法分析、查询优化等一系列操作后转发给相应的ChunkServer或者U