我在之前的博文提过Flashcache的cache是以set为单位管理的，每个set默认2M。 当单个set里面的脏页数量超过dirty_thresh_pct的时候，就会启动背景工作队列来把超过设置的脏页回写到后备磁盘去。 这里有别的同学对flashcache设计文档的翻译. 参看dirty_thresh_pct的文档解释： dev.flashcache..dirty_thresh_pct = 20 Flashcache will attempt to keep the dirty blocks in each set under this %. A lower dirty threshold increases disk writes, and reduces block overwrites, but increases the blocks available for read caching. Flashcache之所以这样做的目的是当它在处理用户IO请求需要cache块的时候，保证马上可以拿的出来。因为读写的时候，如果需要的cache块不能满足的话，flashcache选择简单的绕过cache机制，直接走uncache io, 同时启动页面回收，一下子收回超过设置部分的页面，对性能有很大的损失。 特别是顺序写的时候，写一圈，再回绕在写的场合，性能特别差，就是这个原因。 那么如何保持一定量的可用cache块就很重要。通常cache数据都有冷热点，而且和时间很大关系。flashcache对冷热的判断是透过LRU类似的算法来判断的，这个是基于使用频度的维度。但是缺乏时间维度的判断。 新版本的flashcache引入了fallow_delay参数来解决这个问题，如果一个脏页超过fallow_delay秒，默认15分钟，都没有重新被访问到，那么数据就会被回写。 回写后，作为候选页面可以被新的cache重新利用。 参看fallow_delay的文档解释： Sysctls for writeback mode only : dev.flashcache..fallow_delay [...]

引子 VoltDB是一个宣称性能超过Mysql 100倍的新型数据库。它源自Micheal Stonebraker一篇论文H-Store。在这篇论文发表后，Stonebraker成立了VoltDB公司带着他的一些学生开始在OLTP数据库领域打拼。Stonebraker从上世纪70年代——数据库刚开始发展的时间——就开始在数据库领域活跃，这样的老古董提出的数据库的新想法，给了整个存储领域很大的想象空间。 VoltDB源起于应用领域与硬件发展翻天覆地的变化。用户的使用方法发生了变化，在数据库开始发展的阶段，事务是一个较长的过程，用户或者管理员可以在”BEGIN TRANSACTION”和”END TRANSACTION”之间慢慢地人工执行整个事务的步骤。但是现在，大部分操作是由Web服务端发起的书写良好的事务，用户访问的是Web服务器，在Web服务器的执行逻辑里再访问数据库，所以即使是很复杂的事务也可以很快执行完。计算机硬件的发展更是一日千里。几十GB的内存服务器已经很常见。以太网络也已经步入Gbps时代，而且正在朝向10Gbps方向迈进。基于以太网的集群的机器价格也降低到比PC机贵不了太多。VoltDB的设计充分利用了这些特点，数据主要存储在内存中，Shared Nothing的集群结构，单机是单线程处理事务，不是用锁而是基于Optimistic的方法处理事务并发，所有的事务必须以存储过程形式先提交到VoltDB系统。下面分开来说。 事务提交 既需要支持复杂的事务操作，又需要快速的执行过程，VoltDB采取了一个比较极端的事务提交方式。虽然VoltDB支持部分SQL语句接口，但是不允许用户使用传统的”BEGIN TRANSACTION”和”END TRANSACTION”的语法模式，而是完全基于存储过程。用户通过写存储过程完成应用程序的逻辑，作为一个先置条件将存储过程提交到VoltDB。运行时，用户程序调用存储过程完成事务操作，所有事务的运行逻辑是由VoltDB在服务器进程中完成的。这种方式保证了事务不会被人为打断，并且服务器可以预先判断各个事务的逻辑，也为事务并发处理挖掘信息。 数据分布 VoltDB使用Shared Nothing结构，整个数据库的数据分散到集群的多台机器上。VoltDB的数据分布策略是基于哈希的，存储在VoltDB中的每一张表，对数据的主键哈希取模后的结果对应于数据存储的节点。相比较于BigTable基于主键的连续范围分段的方法，哈希方法的好处是数据分散的均匀，没有动态数据调整的烦恼。但也有很多缺点，采用这种方法后，集群的规模是事先确定好的，新增机器需要停止服务后重新分布数据。另外，数据哈希被分散后，数据的连续性被打乱了，在这个数据结构上做范围查询需要动用服务这张表的所有机器，这个后面会祥说。 上面这张图描述了数据的分布方式，VoltDB集群的每台机器都会服务多张表。从图里还能看到VoltDB的数据复制是基于机器单位的，蓝色框圈住的两台机器内的数据是完全同构的。 VoltDB的哈希分布数据的方法是系统设计的简化，这种简化让VoltDB工程实现难度降低，可以快速的商用。天下没有免费的午餐，这个设计也是VoltDB功能缺陷，导致VoltDB无法动态扩容以及其他一些问题。 数据一致性 同一份数据的多个副本之间需要保证数据一致性，VoltDB采用所有修改操作在每一个副本上单独更新的方式。如何保证更新操作在所有副本上以相同的顺序更改而不至于产生不一致，这就要提到VoltDB的并发控制方式。 VoltDB的事务并发控制需要依赖于集群内所有机器的时间是一致的，这个可以使用NTP之类的时间同步协议，保证机器之间的时间差异远远小于一个交换机下的两台机器之间的Round Trip时间。VoltDB对于用户每一次事务的调用分配一个时间戳，并且保证这个时间戳是全局有序的，虽然时间戳是由集群中的各台机器独自分配的，但是加上机器的序号，可以保证（机器序号，时间戳）的组合值是全局有序的。一台服务器执行事务之前，需要等待Round Trip时间后，如果其他机器没有开始比自己更早的事务，那么就执行自己的事务。以这种方式保证集群内多台机器之间事务的有序。数据的多个副本的更新操作也都以相同的顺序进行修改，所有副本之间保证了一致性。 事务并发处理 为了充分发挥多核机器的性能，而又不引入多线程执行事务的复杂性，VoltDB的数据分片规模是按照集群核数来划分的。一台物理机器上可能运行多个VoltDB服务器进程，每个进程对应于一个核，服务器进程之间都是通过网络进行通信。在单个进程内，只使用单线程，所有的事务执行都是顺序进行的。 多个事务在多个服务器节点同时执行，VoltDB保证如果事务之间有冲突，那么事务的执行是完全隔离的，即达到SERIALIZABLE ISOLATION。VoltDB会事先分析好存储过程之间的关系，如果两个事务可能存在冲突，则不让这两个进程在同一个时间执行。 在VoltDB的并发处理中，每一个事务在执行之前都要等待一个Round Trip时间，显然会增加事务执行的时延。这么做是为了确保别的节点没有发起比这个事务更早的事务，保证事务执行的顺序。在实现中，VoltDB用了另外一种优化方法。例如A，B两个节点，分别要执行事务1和2，A节点开始执行事务1的时间是T1，如果A收到B发了事务2的执行需求，并且T2 > T1，那么A节点可以确认从B节点不会有更早的事务再发送过来，A节点就不必等Round Trip时间，可以直接执行事务1。当整个系统压力比较大时，这个优化方法效果尤其明显，事务的时延有效降低。 VoltDB还花了很大精力在处理事务之间的逻辑关系，尽可能对事务分门别类进行处理，以期获得更好的性能。 范围查询的处理 VoltDB取巧的采用的哈希的方法做数据分布，在面对范围查询的需求时，再次吃到苦果。哈希方法打乱了数据的连续性，对于范围查询的处理能力显著下降。VoltDB执行某张表的范围查询，需要发送这个查询到这张表的所有数据分片上。在所有分片完成同样的范围查询，再将结果汇总，才能得到全局的准确结果。所以VoltDB处理范围查询会很低效 数据持久化 虽然Stonebraker在H-Store的论文里反复提到，在内存型数据库里，即使使用Group Commit写操作日志也是非常低效的，但是为了保证数据的持久性，VoltDB还是不得不采用记操作日志的办法。VoltDB使用定期做Snapshot加上记操作日志来保证数据持久性，这种方法没有什么特别的地方。

