显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

风轻扬

活着就是为了追求幸福

 
 
 
 
 
 

Amazon DynamoDB详解

2012-1-19 13:17:40 阅读7726 评论2 192012/01 Jan19

今早Amazon发布了DynamoDB,作为AWS服务的新成员,提升了AWS管理结构化数据的能力。总体来说,DynamoDB是基于Amazon Dynamo技术实现的可伸缩性和可用性优异的NoSQL数据库托管服务。

我们知道,Amazon搞了一个很牛的KV数据库Dynamo,可伸缩性、可用性和性能稳定性非常好。但Dynamo推出后并没有在Amazon内部被广泛接纳,主要原因是Dynamo是作为软件系统提供给开发者,要用得部署各自的Dynamo集群,安装管理成本很高。后来Amazon推出了SimpleDB托管服务(Managed Service),没有部署和管理开销,很受欢迎。用户也很欢迎SimpleDB灵活的数据模型。

但是SimpleDB也存在几个主要问题:

1、可伸缩性有限。因为批量操作只有Domain数据在一个节点上才能有效完成,导致单个Domain最大只能支持到10G;

2、性能不可预期。SimpleDB为了方便使用,所有属性都建索引,都可以搜索,这导致更新性能不可控,如果属性一多或数据量一大更新就很慢;

3、最终一致性难以使用。一开始SimpleDB只提供最终一致性读,开发者觉得开发应用时很麻烦,几年后SimpleDB才提供了一致性读选项;

4、Machine Hours计费很难用;

根据这些经验,Amazon重新设计了DynamoDB。采纳了SimpleDB中成功的托管服务形式及灵活的数据模型,并从一开始提供了一致性读功能。限制了系统的功能,只能通过主键去操作记录,不能进行批量更新,这使得系统可以保证可伸缩性及任何时候的高性能。另外,全面的使用SSD来提升系统性能。

作者  | 2012-1-19 13:17:40 | 阅读(7726) |评论(2) | 阅读全文>>

Hadoop++:Hadoop的局部性能改良

2011-12-16 16:48:35 阅读2941 评论0 162011/12 Dec16

Hadoop++是对Hadoop Map Reduce的非入侵式优化,通过自定义Hadoop框架中的split等函数来提升,提升查询和联接性能。 项目由德国Saarland大学Jens Dittrich教授主持。项目主页是 http://infosys.uni-saarland.de/hadoop++.php

Hadoop++对Hadoop的优化主要是Trojan Index、Trojan Join和Trojan Layout三方面。

1、Trojan Index

Trojan index的核心是将数据组织成依次由数据、索引、Header和Footer这四部分构成的split,其中Footer是split的分界符,最后一个Footer一定位于文件末尾。索引构建时由MapReduce完成排序。查询时split函数从文件末尾开始根据Footer信息解析出各个split,itemize函数根据搜索范围条件快速定位满足条件的内容。

以数据库技术类比,Trojan Index类似于索引组织表。

2、Trojan Join

Trojan Join根据联接属性将来自多表的相关记录分到一个split,组织成类似于Trojan Index的结构,itemize出来的记录同时包含了参与联接的双方的属性,这样不再需要在查询时再根据联接属性用map/shuffle/reduce来计算联接。

作者  | 2011-12-16 16:48:35 | 阅读(2941) |评论(0) | 阅读全文>>

Hadoop执行过程

2011-12-15 16:31:56 阅读5378 评论0 152011/12 Dec15

根据Hadoop++论文的描述,Hadoop执行过程分为Load、Map、Shuffle、Reduce这四个阶段,可以看成是一个由split、itemize、map、reduce等10个函数或算子组成的DAG。其中每一个函数或算子,都可以提供自定义的实现以此来扩展Hadoop的功能或优化性能。

1、Load阶段

输入数据经block函数,按配置的block大小切分成多个block,每个block按配置存储多个复本,Hadoop尽可能保证不同复本存储在不同结点上。

2、Map阶段

每个mapper子任务读取一个split。每个split包含一个或多个block,是一个逻辑单元。split函数决定怎么划分split。split通过itemize函数分割成记录,框架对每条记录调用map函数。map的输出由mem函数切割成多个spill。spill中的每条记录由sh函数决定输出到哪个reducer,为每个reducer产生一个逻辑分区。每个逻辑分区根据cmp函数排序并根据grp函数分组,再根据combine函数进行预reduce处理后存储到文件。如果一台mapper机上对某个reducer产生了多个上述处理所得的spill文件,则进行合并,合并时同样执行排序、分组和combine流程。

