亚洲av无码专区国产乱码在线观看,亚洲欧洲成人精品香蕉网,国产精品久久亚洲一区二区

NOSQL- Questions

wz.xjtu — Wed, 24 Feb 2010 02:47:00 GMT

�q�篇文章是用英文写的�Q�由于某�U�原因，�q�篇文章可以很直接的说是Anti-MongoDB一个和谐的DB�Q�一�Q�。写一的时候其实有很多问题�Q�还是不很清楚的。所以有了以下的问题�Q?

I has some questions about the nosql and the document database solutions because I just touch the nosql solutions these days,
I tried to understand and find the benefit of the NOSQL solutions (performance and scalability), but I cannot convince myself for the reasons, specially for the complex business related cases,
After read a lot of the articles and find the CAP, relational and Scalability are the three points for the NOSQL solutions,
CAP : only can pickup two of the three factors, and the NOSQL solutions pickup the AP, and use the eventually consistency to handle the consistency, now, let's check the RDBMS, if we have a lot of database servers, we also cannot have a good Consistency because of the performance issues, so we can choose the Master/Slave and asynchronize copy to handle the consistency (Similar with Eventually Consistency) which is similar with the NOSQL, so what is the benefit of the NOSQL (specify document database) from the CAP theory?
No-Relational object : the NOSQL is good at the no-relationship objects, for example, log. but log also can save to the RDBMS without relationship, so for the no-relationship objects, I think the mongo solution and the RDBMS solutions should be have the same performance and scalability. right?
Relational : in the mongodb.org there is a good example as following,

the address is embedded into the student which is reasonable and will make the performance better if we need load the address from the student in the UI, but the RDBMS also can do it for the 1-1 relationship, and the scores need ref to the another collection and which is also similar with the RDBMS and also need touch database two times when we load the course which also similar with RDBMS. so what is the benefit.
Partition and Sharding : RDBMS also provide the solutions (although need change some codes), and RDBMS also can handle them.

wz.xjtu 2010-02-24 10:47 发表评论

MongoDB之一NOSQL

wz.xjtu — Wed, 24 Feb 2010 02:46:00 GMT

NOSQL数据库经�q�了风风火火的一�q�_��各个解决�Ҏ��做的一个比一个有个性，�q�且大部分都有了商业应用�Q��M��来说自己创造出来�ƈ且可以进行自行优化的东东�q�是�l�得起历�l�的�?

MongoDB在过�ȝ��一�q�中�Q�变化非�怹�大，刚开始关注它的时候，它只是一个没�?.0版本的东东，但是现在已经加上太多太多的功能了�Q�其中包�?MapReduce�Q�Auto Sharding�Q�等�?

�l�过了比较深入的研究�Q�还会��l�研�IӞ��Q�发现这个最像关�p�d��数据库的数据��实做的很强大。有很多东西�q�是非常值得探讨的。我们先从以下方面进行研�I�关�p�d��数据库和非关�p�d��数据库的区别�Q�以及�ؓ什么要在某�U�条件下摈弃关系型数据库�?

