简介 Hibernate Shards是Hibernate的一个子项目，由Google工程师Max Ross创建并捐献给Hibernate社区。 http://www.hibernate.org/subprojects/shards.html https://github.com/hibernate/hibernate-shards Hibernate Shards是对Hibernate Core提供水平分区支持的一个框架。 标准Hibernate编程模型 灵活的分片策略 支持虚拟分片 免费/开源 实现Hibernate Shards Hibernate Shards几乎可以与现有Hibernate项目无缝结合使用。 Hibernate Shards的首要目标是让程序员使用标准Hibernate Core API查询和处理已分片的数据库,因此Hibernate Shards主要由大家已经熟知的Hibernate Core接口的实现（分片感知）组成，大多数Hibernate应用程序使用Hibernate Core提供的接口，因此无需对已有代码做过多重构。 |Hibernate Core接口|Hibernate Shards实现 |—– |org.hibernate.Session|org.hibernate.shards.session.ShardedSession |org.hibernate.SessionFactory|org.hibernate.shards.ShardedSessionFactory |org.hibernate.Criteria|org.hibernate.shards.criteria.ShardedCriteria |org.hibernate.Query|org.hibernate.shards.query.ShardedQuery 唯一问题是 Hibernate Shards 需要一些特定信息和行为。比如，需要一个分片访问策略、一个分片选择策略和一个分片解析策略。这些是您必须实现的接口，虽然部分情况下，您可以使用默认策略。我们将在后面的部分逐个了解各个接口。 首先让我们看一下《HibernateShard 参考指南》中所用的数据库模式、对象模型及映射。 气象报告数据库模式 CREATE TABLE WEATHER_REPORT ( REPORT_ID INT NOT NULL AUTO_INCREMENT PRIMARY KEY, CONTINENT ENUM('AFRICA', 'ANTARCTICA', 'ASIA', 'AUSTRALIA', 'EUROPE', 'NORTH AMERICA', 'SOUTH AMERICA'), LATITUDE FLOAT, LONGITUDE FLOAT, TEMPERATURE INT, REPORT_TIME TIMESTAMP ); 气象报告对象模型 @Entity @Table(name="WEATHER_REPORT") public class WeatherReport { @Id @GeneratedValue(generator="WeatherReportIdGenerator") @GenericGenerator(name="WeatherReportIdGenerator", strategy="org.

数据库分区是逻辑数据库的分割。分区可以通过创建独立的较小数据库（每个有自己的表、索引和事物日志）或分割所选的元素（例如一个表）来实现。数据库分区通常是为了易管理性、性能和数据有效性。 分类 分区主要有两种形式： 水平分区 水平分区是将不同的行放入不同的表中。比如将邮编小于50000的客户放入“东部客户”表中，将邮编等于或大于50000的客户放入“西部客户”表中。该例中有两个分区表“东部客户”和“西部客户”，其合集视图就是所有客户的完整视图。 通过这样的方式不同分区里面的物理列分割的数据集得以组合，从而进行个体分割（单分区）或集体分割（1个或多个分区）。所有在表中定义的列在每个数据集中都能找到，所以表的特性依然得以保持。 垂直分区 垂直分区创建含有（主键加上）较少列的表并使用额外的表存储（主键加上）剩余的列，每个分区表中都含有其中列所对应的行。范式化是内在包含垂直分区的过程。 垂直分区被称为“行分割”，通常用于分割表中（查找很慢的）动态数据和（查找很快的、使用较动态数据更频繁的）静态数据。这样在保证数据相关性的同时，在诸如统计分析之类的查询中访问静态数据还能提高性能。 不同的物理存储也可以用于垂直分区，例如不频繁使用的列或者宽列被存入不同的设备。 其缺点是需要管理冗余列，查询所有数据需要join操作。 分区标准 当前高端关系数据库管理系统提供分割数据库的不同标准。这些标准使用分区键基于一定标准分配分区。常用的标准为： 基于范围的分区 通过判断分区键是否在一定范围内选择分区。例如所有邮编列在70000和79999之间的行可以是一个分区。 基于列表的分区 一个分区分配给一列数值。如果分区键为这些值之一，该分区被选中。例如所有国家列为冰岛、挪威、瑞典、芬兰或丹麦的行可以是一个北欧国家分区。 基于哈希的分区 哈希函数的返回值决定分区归属。假设有四个分区，哈希函数返回值为0到3。 组合分区允许上述分区方案的一定组合。例如先使用基于范围的分区，然后使用基于哈希的分区。 PostgreSQL数据库分区 PostgreSQL支持基本的数据库分区，本文以PostgreSQL 9.1为例介绍一下PostgreSQL数据库分区。 优点 分区具有下列优点： 在某些情况下查询性能能显著提升，特别是表中频繁访问的行在一个单独分区或者少数量分区中。分区替代索引起始列会减少索引大小，使频繁使用的索引更有可能放入内存。 当查询或更新访问单个分区的大部分记录时，通过对分区的顺序扫描取代对全表的索引读或随机读，也会提升性能。 如果批量加载和删除需求付诸于分区设计，这些需求可以通过添加或删除分区来完成。ALTER TABLE NOINHERIT和DROP TABLE都比批量操作更快，而且完全可以避免批量删除导致的VACUUM负担。 很少使用的数据可被移往更便宜更慢的存储媒体。 这些优点仅在表非常大时是真正有价值的。对表采用分区的收益取决于应用程序，一般经验法则是表超过了数据库服务器的物理内存时使用分区。 表继承 PostgreSQL通过表继承支持分区，每个分区作为单个父表的子表创建。父表本身通常为空，仅用于代表整个数据集。 CREATE TABLE cities ( name text, population float, altitude int -- in feet ); CREATE TABLE capitals ( state char(2) ) INHERITS (cities); 父表的所有check约束和not-null约束自动被子表继承，其他类型的约束（unique、主键和外键约束）不会被继承。 SELECT name, altitude FROM cities WHERE altitude > 500; SELECT name, altitude FROM ONLY cities WHERE altitude > 500; -- 通过ONLY关键词，第二个查询仅作用于表cities而不会用于cities的子表。 支持的分区标准 PostgreSQL数据库支持基于范围的分区和基于列表的分区。