3、Shuffle阶段

每个mapper产生的spill文件再次经过sh函数分派给每个reducer。每个reducer从每个mapper接收给它的数据,如果能在内存中合并就在内存中合并,否则接收后先存储,等全部完成后再来合并。最终为每个reducer准备好一个待处理的文件。

作者  | 2011-12-15 16:31:56 | 阅读(5378) |评论(0) | 阅读全文>>

Amaon AWS's EBS

2011-10-20 20:37:05 阅读4688 评论0 202011/10 Oct20

EBS是Elastic Block Service的简称,简单的说是可以像普通硬盘一样挂载用的裸块设备。容量1G到1T,属于一个Availability Zone的EBS只能被挂载到同一AZ的EC2主机。一个EBS设备在同一时候只能接到一台EC2实例。

EBS在同一AZ内部复制,但不像S3那样跨AZ复制。因此EBS的可靠性高于单盘,但不是绝对可靠。具体的可靠性取决于容量和最后一次snapshot之后修改的数据量。据官方数据,最后一次snapshot之后修改的数据量小于20G时,年故障率为0.1% – 0.5%。

可以创建存储于S3的快照。这些快照不能通过普通的S3 API操作,只能用于恢复EBS卷。快照是块级增量的。快照不保证一致,如果想获得一致快照,请先停止对EBS的所有写操作。

== 关于EBS的实现机制和性能

据很多用户报告EBS的性能一般也不太稳定。据估计EBS没有用NetApp、EMC等高端存储,而是基于经济型服务器的软件RAIN(Redundant Array of Inexpensive Nodes)的方式来构建。 [1] EBS是通过EC2实例的一般为1G带宽的以太网接入。据第三方测试,EBS的性能不太稳定,最好的时候IOPS可以高至70~80K,每秒7K次seek,但差的时候IOPS可能只有200。[2]创建快照的速度一般在20MB/s左右。[3]

== 参考资料

1、http://perfcap.blogspot.com/2011/03/understanding-and-using-amazon-ebs.html

作者  | 2011-10-20 20:37:05 | 阅读(4688) |评论(0) | 阅读全文>>

Amazon SimpleDB

2011-10-19 14:32:13 阅读4626 评论0 192011/10 Oct19

4年前SimpleDB刚推出的时候我写了一篇日志《一条腿的Amazon SimpleDB路难行》,是说SimpleDB当时还不支持排序,功能严重残缺。现在SimpleDB早已支持排序了,而且从那之后也加了很多功能。这几天在看AWS,顺便把SimpleDB再记录一下。

一、数据模型

数据分为多个domain,domain包含多个item,每个item包含多个属性/值对,值可以是一个集合,每个单值都是字符串类型。domain类似于表,item类似于行。无固定模式。没有Version的概念。

不需要显式建索引,自动索引。据推测相当于每个属性上都建了索引,无法实现多属性联合索引:猜测where a = xxx and b = xxx的执行过程是做列表的intersect。

二、操作

操作分以下几类:

1、创建/删除/枚举domain

2、PutAttributes/BatchPutAttributes/DeleteAttributes/BatchDeleteAttributes/GetAttributes。支持有条件的UPDATE/DELETE,实现CAS语义。通过NextToken可以一小批一小批的遍历大量数据,类似于翻页。

3、SELECT:类似于数据库单表SELECT,聚集函数只

作者  | 2011-10-19 14:32:13 | 阅读(4626) |评论(0) | 阅读全文>>

Oracle NoSQL Database

2011-10-19 11:57:55 阅读5402 评论2 192011/10 Oct19

近日Oracle提供了不久前公布的NoSQL数据库的下载,目前只有企业版,开源的社区版还没提供,也就是说还看不到源码。不过根据文档也能大致了解这个NoSQL数据库怎么样。快速看了看,总结如下。

一、数据模型

key包含一到多个major key component和零到多个minor key component,组合起来唯一标准一条记录。key component为Java String,按对应encoding排序。value则是字节流。key和value的大小都没有严格限制。

