Digg采用Cassandra遭遇失败,工程副总裁离职 - 开源中国社区
Digg采用Cassandra遭遇失败,工程副总裁离职
红薯 2010年09月08日

Digg采用Cassandra遭遇失败,工程副总裁离职

红薯 红薯 发布于2010年09月08日 收藏 0 评论 12

腾讯云-1小时搭建人工智能应用,让技术更容易入门>>>  

北京时间9月8日消息,据国外媒体报道,消息人士透露,由于社交新闻网站Digg改版遭遇用户不满,目前Digg工程副总裁约翰·奎恩(John Quinn)已经离职。

Digg工程副总裁约翰·奎恩(John Quinn)

在今天发布的一段视频中,Digg首席执行官凯文·罗斯(Kevin Rose)解释了Digg网页的一些技术问题,以及Digg网页为何不能返回到原先的架构。新版的Digg网站设计,也就是Digg v4是基于分散式数据库Cassandra,取代了原先的MySQL数据库。

Cassandra数据库速度更快,但或许它仍然处于实验期,也或者是Digg正在对Cassandra数据库进行测试,总之Cassandra的运行状况并不能令用户满意。凯文·罗斯表示,目前Digg所有工程师都在努力改进网站设计,使其运转顺畅。

消息人士表示,奎恩是推动Digg用Cassandra取代MySQL数据库的主要支持者。现在由于Digg采用Cassandra而遭遇重大反对,至少遭遇了严重的短期问题,因此奎恩也因此丢掉了在Digg的工作。

奎恩也将近三年前加盟Digg。在加盟Digg之前,奎恩担任SquareTrade工程副总裁,也曾担任甲骨文的软件工程师。目前尚不清楚谁将接任Digg工程副总裁一职。

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 开源中国社区 [http://www.oschina.net]
本文标题:Digg采用Cassandra遭遇失败,工程副总裁离职
分享
评论(12)
最新评论
0

引用来自“reck”的评论

此外大多数关系型数据库以b-tree或者b+tree等来进行索引存储,本身由于key的分布关系可能存在资源读写的竞争关系,如果你对数据分片存储,那么索引如何建立?每个分片建立一个索引?最终合并索引数据?你是否有考虑过性能的问题?
如果来自客户端的随机访问集中在某个分片,那么该分片的压力如何解决?单靠你的数据负载方案?恐怕跟没分片一样吧。
nosql的产生有着其深刻的背景,对于新的事物简单的否定,欠缺深思熟虑的思考,恐怕并非一个技术人员的初衷。

nosql和关系型数据库所擅长的领域本来就是不太一样的,不应该简单地替换。
分片是指所谓的数据切分么?虽然具有很大作用,但是问题也不小。除了你说的一致性和负载集中的情况,还有未来扩展和继续细化切分的问题。并不是像楼上所说那样好像是轻松解决任何问题了。这是由关系型数据库单点性能决定。
0
Cassandra就这样给中枪了
0

引用来自“reck”的评论

此外大多数关系型数据库以b-tree或者b+tree等来进行索引存储,本身由于key的分布关系可能存在资源读写的竞争关系,如果你对数据分片存储,那么索引如何建立?每个分片建立一个索引?最终合并索引数据?你是否有考虑过性能的问题?
如果来自客户端的随机访问集中在某个分片,那么该分片的压力如何解决?单靠你的数据负载方案?恐怕跟没分片一样吧。
nosql的产生有着其深刻的背景,对于新的事物简单的否定,欠缺深思熟虑的思考,恐怕并非一个技术人员的初衷。

我觉得nosql较之传统的关系型数据库,能够减少sql解析和执行的一个开销,还能够减少事务带来的开销,通过弱一致性来保持高可用性。而且很多nosql db支持动态列集的概念,动态列集在一些场景能够带来很大的便利。
不同存储方案解决不同的应用场景,所以你的很多观点我都是赞同的。
不过有一点就是“分片机制”,主要还得看应用场景的数据特征来分析,它还是有很大的适用范围的。可能你也是指这个意思,但是偶误解了你的意思而已,呵。
0
此外大多数关系型数据库以b-tree或者b+tree等来进行索引存储,本身由于key的分布关系可能存在资源读写的竞争关系,如果你对数据分片存储,那么索引如何建立?每个分片建立一个索引?最终合并索引数据?你是否有考虑过性能的问题?
如果来自客户端的随机访问集中在某个分片,那么该分片的压力如何解决?单靠你的数据负载方案?恐怕跟没分片一样吧。
nosql的产生有着其深刻的背景,对于新的事物简单的否定,欠缺深思熟虑的思考,恐怕并非一个技术人员的初衷。
0
楼上的,你分片解决,如果一台宕机,你的一致性如何解决?
关系型数据库自身一致性锁性能主要受到内部线程锁影响。如果你利用网络分片,则将一致性锁让给网络来承担,那么锁性能的好坏取决于网络带宽。此时你的一致性的性能将受到外部影响的因素更多。
0
现有的不同类别的技术都可以解决,只是复杂度不一样。Nosql只是还没有成熟的果子,现在就摘下来吃当然要代价,除非你的忍耐和技术都非常好。大势所趋,Nosql以后应该会长得比关系型更好。
做技术,不必要绑死在一棵树上。多了解一些不同的技术会开阔自己的视野。
0

引用来自“reck”的评论

楼上的,你放置1000个关系型数据库的分布式,光分布式锁机制就能将你的读写效率降到最低,何谈你的数据一致性?而且你见过这样的关系型数据库的架构嘛?nosql则可以轻松实现这一点

服务分片,不存在大量并发锁!关系数据库绝对解决的了
0
仔细分析digg迁移过程,全过程并未说明cassandra有什么技术上的问题,只是因为迁移后导致原先的页面访问无法被兼容。
这只能说是迁移过于革命性或者激烈。
0
楼上的,你放置1000个关系型数据库的分布式,光分布式锁机制就能将你的读写效率降到最低,何谈你的数据一致性?而且你见过这样的关系型数据库的架构嘛?nosql则可以轻松实现这一点
0
关系型数据库难道不能分布式?难道不能高并发?

简直是笑话~
0
关系型数据库不死!

从其产生到现在,有多少号称关系数据库杀手的?对象数据库、分布式数据库等等,今何在?

关系数据库,V5 !!
0
还好我们还没换。NoSQL是一大趋势,Cassandra是其中开发较好的一个了。个人感觉关系型数据库快不行了(更别说Mysql),最后还是要转到非关系型的,只是至少过5年再说。看看甲骨文件都在做什么就知道了,他们也在转型。
顶部