您好,UncleToo欢迎您!  为了更好的浏览本站,请使用高版本浏览器
RSS  Tag     设为首页 | 加入收藏
 您所在的位置:首页 > 数据库技术 > NoSQL

LinkedIn资深专家:我的NoSQL之路

作者:UncleToo  来源:互联网  日期:2013-09-20 14:29:42
收藏  评论:( 0 )  阅读:498

如果你已经在互联网公司工作过3年以上的时间,你将不会对云计算和NoSQL的概念感到陌生。在2007年,Amazon公布了其Dynamo(Dynamo是亚马逊的key-value模式的存储平台,具备高可用性、高扩展性和高性能)的详细资料。并详细介绍了Dynamo是如何利用技术集合解决容错等问题,并提供一个灵活的线上购物方案。在过去几年,AWS的工程师一直在默默无闻的完善运行在自身公共云之上的Dynamo。

Siddharth Anand的NoSQL历程

2008年12月,当我还在Netflix软件基础设施团队工作时,我们得知了CAP原理(Consistency、Availability和Partition Tolerance,CAP原则要求在分布式系统只能选择一致性、可用性和分区容忍性其中的两项)。因为CAP原理我们放弃数据中心并租用云计算服务。

在2008年到2010年期间,我们的工作集中在Netflix推出的视频流业务,而CAP原理中的可用性和分区容忍性以及高可用性系统是我们的工作重点。

在2010年我帮助Netflix完成了两次迁移,其一是将Netflix的数据中心迁移到了Amazon AWS之中,其二是将Oracle数据库迁移至SimpleDB。而到了2011年又从SimpleDB迁移到Cassandra,利用Cassandra提供的路由配置,集群可以被部署在多个大洲。

来到2012年,我已经度过了我在LinkedIn的第一个月。经过这一个月时间的熟悉,我知道LinkedIn在内部建立了多种NoSQL系统。包括Voldemort(另一套基于Dynamo的系统)、Krati(单击数据存储)、Espresso(正在积极开发的数据库系统)等。LinkedIn现在正面临着类似3年前Netflix的挑战。

NoSQL领域没有王者

当企业决定使用NoSQL时,他们首先需要在众多版本中进行选择。从现今的NoSQL领域来看,创业公司普遍选择Cassandra、Riakedge以及MongoDB。同时有些企业则直接将自身部署在AWS S3、SimpleDB以及DynamoDB之上。 企业选择哪种类型的NoSQL需要从自身业务的角度出发。例如MongoDB在全局写入时存在write-lock,这意味着MongoDB不适合需要高吞吐量的写入的环境。

而Cassandra虽然提供基于主键(如get、put、delete等)的存取操作,但其辅助索引查找扩展性不佳。同时Cassandra虽然拥有大量可调参数和繁多的内部机制,但为了维护其稳定性,最好关闭诸如Anti-entropy repair和row cache等功能,以保障其一致性。另外如果企业系统需要24×7的业务支持,同时又没有足够的人力,建议使用Dynamo。

同时许多人将NoSQL各个版本间的竞争比作上世纪80年代传统关系数据库之间的战斗。但在NoSQL世界里,由于受限于分布式系统,没有哪个NoSQL版本可以适用于所有的领域。

坚持自身设计原则

我最近在查看Voldemort的代码时给我留下的最深刻的印象是代码的清晰度和质量。Voldemort作为开源项目已经运作多年,一直尊需严格的设计要求。开发人员了解系统的DNA,所以不会增加不适合系统的功能。同样,Krati、Kafka和Zookeeper等著名的开源项目也都坚持着自身的设计原则。正因为如此,其可以保证在基础设施中的分布式文件系统中反复部署。




NoSQL
 
CAP
 
MongoDB
 
除非特别声明,本站所有PHP教程及其他教程/文章均为原创、翻译或网友投稿,版权均归UncleToo中文网所有, 转载请注明作者及出处。
原文网址:http://www.uncletoo.com/html/nosql/349.html
读完这篇文章后,你是否有所收获? 分享是一种生活的信念!
  • 0
  • 0
我来说两句
更多>>网友评论