记录还有版本号,每次更新都产生唯一的新版本号。在put/delete/get操作时,都可以指定要版本号,其中get时用于指定要读的版本,而put/delete指定版本号是指当记录的最新版本还是指定版本时才更新,用于实现原子Compare-and-Swap语义。版本号应该至少是在一个partition内部是全局唯一的。

二、分区与架构

两层架构,客户端直接到存储节点。核心架构是Replication Node和Replication Group,一个Replication Group包含一个可写的Master Replication Node和多个只读的replica。master失败时会failover到某replica。现在发布的版本暂时还不能动态调整存储节点个数,以后会加。

数据按major key hash分区到partition。这样拥有相同的major key仅仅minor key不同的多条记录一定在同一par

作者  | 2011-10-19 11:57:55 | 阅读(5402) |评论(2) | 阅读全文>>

Clustrix Sierra关系数据库集群

2011-8-29 17:58:30 阅读4287 评论5 292011/08 Aug29

Clustrix的Sierra数据库集群引擎是一个share-nothing架构的可伸缩关系数据库集群。官方宣传的非常诱人,说是功能像集中式关系数据库一样强大,可伸缩性超强,不需要规划什么数据分区,可用性也非常高。简直是集SQL和NoSQL的优点于一身。据说最近阿里云的RDS服务很可能是基于这个,因此仔细去了解了一下,发现架构上属于软硬一体化的路子,感觉架构上还是有些问题,对硬件的要求也不低。

Sierra前端采用MySQL协议,但本身跟MySQL没有任何关系。系统是一层架构,每个节点既负责处理逻辑,又负责数据存储,没有做处理和存储分层。

表数据根据某些可指定的属性或属性组合Hash/Range分区划分为slice。slice有多个复本保证可靠性。没有专门的主复本机或从复本机,每个节点都可以存储任意复本。slice的数目与表大小有关,太大时分裂,也可以由用户来设slice的数量。slice可以在集群中在线移来移去,新节点上线时分配一些slice给它。每个slice有个主复本,只有主复本处理读操作并有缓存,写操作要更新所有复本。索引是一张内部的独立的表,即全局索引,根据索引键值分区。没有局部索引。全局索引的优点是方便支持唯一性和外键。

每个节点上都有分区信息,查询提交到任意一个节点,Database Personality Module负责将查询分解路由到多个节点并发执行。简单操作直接定位一个节点处理就行了,可伸缩性应该非常不错。复杂查询尽可能的将操作下推给数据所在节点,减少节点间交互。

并发控制使用MVCC,保证事务ACI

作者  | 2011-8-29 17:58:30 | 阅读(4287) |评论(5) | 阅读全文>>

NTSE最近的进展及随想

2011-8-10 18:20:54 阅读4391 评论9 102011/08 Aug10

一、NTSE 0.7发布

几天前NTSE 0.7发布了,核心功能有基于字典的记录压缩和在线建索引两个。在线建索引功能能够在不影响事务并发读写时建索引,并且是由基于排序的高性能索引创建算法,对提高数据库的可用性很有帮助。在线建索引比较简单,重点要说的是基于字典的记录压缩。首先来看模拟博客日志模块的blogbench测试结果。

上图是NTSE 0.7和NTSE 0.5及InnoDB的性能对比,纵坐标是TPS,横坐标是内存占数据量的比例。可以看出NTSE 0.7比0.5在小内存配置下又有了近一倍的性能提升。与InnoDB相比小内存时的吞吐率达到15倍以上。第二个数据是压缩后记录占用的存储空间也节约了将近一半。这样,对部分应用无论从任何角度考虑,用NTSE 0.7都可以比用NTSE 0.5时节约一半硬件资源。相比InnoDB,大约可以只用1/4的硬件。这一结果可谓非常理想。看来记录压缩对提升WEB应用的数据库性能还是很有帮助的。

NTSE的记录压缩基于表全局字典来做,不同记录和页面中的记录都共享一个字典,多个属性可以组合压缩成一个单词,一个属性内部也可能被切分成多个单词来压缩,压缩率远高于InnoDB的页面级zip压缩(只能说InnoDB的页面级zip压缩太烂了)。在内存中也是压缩格式因此能够显著的优化缓存效率减少IO。压缩和解压以记录中的属性组为单位(默认记录中所有属性都是一个属性组),压缩和解压都非常快并且粒度非常细,因此启用压缩对性能的影响非常小,纯内存blogbench测试开不开压缩对吞吐率几乎没影响。