1. 关系型数据库的��生就是�ؓ关系所生，如果一条条的都不是关系型的数据�Q�需要进行关�p�d��数据库吗�Q?�{�案很简单：不需�?

�l�典应用�Q�Log的存�?�Q�存储到关系型数据库的话�Q�耽误了我们可怜的不好扩张的数据库呀�Q�如果存储在文�g里面�Q�那又不好进行管理，所以非关系型数据库是一个很好的解决�Ҏ��Q?

2. 关系型数据库�q�多的强调了关系�Q�关�p�d��数据库的目标是把我们的数据库打造成一个第三范式遍布的数据�l�构�Q�无传递函��C��赖和部分函数依赖�Q�。但是这�U�拆解变相的多了一�ơ数据库操作�Q�也��是一�ơIO�Q�性能也就会下降了�?例子如下�Q�当我们��x��开一个帖子的时候，我们肯定�q�是��x��下面的Comments都拿到的�Q�如果我们直接能把Comments存在�q�个帖子之下��很容解决了吧�?

3. 关系型数据库�q�的��x��consistency�Q�其实我们很多的�pȝ��中�ƈ不需要这么好的consistency�Q��v码很多的Web2.0或者是普通的�|�站来说�Q�只要把Support�Q�维护，alert机制做好�Q�不需要太多的consistency一样可以做出很好的�pȝ��。当然我们也可以通过一些机制实�?eventually consistency �Q�没有很深入的研�I�过�Q�。太多的consistency的关注必然导致最后的available不会做到很好。进而关�p�d��数据库很难scaling out。�ؓ了scaling out read�Q�我们只能去做partition�Q�但是partition很难做呀�Q�一半都会牵扯到很多代码的改动。这些代码的改动会严重媄响项目的�E�_��性而且风险性很大。而�ؓ了scaling out write 只能��d��master-slave的解��x��案（async和sync每种都有自己的问题）。很多NOSQL都解决了�q�个问题�Q�无论是auto- sharding�Q�因为是key做主的东西，可以很好的拆分）�q�是replication。（�q�一块要�q�一步研�IӞ��

4. Schema问题。关�p�d��数据的schema都是一定的�Q�如果增加或减少一个column那可是一个大动呀。但是NOSQL却是能很�Ҏ��的解册��个问题，因�ؓ他们��是key-value而已�?

NOSQL的提出是一个思想的进步，是一�U�编�E�理�늚��q�步�Q�数据库只是一个存储的库而已�Q�他不应该过多的��x��于其他的business相关的东�ѝ��将来发展的前景是我们所有的business的逻辑都应该在Domain里面体现�Q�我们不用关注下面到底存储到那里�?/p>

wz.xjtu 2010-02-24 10:46 发表评论

LinkIn��Z��Dynamo设计的系�l?[ZZ]

wz.xjtu — Mon, 18 Jan 2010 14:45:00 GMT

Key-Value存储

��Z��实现高性能和高可用性，我们只允讔R��常简单的键值数据存取。key和value可以是list和map的复杂类型，但美中不��的是只有以下的查询是有效的�Q?/p>

value = store.get(key)

store.put(key, value)

store.delete(key)

�q�可不是解决了所有的问题�Q�其实做了许多的取舍�Q?/p>

�~�点

没有复杂的查询过滤器

所有的联合查询必须在代码实�?/p>

没有外键的结�?/p>

没有触发器和视图

优点

只有高效的查询可用，性能是可惛_��?/p>

�Ҏ��分布到集��?/p>

不管怎样�Q�面向服务常�怸�允许外键的结构，�q�且强制在代码中实现联合�Q�因为和数据相关的key�q�个关系在另一个服务中�l�护着�Q?/p>

使用关系型数据库你必��要有一个缓存层用来扩展��L��作，不过�q�个�~�存层很典型地强制你使用了key-value的存储系�l?/p>

��Z��性能�Q�最后不得不使用xml或者是其他不够正规的一砣文�?/p>

佉K��辑和存储分��L��晎ͼ��Z��性能原因�Q�SQL鼓励��商业逻辑和存储操作�؜在一��P��

没有对象-关系数据的丢失匹配问�?/p>

数据模型的详�l�的讨论��在下面�l�出�?/p>

�pȝ��架构

代码中的每层实现了简单的put get和delete操作的接口。每一层都会负责一个方法，诸如tcp/ip�|�络通信、序列化、版本冲�H�解冟뀁内部结点�\��q��{�。例如�\由层负责发�v一个操作，比方说是Put�Q��ƈ且分发给N个存储�ƈ行执行复�Ӟ��同是要捕��h��有的��p�|�?/p>

�?

保持每一层独立意味着可以混合和匹配��用以满��q�行中不同的需求。例如，我们可以增加一个压�~�层�Q�将字节值的压羃水��^降低到序列化之下。同��P��在将数据路由到分区的时候我们可以做灉|��的智能�\由。硬件负载均衡的http客户端（用ruby写的�Q�这��工作可以在客户端做�Q�smart的客��L��Q�，也可�? 在服务端做成�ȝ��式的使用。要把网�l�层攑֜�路由层的上面�q�是下面�Q�我们需要做的是一件简单的事情�?/p>

�?

在上图中“Load Bal.”是指负蝲均衡的硬件或者是轮��@软�g负蝲均衡器，“Partition-aware routing”是存储的内部路由。从传�g�q�角度来看，��少的蟩是�g好事�Q�因为，嗯，�q�样��p��得少了）�Q�从吞吐量的角度来说也是件好事（因�ؓ可预见的瓉�� 更少了）�Q�但是需要把路由信息攑ֈ�栈顶�Q�例如，客户端必��L��java的而且�q�要使用我们的库�Q�。最后，最右的图中�Q�http-rpc发送到服务的请求被�? 由到了包含正��数据的机器�Q�如果有的话�Q�，因此�Q�在一个单独的复制�ȝ��单的情况下，机器必须能够直接从本地bdb�U�程内部获取数据�?/p>

�q�一灉|��性��得高性能的配�|�成为可能。在存储中，��盘的访问是一个独立的最大的性能冲击�Q�第二个是网�l�的��x��。靠分区数据和尽可能�~�存数据�Q�可以避免磁盘访问。网�l�蟩数需要架构的灉|��性来消除。请注意在上图中�Q�我们可以用不同的配�|�文件来执行3�?跛_��1跳的�q�程服务。要获得非常高的性能�Q�就必须�? 由服务直接找到正��的服务器�?/p>

数据分区和复�?/h3>
数据必须分区��C��个集��的所有服务器上，使没有�Q何一台单一的服务器需要保存所有的数据集。即便数据可以在一个单独的��盘上存下，��盘讉K��值数�? 的时候是受寻找时候所控制�Q�因此分区有改善�~�存性能的作用，它依靠把热的数据集分成更��的块，能够�Q�希望能够）整个地放到那个存有整个分区的服务器内�? 里。这��意味着�Q�在集群里的机器是不可以互换的，��h��必须被�\由到保存有所��h��的数据的机器�Q�而不只是随便地到某一台可用的机器上�?/p>
同样�Q�因��载过重或者是�l�护原因的停机，服务器经�怼�不可用。如果有S台机器�ƈ且每台机器一天有p的概率会独自挂掉�Q�因此一天里一台机器丢失数据的概率�? - (1 - p)^s�Q�显�Ӟ��鉴于�q�一事实�Q�我们不能将数据只保存在一台机器上�Q�或者说�Q�数据丢��q��概率与群集中的数量成反比�?/p>
最��单的方式来完成这件事是，��数据分成S个分区（每个机器一个）�Q��ƈ且在R台机器上面保存键为K的值的拯��。用K�q�个键来兌��R台机器的一�U�方�? 是，设a=K%S�Q�然后将�q�个��g��存在机器a�Q�a+1�Q�a+2�Q?#8230;a+r。因此，对于��M��的概率p�Q�你都可以选择一个合适的复制因子R�Q�来辑ֈ�一个可接受的够低的数据丢失的概率�?/p>
�q�个�pȝ��有个非常漂亮的特性，那就是�Q何�h只要知道数据的key��可以计��到数据所处的位置�Q�系�l�允许我们以peer-to-peer的方式做数据��L��Q�而不需要联�p�M��个装有所有的key到服务器的映��信息的中央元数据服务器�?/p>
当从集群中添加、删除机器时�Q�这栯��是因为我们购买新的硬件或服务器��时关闭）�Q�上�q�方法会��D��~�点。在�q�种情况下，d会被改变�Q�数据会在机器之间迁�U�R��假如d不变�Q�那负蝲不会�q�_��C��原来删除的或者是坏了的机器分布到集群中剩余的部分�?/p>
一致性哈希是一�U�避免这�U�问题的技术，我们用它来计��每个key在集��中所处的位置。��用这�U�技术，伏地��有了这��L��Ҏ��，当一台机器挂了的时候，负蝲可以�q�_��地分布到集群中剩余的机器。同��P��当增加一台机器给一个有S台机器的集群�Ӟ��只有1/(S+1)的机器上的值需要迁�U�d��新机器�?/p>
��Z��形象化一致性哈希方法，我们可以看到�Q�用可能出现的整数哈希��|��q�样�Q�环��׃��0开始，��着环旋转到2^31-1。这个环被��^均分成Q个分区，Q>>S�Q�这样S个机器中的每个，都能分到Q/S个分区。一个key用�Q何一�U�哈希算法映��到环上�Q�然后我们顺旉��看分区找到第一个唯一的R节点�Q�计��出一个负责这个key的R个所有机器的列表。下面这个图��d��了ABCD四个机器的一个哈希环。箭头表�C�key映射到哈希环�Q�结果给出当R�? 3时对应的保存了那个key的值的所有机器的列表�?/p>
�?

数据格式化和查询

在关�p�L��据库中的数据被分成二�l�表。在�q�里它的�{��h物是“存储”�Q�如果数据不是必��L��表，我们不��用字表结构（一个值可以包括列表，以及不需要考虑严格的关�p�d��的映��）。每个key都有一个唯一的存储，�q�且每个key都最多只能有一个倹{�?/p>

查询

伏地��系�l�支持哈希表的语义，因此一个单独的值可以一�ơ进行修改，同时可以按照主键查询。因为可以通过主键来切分，�q��得通过机器做分布式非常��单�?/p>

��h��意，虽然我们不支持一对多的关�p�，但我们支持把列表做�ؓ��|��q�样也就完成了同��L��事情�Q�因此存储一个合理数量的有关联的值成为可能。这相当于一个java.util.Map的值是一个java.util.List。在大多数情况下�Q�这样不规范来做是一个巨大的性能改善�Q�因为只需要一个单独的��盘 ��d��q�程。但对于非常大的一个一对多关系�Q�例如，而一个key映射到数千万的value�Q�，必须保存在机器上�Q�再通过游标慢吞吞地�q�一遍，�q�样子是不实�? 的。这�Q�很��见�Q�，必须��他们分成子查询或以其他方式在应用层处理�?/p>

查询��单可能是一�U�优势，因�ؓ每个查询都有非常可预��的性能�Q�很�Ҏ��服务的性能拆分成存储操作的数量份，它执行�ƈ�q�速估计负载。相反，SQL查询往往不透明�Q�而且执行计划是数据依赖的�Q�因此很难估计一条给定的SQL在实际负载下的数据中�q�能很好地执行（特别是对于一��Ҏ��的功能，既没有数据也没有�? 载的情况下）�?/p>

此外�Q�有三个操作接口�Q��得在整个存储层之上的透明层成为可能，�q�且在单元测试中使用模拟存储�Q�它的实��C��q�是一个HashMap的模拟。这样可使得单元��试在特�D�的容器或者是环境之外�Q�会更加实用�?/p>

数据模型和序列化

在伏地魔�pȝ��中，序列化是可插拔的�Q�因此你可以使用一个弄好的序列化方法同时也可以��单也写自��q��。在伏地��系�l�的最底层�Q�数据格式是只包括key 和value的字节数�l�。高层次的数据格式化是每个存储都讄��的配�|�选项�Q�处理字节到对象的�{变时�Q�依靠实现序列化�c�，所有格式的数据都可支持。这样做�? ��保客户端的字节序列正确�?/p>

通过输入在存储上的配�|�文�Ӟ��我们可以�q�泛地支持以下各�U�类�?

json–二进�Ӟ��c�d��的JSON数据模型�Q�支持列表，地图�Q�日期，布尔值和各种�_�ֺ�数字。这是唯一的一�U�可以从字节<->对象和字�W? �?lt;->对象映射的序列化的类型。这��意味着�Q�它可以和SQL�怺�作用�Q�例如通过命��o行客��L��Q�。我们当前的产品设计中��用了一�U�有�c�d��的�? 压羃的、结构检查的�c�Json格式�Q�但�q��ƈ没有�Ҏ��的状态，对于其他的应用��Y件来��_��其他的序列化机制可能会更好�?/p>

字符�?#8211;只保存原生的字条串类型。对xml数据块比较有用�?/p>

java序列�?#8211;我们的老朋友java序列化。当你保存许多的java对象之前�Q�请��认了解java序列化所提供的兼�Ҏ��保证�?/p>

protobuf–Protocol buffers是来自google的代码生成的序列化格式，�q�可能是条不错的道，如果你不需要命令行讉K��的话�?/p>

identity–�q�个�c�d��有效地禁止了序列化，��返回给你确切的byte[]

字符串和identity的序列化都是相当的不�a�自明。Protocol Buffers最好的说明应该是google来说。因此本节的剩余部分讲述json背后的机制�?/p>

json序列化类型详�?/h3>

可能会有三种状态的数据会驻留，我们希望能够在它们之间进行�{换：

在内存中的数据结构，例如一个User对象�Q?/p>

持久性和�|�络传输的字节；

文本表示�Q�DBA在检查特定的值和在线升��时不需要写新的代码是非帔R��要的�?/p>

SQL基本上就通过文本查询格式化来辑ֈ�标准化，�E�序来处理这些字�W�串和程序所使用的内部数据结构的映射关系。这是传�l�的对象关系映射的问题�?/p>

对于存储来说�Q�json是一个优�U�的数据模型，因�ؓ它支持了所有编�E�语�a�中的数据�c�d��Q�字�W�串�Q�数字，列表/数组�Q�以及对�?哈希表）。问题在于，它是本质上是��结构的。对于�Q何存储问题最常见的情况，是有使用完全相同的格式保存的N行数据（包括有相同的列）�Q�在�q�种情况下，用json是一�U�浪费，因�ؓ它每一行都带有数据的格式。同��P��我们希望能够数据的表单声明，避免错拼了列保存了脏数据。�ؓ了避免这�U�情况，我们要给每个存储上的key�? value都分配一个结构，�q�个�l�构要能描述什么允�怿�存，以及怎么栯��{成字节和从字节�{成数据。��用如下的�c�d��Q�json本��n��可以指定结构：

int8, int16, int32, int64, float32, float64,string, date, object, bytes, boolean, object, array

例如�Q�如果我希望一个存储包含字�W�串�Q�我指定那个表的�c�d��为：

"string"

��h��意，此类型的定义本��n���是有效的JSON�?br />
JAVA代码取到数据的时候就是字�W�串�c�d��的�?br />
如果我期望存储包含一个整数列表，例如�Q�会员ID�Q�我可以指定�c�d���Q?br />
["int32"]

JAVA代码���会�q�回List�?br />
如果我期望存储包含一个简单的用户对象�Q�可以定义的�c�d���Q?br />
{"fname":"string", "lname":"string", "id":"int32", "emails":["string"]}

�q�里JAVA代码���返�?Map �Q�包含了每个�l�出的key�Q�以及对应的倹{�?br />
下面是所有允许的�c�d���Q?/pre>

    
        
            type
            storable substyles
            bytes used
            Java type
            example JSON
            example type definition
        
        
            number
            int8, int16, int32, int64, float32, float64, date
            8, 16, 32, 64, 32, 64, 32
            Byte, Short, Integer, Long Float, Double, Date
            1
            “int32″
        
        
            string
            string, bytes
            2 + length of string or bytes
            String, byte[]
            “hello”
            “string”
        
        
            boolean
            boolean
            1
            Boolean
            true
            “boolean”
        
        
            object
            object
            1 + size of contents
            Map
            {”key1″: 1, “key2″:”2″, “key3″:false}
            {”name”:”string”, “height”:”int16″}
        
        
            array
            array
            size * sizeof(type)
            List
            [1, 2, 3]
            ["int32"]
        
    

从这个意义上来说�Q�类型定义是一套在标准json上的限制集，�q�样能��序列化高效执行（通过分段重复的字�D�，�q�且压羃数字�Q�，�q�且允许基础数据正确性检����?/p>
��h��意，即��一个值可能有不同的字�D�，但只支持依赖存储时定义的key来查询�?/p>
��Z��帮助�l�构的发展，�q�JSON实现了版本，允许数据的逐步�q�移的结构。数据��L��以最新的�l�构来写�Q�但是，�ȝ��时候要可以用�Q何一�U�写的时候用的结构。这样做可以在结构迁�Uȝ��时候不需要停下服务来取数据�?/p>
一致性和版本�?/h3>
当多个同步的写到多个分布的机器（甚至是多个数据中心）�Q�数据的一致性成了一个难题。传�l�的解决�q�个问题是分布式事务�Q�但�q�些都是�~�慢�Q�由于很�?
跻I��和脆��q���Q�因��Z��们要求所有服务器���可用于处理。如果应用程序运行在多个数据中心�Q�而跨数据中心操作的�g�q�将会非常地高，特别圎ͼ���M��一个算法要提及
大于癑ֈ�之五十的机器都能保证一致性将会非常困难�?/p>
其他的解军_��法是容忍不一致的可能性，�q�在��d��时解决不一致。这���是�q�里所探讨的�?/p>
应用�E�序通常只读、修攏V��更新序列时�Q�修�Ҏ��据。例如，一个用户往他的账号里增加一个email�Q�我们必���d��搞到用户对象�Q�增加email�Q�然后把
新的值写回到db。数据库的事务是�q�个问题的解��x��案，但当事务跨越多个��面的加载时�Q�有可能加蝲完也可能没完�Q��ƈ且可能在指定的时间片里完成）�Q�这�q�不
是一个真正的选项�?/p>
当所有的update不存在时�Q�给定的key的值是一致的�Q�所有的��L��作都���会�q�回一个相同的倹{��在只读世界中，数据被以一致性的�Ҏ��创徏�q�且�怸�
改变。当我们增加了写操作、复�Ӟ��会遇到问题：现在我们需要更新在多个机器上的多䆾数据�Q��ƈ且要让所有的东东都保持一致。在机器故障面前�Q�这样做很困难，
在网�l�分区的面前�Q�这样做被证明是不可能的�Q�例如分区的情况�Q�A和B可以互通，C和D可以互通，但是A、B与C、D�q�不能互�?�Q��?/p>
下面有些�Ҏ���Q�靠不同的保证和折衷性能来达��C��致性：
两步提交–�q�是一个锁协议�Q�包括在机器之间两轮的协作。它是完全一致的�Q�但不能兼容出错�Q�而且很慢�?/p>
Paxos式的��p��–�q�是一个在一个��g��达成��p��的协议，能够更多地兼容出错�?/p>
��M���?#8211;前两�U�方法防止永久不一致。这�U�方法在写的时候写入所有的不一致版本，在读的时候检���所有的冲突�q�且解决问题。这不涉及协调工作，是完全兼容出错的�Q�但可能需要额外的应用�E�序逻辑来解军_���H��?/p>
我们使用版本和读修复。这有一个最好的可用性保证，和最高的性能�Q�N�ơ复制只需要W�ơ的�|�络往�q�写�Q�W可以配置成小于N的��|��。两步提交需�?N�ơ的��d���|�络往�q�。Paxos变化有很大不同，但相比两步提交也差不多�?/p>
许多的细节，以下文�g借自亚马�?/p>
�q�里有一些很好的写关于这个问题的东东�Q?/p>

    Consistency in Amazon’s Dynamo
    Paxos Made Simple
    Two-phase commit
    The meaning’s of eventual consistency (by Amazon’s CTO Werner Vogels)

分布式系�l�中的版�?/h3>
一个简单的版本控制�pȝ��只是乐观锁定–我们保存一个唯一的计数器或者是旉���值在每一片数据上�Q��ƈ且只允许更新数据的时候才能更新这个倹{�?/p>
在集中式的数据库中这�q�行良好�Q�但在一个机器时好时坏、复刉���要时间的分布式系�l�中�Q�它���挂了。对于这�U�用法，一个单一的��g��能保存��够的写入历史�Q�以便我们丢弃老的版本。考虑下面的一�p�d��指��o�Q?/p>
#两个机器同时取一个相同的�?br />
[client 1] get(1234) => {"name":"jay", "email":"jay.kreps@linkedin.com"}

[client 2] get(1234) => {"name":"jay", "email":"jay.kreps@linkedin.com"}



#1客户端作了一�ơ对name的修改�ƈ且put了一�?br />
[client 1] put(1234, {"name":"jay kreps", "email":"jay.kreps@linkedin.com"})

#2客户端作了一�ơ对email的修改也put了一�?br />
[client 2] put(1234, {"name":"jay", "email":"jay.kreps@yahoo.com"})



#现在我们有了以下的冲�H�版�?br />
{"name":"jay", "email":"jay.kreps@linkedin.com"}

{"name":"jay kreps", "email":"jay.kreps@linkedin.com"}

{"name":"jay", "email":"jay.kreps@yahoo.com"}
在这个模型中�Q�后面两�ơ的写入使原��g��再可用（因�ؓ是基于原值的修改�Q�。尽���如此，我们没有规则来告诉服务器是要抛弃对name的修改，�q�是对email的修攏V��因此我们需要一个版本系�l�来允许我们������重写和抛弃老版本内容，同时也要能检���冲�H��ƈ且让客户去解冟�?/p>
解决�q�个问题的一个答案是靠传说中的向量时钟版本。一个向量时钟在每次写机器的时候都保持一个计数器�Q�在两个版本冲突和一个版本成功或者是比另一个新的时候，我们能计���它�?/p>
向量旉���是一个服务器和版本对的列表：
 [1:45,2:3,5:55]
从这个版本能够看出对那个写的数字来说�q�是一��C��服务器�?/p>
对i来说v1�l�承自v2�Q?em>v1_i > v2_i。如�?v1 > v2�?em>v1 < v2都不满���Q�那么v1和v2同现�Q�也���是冲突了。下面是两个冲突的版本的例子�Q?/p>
	[1:2,2:1]

[1:1,2:2]
我们的版本结构定义了一个偏序，而简单的乐观锁是一个全序�?/p>
路由参数
��M��持久存储的系�l�都需要回�{�的一个问题就�?#8220;我的东西存在哪里”。如果我们有一个集中的数据库，�q�是一个简单的问题�Q�因为答案��L��“它们在数据库
里的某个地方”。在一个键分离的系�l�中�Q�可能在在多台机器有所需要的数据。当我们执行��L��作的时候，我们臛_��需要从一台机器去取数据，当我们写的时候，�?
们需要写到N个复制去�?/p>
因此�Q�有三个参数的问题：

    N - 复制的次�?/li>
    
R - ��L��据的节点�?/li>
    
W -写成功的分区�?/li>

��h��意，如果R + W > N能够保证我们“��L��们所�?#8221;。如果w=0�Q�那么写�?
作是不阻塞的�Q�写成功是没有保障的。取操作和删除操作既不是立即一致的�Q�也不是孤立的。这意思是��_��如果一个put/delete操作要成功，需要W个节
炚w���q�行了同��L��操作�Q�然而，如果写失败了�Q�这栯���是因为极���数的节点能够马上完成操作）�Q�那状态就是不���定的了。如果一个put/delete操作成功
了，那最后这个值都会变成最�l�的��|��但如果没有成功的�q�个值将会失效。如果客��L��要确保这个状态，必须在一�ơ写操作��p�|后再发�v一�ơ写操作�?/p>
持久�?/h3>
持久存储我们默认使用JAVA版的BDB。MYSQL和内存存储也同样支持。要��d��一个新的持久化实现�Q�你需要实现put\get\delete�Q��ƈ且要提供一个本地存储的值的�q�代�E�序�?/p>
扚w��计算数据支持
数据最密集的存储需求之一是在我们的系�l�批量计���关于成员和内容的数据。这份工作常常涉及到实体之间的关�p�（比如说有关系的用戗���相关的新闻文章�{�）�Q�那�q�样N个实体就会增长出N²�?
关系来。在LinkIn的一个实例是用户�|�络�Q�如果要为所有用户准���保存会�?2TB的范围。批量数据处理通常比随�����问更有效率，也就意味着扚w��处理�?
数据可以被实际系�l�简单地讉K��。Hadoop极大地扩充了�q�一炏V��我们正在开源伏地魔的后端持久化的东东，它支持非帔R��效的只读访，�q�能解徏立、发布以�?
���理大量的、只��d��指计���数据集�{�许多痛苦的事情�?/p>
处理扚w��计算的大多数痛苦来自于从数据仓库或者是hadoop传输数据到线上系�l�的“推�?#8221;的过�E�。在传统DB�q�意味着在线上机器重建新数据的烦
引。做��C��百万计的insert和update操作一般不会所有都很高效地执行�Q�通常在一个sql数据库里数据需要被布到一个新的表中，当新表徏立完毕，
再交换回来替换当前数据。比数百万计的单独的update操作来说�q�样做更好，但是�Q�当同时服务于真实环境时�Q�这仍然意味着�U�上�pȝ��现正为新的数据集�Q�或
者是performa�Q�兴�����多GB的烦引。仅此一点可能需要数���时或数天，�q�可能会毁了实时查询的性能。有人想搞定�q�个问题�Q�通过���数据库�U�别�?
swap换出�Q�比如说�Q�有一个在�U�的DB和一个离�U�的DB�Q�进行交换）�Q�但�q�要求做许多事�ƈ且意味着你将只有一半的����g正在使用。伏地魔依靠���可能的��ȝ��
重徏自��n的烦引（在hadoop之上或者其他）�Q�然后简单地推送给�U�上机器�q�且透明地进行交换�?/p>
参考文�?/h2>

      Dynamo: Amazon’s Highly Available Key-Value Store  �?	 This is the original!
      Time, Clocks, and the Ordering of Events in a Distributed System  �?	 This is the template for the versioning system
      Eventual Consistency Revisited 
    Very interesting discussion on Werner Vogels’ blog on the developers
    interaction with the storage system and what the tradeoffs mean in
    practical terms.
     Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services �?Consistency, Availability, Partition-tolerance choose two.
     Berkeley DB performance �?A somewhat biased overview of bdb performance.
     Google’s Bigtable �?For comparison, a very different approach.
      One Size Fit’s All: An Idea Whose Time Has Come and Gone  �?Very interesting paper by the creator of Ingres, Postgres and Vertica
      One Size Fits All? - Part 2, Benchmarking Results  �?Benchmarks to go with the above paper
      Consistency in Amazon’s Dynamo  �?A good blog post on Dynamo
      Paxos Made Simple 
     Two-phase commit �?Wikipedia description.



wz.xjtu 2010-01-18 22:45 发表评论

type	storable substyles	bytes used	Java type	example JSON	example type definition
number	int8, int16, int32, int64, float32, float64, date	8, 16, 32, 64, 32, 64, 32	Byte, Short, Integer, Long Float, Double, Date	1	“int32″
string	string, bytes	2 + length of string or bytes	String, byte[]	“hello”	“string”
boolean	boolean	1	Boolean	true	“boolean”
object	object	1 + size of contents	Map	{”key1″: 1, “key2″:”2″, “key3″:false}	{”name”:”string”, “height”:”int16″}
array	array	size * sizeof(type)	List	[1, 2, 3]	["int32"]

Selenium – Acceptance Testing Tool

wz.xjtu — Sun, 10 Jan 2010 16:02:00 GMT

周末�Q�由于项目需要，作�ؓ一个开发者，我决定研�I�一下自动化��试�Q�因为最�q�，我们要统计User Story所带来的Defect的个敎ͼ�所以Dev要在开始的时候就要准备自己在自己的开攄��境上多测试几遍�?/p>

公司一直在用QTP��试�Q�用VB��d��脚本�Q�额的神呀�Q�那语言我玩不�{�Q�所以还是选择了Selenium�Q�因为它提供了Java的driver�Q�还是不错的。先装了一个Firefox插�g�Q�录制了一些脚本，拯��到JUnit里面�Q�竟然不可以�q�行。网上Google了很久没有找到好的方法，一斚w��是由于我们的�q�个frame写的不是怎么标准�Q�另外一个方面估计是�|�络太慢了。所以我加上了一个waitForPageLoad�Q�竟然神奇的可以通过了。不知道��Z��么，但是�q�样的脚本的东西�Q�我也懒得去理解��Z��么�?/p>

一直想怎么把东西做到超�U�的自动化，自动化达到在一个地方输入，另一个地方就可以验证了，最后决定，把输入数据写到Excel里面�Q�中间的数据存储到数据库中（必须的，其实�q�是可以在Excel里面存着�Q�不�q�懒得这样存�Q�访问Excel不是俺的强项�Q�。最后去�Ҏ��q�些中间的结果去验证最后的输出是不是正��?/p>

��x��很好�Q�开始做了，遇到了第一个问题，输出是简单的test, 怎么去验证这个test是不是正��呢�Q?�ȝ��上��l�搜索，发现用xpath能解册��个问题，最后用以下的path解决了这个东东，如下�Q�xpath=//div[@id='reponseFormHeader']/div/table/tbody/tr[1]/td[1]�Q?可以用一个firefox差�hxpather��d��现这个东东，�q�且写上去，也解决了�l�这些没有必要的text写上一个Identifier的问�?�Q�QA一直强调要�l�这些Text都加上一个ID方便自动化测试）�?/p>

最后选择把中间结果写在MongoDB里面�Q�原因很��单，Schemaless和Map driven的DB�Q�我仅仅需要把Map往里面一扔，后面的就不用��了。简单粗��_��但是又是很实用�?自动化测试不是很难，但是要用心去做，QA也不是很�Ҏ��Q�很多东西，资料不多�Q�写��h��也很奇怪�?/p>

最后说说敏捯��Y件开发，什么时候写自动化测试呢�Q?看网上有��Q�QA��试�?0%的要手工��试�Q�我比较不同意，我认�?0%都可以进行自动化��试。自动化��试是QA可以在很早就可以开始的�Q�Mockup出来后就可以开始了。只要我们把自动化测试当成一回事��d��Q�可以省��d��多很多的effort�Q�不�׃ؓ一�U�敏��L��快捷之�\�?/p>

wz.xjtu 2010-01-11 00:02 发表评论

NoSQL & MongoDB

wz.xjtu — Sat, 19 Dec 2009 17:31:00 GMT

最�q�在准备一个小的讨��Z��Q�题目可以自定，我感觉这个MongoDB�q�是蛮有意义的，值得讨论一下。做了一些slides�Q�节选如下，

What is NOSQL

NOSQL != NO SQL
NOSQL = Not Only SQL

What do we want?

Performance
Scalability
Flexibility

Two important theories

CAP (Every system only can match 2 of them, NoSQL supports to match A and P)

Consistency
Availability
Tolerance to network Partitions

ACID & BASE(Anti-ACID)

ACID – RDBMS use this theory
BASE – Anti-ACID and NoSQL use it.

Compare with current RDBMS with NoSQL solutions

RDBMS are working w/ relationship, and the relationship are not easy to extend (scalability)
RDBMS software are implemented as a big system with additional function which make the database slow
ACID can make the data perfect, but it does not care about the performance.
Most of NoSQL solutions are schemaless
Make the simple things simple (for example: log)

Upcoming solutions of the software.

NoSQL is nibbling up the SQL solutions.
NoSQL + SQL = Data solution

What is the issues we are meeting now?

Performance
Document generation (PDF/Email)
Image solutions

Compare with MySQL

Performance is better
Scalability is excellent

MongoDB vs CouchDB

Similar solutions.
Performance of MongoDB is better than CouchDB
MongoDB is better at web solutions.

Three words about the MongoDB

NOSQL –> RDBMS
BSON
GridFS

How to use it?

1 Click install
2 clicks helloworld using java client
types which mongo supports now
Collection oriented database.
index using with MongoDB
GridFS for the big file

Sharding with Mongodb

How to shard?
Scalability is excellent.

Upcoming solutions for Mongodb

ORM with MongoDB java client
Performance tuning with java client

What can Mongodb do? cannot do?

Document
Image store
Real-time Analysis
Caching

Upcoming simple desgin with Mongodb.

wz.xjtu 2009-12-20 01:31 发表评论

wz.xjtu — Wed, 09 Dec 2009 03:44:00 GMT

�q�两日对Cache研究了一点，��M��一些源代码�Q�自�׃��写了点code�Q�借此假期也算是休闲加学习了�?br />
什么时候用Cache�Q?br />
在系�l�中�Q�如果要考虑�pȝ��的性能�Q�我们最好都使用Cache�Q�在各个层次上都用上Cache�Q�这��L��话可以尽最大程度的减少数据库的压力。估计现在的�pȝ��都在分层�Q�vo�Q�po�Q�do�Q�domain object�Q�；我们可以把这些东西能�~�存的都�~�存��h��Q�当然要�Ҏ��具体�pȝ��具体分析�Q�Cache多长旉��Q�Cache多少东西�Q��?br /> Tip�Q�公司的�pȝ��中，�׃��用一台数据库�Q�数据库的压力一直都是一个很大的问题�Q�timeout�Q�too many connection�Q�等问题应接不暇�?br />
怎么用Cache�Q?/strong>

估计每个公司都有自己的Cache framework�Q�简单的��是几个�c�，�ȝ��的可以做个小的framework��d��装已有的opensource的cache provider。很多opensource的cache provider�Q�例如：oscahe�Q�ehcache�Q�都�Ҏ��能�q�行了优化，所以肯定性能比Map好很多，但是肯定不能拿过来就用，那样的话每次调用的时候太�q�于�ȝ��Q�写很多的类�Q�很多的�Ҏ��。所以说包装是很重要的，��包装成一个Bus一��L��东西�Q�CacheBus�Q�叫做CacheManager比较好）�Q�这��L��话就可以在各个层�ơ都向上面写和读了�?br />
Tip�Q?Cache��是key value�Q�我们只要能写好key-value怎么写都可以的。这样也让系�l�变得简单实用（更能体现OO�Q?br />
Cache Provider

Oh�Q�这斚w��太多东西了，oscache�Q�貌似停止开发了�Q�，ehcache�Q�被terracotta收购了，前途不错）�Q�treecache�Q�jbosstreecache大而全�Q�，memecached�Q�很火了很久�Q�，nosql相关的东西（couchdb�Q�mongodb�Q�。Oh...不能忘记Map

其实用什么都可以�Q�关键是用好�Q�一般的解决�Ҏ��很简单，既然你要在系�l�中用Cache�q�且想风风火火的用一下，那就来个二��Cache�Q�第一�U�用本地Cache�Q�速度快，但是东西不能太多�Q�，�W�二�U�，用memcached �Q�能存放大的东东�Q�便宜）。第一�U�Cache�?分钟�Q�自��p��调试��定旉��Q�，自动收割到第二��Cache中�?br />
什么在�W�一�U�Cache中永�q�存�z�？ ��的�Q�永�q�都要用的，例如用户信息�Q�Site信息�Q�一些template�{��?br />
特别��一�?u>nosql �q�方面mongodb和couchdb做的很好�Q�在document相关的东西，可以�~�存到这里面�Q�例如：�pȝ��要在半天后发一��邮�Ӟ��q�封邮�g所有的数据现在内存中都有，比较大的东东。到时候再��d��复杂�Q�太��费内存了。怎么办呢�Q?攑֜�一�U�缓存肯定不合适，攑֜�二��~�存�Q�要存活半天呀�Q�太��费旉��了，存在数据库里面，增加压力�Q�也不是很好�Q�NOSQL的mongodb和couchdb��可以解册��个问题，�q�个schemaless的数据库�Q�可以让你轻杄��存�Q何的东西�Q�性能不错�Q�。（自己要优化一下代码）

举例�Q?br />
Annotation

@Documented
@java.lang.annotation.Target(value={java.lang.annotation.ElementType.TYPE})
@java.lang.annotation.Retention(value=java.lang.annotation.RetentionPolicy.RUNTIME)
public @interface CacheIt {
    //Provide the cacheProvider which will be use to cache the object which is just used to replace the xml configuration.
    public String cacheProvider();
    //Used to define how long the cache need to be provide
    public long cacheDuration();
    //The level of the cache, define, level1, level2 (If there is level2 defination in the annotation, the cache will be kick to level2 after the timeout in the level1)
    public int cacheLevel();

}

一个VO的configuration

@CacheIt(cacheProvider="com.javaeye.wmwm.cache.impl.HashMapCacheProvider", cacheDuration=10000, cacheLevel=1)
public class TestVo {

    @Identifier
    public String key;

    public String test;

    public String getKey() {
        return key;
    }

    public void setKey(String key) {
        this.key = key;
    }

    public String getTest() {
        return test;
    }

之后写一个CacheManager

public class CommonCacheManager implements CacheManager {
    /**
     * Cache the object into the cache.
     *
the provider is defined in the annotation in the related Vo/PO/DO
     *
the key is annotated by the Identifier.
     * @param object represents the input objects which needs to be cached.
     */
    public void cache(Object object) {
        Cache cache = CachePool.getInstance().loadCache(object.getClass());
        Object key = new CacheKeyFinder().find(object);
        cache.put(key, object);
    }

    public Object load(Class clazz, Object key) {
        Cache cache = CachePool.getInstance().loadCache(clazz);
        return cache.get(key);
    }
}

wz.xjtu 2009-12-09 11:44 发表评论

亚洲av无码专区国产乱码在线观看,亚洲欧洲成人精品香蕉网,国产精品久久亚洲一区二区

NOSQL- Questions

MongoDB之一NOSQL

LinkIn��Z��Dynamo设计的系�l?[ZZ]

Key-Value存储

�~�点

优点

�pȝ��架构

数据格式化和查询

查询

数据模型和序列化

路由参数

持久�?/h3> 持久存储我们默认使用JAVA版的BDB。MYSQL和内存存储也同样支持。要��d��一个新的持久化实现�Q�你需要实现put\get\delete�Q��ƈ且要提供一个本地存储的值的�q�代�E�序�?/p>

扚w��计算数据支持

Selenium – Acceptance Testing Tool

NoSQL & MongoDB

What is NOSQL

What do we want?

Performance

Scalability

Flexibility

Two important theories

CAP (Every system only can match 2 of them, NoSQL supports to match A and P)

ACID & BASE(Anti-ACID)

ACID – RDBMS use this theory

BASE – Anti-ACID and NoSQL use it.

Compare with current RDBMS with NoSQL solutions

RDBMS are working w/ relationship, and the relationship are not easy to extend (scalability)

RDBMS software are implemented as a big system with additional function which make the database slow

ACID can make the data perfect, but it does not care about the performance.

Most of NoSQL solutions are schemaless

Make the simple things simple (for example: log)

Upcoming solutions of the software.

NoSQL is nibbling up the SQL solutions.

NoSQL + SQL = Data solution

What is the issues we are meeting now?

Performance

Document generation (PDF/Email)

Image solutions

Compare with MySQL

Performance is better

Scalability is excellent

MongoDB vs CouchDB

Similar solutions.

Performance of MongoDB is better than CouchDB

MongoDB is better at web solutions.

Three words about the MongoDB

NOSQL –> RDBMS

BSON

GridFS

How to use it?

1 Click install

2 clicks helloworld using java client

types which mongo supports now

Collection oriented database.

index using with MongoDB

GridFS for the big file

Sharding with Mongodb

How to shard?

Scalability is excellent.

Upcoming solutions for Mongodb

ORM with MongoDB java client

Performance tuning with java client

What can Mongodb do? cannot do?

Document

Image store

Real-time Analysis

Caching

Upcoming simple desgin with Mongodb.

持久�?/h3>
持久存储我们默认使用JAVA版的BDB。MYSQL和内存存储也同样支持。要��d��一个新的持久化实现�Q�你需要实现put\get\delete�Q��ƈ且要提供一个本地存储的值的�q�代�E�序�?/p>