字符处理Encoding(x) Encoding(x) <- value enc2native(x) enc2utf8(x) 读取或设置字符向量的编码> ## x is intended to be in latin1 > x <- "fa\xE7ile" > Encoding(x) [1] "latin1" > Encoding(x) <- "latin1" > xx <- iconv(x, "latin1", "UTF-8") > Encoding(c(x, xx)) [1] "latin1" "UTF-8" > Encoding(xx) <- "bytes" # will be encoded in hex > cat("xx = ", xx, "\n", sep = "") xx = fa\xc3\xa7ilenchar(x, type = "chars", allowNA = FALSE) 返回字符长度，在我的测试中allowNA参数没有作用？ nzchar(x) 判断是否空字符

R中数值计算的对象一般是向量或列表，不同长度的对象进行计算时，短的对象元素将被循环使用。 运算操作符+ - * / & | ！ == != > >= < <= ^ 幂运算 %% 取模 %/% 整除> a<-c(2,49,25,8) > b<-c(2,7,6) > a/b [1] 1.000000 7.000000 4.166667 4.000000 Warning message: In a/b : longer object length is not a multiple of shorter object length > 2^5 [1] 32 > 25%%6 [1] 1 > 13%/%5 [1] 2 > 7&8 [1] TRUE无归类的函数sign 取符号> sign(-2:2) [1] -1 -1 0 1 1abs 取绝对值sqrt 取平方根> sqrt(-2:2) [1] NaN NaN 0.

综合 Pro Git 英文版 中文版 Git Community Book 英文版 中文版 GotGitHub Git使用详解 项目主页 Creating Project Pages manually Setup GitHub Pages “gh-pages” branch and “master” branch as subfolders of a parent project folder (“grandmaster”). Setup GitHub Pages “gh-pages” branch as a subfolder within the “master” project on your local checkout - a step-by-step guide. 其他 Collaborative Github Workflow 如何理解git reset 取消提交的操作？ Git Document Atlassian Git Tutorial 版本管理svn,git,cvs比较 learnGitBranching a successful git branching model