二、NTSE又添新应用

作者  | 2011-8-10 18:20:54 | 阅读(4391) |评论(9) | 阅读全文>>

基础系统软件的价值

2011-7-21 14:59:29 阅读7366 评论16 212011/07 July21

盛大推出云计算服务,看起来想做类似于Amazon AWS的IaaS。看了一下,结构化数据管理的功能很弱,只有最简单的Key-Value服务,只有GET/PUT/DEL,没有条件更新没有锁,没有扫描,这让我觉得很不靠谱。结构化数据管理是99.9%的应用都需要的,而基于盛大云这样简单Key-Value来开发应用是很麻烦的事。比如:

1、如果把多个实体属性拼起来,没法索引,效率也不高;如果分开,那经常得用很多个GET;

2、没有索引和扫描,各种数据列表都不容易,比如按时间/阅读次数/评论次数排序的文章列表,你要用一个KV来维护ID列表,这会涉及复杂逻辑(比如按阅读次数排序的列表就不好搞),而且还会数据不一致;

3、刚说到阅读次数,好把,基于盛大云要维护一个会被并发更新的准确的计数是不容易,很不容易,简单到文章阅读次数,评论次数,好友个数等等。因为没有条件更新和并发控制,你把值读出来,+1再存回去,一并发就错了。

总之,这种最简单的Key-Value系统,我一直认为是对系统实现者来说是福音,但对系统使用者来说是绝对坑到祖宗的玩意。如果盛大云就只有这把刷子,没几个开发者愿意用。还好盛大云据说会推出MongoDB服务,这还算有点靠谱。

我越来越觉得这不是正确的做事方式。我觉得做基础系统软件,是希望能够让用户(也就是基于这些基础软件来做应用的人)能够很简单的做出正确、稳定并且高效的应用。很简单的做出应用是指开发效率高;系统不出错并且稳定,这几点是最重要的,高效是在满足前面这几点之后再追求的。系统常出错或不稳定,性能再高也没用,这点可能不用多说。但开发效率的重要性,是工作之后再深刻的体会到的。

作者  | 2011-7-21 14:59:29 | 阅读(7366) |评论(16) | 阅读全文>>

分布式事务性能分析

2011-7-13 17:18:28 阅读5793 评论12 132011/07 July13

这两年来,随着NoSQL系统、CAP理论和Eventual Consistency的大热,关于分布式操作要保证强一致还是弱一致性的讨论络驿不绝。双方各执一词,倾向实现强一致性的一方认为弱一致性满足不了应用开发的需要,倾向实现弱一致性的一方则认为保证强一致性将导致系统性能与可伸缩性难以接受。弱一致性能否满足应用开发的需求这一点由应用特征决定,难以一概而论,但强一致性对系统性能、可伸缩性和可用性的影响则是可以作技术分析的。奇怪的是,找了很久,也没找到对这一问题的深入分析,决定自己来做一个。

对于分布式操作,一般来说有以下两种实现选择:

1、    在每个节点上使用单独的事务,只实现弱一致性。

2、    使用2PC保证强一致性。即分布式事务协调者先要求所有参与节点PREPARE,大家都说PREPARE成功后,再要求所有节点COMMIT。只要有一个节点PREPARE不成功,大家都要回滚。这样参与者要强制写两次日志,协调者在决定要COMMIT时也要强制写一次日志。

首先,假设用户发起分布式操作的速率为TpS(Transactions per Second),每个分布式操作平均会操作K个节点。在每个节点上,平均要操作RpT(Rows per Transaction)条记录,而操作每条记录平均要用时TpR(Time per Row),这样在每个节点上事务操作的执行时间为:

    TExec=RpT×TpR

另外,设定以下参数:

作者  | 2011-7-13 17:18:28 | 阅读(5793) |评论(12) | 阅读全文>>

Facebook Open Compute:如何实现一个高效低成本的数据中心

2011-7-8 9:28:26 阅读5498 评论1 82011/07 July8

Facebook Open Compute(FOC)是一个很无私的项目,据说一个团队辛辛苦苦搞了18个月,最终的结果很无私的公布出来。就这点来说Facebook比Google开放的多了,Google的数据中心技术上很保密。

