云+微服务+新硬件下一代大规模并行数据库架构风格.docxVIP

云+微服务+新硬件：下一代大规模并行数据库架构风格 并行数据库的定义和架构特点 在维基百科上，并行数据库被定义为通过并行使用多个CPU和磁盘来将诸如装载数据、建立索引、执行查询等操作并行化以提升性能的数据库系统。其中最重要的关键词是并行。 在组成大规模计算机集群的时候，通常有两种特性要考虑：并行和分布式。并行强调多节点同时执行，共同解决一个大问题，通常在严格的高性能网络环境中，有严格的执行要求和反馈时限。因此，并行和并发大多数时候是矛盾的两面，你不应该指望并行数据库能在极短的时间处理大量的请求，因为它是为了解决大问题而设计的，而不是大量的小问题。分布式则是另外一个特性，它强调数据或计算分布在不同的节点，并对上提供透明性。 因为目的不一样，通常设计运行在大规模集群的软件时，不会同时追求这两者。并行数据库被设计为最求极致的并行，即使仅查询一条数据的SQL，也会被扔给所有的数据节点来执行；而HDFS则不是这样，它不会要求一个文件块完全分布在所有的数据节点上，并同时提供访问，它只需要将一个文件按照顺序分成几个块分布在数个节点上即可，一个接一个地被访问。因此一个HDFS数据节点失效影响不了全局；但是一个MPP的数据节点失效会影响全局。这是两种特性的典型差别。理解了这个“并行”的特点对理解并行数据库的设计非常重要。 很明显，因为并行数据库的技术特点是为了某类需求设计的，因此它有自己的适用环境。首先因为它采用关系理论，因此它仅适合结构化数据。非结构化或者某些半结构化数据，当然也可以在其中存和取，但是实际上有很多更好的解决方案可以选择。其次还是因为它采用关系理论，关系代数和关系演算是其擅长的，因此它在并行计算，特别是复杂的多表关联、流水线等一系列操作中特别擅长，如果只是存入和取出的话，NoSQL会更加适合。再次，因为并行数据库的SQL语言是一种申明式的语言，甚至当初设计的目的并不是给程序员使用，而是给业务人员用的，因此处理日常重复性任务有更好的解决方案，比如MapReduce和Spark。最后一点，因为并行数据库需要在数据分布（计算Hash）和存储格式（比如列存、压缩、索引、页面统计信息等）方面进行较多的处理以便为查询进行优化，因此装载数据比较耗费精力，花费时间较长。所以入库后只会被读取少数次的任务，最好不要麻烦它来做。 并行数据库目前的主要问题来自于它的设计目的，因为要实现完美的并行，因此它大多被设计为计算和存储紧密耦合，这样计算可以控制每行数据的存储位置和每个数据块的存储格式，这样对大任务提供了很好的性能（类比于“鱼”）。同时也使得系统鲁棒性不高，这体现在一个节点退服后性能下降严重，两个节点退服有全库停止的可能。另外系统扩展性也受到限制，一是规模不能太大，二是基本需要对等性能的机器，三是重新计算Hash并移动数据是非常麻烦和缓慢的（类比于“熊掌”，目前是鱼与熊掌不可兼得）。 并行数据库技术要点分析 并行数据库主要由执行引擎、存储引擎和管理功能模块组成。它们的不同技术风格形成了各个有特色的并行数据库产品。 因为是大规模集群的数据库，所以首要要面对的就是主、从节点的风格。主节点要承担入口、元数据管理、SQL Parser、生成执行计划和任务调度、管理两阶段提交等功能。目前有两种方式：有专职Master和无专职Master。 从开源的PostgreSQL演变来的并行数据库，多为有专职Master的。这种架构比较简单，因此数据节点的对等性比较容易维护，不会形成性能短板。它们的Master形成了主备模式，切换的时候影响比较大，而且主节点的动态伸缩也是问题。 从头设计的并行数据库多为无专职Master的，比如Gbase 8a和Vertica。数据节点和Master节点代码部署到一台物理机，被连接上即充当此次连接的Master。其优点是足够的扩展性和更好的高可用性，但是缺点在于Master的进程可能拖慢数据节点，形成性能短板。而且Master之间的元数据同步也是一个负担。 两种方式各有优劣，在大规模集群下，无专职Master架构优势更加明显，其向“多Master”架构发展也很容易。我认为多Master是未来方向，这样在提供良好的扩展性和高可用的同时，也保持了数据节点的对等性。 在存储引擎中最为关键的就是数据分布。按行进行Hash分布是并行数据库的重要特征。其它数据分布方式无法精确控制数据摆放，也无法提供足够用于查询优化的存储信息。 就像之前说的那样：这种紧密耦合的非透明的方式带来了巨大的好处（同样分布的表的高效关联），同时也带来了麻烦（扩展性、高可用等）。鱼与熊掌不可兼得。一些改进的SQL on Hadoop方案借用了这一点，比如HDFS Colocation、Pivotal HAWG、Vertica VIVE等。没有解决Hash分布的解决方案，都难以