背景介绍 在Hadoop的代码中，存在org.apache.hadoop.mapred和org.apache.hadoop.mapreduce两个包。mapred包下是老的API，在Hadoop0.20时被废弃了，引入了新包mapreduce，但是由于新的API迟迟没有完成，所以在Hadoop0.21中取消了mapred包的废弃状态。原来的设想中老包mapred在Hadoop0.22和1.0中将再次设成废弃状态，但时至今日也没有被废弃。 区别 本文将通过WordCount示例代码，介绍一下二者的区别。WordCount示例代码分别取自0.19和0.23.9版本的Hadoop源码。 0.19版WordCount示例 0.23.9版WordCount示例 区别新API老API包新API位于org.apache.hadoop.mapreduce包内老API位于org.apache.hadoop.mapred.包内Mapper和Reducer类型新API使用Mapper和Reducer抽象类 抽象类更容易扩展，Hadoop实现可以轻松向其抽象类中添加方法(用默认的实现)而不会对已有Hadoop应用造成影响老API使用Mapper和Reduceer接口使用对象新API使用Configuration和一些Helper类完成作业配置； 新API使用Job完成作业控制； 新API使用Context完成用户代码与MapReduce系统的通信。老API使用JobConf 完成作业配置，它是Configuration子类； ![[Hadoop]?mapred和mapreduce包的区别](/images/2013/7/0026uWfMzy78EeY1A9Ge0.png) 老API使用JobClient完成作业控制； 老API使用OutputCollector和Reporter完成用户代码与MapReduce系统的通信。 方法map() reduce() clearup() setup() run()； 所有方法可抛IOException或InterruptedException； Reduce()输入值为java.lang.Iterable；键值对输出通过Context对象的write方法实现； map() reduce()； 所有方法可抛IOException； Reduce()输入值为java.lang.Iterator； 键值对输出通过OutputCollector对象的collect方法实现；输出文件part-m-nnnnn和part-r-nnnnn (nnnnn为从0开始的整数)part-nnnnn 注意事项 尽量使用新API。在mapred和mapreduce两个包下存在FileInputFormat、FileOutputFormat等名字一样的类，如果引入错误的话，程序会无法通过编译。 参考 Upgrading To The New Map Reduce API Difference between Hadoop OLD API and NEW API

Lubos: Eclipse plugin and RCP development notes