搞FOC项目的目的是想建一个业界最为高效和低成本的数据中心,所谓高效,指的是能源效率,简单的说关键就是PUE。最终的成果很不错,PUE达到1.07,比目前业界主流先进水平高38%,建设和运营成本降低24%。PUE 1.07确实是很牛了,像国内的机房据说PUE一般只有2,一半的电力都没有供给给IT设备,而FOC只有7%的电力没有供给给IT设备。再优化的余地不多了。当然业界也不是只有FOC一家能做到很低的PUE,根据下图,Google和Yahoo的数据中心的PUE也都是接近的。但业界主流的传统运营商机房的PUE相比确实是差多了。

要建一个极低PUE的数据中心,气候条件很重要。最近Google号称是在搞海里的数据中心,用海水来冷却和发电。FOC没这么夸张,但FOC的数据中心特意的选在一个总体来说天气干冷的地方,这样才适合使用蒸发冷却系统。具体是在Oregon州的Prineville,沙漠地区。这里夏季7月气温最高时平均最高气温约30C,但湿度低干湿球温差很大,冬季最冷的1月份平均最高气温约10C,湿度也不大。蒸发冷却这个专业不懂,但大致说来应该是湿球温度低,干湿球温差大时就比较合适。

此外FOC对机房环境的制定比ASHRAE(美国采暖、制冷和空调工程师协会)的标准要松,ASHRAE标准是干球温度最高80.6F,FOC最高允

作者  | 2011-7-8 9:28:26 | 阅读(5498) |评论(1) | 阅读全文>>

SSD的随机写一定很慢吗?

2011-7-7 22:03:55 阅读7869 评论6 72011/07 July7

对SSD一种常见的认识是随机读、顺序读、顺序写都很快,但随机写很慢。从很多目前公布的产品性能指标数据和测试结果看,确实如此。一般SSD小块随机读性能可以达到几万甚至过十万,但小块随机写性能则一般只有3-5千,相差一个数量级。

我认为这一认识不完全正确。SSD是一个很复杂的硬件,也还在不断改进,各代产品的性能表现往往有很大差异,针对不同的IO操作模式,SSD的性能表现可能有非常大的差异,它的性能表现决不能用“三快一慢”来简单的描述。要用好SSD,需要从原理上对SSD有深刻的理解,这样才能预计各种应用模式下SSD的性能表现,特别是才能预计出未来SSD的性能特征将走向何方。

SSD最基础的硬件是一堆可以并行操作的NAND Flash,之上的控制器提供了读写缓存、LBA到HBA的映射、wear-leveling、garbage collection等众多功能。控制器非常复杂,各个产商的实现也都不同,但基本上可以认为一个设计的还不错的SSD应该能够较好的发挥出底层NAND Flash的性能。如此,了解底层NAND Flash的性能特征非常重要。根据Wikipedia和《Design Tradeoffs for SSD Performance》论文的数据,NAND Flash的基本性能指标大致如下:

   4K Page read latency: 25us

作者  | 2011-7-7 22:03:55 | 阅读(7869) |评论(6) | 阅读全文>>

数据库如何抵抗随机IO:问题、方法与现实

2011-4-21 19:48:51 阅读15485 评论14 212011/04 Apr21

随机IO几乎是令所有DBA谈虎色变的一个问题,这个问题,往往在数据量小的时候不出现,在数据量超过内存大小时,才陡然出现,令没有经验的DBA促不及防,也令有经验的DBA寝食难安。

传统的数据库架构对随机IO几乎没有还手之力。传统数据库的核心通常是页级缓存、B+树、堆或索引组织表,这些机制,对随机IO的抵抗能力,都无一例外的可悲的差。页级缓存有很强的“连坐”效应,就是为了要缓存一条有价值的记录,顺带可能要同时缓存百条无价值的记录。传统上这一点自豪的称之为locality,是用来减少IO的,但往往会导致内存缓存的利用率很差。在记录的级别,应用的访问模式通常符合Zipf分布,其中10%的记录所占的访问概率超过90%。如果我们用记录级的缓存,用相当于数据量10%的内存,就可以消除90%的IO,但用页级缓存,这10%的热点记录,很可能就分布在70%的页面上,这样同样10%的内存,很可能只能消除可悲的30%的IO。B+树的情况也好不了,如果索引大于内存量,每次随机的索引搜索、插入和删除,几乎都将带来一次随机IO(假设索引的非叶节点都在内存中)。

