摘要:
Tair是由淘宝网自主开发的Key/Value结构数据存储系统,在淘宝网有着大规模的应用。您在登录淘宝、查看商品详情页面或者在淘江湖和好友“捣浆糊”的时候,都在直接或间接地和Tair交互。
阅读全文
posted @ 2010-09-09 11:16
Jonson Li
阅读(327)
推荐(0)
摘要:
在众多不同的数据模型里,关系数据模型自80年代就处于统治地位,而且有不少实现,如Oracle、MySQL和MSSQL,它们也被称为关系数据库管理系统(RDBMS)。然而,最近随着关系数据库使用案例的不断增加,一些问题也暴露了出来,这主要是因为两个原因:数据建模中的一些缺陷和问题,以及在大数据量和多服务器之上进行水平伸缩的限制。
阅读全文
posted @ 2010-09-09 11:14
Jonson Li
阅读(745)
推荐(0)
摘要:
随着互联网web2.0网站的兴起,非关系型的数据库现在成了一个极其热门的新领域,非关系数据库产品的发展非常迅速。而传统的关系数据库在应付web2.0网站,特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心,暴露了很多难以克服的问题。
阅读全文
posted @ 2010-09-09 11:12
Jonson Li
阅读(223)
推荐(0)
摘要:
Terracotta公司近日推出了Terracotta 3.0,这是一款开源的Java内存缓冲数据库平台。内存缓冲(In-Memory Caching)技术最近发展迅速,它给基于网络交易的数据库应用程序提供了一种新的方案。
阅读全文
posted @ 2010-09-09 11:11
Jonson Li
阅读(300)
推荐(0)
摘要:
摘要:非关系型数据库正在吸引人们的注意,因为它们可以忽略许多的规则,而这些规则正是经验丰富的数据库管理员积累的深刻教训。所有的Web应用程序设计者都梦想构建一个多机运行的应用程序,保存所有用户的所有数据,要想做到这些,有些老的规则需要避开,甚至是打破。
阅读全文
posted @ 2010-09-09 11:09
Jonson Li
阅读(193)
推荐(0)
摘要:
摘要:本文作者从业专业软件开发多年来,一直认为一个数据库的持久性整体规划通常都是不成套的。近几年来随着云计算开始流行,有很多声音开始质疑关系数据库的末日是否已经来临。在众多备受瞩目的替代品中,Terracotta是比较杰出的一支。
阅读全文
posted @ 2010-09-09 11:06
Jonson Li
阅读(275)
推荐(0)
摘要:
摘要:最近,大量新的非关系式数据库如雨后春笋般出现在云里云外。这其中所释放出的一个关键信息是:“如果想获得丰富而随需应变的可伸缩性,你需要一个非关系数据库。”如果这是真的,那么这是不是一个迹象,表明曾经强大的关系式数据库终于在它的盔甲上出现了裂缝?关系数据库的日子是不是到头了?该隐退了?在本文中,我们将检视当前这种在特定情况下摆脱关系数据库的趋势,并分析这对于关系数据库的未来意味着什么。
阅读全文
posted @ 2010-09-09 11:03
Jonson Li
阅读(253)
推荐(0)
摘要:
摘要:数据库厂商微软和甲骨文是在2008年开始重视云数据库。分析师们预计,在2009年数据库厂商会把更多的数据库功能增加到云中。2008年只是云计算开始步入数据库市场。
阅读全文
posted @ 2010-09-09 11:01
Jonson Li
阅读(190)
推荐(0)
摘要:
摘要:尽管大型关系数据库如甲骨文公司提供的产品,已经被部署在很多数据中心,但云计算需要一种不同的设置来充分发挥其潜力。
阅读全文
posted @ 2010-09-09 11:00
Jonson Li
阅读(202)
推荐(0)
摘要:
就像当年波士顿的爱国者为反抗英国重税的行动一样,NoSQL的支持者们从各地涌来,分享他们如何推翻缓慢而昂贵的关系数据库的暴政,怎样使用更有效和更便宜的方法来管理数据,他们开始对SQL说不!
阅读全文
posted @ 2010-09-09 10:58
Jonson Li
阅读(193)
推荐(0)
摘要:
作为企业架构师,我的职业习惯之一,就是不断的探求各种新的有前景的概念和思想,看其是否有潜力为我所服务的来自各行各业的企业客户带来价值。同样出于对这种理念的追求,我对NoSQL领域的关注了也有一段时间了,甚至从这个术语产生(或者错误的产生?)之前就开始了。Google首先在这方面点了一把火,发布了论文Big Table架构,对关系数据库是银弹这种普遍的信念提出了质疑,而Amazon关于Dynamo的论文则紧随其后。 过去的一年中我们见证了NoSQL强劲的势头,在这一领域有多达25种产品/解决方案发布,并且NoSQL的触角已经伸向了业界的各个角落。在此前提下,我最近考虑深入这一领域,评估一下我的客户究竟如何才能从这种NoSQL运动中获益。不仅如此,我还想探究对于企业来说,是否是到了该认真考虑采纳NoSQL的合适时机了。
阅读全文
posted @ 2010-09-09 10:55
Jonson Li
阅读(270)
推荐(0)
摘要:
王迪是FreeWheel核心系统的技术总监,从07年FreeWheel创立起,他全程参与到其广告核心系统的架构设计,也见证了FreeWheel从最初的的只有20台广告服务器、日均几十万的访问量、不到1G/天的日志量,发展到现在拥有60台广告服务器、日均广告请求5000万次、日志处理服务器8台、日均4小时处理日志200G这么一个规模。3年之间,流量增长20倍。他主要谈到了以下的一些经验和原则:
应用服务扩展
无状态应用服务
复制与多层次Cache
数据仓库扩展
De-normalization/Pivot
Roll up/Data Availability
Benchmarking与查询优化
Split-Loading/Sharding
运营原则
50%运行负载上限 & N+1 Data Center
监控和响应
多阶段部署
很多具体的实践方法,都是针对他们具体的商业模式以及实际工作中摸索出来的,它不一定是“最好”的,但却是最适合的,比如对系统的负载当达到50%的时候,就是一个优化和扩容的信号了;再比如,以自动化回归测试为核心,但并未使用TDD单元测试,等等等等
阅读全文
posted @ 2010-09-09 10:47
Jonson Li
阅读(249)
推荐(0)
摘要:
为Hadoop的发展贡献自己的力量
在马如悦的演讲中,他主要介绍了百度的大规模数据存储、数据分析以及数据索引,主要包括以下内容点:
大规模数据存储
Lustre和HDFS
系统结构
HDFS优势、不足
大规模数据分析
MPI和MapReduce
MapReduce概念模型、实现模型
MapReduce-Hadoop实现
大规模数据索引
MySQL和HBase对比
HBase详解
在以上三方面百度遇到的问题、对策和原则
其中,马如悦提到,百度现在要处理的数据量非常庞大:存储20PB+数据,每日新增数据10TB+,每天处理的数据1PB+,每天提交10K+次作业。现在使用的文件系统是HDFS,数据存储是HBase,有超过2K台服务器节点,每个节点为2*4 core。现在遇到的一个棘手问题便是namenode的瓶颈问题:因为要存储大量的(小)文件,使namenode的压力非常大,他们刚刚采购了48GB的内存,但是这48GB的内存,预计只能坚持到今年年底,到时候,可能会采购96GB的内存来紧急应对这个问题。所以百度在namenode的分布式方面,进行了很多研究。马
阅读全文
posted @ 2010-09-09 10:44
Jonson Li
阅读(348)
推荐(0)
摘要:
源地址:http://www.infoq.com/cn/presentations/liuhongqing-data-store演讲嘉宾及主题嘉宾简介:黄方荣WEB开发高级工程师,1998年大学毕业,2000年开始从事WEB开发工作。现就职于百度,从事于大型WEB项目(前端)技术架构。用最适合的方案解决WEB开发的各种难题!演讲主题:WEB数据交互的艺术主要演讲的内容:交互数据的格式;几种疑难数据...
阅读全文
posted @ 2010-09-09 10:42
Jonson Li
阅读(330)
推荐(0)
摘要:
主要演讲的内容:交互数据的格式;几种疑难数据交互的实现(跨页交互、跨域交互、即时交互等),这些解决方案一部分是已经在现有产品线上实现,还有一部分是正在实施;数据交互的意义等……;WEB发展的源动力是用户的需求,用户的需求又都通过数据的交互来实现,即什么样的交互数据决定着什么样的WEB。本次交流的内容就是从技术上来解析数据交互的实现,让每个解决方案都如同艺术品一样,简洁,优美!
阅读全文
posted @ 2010-09-09 10:38
Jonson Li
阅读(323)
推荐(0)
摘要:
MapReduce是一个编程模型,也是一个处理和生成超大数据集的算法模型的相关实现。用户首先创建一个Map函数处理一个基于 key/value pair的数据集合,输出中间的基于key/value pair的数据集合;然后再创建一个Reduce函数用来合并所有的具有相同中间key值的中间value值。现实世界中有很多满足上述处理模型的例子, 本论文将详细描述这个模型。
MapReduce架构的程序能够在大量的普通配置的计算机上实现并行化处理。这个系统在运行时只关心:如何分割输入数据,在大量计算机组成的 集群上的调度,集群中计算机的错误处理,管理集群中计算机之间必要的通信。采用MapReduce架构可以使那些没有并行计算和分布式处理系统开发经验的 程序员有效利用分布式系统的丰富资源。
我们的MapReduce实现运行在规模可以灵活调整的由普通机器组成的集群上:一个典型的MapReduce计算往往由几千台机器组成、处理 以TB计算的数据。程序员发现这个系统非常好用:已经实现了数以百计的MapReduce程序,在Google的集群上,每天都有1000多个 MapReduce程序在执行。
阅读全文
posted @ 2010-09-09 09:46
Jonson Li
阅读(546)
推荐(0)
摘要:
本篇是本系列的最终章,将总结一下App Engine在使用方面的注意点,最佳实践和适用场景,最后会谈一下我对App Engine的一些期望。
阅读全文
posted @ 2010-09-09 09:38
Jonson Li
阅读(150)
推荐(0)
摘要:
本篇会首先会从程序员角度来介绍一下Datastore在使用方面的一些信息,之后会接着介绍Datastore是如何构建的。
阅读全文
posted @ 2010-09-09 09:37
Jonson Li
阅读(234)
推荐(0)
摘要:
本篇将首先介绍App Engine的一些设计理念,接着将对App Engine的组成部分等进行介绍。
阅读全文
posted @ 2010-09-09 09:36
Jonson Li
阅读(208)
推荐(0)
摘要:
通过前面两篇介绍,大家应该对Google强大的基础设施有一定的了解。本篇开始介绍构筑在这强大基础设施之上的Google App Engine。
Google App Engine的介绍
由于发布S3和EC2这两个优秀的云服务,使得Amazon已经率先在云计算市场站稳了脚跟,而身为云计算这个浪潮的发起者之一的Google肯定不甘示弱,并在2008年四月份推出了Google App Engine这项PaaS服务,虽然现在无法称其为一个革命性的产品,但肯定是现在市面上最成熟,并且功能最全面的PaaS平台。
Google App Engine 提供一整套开发组件来让用户轻松地在本地构建和调试网络应用,之后能让用户在Google强大的基础设施上部署和运行网络应用程序,并自动根据应用所承受的负载来对应用进行扩展,并免去用户对应用和服务器等的维护工作。同时提供大量的免费额度和灵活的资费标准。在开发语言方面,现支持Java和Python这两种语言,并为这两种语言提供基本相同的功能和API。
阅读全文
posted @ 2010-09-09 09:35
Jonson Li
阅读(218)
推荐(0)
摘要:
本文是基于现有的公开资料和个人的经验来对Google的整体架构进行总结和猜想。
阅读全文
posted @ 2010-09-09 09:34
Jonson Li
阅读(182)
推荐(0)
摘要:
本系列文章基于公开资料对Google App Engine的实现机制这个话题进行深度探讨。在切入Google App Engine之前,首先会对Google的核心技术和其整体架构进行分析,以帮助大家之后更好地理解Google App Engine的实现。
本篇将主要介绍Google的十个核心技术,而且可以分为四大类:
分布式基础设施:GFS、Chubby 和 Protocol Buffer。
分布式大规模数据处理:MapReduce 和 Sawzall。
分布式数据库技术:BigTable 和数据库 Sharding。
数据中心优化技术:数据中心高温化、12V电池和服务器整合。
阅读全文
posted @ 2010-09-09 09:31
Jonson Li
阅读(234)
推荐(0)
摘要:
Google App Engine 提供一整套开发组件来让用户轻松地在本地构建和调试网络应用,之后能让用户在Google强大的基础设施上部署和运行网络应用程序,并自动根据应用所承受的负载来对应用进行扩展,并免去用户对应用和服务器等的维护工作。同时提供大量的免费额度和灵活的资费标准。在开发语言方面,现支持Java和Python这两种语言,并为这两种语言提供基本相同的功能和API。
阅读全文
posted @ 2010-09-09 09:26
Jonson Li
阅读(672)
推荐(0)
摘要:
我们设计并实现了Google GFS文件系统,一个面向大规模数据密集型应用的、可伸缩的分布式文件系统。GFS虽然运行在廉价的普遍硬件设备上,但是它依然了提供灾难冗余的能力,为大量客户机提供了高性能的服务。
虽然GFS的设计目标与许多传统的分布式文件系统有很多相同之处,但是,我们的设计还是以我们对自己的应用的负载情况和技术环境的分析为基础 的,不管现在还是将来,GFS和早期的分布式文件系统的设想都有明显的不同。所以我们重新审视了传统文件系统在设计上的折衷选择,衍生出了完全不同的设计思路。
GFS完全满足了我们对存储的需求。GFS作为存储平台已经被广泛的部署在Google内部,存储我们的服务产生和处理的数据,同时还用于那些需要大规模数据集的研究和开发工作。目前为止,最大的一个集群利用数千台机器的数千个硬盘,提供了数百TB的存储空间,同时为数百个客户机服务。
在本论文中,我们展示了能够支持分布式应用的文件系统接口的扩展,讨论我们设计的许多方面,最后列出了小规模性能测试以及真实生产系统中性能相关数据。
阅读全文
posted @ 2010-09-09 09:24
Jonson Li
阅读(369)
推荐(0)
摘要:
我们设计并实现了Google GFS文件系统,一个面向大规模数据密集型应用的、可伸缩的分布式文件系统。GFS虽然运行在廉价的普遍硬件设备上,但是它依然了提供灾难冗余的能力,为大量客户机提供了高性能的服务。
虽然GFS的设计目标与许多传统的分布式文件系统有很多相同之处,但是,我们的设计还是以我们对自己的应用的负载情况和技术环境的分析为基础 的,不管现在还是将来,GFS和早期的分布式文件系统的设想都有明显的不同。所以我们重新审视了传统文件系统在设计上的折衷选择,衍生出了完全不同的设计思路。
GFS完全满足了我们对存储的需求。GFS作为存储平台已经被广泛的部署在Google内部,存储我们的服务产生和处理的数据,同时还用于那些需要大规模数据集的研究和开发工作。目前为止,最大的一个集群利用数千台机器的数千个硬盘,提供了数百TB的存储空间,同时为数百个客户机服务。
在本论文中,我们展示了能够支持分布式应用的文件系统接口的扩展,讨论我们设计的许多方面,最后列出了小规模性能测试以及真实生产系统中性能相关数据。
阅读全文
posted @ 2010-09-09 09:20
Jonson Li
阅读(281)
推荐(0)
摘要:
虽然传说中的Donald Knuth同学曾经说过“过早优化是万恶之源”(premature optimization is the root of all evil),但在产品代码基本稳定的时候,做一定优化,还是非常有帮助,比如,我曾经通过使用多线程技术将一个原本需要30分钟才能搞定的流程优化到只需30秒,还有,虽然Windows 7和Vista之间的codebase非常相近,但是由于Windows 7在Vista的基础上做了许多的优化,所以Windows 7在保持其绚丽特效的情况下性能非常优异,从而保证其能成功替代Windows XP。谈到BigTable,Google的工程师也同样为了其性能采用了一些优化技术,本文将会根据BigTable的论文来对这些性能优化技术进行详细地分析,在切入正题之前,如果大家对BigTable或者YunTable有什么不熟悉的话,可以通过点击此来阅读本系列之前所有的文章。
阅读全文
posted @ 2010-09-09 08:32
Jonson Li
阅读(344)
推荐(0)
摘要:
在写完前面一篇YunTable日记(也就是第9篇)之后,有很多博友向我反映,他们不清楚YunTable到底是用来干什么的?今天就和大家聊聊YunTable的目标。
阅读全文
posted @ 2010-09-09 08:22
Jonson Li
阅读(211)
推荐(0)
摘要:
最近两周除了写博客之外,还花了一定的时间在YunTable上,并且已经快接近YunTable的下一个Milestone,也就是0.2版。在整个开发过程中,我收到了来自很多朋友的热心关切,我在这向大家表示衷心感谢,同时让我感到更欣慰的是已经有多位有实力的同学和我沟通过了,希望将来有机会能参与YunTable的开发,而且还有几位博友也对我提出了一些批评和建议,那么在介绍0.2版的目标和今后的规划之前,为了方便今后和大家的沟通,我先介绍我的一些理念:
阅读全文
posted @ 2010-09-09 08:20
Jonson Li
阅读(194)
推荐(0)
摘要:
在发布YunTable0.1版之后,我将这个好消息和我一个在中国移动工作的同济同学分享了,他首先向我表示祝贺,但是他不理解像YunTable这样的分布式数据库和Oracle这样的关系型数据库有什么区别?当接到这个问题的时候,我并没有立即回答,因为我感到这个疑问不仅是他一个人会有,而且估计有很多同学也有类似的疑问,这就是本文的由来。但在介入分布式数据库之前,让我们剖析一下关系型数据库有哪些不足。
阅读全文
posted @ 2010-09-09 08:17
Jonson Li
阅读(218)
推荐(0)
摘要:
本文是HBase的欧洲传道者LARS GEORAGE的HBase vs. BigTable Comparison(需要FQ)一文的节选翻译版。
阅读全文
posted @ 2010-09-09 08:15
Jonson Li
阅读(271)
推荐(0)
摘要:
在介绍了BigTable的存储模型之后,本篇将重点给大家介绍其分布式模型。由于本文大多数内容参考BigTable的论文,如果有些博友已经熟读这篇论文,可以跳过本文。
阅读全文
posted @ 2010-09-09 08:13
Jonson Li
阅读(310)
推荐(0)
摘要:
经过两个星期的努力(如果刨去学习C语言的时间),YunTable终于走完一个从无到有的历程,今天,也就是2010年7月12日,YunTable正式对外发布其0.1版,在0.1版中YunTable虽然在特性,优化和内存管理这三方面还有很多的缺失,但是总体而言,已经实现了一个身为BigTable克隆的基本要求,也就是分布式查询和管理,以及以column为核心的存储。这是0.1版的下载链接(上次因为对Skydrive的存储机制不熟,导致部分博友没有第一时间拿到0.01版的源代码,在这里向大家表示我的歉意)。
阅读全文
posted @ 2010-09-09 08:12
Jonson Li
阅读(219)
推荐(0)
摘要:
虽然进度比我之前预想的慢了很多,但是经过最近几天的coding,终于完成YunTable的0.01版,虽然在支持的功能和之前预期的相比简单了很多,如果大家对这个0.01版感兴趣的话,可以通过这个链接下载。下面是关于0.01版的综述,使用教程和计划。
阅读全文
posted @ 2010-09-09 08:11
Jonson Li
阅读(184)
推荐(0)
摘要:
经过这几天的开发工作,我已经将YunTable所需的一些基本类库搭建起来,比如内存管理,字符串处理,I/O处理和基本的数据结构等,由于之前的编程以Java为主,所以在这方面花了一定的时间,导致整个项目的进度偏离了之前的预期,但是我也有很多的收获,比如我感受到了Java和C之间的异同:异就是Java能通过JVM和JDK提供给程序员一个非常便捷和安全的开发环境,就好象一个温室那样,而C语言呢?则是提供一个简单到以至于简陋的工具给程序员,但是却导致其具有非常强大的灵活性,在这方面,有点类似围棋。而同呢?就是不论写Java代码还是C代码,最核心也是最关键的,就是使用优雅的方式将重复的代码降至最低,从而降低整体的代码数量和复杂度。在关于语言特性的讨论之后,接下来就将介绍本文的核心内容,也就是BigTable的存储模型,首先是Tablet的运行机制。
阅读全文
posted @ 2010-09-09 08:09
Jonson Li
阅读(308)
推荐(0)
摘要:
本文将深入分析BigTable的数据模型,并介绍它是如何被调用的。
阅读全文
posted @ 2010-09-09 08:08
Jonson Li
阅读(339)
推荐(0)
摘要:
本来想周二写这篇开发日记,可惜一直抽不出时间,所以延到了周四。在这篇日记中,会首先做一下前三天的开发总结,接着会解答博友的一些疑问。
阅读全文
posted @ 2010-09-09 08:06
Jonson Li
阅读(201)
推荐(0)
摘要:
因为书的初稿已经写好,所以现在这个阶段主要以研发产品原型为主,而且将关注点主要集中于下一代云计算系统。可惜的是,我之前主要使用的开发语言是Java,而对常用于构建云计算系统中的C语言不是很熟悉,同时由于C的灵活性和其牵涉到很多底层技术,使得这个坎非常不好过,但是既然已经走到了这步,不论是再艰难的东西,也要坚持下去。那么什么方式能最有效地提升编程能力呢?对于有一定编程的经验的人而言,答案非常简单,那就是“做项目”,所以为了提升我的C语言能力,所以我决定在七个开发日的时间内完成一个最简单的BigTable的原型,名为“YunTable”,接下来是这个项目的简要介绍和开发计划。
阅读全文
posted @ 2010-09-09 08:00
Jonson Li
阅读(221)
推荐(0)
摘要:
Bigtable是一个分布式的结构化数据存储系统,它被设计用来处理海量数据:通常是分布在数千台普通服务器上的PB级的数据。Google 的很多项目使用Bigtable存储数据,包括Web索引、Google Earth、Google Finance。这些应用对Bigtable提出的要求差异非常大,无论是在数据量上(从URL到网页到卫星图像)还是在响应速度上(从后端的批量处理到实时数据服务)。尽管应用需求差异很大,但是,针对Google的这些产品,Bigtable还是成功的提供了一个灵活的、高性能的解决方案。本论文描述了Bigtable提供的简单的数据模型,利用这个模型,用户可以动态的控制数据的分布和格式;我们还将描述Bigtable的设计和实现。
阅读全文
posted @ 2010-09-09 07:50
Jonson Li
阅读(740)
推荐(0)