|
|
Digg在挣扎,技术副总裁已卷铺盖走人
by Erick Schonfeld,Translated By Jametong
自从网站的新版本发布以来,Digg就一直麻烦缠身,不仅仅是网站不停地宕机.新架构的问题是如此之糟糕,其技术副总裁John Quinn已为此卷铺盖走人,接近Digg的消息人士确认了此消息.
在今天的一份Diggnation的电视节目中,Digg的CEO Kevin Rose解释了网站最近遭遇的技术问题解,以及为什么Digg无法简单的回滚到之前的架构.Digg的新版本(V4)使用了一种分布式数据库,Cassandra,来替代它们网站之前使用的MySQL数据库.Cassandra非常先进,它承诺可以更快也更容易扩展,但是,或许仍然不够成熟.或者,可能仅仅是Digg实现它的方式有问题(Twitter也在使用Cassandra,虽然不用它来做主数据存储,Facebook也在使用,但是,显然,Cassandra并没有人们需要的那样久经考验).目前,Digg的每一个工程师都只是在努力保持其网站正常运转.
Quinn是将Digg的数据架构迁移到Cassandra的主要推手,我们的消息来源透露.现在,它们网站遭遇到了重大的打击,起码在短期看是这样,因为这个决策与/或它的具体实现方式,Quinn为此丢了工作.但是,Digg应该如何做仍然不明朗.Digg最初架构在久经考验的LAMP(Linux,Apache,MySQL,PHP)的开源技术组合上,但是,Digg的访问负载非常紧张.使用Cassandra替代MySQL被认为有助于解决此问题.不过,它也带来了属于它的更大的问题.
Quinn在大概3年前加入Digg.在此之前,他是SqareTrade的副总裁和Oracle公司的软件工程师.谁将替代他在Digg的位置仍是个未知数.
为什么Flowdock从Cassandra迁移到MongoDB
by Otto Hilska @mutru Translated by Jametong
Flowdock是一个基于Web的团队通讯工具.所有的软件开发人员都应该使用它进行沟通,而不是使用Campfires、Skype Chats或IRC等工具.因为它可以更好的的支持他们的真实工作流.
上周,我们对Flowdock的数据库服务做了一次切换,聪从Cassandra迁移到了另一种NoSQL工具-MongoDB.由于我们的技术选择已经引起了大家的部分兴趣,我将在此向公众说明下我们的决策理由.
我们的部分客户一定对下面这个图片记忆犹新:
从一定程度上讲,我们遭遇到了Cassandra的稳定性问题.所有的节点都陷入无线无限循环(infinite loop),运行垃圾回收工作(GC, Garbage Collection)并尝试压缩数据文件-并偶尔导致集群瘫痪.除了对集群进行重启并经常性的手工对节点做压缩工作以让其稳定一会外,我们无计可施.其他人也报告过类似的问题.在前面几周的时间里,我们的Cassandra节点总是会吃掉给他分配的所有资源,而导致Flowdock运行缓慢.
由于我们刀口嗜血式的数据库选择(James注: 这是我不认同的地方,可能对于一些Startup的公司来讲,这是一种不得已的选择.),这已经不是我们第一次遇到此类问题了.从Cassandra 0.4升级到0.5的时候,我们被迫关闭了整个集群,仅仅是为了将所有的数据刷新到磁盘上(虽然,我们已经按照文档进行了手工刷新的操作).这个操作导致我们丢失了几分钟的讨论内容,以及我们手工创建的索引出现严重的不一致,以致于需要做完全的重建.我想,我们最后离开办公室的时间已经是凌晨4点了.
从我们最初选择Cassandra到现在,NoSQL社区已经出现了很大的变化.MongoDB已经发生了很大的改变,最近新增的自动分片(auto-sharding)与副本集(replica set)使得它可以作为Cassandra的有力的替代品.因此,我们决定试试MongoDB.
写从Cassandra往MongoDB的数据迁移的脚本耗费我一天的时间.在一周左右的时间内,我们已经可以完全在MongoDB上运行Flowdock了.在生产环境部署MongoDB之前,内部测试持续进行了好几个星期.
目前,我们已经完成这个调整,
1. 智能(多键)索引. 手工维护的索引令人生厌,MongoDB可以自动帮我们维护所需的索引.例如,我们的消息包含标签(tag),例如下面这个格式的document:
{ content: “Write a blog post about #mongodb.”,
workspace: ‘myflow’,
tags: ["mongodb", "todo", "@Otto"] }
这样,如果仅检索自己的任务,Flowdock的后台只需要做下面这个查询:
db.messages.find({
workspace: ‘myflow’,
tags: { $all: ["todo", "@Otto"] }
})
2. 查询.无论数据模型多么简单,每当需要执行一个查询的时候,你都不需要提前规划此事.在MongoDB中,你可以直接在控制台定制复杂的查询,这一点非常类似于SQL数据库.它会据此执行一次顺序扫描,这比在客户端手工处理上百万的记录要更快捷也更便利.
3. Map-Reduce. 这是分析人员的利器啊.MongoDB的Map-Reduce功能支持虽然不是非常完美,但它起码很易用.
4. GridFS让我们的文件存储操作变得非常容易.它的存储能力可以随着我们的MongoDB集群的扩展一起增长.
我们也遭遇到部分轻微的限制:
1. 我们发现了一个JSON解析的bug,不过我们在10分钟内就解决了此bug.
2. BSON的Document键中不支持点(dot).通常,这或许不是个问题,但是我们必须在数据迁移中解决此问题.
3. Document有4MB的大小限制.这对于我们的数据模型来讲不是问题,由于MongoDB对在位的原子更新(atomic in-place updates)有非常好的支持,所以,你需要关注,Document不要超过4MB的限制.
4. 增加新的节点没有在Cassandra中那么容易.然而,Cassandra在新增节点的负载均衡上有它自己的问题.
到目前为止,它的运行还非常平稳.开发人员与数据库管理员的工作也因此减轻了很多.
Cassandra vs HBase
By Vaibhav Puranik Translated By Jametong
我们是一家广告网络公司.我们需要存储展示与点击信息.我们在为我们的新项目评估多个不同的大批量数据(或nosql,或任何你喜欢的称呼)系统.过去8个月中,我们一直在一个测试产品上使用HBase,并且满意它的表现,但是,最近Cassandra的风头很高,因此,我们决定对它做个测试.我认为,从某些角度讲,Cassandra团队的推广做的很不错.你将发现,在Santa Monica，哪怕是非技术人员(诸如风险投资商、CEO以及产品经理)也会相互推荐使用Cassandra.
Cassandra给人的第一印象很好.它们的首页看上去比HBase更加专业也更加友好.安装并运行它也很简单.这个网站的文档很丰富.说实在话,安装并让其工作只花费了我5分钟的时间.
真正的挑战是理解Cassandra的数据模型,并尝试在我们的使用场景中实现它.我们很清楚如何在HBase中实现它,因为我们对HBase有相当不错的使用经验.虽然Cassandra也是从BigTable出继承了同样的数据模型,Cassandra与HBase之间还是有一些根本性的不同的.我试图用表格整理了两个系统之间的差异,如下:
Cassandra
HBase
缺少类似于表的概念.所有的文档都告诉你,有多个Keyspace的情况不常见.这意味着你必须在一个集群中共享同一个key space.另外,新增keyspace需要重启集群才能生效.
存在表相关的概念.每个表都有它自己的key space. 这一点对我们来说很重要.添加/删除表都很容易,跟在RDBMS中一样.
使用字符串的Key.通常使用uuid作为Key.如果希望你的数据按照时间排序,可以使用TimeUUID.
使用二进制Key.通常将三个不同的项目组合在一起来构建一个Key.这意味着你可以搜索一个给定表中的多个键.
即使使用TimeUUID,也不会发生热点问题,因为Cassandra会对客户端请求做负载均衡.
如果Key的第一部分是时间或者序列数,就会发生热点问题.所有新的Key都会被插入同一个区域,一直到此区域被塞满(因而导致出现热点问题).
支持列排序
不支持列排序
超列(Super Column)概念使得你可以设计非常灵活也非常复杂的表结构.
不支持超列.不过可以设计一个类似与超列的结构,不过列名称与值都是二进制的.
没有便捷的方法来自增长一个列的值.实际上,最终一致性的不同特性使得更新/写入一条记录并在更新后立即读出非常困难.必须确保使用R+W>N来实现强一致性.
由于设计上就是一致性.提供了一个非常便捷的方法来自增计数器.非常适合做数据汇总.
刚开始支持Map Reduce接口.还需要有一个hadoop集群来运行它.需要将数据从Cassandra集群迁移到Hadoop集群.不适合对大型数据运行map reduce任务.
对Map Reduce的支持是原生的.HBase构建在Hadoop集群上.数据不需要做迁移.
如果不需要Hadoop的话,维护相对简单.
由于包含多个诸如Zookeeperr、Hadoop以及HBase本身的可活动组件，维护相对复杂.
到目前为止,还没有本地化的Java Api支持.没有Java文档.虽然是使用Java编写的,你还是必须用Thrift接口来与集群进行通讯.
有友好的本地Java API.比Cassandra更像是Java系统.由于我们的应用是基于Java的,这一点对我们很重要.
没有主节点,因此也没有单点故障.
虽然在概念上有一个主节点服务,HBase本身对它的依赖并不严重.即使在主节点宕机的情况下,HBase集群仍然可以正常提供数据服务.Hadoop的Namenode是一个单点故障.
在按照这种方式比较过数据模型与相关特性后,对我们来讲,HBase是明显的优胜者.我的看法是,如果你确实需要一致性,HBase是一个明显的选择.更进一步,本地化的Map Reduce支持、表概念以及可修改而且不用重启集群的简单的表结构是你不可忽略的加分项.HBase是一个更加成熟的平台.当人们说Twitter、Facebook在使用Cassandra时,他们忘记了这些公司同时也在使用HBase.实际上,Facebook最近雇用了一个HBase的代码提交者(Commiter),这清楚地表明Facebook对HBase的兴趣.
总之,我们全力支持HBase!!
以下内容摘自Eric Evans在OSCON上的ppt (Hands On Cassandra)
1. 设置Java的Heap Size.
# Arguments to pass to the JVM
JVM_OPTS=” \
…
-Xmx1G \
…
2. 设置memtable flush的策略.
# 达到的数据量大小(这个与memtable大小的设置一致).
memtable_throughput_in_mb: 64
# 包含的对象数量(单位:百万)
memtable_operations_in_millions: 0.3
# 经过的时间长度
memtable_flush_after_mins: 60
3. 缓存设置策略
keyspaces:
- name: Twissandra
…
column_families:
- name: User
keys_cached: 100 ## 缓存的Key的数量
preload_row_cache: true ##是否预载行缓存
rows_cached: 1000 ##行缓存的键的数量.
…
4. 磁盘访问策略.
# [...]
选择一个键值存储系统(Cassandra Vs Voldemort)
By Diego Erdody on May 07, 2010 Translated by Jametong
目的
在Medallia,我们的系统目前有一个关键组件是运行在一个开源的关系型数据库上.由于此组件主要通过主键来查询数据库的条目,我们想尝试将此组件切换到一个键值存储系统上,以利用键值系统提供的多种好处,包含分布式复制、负载均衡以及失败切换.对此组件进行重构以实现纵向扩展是我们的一个目标,附带的其它好处是,可以缓解我们目前较高的磁盘存储需求.
最近,我们花了部分时间来研究这项技术(以及部分其他技术改进,Medallia激动人心的时刻!),考察了多个不同选项.长话短说,最终落在以下两个选择上:Apache Cassandra与Project Voldemort.
这两个项目看似是他们所在开源类别中最成熟的了,都可以提供内置的分散化集群支持,包含分区、容错性以及高可用性.两者都是基于Amazon的Dynamo论文,主要的差异是,Voldemort遵循简单的键值模型,而Cassandra使用了基于BigTable持久化模型的面向列的模型.两者都支持读一致性,也就是读操作总是返回最新的数据,这一点是我们业务所需要的.
高层次的比较
Project Voldemort
虽然不是一份详尽的清单,下面是我们考查这两个存储系统最关心的优势与劣势.
优势
更简单的API
基于Berkley DB的持久化,一个成熟并广泛使用的键值DB
使用向量时钟而不是简单的时间戳.它不需要节点(客户端)的时钟保持同步.
劣势
没有内置的”多数据中心”相关路由支持(意味着至少有一个额外的数据中心有此数据的一份拷贝)
Apache Cassandra
优势
更广泛的生产系统部署(Facebook、Twitter、Digg、Rackspace)
更丰富的API,值可以支持动态的列结构(Schema-free).列可以独立演化,意味着你不需要读出整个结构就可以更新其中的一列.
为写操作做过专门优化(设计上).
可配置的一致性级别(在每个请求上指定)
劣势
文件格式仍在开发中,内部结构仍然可能会发生变化.鉴于它所支持的灵活性,文件格式更加复杂也更加难以理解,在性能方面尤其如此
需要同步时钟(NTP)(节点与客户端都需要)
与竞争产品相比,读操作更加磁盘密集
不支持客户端的冲突检测,因此最近的数据总是赢家
性能测试
令我们吃惊的是,这是我们找到的对这两个项目的进行性能比较的唯一链接,因此,我们决定写这篇文章来分享我们的研究.我们使用了vpork的测试框架,对它的代码做了修改以适应我们的需求,升级客户端代码到最新版本、添加热身阶段、增加了重写能力。下面是我们测试的结果.
配置:
版本
Voldemort v0.80.1
Cassandra 0.6.0-beta3
机器-3个类似与如下配置的节点
最大4GB的堆大小(heap size)
复制参数: N=3(每个条目的副本数),R=2(每次读时需要等待返回的节点数),W=2(每次写需要等待响应的节点数)
每台服务器上有8个处理器(Intel(R) Xeon(R) CPU E5504 @2.00GHz)
1TB的磁盘空间(Seagate ST31000340NS,7200rpm,32MB Cache)
持久化参数
Voldemort(默认值)
Key-serializer: String
Value-serializer : identity(字节数组)
persistence=bdb(Berkley DB)
Cassandra
ColumnFamily定义: CompareWith=”BytesType” RowsCached=”10000″
ReplicationFactor=3
Partitioner=org.apache.cassandra.dht.RandomPartitioner
ConcurrentReads=16
ConcurrenWrites=32
测试
客户端线程数: 40
初始加载:500万记录-每次测试开始前就有的记录数
热身:2万记录-在记录测试时间前的初始化写操作
每次测试的操作次数:50万
我们测试以下4种不同的写-重写-读配置.一次写操作等价于一个包含一条新记录(不存在的Key)的put操作.一次重写操作是一个包含已有Key的put操作.一次读是对一个已有Key的get操作.下面是我们测试的配置:
50% Write 50% Read
10% Write 40% Rewrite 50% Read
50% Rewrite 50% Read
90% Rewrite 10% [...]
|
|
最近评论