新的SSD硬件可以缓解随机读问题,但对随机写依然是无能为力。SSD的技术比较成熟了,期望它哪一天能魔术般的也搞定随机写,是不现实的。但我们可以从数据库架构上来想办法,谢天谢地,其实有很多办法,虽然未必能马上就用上。

先说记录的随机IO。之前已经说过,用记录级的缓存是很好的,我们

作者  | 2011-4-21 19:48:51 | 阅读(15485) |评论(14) | 阅读全文>>

InnoDB加锁实现机制初步分析

2011-1-7 16:04:40 阅读2635 评论3 72011/01 Jan7

虽然普通的SELECT在InnoDB里是不需要加行锁的,但LOCK IN SHARE MODE、更新操作及高串行化级别中的SELECT都要加锁。InnoDB宣称其行锁实现非常先进,开销只有每行3-4 bit。传统的数据库锁表结构,锁定一条记录时要构建一个包含被锁定对象ID信息、等待者队列、持有者队列链接等一系列东东的复杂数据结构,开销至少在100字节以上。InnoDB竟然可以做到只有3-4 bit,真是牛到不可思议。

于是,去初步了解了一下。基本原理应该是像这篇日志里说的这样还是用的Hash的锁表,只不过不是锁一条记录就创建一个复杂的结构,而是用位图来表示页面中各记录的锁定情况,这样,一个事务锁定页面中的很多行时,只需要把很多个位置设为1就行了,事务锁定大量记录时的平均空间开销就会很小。上述日志里做了个测试,一个事务锁定过百万条记录时,确实锁表占用的空间大概只有每条记录3 bit。

据此推测,如果一个事务只锁定页面中的少量记录,那这个平均开销就大了,上述日志没做过这样的测试。我简单测试了一下,发现确实如此,如果只锁定一个页面中的一条记录的话,也会新建个lock struct,占用空间似乎过百字节。如果一个事务锁定属于同一页面的两条记录,则只有一个lock struct,如果锁定不属于同一页面的两条记录,则就会产生两个lock struct。另外一条记录如果被N个事务同步锁定,锁占用的空间似乎就会达到N倍。

作者  | 2011-1-7 16:04:40 | 阅读(2635) |评论(3) | 阅读全文>>

Dropbox差异同步算法rsync及其改进算法原理

2010-11-12 17:26:32 阅读9355 评论8 122010/11 Nov12

之前用过rsync很多次,只知道可以做差异同步也没研究过原理。所谓差异同步是指只通过传输两文件的差异部分将两文件同步到一致,自己取的称谓,不知道学术术语是什么。差异同步算法中最有名的就是rsync系列了。

近来研究Dropbox,想看看它的同步怎么做的,没找到官方资料,不过据推测应该用的就是rsync,于是,看看鼎鼎大名的rsync是怎么实现的吧。

rsync算法要解决的问题很简单:A和B两个文件在两台服务器中,要将A同步到与B一致,要求尽量减少同步带来的网络传输开销。

rsync基本算法

先说基本的rsync算法,并不复杂,简单的说是三步:

1、按固定大小将A分为多块,每块都计算出一个32位的滚动哈希值和一个128位的MD4(有些也用MD5),发给B一端。

2、B一端从位置0开始按的同样块大小的滚动哈希值,查找看是否命中A给的某个滚动哈希值,若匹配,则表明B文件中的这块内容与对应的A中的那块内容很可能是一致的,但由于32位的哈希值强度不够,因此再计算MD4,若还是匹配,则确认是一致内容,这时B发给A端匹配的段号。对于那些不能匹配的内容,则发给A端原始内容。

3、A端得到B端给的匹配信息,构造一个与B一致的复本,若是匹配的块,则拷贝原A文件中对应的块,若是不匹配内容则追加之。

作者  | 2010-11-12 17:26:32 | 阅读(9355) |评论(8) | 阅读全文>>

查看所有日志>>

 
 
 
 
 
 

重要链接

 
 
模块内容加载中...
 
 
 
 
 

精华区

 
 
模块内容加载中...
 
 
 
 
 
 
 

浙江省 杭州市 金牛座

 发消息  写留言

 
关注互联网应用架构、分布式与海量数据处理技术、云计算、数据库技术
 
博客等级加载中...
今日访问加载中...
总访问量加载中...
最后登录加载中...
 
 
 
 
 
 
 
心情随笔列表加载中...
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2018

注册 登录  
 加关注