Monthly Archives: June 2014

数据分析工作负载VS事务性工作负载证明商业和技术可靠的大规模分布式数据库，支持ACID、有效存储PB级别数据的系统 分析数据库的架构，关注与C-Store不同的点 实施和部署的经验，为什么引入那些不同 现实世界的经验可以引导未来大规模数据分析系统研究的方向2.背景 2.1.1设计目标：分析工作负载不是事务工作负载 事务工作负载：每秒事务数多，每个事务会影响少数几个元组，大部分的事务是增加一个新行或者修改部分已存在的列 分析工作负载：每秒事务数少，每个事务检查很多表中的元组，比如分析用户的行为，行处理每秒很多数据量级的增加，即使是小公司 最初就是设计一个分布式数据库 1、新节点加入系统性能有线性的扩展。使用共享磁盘的架构也能获得这样的扩展，但这很快会成为系统的瓶颈 2、优化和执行的引擎避免大量的网络数据传输，以避免内部互联成为系统瓶颈 3、查询和加载数据每秒都会有很多，必须关注支持高插入，否则只能有限的应用，批量的加载应该很快而又不能影响并行的查询 4、操作可在线，管理和维护任务不应该停止或暂停查询 5、易于使用是一个明确的目标。用CPU换时间，形式上减少复杂的网络和磁盘设置，减少性能的调优，自动化的物理设计和管理3数据模型 3.1 （列）计划 属性排序子集（经过编码和压缩并按某种次序排序和分割的纵列集合） 加载过程中自动维护 每个Projection都有自己的排序，数据是完全排序的 任意数量、带有不同排序的推算或表列的子集是被允许的，可针对不同的查询进行优化。不同排序规则，可被看成物化视图，但它们是物理数据结构，不是辅助索引。它不包含聚集、连接、额外的查询，认为它们在现实的分布式数据库中是不切实际的。 2.2连接索引，没有被实现，代价比带来的优势要少，实现复杂，执行代价在重现全元组在分布式查询时很高。 明确存储行ID，会点用很多空间，我们高效的压缩实现有助于减少这种开销，但没有计划实现它 3.3预连接推算 没有预期使用的多和重要：在小表连接操作上已经够好（高度优化的hash和合并算法），用户一般不愿意减慢 批量数据加载数据去优化查询速度。在加载数据时比连接查询时能够进行的优化机会要少，因为数据库在加载流中没有什么先验。3.4 编码和压缩 不同列有不同的编码，同样的列在他们的每个推测中也可有不同的编码 自动：根据类型和配置，当使用场景不同确时 替换：低基数列3.5 分区 c-store节点内水平分区，在单个节点使用并行提升性能 获得节点性并行并不需要硬盘物理分隔，在运行时逻辑分区，然后并行处理。尽管能够自动并行化，也提供根据value保持在物理上隔离 分区原因：快速批量删除（其它系统分区也是如此），否则需要查询所有物理文件要删除的行，添加删除标记，比起直接删文件慢的多 增加了存储的需求，在元组没有执行合并操作前影响查询性能。如果分区在所有推算上都一致，批量删除才是快速的，所以它是表层次的，而不是推算层次的分区原因：增加查询性能，它保存最小值和最大值在每个ROS中，在做计划时就能够修剪容器。分区使这种技术更高效，分区使列数据不混合 3.6 分割：集群分布 可以指定列做hash到段 c-store根据projection的排序字段的第一个列分割物理存储到段 完全的分布式存储系统，分配存储元组到不同计算结点 节点内水平分区和节点外水平分区（分割） 分割对每个推算在排序方式上可能不同，推算分割提供决定把元组映射到节点，可以做许多重要的优化。（ … Continue reading →