事务 概念 企业级应用程序经常需要访问多个组件共享的分布式数据并执行操作。这些程序应该在下列情况下保持（由应用程序商业规则所定义的）数据完整性： 分布式访问单个数据资源 从单个应用组件访问分布式资源 在这种情况下，对（分布式）资源上的一组操作可能需要被作为一个工作单元来对待。在一个工作单元中的所有操作必须全部成功或在失败时一起回滚到之前的状态。 下列情况下情况会更加复杂，需要应用程序维护工作单元的成功或失败信息： 在一组分布式组件上实现的工作单元对多个资源上的数据进行操作 串行或在并行线程中执行的操作需要协调或同步 事务(Transaction)以及事务管理器（或事务处理服务）降低了企业级分布式应用程序构建难度，维护了数据的完整性。 特性 事务是恢复和并发控制的基本单位。 事务应该具有4个属性：原子性、一致性、隔离性、持久性。这四个属性通常称为ACID特性。 原子性（atomicity）。一个事务是一个不可分割的工作单位，事务中包括的诸操作要么都做，要么都不做。当任一操作失败，事务中的所有操作需要撤销，数据恢复到之前的状态。 一致性（consistency）。事务必须保持定义在数据上的不变属性（例如完整性约束）。在事务成功结束后，数据必须处于一致状态。换句话说，事务必须是使资源从一个一致性状态变到另一个一致性状态。一致性与原子性是密切相关的。 隔离性（isolation）。一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相干扰。这需要：在事务执行期间，数据的（可能不一致的）中间状态不会暴露给其他事务；两个并发事务不能对同一数据进行操作。数据库管理系统通常使用锁机制实现这一功能。 持久性（durability）。持续性也称永久性（permanence），指一个事务一旦提交，它对资源中数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其有任何影响。 嵌套事务 事务处理组件 应用程序组件 应用程序组件是事务型资源的客户端，包含商业事务程序。在事务管理器的帮助下，这些组件创建全局事务并划分事务界限，在必要时传播事务上下文，在事务范围内通过资源管理器对事务型资源进行操作。这些组件不负责实现事务语义。然而，作为应用逻辑的一部分，这些组件通常决定是否提交还是回滚事务。 资源管理器 资源管理器是管理持久化和稳定数据存储系统的组件，并同事务管理器一起参与两阶段提交和恢复协议。 资源管理器通常是稳定数据存储系统的驱动或者包装器，提供两套接口接口：一套接口用于应用程序组件获得连接并操作数据、另一套接口用于事务管理器参与两阶段提交和恢复协议。该组件可能也直接或间接向事务管理器注册资源，以便事务管理器能够跟踪所有参与事务的资源。该过程称之为资源征集（enlistment）。为了实现两阶段提交和恢复协议，资源管理器应该实现辅助机制用于事务恢复。 事务管理器 事务管理器是事务处理环境中的核心组件。主要职责是应应用程序组件请求创建事务、允许资源征集（enlistment）和遣散（delistment）、同资源管理器一起实施两阶段提交和恢复协议。 一个典型事务型应用程序发起事务，向事务管理器发出请求初始化一个事务。作为应答，事务管理器启动一个事务并与当前线程关联。事务管理器也会创建一个事务上下文。所有参与事务的应用程序组件/线程共享事务上下文。发起事务的线程或其他线程在事务管理器允许的情况下通过发出提交或回滚请求来终止事务。 在事务终止之前，任意数量的组件或线程可在事务管理器已知的任意数量事务型资源上执行事务型操作。在资源管理器允许的情况下，事务在最终终止之前可以被挂起或恢复。 一旦应用程序发出提交请求，事务管理器（通过投票）准备用于提交操作的所有资源，并基于是否所有资源准备好提交向所有资源发出提交或回滚请求。在两阶段提交和恢复协议处理过程前后调用应用程序组件synchronization回调。 两阶段提交（2PC） 两阶段提交分为两个阶段：投票阶段和决策阶段。 在投票（或准备）阶段，事务管理器会询问每个资源管理器是否同意成功执行。资源管理器有可能返回否定应答，例如当超时导致数据库回滚。如果资源管理器做肯定应答的话，它应该确信它始终可以将工作持久化（这暗示它不会应为内部超时取消工作）， 事务管理器接收到所有应答（也称之为选票），会对事务结果作出全局决策。该决策取决于收集的应答: 如果所有应答都是肯定的（意味着每个稳定数据存储系统都可以将工作持久化），事务管理器会指示每个资源管理器进行提交。 如果有一个应答是否定的（或丢失），则回滚决策会发给剩余的资源，剩余资源取消该事务中的工作。 有两件事需要注意: 每个资源必须有能力理解两阶段提交：它需要回复来自事务管理器的准备请求，并能在事务管理器决定回滚时取消工作。 如果资源在准备阶段投肯定票之后跟事务管理器联系中断（例如事务管理器崩溃），它将不知道如何去做。由于两阶段提交协议规则它不能自己取消，因此它需要无期限地记着这个事务。此外，这限制了其他事务的并发访问。在这种情况下，该资源被称为不确定的。 资源处于不确定状态并限制并发访问令很多厂商烦恼。为了减少限制，两阶段提交协议的实践变种包含一种叫做试探性决策：太长时间处于不确定状态的资源会决定单方面回滚（或提交）事务，有可能导致违背全部接受或全部不接受的特性。 事务处理标准和技术 X/Open 分布式事务处理(DTP)模型是厂商协会OpenGroup提出的一个分布式处理模型，在事务处理和数据库领域中多数商业厂商间的一个标准。 对象事务服务(OTS)是由对象管理组织(OMG)规定的分布式事务处理服务。这个规范扩展了 CORBA 模型并定义了一系列跨越多个CORBA 对象完成事务处理的接口。 JTA和JTS是Sun提出的事务处理和事务服务的Java规范。 微软事务服务器（MTS）是一个基于构件的事务服务器，它的构件基于微软的构件对象模型(COM)。MTS编程模型为建造事务性COM构件提供接口，而MTS运行环境提供一个部署和管理这些构件和管理事务的方法。使用了MTS，由多个COM构件做的工作可被组合在一个单一的事务中。 企业级Java Beans (EJB)是Sun提出的一个技术规范。它规定了一个建造基于构件的分布式应用的框架。 JTA 概念 JTA是Java事务API的缩写，定义了在事务管理器与分布式事务系统的资源管理器、应用服务器、事务型应用程序之间的标准Java接口，包括javax.transaction和javax.transaction.xa包。在实际系统中还需要厂商专有的JTA实现。JTA是JavaEE平台的标准部分和每个EJB应用服务器都包含了JTA实现。 JTA组件 JTA的主要组件为： TransactionManager TransactionManager可用于创建事务，获取、挂起和恢复当前事务,设置事务超时值属性。其方法为线程安全的，多个并发线程可以创建自己的事务，获取仅自己创建的事务。 |begin|创建一个新事务并与当前线程关联 |commit|提交当前线程关联的事务 |getStatus|获取当前线程关联的事务状态 |getTransaction|获取当前线程关联的事务 |resume|使用挂起的事务对象代表的事务恢复调用线程的事务上下文 |rollback|回滚当前线程关联的事务 |setRollbackOnly|修改当前线程关联的事务以致事务的唯一可能结果是回滚 |setTransactionTimeout|修改当前线程使用begin方法启动的事务的超时值 |suspend|挂起调用线程当前关联的事务并返回代表正在挂起事务上下文的事务对象 Transaction Transaction允许对有效的事务进行操作。一个事务对象对应着一个全局事务，它可用于资源征集/遣散、synchronization注册、结束事务和状态查询操作。 |commit|提交事务对象代表的事务 |delistResource|接触资源与目标事务对象代表的事务之间的关联 |enlistResource|关联资源与目标事务对象代表的事务 |getStatus|获得目标事务对象代表的事务 |registerSynchronization|向目标事务对象代表的事务注册Synchronization |rollback|回滚事务对象代表的事务 |setRollbackOnly|修改目标事务对象代表的事务以致事务的唯一可能结果是回滚