我们很高兴的宣布由淘宝网核心系统部开发的Tengine服务器终于正式开源了。
淘宝网是亚洲最大的电子商务网站，Alexa全球排名第12位。每天访问淘宝网的PV超过了几十亿。大压力的访问，对淘

   在做Shuffle阶段的优化过程中，遇到了数据倾斜的问题，造成了对一些情况下优化效果不明显。主要是因为在Job完成后的所得到的Counters是整个Job的总和，优化是基于这些Counters得出的平均值，而由于数据倾斜的原因造成map处理数据量的差异过大，使得这些平均值能代表的价值降低。Hive的执行是分阶段的，map处理数据量的差异取决于上一个stage的reduce输出，所以如何将数据均匀的分配到各个reduce中，就是解决数据倾斜的根本所在。规避错误来更好的运行比解决错误更高效。在查看了一些资料后，总结如下。 1数据倾斜的原因 1.1操作： 关键词 情形 后果 Join 其中一个表较小， 但是key集中 分发到某一个或几个Reduce上的数据远高于平均值 大表与大表，但是分桶的判断字段0值或空值过多 这些空值都由一个reduce处理，灰常慢 group by group by 维度过小， 某值的数量过多 处理某值的reduce灰常耗时 Count Distinct 某特殊值过多 处理此特殊值的reduce耗时 1.2原因： 1)、key分布不均匀 2)、业务数据本身的特性 3)、建表时考虑不周 4)、某些SQL语句本身就有数据倾斜 1.3表现： 任务进度长时间维持在99%（或100%），查看任务监控页面，发现只有少量（1个或几个）reduce子任务未完成。因为其处理的数据量和其他reduce差异过大。 单一reduce的记录数与平均记录数差异过大，通常可能达到3倍甚至更多。 最长时长远大于平均时长。 2数据倾斜的解决方案 2.1参数调节： hive.map.aggr = true Map 端部分聚合，相当于Combiner hive.groupby.skewindata=true 有数据倾斜的时候进行负载均衡，当选项设定为 true，生成的查询计划会有两个 MR Job。第一个 MR Job 中，Map 的输出结果集合会随机分布到 Reduce 中，每个 Reduce 做部分聚合操作，并输出结果，这样处理的结果是相同的 Group By