<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>yybean.com Java编程 Web开发 Ajax技术 Spring框架 Struts2框架 Hibernate技术 在线文档</title>
	<atom:link href="http://www.yybean.com/feed" rel="self" type="application/rss+xml" />
	<link>http://www.yybean.com</link>
	<description>一个java web精品小站...</description>
	<lastBuildDate>Thu, 05 Jan 2012 07:11:21 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
		<item>
		<title>Storm配置项详解</title>
		<link>http://www.yybean.com/storm%e9%85%8d%e7%bd%ae%e9%a1%b9%e8%af%a6%e8%a7%a3</link>
		<comments>http://www.yybean.com/storm%e9%85%8d%e7%bd%ae%e9%a1%b9%e8%af%a6%e8%a7%a3#comments</comments>
		<pubDate>Thu, 05 Jan 2012 07:11:21 +0000</pubDate>
		<dc:creator>tuhai</dc:creator>
				<category><![CDATA[淘宝系技术博客]]></category>

		<guid isPermaLink="false">http://www.tbdata.org/?p=2118</guid>
		<description><![CDATA[什么是Storm? Storm是twitter开源的一套实时数据处理框架，基于该框架你可以通过简单的编程来实现对数据流的实时处理变换。 Storm的配置文件一般存放在$STORM_HOME/conf下，通常名为storm.yaml，它符合yaml格式要求。 配置项详解: 以下是从storm的backtype.storm.Config类中搜集的所有storm支持的配置项(Based storm 0.6.0): 配置项 配置说明 storm.zookeeper.servers ZooKeeper服务器列表 storm.zookeeper.port ZooKeeper连接端口 storm.local.dir storm使用的本地文件系统目录(必须存在并且storm进程可读写) storm.cluster.mode Storm集群运行模式([distributed&#124;local]) storm.local.mode.zmq Local模式下是否使用ZeroMQ作消息系统，如果设置为false则使用java消息系统。默认为false storm.zookeeper.root ZooKeeper中Storm的根目录位置 storm.zookeeper.session.timeout 客户端连接ZooKeeper超时时间 storm.id 运行中拓扑的id,由storm name和一个唯一随机数组成。 nimbus.host nimbus服务器地址 nimbus.thrift.port nimbus的thrift监听端口 nimbus.childopts 通过storm-deploy项目部署时指定给nimbus进程的jvm选项 nimbus.task.timeout.secs 心跳超时时间，超时后nimbus会认为task死掉并重分配给另一个地址。 nimbus.monitor.freq.secs nimbus检查心跳和重分配任务的时间间隔.注意如果是机器宕掉nimbus会立即接管并处理。 nimbus.supervisor.timeout.secs supervisor的心跳超时时间,一旦超过nimbus会认为该supervisor已死并停止为它分发新任务. nimbus.task.launch.secs task启动时的一个特殊超时设置.在启动后第一次心跳前会使用该值来临时替代nimbus.task.timeout.secs. nimbus.reassign 当发现task失败时nimbus是否重新分配执行。默认为真，不建议修改。 nimbus.file.copy.expiration.secs nimbus判断上传/下载链接的超时时间，当空闲时间超过该设定时nimbus会认为链接死掉并主动断开 ui.port Storm UI的服务端口 drpc.servers DRPC服务器列表，以便DRPCSpout知道和谁通讯 drpc.port Storm DRPC的服务端口 supervisor.slots.ports supervisor上能够运行workers的端口列表.每个worker占用一个端口,且每个端口只运行一个worker.通过这项配置可以调整每台机器上运行的worker数.(调整slot数/每机) supervisor.childopts<div><a href="http://www.tbdata.org/archives/2118">阅读全文 &#062;</a></div>]]></description>
		<wfw:commentRss>http://www.yybean.com/storm%e9%85%8d%e7%bd%ae%e9%a1%b9%e8%af%a6%e8%a7%a3/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Flash存储设备在淘宝的应用实践(2011年iDevOps系统技术沙龙）</title>
		<link>http://www.yybean.com/flash%e5%ad%98%e5%82%a8%e8%ae%be%e5%a4%87%e5%9c%a8%e6%b7%98%e5%ae%9d%e7%9a%84%e5%ba%94%e7%94%a8%e5%ae%9e%e8%b7%b52011%e5%b9%b4idevops%e7%b3%bb%e7%bb%9f%e6%8a%80%e6%9c%af%e6%b2%99%e9%be%99%ef%bc%89</link>
		<comments>http://www.yybean.com/flash%e5%ad%98%e5%82%a8%e8%ae%be%e5%a4%87%e5%9c%a8%e6%b7%98%e5%ae%9d%e7%9a%84%e5%ba%94%e7%94%a8%e5%ae%9e%e8%b7%b52011%e5%b9%b4idevops%e7%b3%bb%e7%bb%9f%e6%8a%80%e6%9c%af%e6%b2%99%e9%be%99%ef%bc%89#comments</comments>
		<pubDate>Tue, 27 Dec 2011 04:05:06 +0000</pubDate>
		<dc:creator>褚霸</dc:creator>
				<category><![CDATA[淘宝系技术博客]]></category>

		<guid isPermaLink="false">http://rdc.taobao.com/blog/cs/?p=1416</guid>
		<description><![CDATA[ Flash存储设备在淘宝的应用实践 
 View more presentations from Feng Yu 

]]></description>
		<wfw:commentRss>http://www.yybean.com/flash%e5%ad%98%e5%82%a8%e8%ae%be%e5%a4%87%e5%9c%a8%e6%b7%98%e5%ae%9d%e7%9a%84%e5%ba%94%e7%94%a8%e5%ae%9e%e8%b7%b52011%e5%b9%b4idevops%e7%b3%bb%e7%bb%9f%e6%8a%80%e6%9c%af%e6%b2%99%e9%be%99%ef%bc%89/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>SSD在淘宝的应用实践</title>
		<link>http://www.yybean.com/ssd%e5%9c%a8%e6%b7%98%e5%ae%9d%e7%9a%84%e5%ba%94%e7%94%a8%e5%ae%9e%e8%b7%b5</link>
		<comments>http://www.yybean.com/ssd%e5%9c%a8%e6%b7%98%e5%ae%9d%e7%9a%84%e5%ba%94%e7%94%a8%e5%ae%9e%e8%b7%b5#comments</comments>
		<pubDate>Thu, 22 Dec 2011 16:02:12 +0000</pubDate>
		<dc:creator>褚霸</dc:creator>
				<category><![CDATA[淘宝系技术博客]]></category>

		<guid isPermaLink="false">http://rdc.taobao.com/blog/cs/?p=1413</guid>
		<description><![CDATA[ SSD在淘宝的应用实践 
 View more presentations from Feng Yu 

]]></description>
		<wfw:commentRss>http://www.yybean.com/ssd%e5%9c%a8%e6%b7%98%e5%ae%9d%e7%9a%84%e5%ba%94%e7%94%a8%e5%ae%9e%e8%b7%b5/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Tair ldb（leveldb存储引擎）实现介绍</title>
		<link>http://www.yybean.com/tair-ldb%ef%bc%88leveldb%e5%ad%98%e5%82%a8%e5%bc%95%e6%93%8e%ef%bc%89%e5%ae%9e%e7%8e%b0%e4%bb%8b%e7%bb%8d</link>
		<comments>http://www.yybean.com/tair-ldb%ef%bc%88leveldb%e5%ad%98%e5%82%a8%e5%bc%95%e6%93%8e%ef%bc%89%e5%ae%9e%e7%8e%b0%e4%bb%8b%e7%bb%8d#comments</comments>
		<pubDate>Mon, 19 Dec 2011 14:13:28 +0000</pubDate>
		<dc:creator>那岩</dc:creator>
				<category><![CDATA[淘宝系技术博客]]></category>

		<guid isPermaLink="false">http://rdc.taobao.com/blog/cs/?p=1394</guid>
		<description><![CDATA[Tair是淘宝开源的分布式KV缓存系统，内部将功能模块化，抽离出底层存储细节，可以接入不同的存储引擎。leveldb是Google开源的单机存储引擎，目前，已经作为Tair的持久化存储引擎ldb上线使用，这里对接入leveldb所做的处理以及修改进行介绍。 Tair首先是一个分布式的框架，有一系列策略满足CAP（数据备份，迁移复制等）。另外，还有针对应用场景的功能特性（namespace，数据过期时间，原子计数等）。接入leveldb时主要对KV操作之外的功能做相应的处理。leveldb本身的实现介绍参见leveldb实现解析。 一. 修改配置 leveldb中有一系列参数会与读写的效率有关，将相关的配置以及编译常量统一修改成可运行时配置参数，测试选取最佳配置值。 二. 实例个数控制 首先确定在一个tair server上要启几个leveldb实例？ Tair中以桶来组织数据，如果按照一个桶一个leveldb实例，在做迁移复制的时候会很方便，但考虑如果在一块磁盘上起多个实例，那么整体看来，多个顺序写变成了随机写，每个实例的compact进程会加剧整个磁盘的随机IO，所以并不采用每个桶一个实例，而是针对磁盘的数量由相关配置控制实例的个数。 三. 内部key的格式 为实现Tair中的功能逻辑，ldb传入leveldb的user-key格式如下： 1)    Tair中的数据可以设置过期时间，过期时间保存可以保存在在value的meta中，但考虑能在leveldb内部提前检查，省去解析value的消耗，将过期时间保存在key中，但并不参与排序。 2)    Tair中的数据组织以及迁移复制都是以桶（bucket）单位，为获得一个桶的数据，添加桶号前缀，保证一个桶的数据都存储在一起。leveldb内部对key做前缀压缩，桶号基本都可以被压缩掉。 3)    Tair中的数据区分namespace，会将namespace作为客户端传入key的前缀存储。 四. 自定义comparator 为了实现Tair中的功能逻辑，实现自定义的comparator传入leveldb，实现自定义的排序逻辑(传入leveldb的user-key中表示过期时间的前四个字节不参与排序)，并为comparator添加两个判断数据是否有效的逻辑接口（ShouldDrop()/ShouldDropMaybe()）,修改leveldb内部做遍历以及compact时判断数据是否有效（kTypeValue/kTypeDeletion）的逻辑。 1)    ShouldDropMaybe(): 用来判断数据是否已经过期。解析key中的expired_time即可。 2)    ShouldDrop(): 用来判断数据是否属于已经清理掉的数据（bucket已经迁移或者namespace已经被清理）。 3)    区分过期数据与清理数据的判断，是因为丢弃过期数据必须保证该key是数据的最后出现，否则删除该数据会让该key失去最后的更新状态，而清理数据有gc信息保证，不需要关心数据的状态。 五. 清理数据/自定义的内部compact逻辑 这里把清理数据的操作称为gc。 1.    迁移的bucket以及清理的namespace中的数据 一旦发生bucket迁移或者清理namespace，会把相应的信息保存下来（GcNode） struct GcNode { // 迁移走的bucket或者清掉的namespace int32_t key_; // 清理发生时的SequnceNumber,用来判断数据的时间点 uint64_t sequence_; // 清理发生时的FileNumber，用来缩小compact的范围 uint64_t file_number_; // 清理发生时的时间 uint32_t when_; [...]]]></description>
		<wfw:commentRss>http://www.yybean.com/tair-ldb%ef%bc%88leveldb%e5%ad%98%e5%82%a8%e5%bc%95%e6%93%8e%ef%bc%89%e5%ae%9e%e7%8e%b0%e4%bb%8b%e7%bb%8d/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>leveldb实现解析</title>
		<link>http://www.yybean.com/leveldb%e5%ae%9e%e7%8e%b0%e8%a7%a3%e6%9e%90</link>
		<comments>http://www.yybean.com/leveldb%e5%ae%9e%e7%8e%b0%e8%a7%a3%e6%9e%90#comments</comments>
		<pubDate>Fri, 16 Dec 2011 11:41:25 +0000</pubDate>
		<dc:creator>那岩</dc:creator>
				<category><![CDATA[淘宝系技术博客]]></category>

		<guid isPermaLink="false">http://rdc.taobao.com/blog/cs/?p=1378</guid>
		<description><![CDATA[Tair已经将leveldb作为持久化存储引擎ldb，并部署线上使用。这里对leveldb本身做具体的实现解析。后续会有引入leveldb时所作修改的介绍。
leveldb实现解析.pdf
]]></description>
		<wfw:commentRss>http://www.yybean.com/leveldb%e5%ae%9e%e7%8e%b0%e8%a7%a3%e6%9e%90/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>回车键触发表单提交的问题详解</title>
		<link>http://www.yybean.com/enter-detailed-trigger-form-submission-problem</link>
		<comments>http://www.yybean.com/enter-detailed-trigger-form-submission-problem#comments</comments>
		<pubDate>Wed, 14 Dec 2011 15:55:54 +0000</pubDate>
		<dc:creator>yybean</dc:creator>
				<category><![CDATA[JavaScript]]></category>
		<category><![CDATA[form自动提交]]></category>
		<category><![CDATA[form表单回车提交]]></category>
		<category><![CDATA[form表单提交]]></category>
		<category><![CDATA[js自动提交表单]]></category>
		<category><![CDATA[表单自动提交]]></category>

		<guid isPermaLink="false">http://www.yybean.com/enter-detailed-trigger-form-submission-problem</guid>
		<description><![CDATA[我们有时候希望回车键敲在文本框（input element）里来提交表单（form），但有时候又不希望如此。比如搜索行为，希望输入完关键词之后直接按回车键立即提交表单，而有些复杂表单，可能要避免回车键误操作在未完成表单填写的时候就触发了表单提交。   要控制这些行为，不需要借助JS，浏览器已经帮我们做了这些处理，这里总结几条规则：    &#160;&#160; 

&#160;&#160; 1. 如果表单里有一个type=”submit”的按钮，回车键生效。   &#160;&#160; 2. 如果表单里只有一个type=”text”的input，不管按钮是什么type，回车键生效。    &#160;&#160; 3. 如果按钮不是用input，而是用button，并且没有加type，IE下默认为type=button，FX默认为type=submit。    &#160;&#160; 4. 其他表单元素如textarea、select不影响，radio checkbox不影响触发规则，但本身在FX下会响应回车键，在IE下不响应。    &#160;&#160; 5. type=”image”的input，效果等同于type=”submit”，不知道为什么会设计这样一种type，不推荐使用，应该用CSS添加背景图合适些。

<span class="readmore"><a href="http://www.yybean.com/enter-detailed-trigger-form-submission-problem" title="回车键触发表单提交的问题详解">阅读全文——共1009字</a></span>]]></description>
		<wfw:commentRss>http://www.yybean.com/enter-detailed-trigger-form-submission-problem/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Flashcache新添加驱逐空闲脏页参数</title>
		<link>http://www.yybean.com/flashcache%e6%96%b0%e6%b7%bb%e5%8a%a0%e9%a9%b1%e9%80%90%e7%a9%ba%e9%97%b2%e8%84%8f%e9%a1%b5%e5%8f%82%e6%95%b0</link>
		<comments>http://www.yybean.com/flashcache%e6%96%b0%e6%b7%bb%e5%8a%a0%e9%a9%b1%e9%80%90%e7%a9%ba%e9%97%b2%e8%84%8f%e9%a1%b5%e5%8f%82%e6%95%b0#comments</comments>
		<pubDate>Wed, 14 Dec 2011 14:46:10 +0000</pubDate>
		<dc:creator>褚霸</dc:creator>
				<category><![CDATA[淘宝系技术博客]]></category>

		<guid isPermaLink="false">http://rdc.taobao.com/blog/cs/?p=1374</guid>
		<description><![CDATA[我在之前的博文提过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 [...]]]></description>
		<wfw:commentRss>http://www.yybean.com/flashcache%e6%96%b0%e6%b7%bb%e5%8a%a0%e9%a9%b1%e9%80%90%e7%a9%ba%e9%97%b2%e8%84%8f%e9%a1%b5%e5%8f%82%e6%95%b0/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>VoltDB内存数据库分析</title>
		<link>http://www.yybean.com/voltdb%e5%86%85%e5%ad%98%e6%95%b0%e6%8d%ae%e5%ba%93%e5%88%86%e6%9e%90</link>
		<comments>http://www.yybean.com/voltdb%e5%86%85%e5%ad%98%e6%95%b0%e6%8d%ae%e5%ba%93%e5%88%86%e6%9e%90#comments</comments>
		<pubDate>Mon, 12 Dec 2011 16:50:09 +0000</pubDate>
		<dc:creator>颜然</dc:creator>
				<category><![CDATA[淘宝系技术博客]]></category>

		<guid isPermaLink="false">http://rdc.taobao.com/blog/cs/?p=1360</guid>
		<description><![CDATA[引子 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 &#062; T1，那么A节点可以确认从B节点不会有更早的事务再发送过来，A节点就不必等Round Trip时间，可以直接执行事务1。当整个系统压力比较大时，这个优化方法效果尤其明显，事务的时延有效降低。 VoltDB还花了很大精力在处理事务之间的逻辑关系，尽可能对事务分门别类进行处理，以期获得更好的性能。 范围查询的处理 VoltDB取巧的采用的哈希的方法做数据分布，在面对范围查询的需求时，再次吃到苦果。哈希方法打乱了数据的连续性，对于范围查询的处理能力显著下降。VoltDB执行某张表的范围查询，需要发送这个查询到这张表的所有数据分片上。在所有分片完成同样的范围查询，再将结果汇总，才能得到全局的准确结果。所以VoltDB处理范围查询会很低效 数据持久化 虽然Stonebraker在H-Store的论文里反复提到，在内存型数据库里，即使使用Group Commit写操作日志也是非常低效的，但是为了保证数据的持久性，VoltDB还是不得不采用记操作日志的办法。VoltDB使用定期做Snapshot加上记操作日志来保证数据持久性，这种方法没有什么特别的地方。]]></description>
		<wfw:commentRss>http://www.yybean.com/voltdb%e5%86%85%e5%ad%98%e6%95%b0%e6%8d%ae%e5%ba%93%e5%88%86%e6%9e%90/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>淘宝Web服务器Tengine正式开源</title>
		<link>http://www.yybean.com/%e6%b7%98%e5%ae%9dweb%e6%9c%8d%e5%8a%a1%e5%99%a8tengine%e6%ad%a3%e5%bc%8f%e5%bc%80%e6%ba%90</link>
		<comments>http://www.yybean.com/%e6%b7%98%e5%ae%9dweb%e6%9c%8d%e5%8a%a1%e5%99%a8tengine%e6%ad%a3%e5%bc%8f%e5%bc%80%e6%ba%90#comments</comments>
		<pubDate>Fri, 02 Dec 2011 15:09:00 +0000</pubDate>
		<dc:creator>叔度</dc:creator>
				<category><![CDATA[淘宝系技术博客]]></category>

		<guid isPermaLink="false">http://rdc.taobao.com/blog/cs/?p=1348</guid>
		<description><![CDATA[我们很高兴的宣布由淘宝网核心系统部开发的Tengine服务器终于正式开源了。
淘宝网是亚洲最大的电子商务网站，Alexa全球排名第12位。每天访问淘宝网的PV超过了几十亿。大压力的访问，对淘]]></description>
		<wfw:commentRss>http://www.yybean.com/%e6%b7%98%e5%ae%9dweb%e6%9c%8d%e5%8a%a1%e5%99%a8tengine%e6%ad%a3%e5%bc%8f%e5%bc%80%e6%ba%90/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>数据倾斜总结</title>
		<link>http://www.yybean.com/%e6%95%b0%e6%8d%ae%e5%80%be%e6%96%9c%e6%80%bb%e7%bb%93</link>
		<comments>http://www.yybean.com/%e6%95%b0%e6%8d%ae%e5%80%be%e6%96%9c%e6%80%bb%e7%bb%93#comments</comments>
		<pubDate>Thu, 01 Dec 2011 07:16:44 +0000</pubDate>
		<dc:creator>jijiannan</dc:creator>
				<category><![CDATA[淘宝系技术博客]]></category>

		<guid isPermaLink="false">http://www.tbdata.org/?p=2109</guid>
		<description><![CDATA[   在做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<div><a href="http://www.tbdata.org/archives/2109">阅读全文 &#062;</a></div>]]></description>
		<wfw:commentRss>http://www.yybean.com/%e6%95%b0%e6%8d%ae%e5%80%be%e6%96%9c%e6%80%bb%e7%bb%93/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