折腾GemFire，免不了要折腾序列化和发序列化。GemFire支持Java的序列化，同时也有自己的DataSerializable接口实现自己的序列化，此外还有Delta接口支持数据同步时仅传送上一次数据同步后的更新。 今天测试的实现先用Java的序列化，一开始玩java.io.Serializable接口，后来玩writeObject()和readObject()方法。顺便看看有writeObject方法后ObjectOutputStream调用堆栈与原有分支的不同。 private void writeSerialData(Object obj, ObjectStreamClass desc) throws IOException { ObjectStreamClass.ClassDataSlot[] slots = desc.getClassDataLayout(); for (int i = 0; i < slots.length; i++) { ObjectStreamClass slotDesc = slots[i].desc; if (slotDesc.hasWriteObjectMethod()) { PutFieldImpl oldPut = curPut; curPut = null; if (extendedDebugInfo) { debugInfoStack.push("custom writeObject data (class \"" + slotDesc.getName() + "\")"); } SerialCallbackContext oldContext = curContext; try { curContext = new SerialCallbackContext(obj, slotDesc); bout.setBlockDataMode(true); slotDesc.invokeWriteObject(obj, this); bout.setBlockDataMode(false); bout.writeByte(TC_ENDBLOCKDATA); } finally { curContext.

介绍 当前项目原有设计使用了嵌套的Map作为缓存。我在使用GemFire产品时使用普通region替代外层map，使用动态region替代内层map。 对于"/outer_region/Dimension"region中的条目，键是维ID（例如5），值是动态region"/inter_region/Dimension/5". “/outer_region/Dimension” region的容量是256个条目，动态region"/inter_region/Dimension/5"的容量是10个条目。 当维#5被删除，"/outer_region/Dimension"相应条目应该删除，而动态region"/inter/Dimension/5"应该被销毁。 测试发现，当GemFire节点通过API创建了动态region后，它会将动态region列表发送给其他节点，此后的GemFire节点在创建Cache会失败。通过异常日志可知动态region会在Cache创建过程中被创建，但后继GemFire节点无法找到父region (在该节点创建Cache之前根本没机会创建****region!),这是导致失败的原因。 如果对cache使用cache-xml-file， GemFire会先创建普通region之后创建动态region。这需要将一个cache下所有region定义都放到cache-xml-file里，上述问题可能会被避免。但是一个cache被多个项目共享，所有项目的region定义放在一起的话，配置耦合度很高，对于产品的灵活性和扩展性很不利。 日志 Caused by: com.gemstone.gemfire.cache.RegionDestroyedException: Error -- Could not find a region named: '/inter_region/Dimension' at com.gemstone.gemfire.cache.DynamicRegionFactory.createDynamicRegionImpl(DynamicRegionFactory.java) at com.gemstone.gemfire.cache.DynamicRegionFactory.createDefinedDynamicRegions(DynamicRegionFactory.java) at com.gemstone.gemfire.cache.DynamicRegionFactory._internalInit(DynamicRegionFactory.java) at com.gemstone.gemfire.internal.cache.DynamicRegionFactoryImpl.internalInit(DynamicRegionFactoryImpl.java) at com.gemstone.gemfire.internal.cache.GemFireCacheImpl.readyDynamicRegionFactory(GemFireCacheImpl.java) at com.gemstone.gemfire.internal.cache.GemFireCacheImpl.initializeDeclarativeCache(GemFireCacheImpl.java) at com.gemstone.gemfire.internal.cache.GemFireCacheImpl.init(GemFireCacheImpl.java) at com.gemstone.gemfire.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java) at com.gemstone.gemfire.cache.CacheFactory.create(CacheFactory.java) at com.gemstone.gemfire.cache.CacheFactory.create(CacheFactory.java) at org.springframework.data.gemfire.CacheFactoryBean.createCache(CacheFactoryBean.java) at org.springframework.data.gemfire.CacheFactoryBean.init(CacheFactoryBean.java) at org.springframework.data.gemfire.CacheFactoryBean.getObject(CacheFactoryBean.java) at org.springframework.data.gemfire.CacheFactoryBean.getObject(CacheFactoryBean.java) at org.springframework.beans.factory.support.FactoryBeanRegistrySupport.doGetObjectFromFactoryBean(FactoryBeanRegistrySupport.java) ... 34 more