数据库技术改造方案v2.0.docx

数据库技术改造方案 V2.0 背景 XXXXX系统，其数据库内存放的数据量较大且要求读写速度快，目前利用的Couchbase数据库虽然能满足读写速度上的要求，但服务器必须满足较大内存且各个服务节点（服务器）都是对等存在的，一个节点出现问题并不会影响其他节点正常运行，但总内存容量会缩小。 当前通过对XXXXX更多数据存储到内存，以达到提高数据的读写速率；现把两台服务器内存合并为一个内存bucket，这样的方案导致一台机器出现宕机时 failover 过程有不可用时间，并且部分数据有丢失的可能，且在高负载系统上有假死现象；如果再增加节点且节点的内存只有达到或超过当前节点才能发挥服务器的性能，否则就要缩减Couchbase建立的bucket的占用内存，服务器就不能合理发挥它的性能作用，由此拥有大量的对比数据就需要提供更好且合理的NOSQL数据库。 Couchbase数据库本身也存在以下缺点: 　 １.Couchbase 的存储方式为 Key/Value，但 Value 的类型很为单一，不支持数组。另外也不会自动创建doc id，需要为每一文档指定一个用于存储的 Document Indentifer； 　 ２.各种组件拼接而成，都是c++实现，导致复杂度过高，遇到奇怪的性能问题排查比较困难，（中文）文档比较欠缺； 　 ３.采用缓存全部key的策略，需要大量内存。节点宕机时 failover 过程有不可用时间，并且有部分数据丢失的可能，在高负载系统上有假死现象； ４.逐渐倾向于闭源，社区版本（免费，但不提供官方维护升级）和商业版本之间差距比较大。 目前结构 　　从结构和实际应用看，XXXXX存在问题: 1、对比数据量较大; 2、只有两台服务器只能做到内存扩展无法做到failover; 3、内存数据达到一定比例，再写入数据效率降低； 4、假如再添加节点就要求节点的内存必须接近当前两台节点的内存配置，否则就发挥不了现有节点的性能。 数据库对比 Hbase是一个运行在Hadoop上的分布式和可扩展的大数据仓库，其优点如下： 1、需要的是硬盘空间，能够利用HDFS的分布式处理模式，并从Hadoop的MapReduce程序模型中获益。这意味着Hbase存储容量大，一个表可以容纳上亿行，上百万列； 2、可通过版本进行检索，能搜到所需的历史版本数据； 3、负载高时，可通过简单的添加机器来实现水平切分扩展，跟Hadoop的无缝集成保障了其数据可靠性（HDFS）和海量数据分析的高性能（MapReduce）； 4、?也可有效避免单点故障的发生。 Hbase与目前所用数据库Couchbase在某些方面的对比情况，如下面列表所示： 项目 HBASE COUCHBASE 分片信息 每个server，选主 数据格式 二进制 json 固化方式 一般架设在hdfs上，可以认为是一个分布式内存索引系统 Couchstore／ForestDB 负载均衡 自动均衡，迁移 主备方式 分布式内存索引，无主备 索引支持 仅按key排序 主／二级 过滤器 服务器端 服务器端编程 协处理器。启动时放到服务器端，配置（不能动态上传） 批量写入 支持 直接从hdfs加载文件 不支持 读写内存 可以根据情况调整 定义后不可改 通过以上hbase和couchbase数据库的对比列表可知，在某些方面使用hbase要好于couchbase。 集群中进程名称及作用: NameNode【支持对HDFS中的目录、文件和块做类似文件系统的创建、修改、删除、列表文件和目录等基本操作】 DFSZKFailoverController【Hadoop Ha进程维持namenode高可用】 JournalNode【保证hadoop Ha的高可用(一般启动2n+1个)】 JobHistoryServer【可以 该服务查看已经运行完了的作业记录】 ResourceManager【管理集群资源分配，接收NodeManager的资源汇报】 DataNode【调度存储和检索数据】 NodeManager【负责在单个节点上执行MapReduce任务】 QuorumPeerMain【zookeeper独立的进程,ZooKeeper作用包括管理Hadoop集群中的NameNode，HBase中HBaseMaster的选举，Servers之间状态同步等】 HMaster【管理和分配HRegion、HRegionServer负载均衡、权限控制、实现DDL操作】  HRegionServer【维护HMast