Cassandra的数据存储结构——cassandra总结(一) - 马衡 - 博客园
　　Cassandra&的数据模型是基于列族（Column&Family）的四维或五维模型。它借鉴了&Amazon&的&Dynamo&和&Google's&Big&Table&的数据结构和功能特点，采用Memtable的方式进行存储。在&Cassandra&写入数据之前，需要先记录日志&(&Commitlog)，然后数据开始写入到&Column&Family&对应的&Memtable&中，Memtable&是一种按照&key&排序数据的内存结构，在满足一定条件时，再把&Memtable&的数据批量的刷新到磁盘上，存储为&SSTable&。
1.&Cassandra&的数据模型图：
2.Cassandra&的数据模型的基本概念：
　　Cluster：Cassandra&的节点实例，它可以包含多个Keyspace。 　　Keyspace:：用于存放&ColumnFamily&的容器，相当于关系数据库中的&Schema&或&database。
　　ColumnFamily:：用于存放&Column&的容器，类似关系数据库中的&table&的概念&。
　　SuperColumn:：它是一个特列殊的&Column,&它的&Value&值可以包函多个Column。
　　Column:：Cassandra&的最基本单位。由name&,&value&,&timestamp组成。
3.Cassandra中数据存放规则
　　data：存储真正的数据文件，既后面的SStable文件，可以指定多个目录。
　　commitlog：存储未写入SSTable中的数据（在每次写入之前先放入日志文件）。
　　cache：存储系统中的缓存数据（在服务重启的时候从这个目录中加载缓存数据）。
4.Cassandra的特点如下：
　　1.灵活的schema：不需要象数据库一样预先设计schema，增加或者删除字段非常方便（on&the&fly）。
　　2.支持range查询：可以对Key进行范围查询。
　　3.高可用，可扩展：单点故障不影响集群服务，可线性扩展。
5.Cassandra内部数据的排序
　　有一点需要明确，我们使用Cassandra的时候，数据在写入的时候就已经排好顺序了。在某一个Key内的所有Column都是按照它的Name来排序的。我们可以在storage-conf.xml文件中指定排序的类型。目前Cassandra提供的排序类型有：BytesType,&UTF8Type，LexicalUUIDType,&TimeUUIDType,&AsciiType，和LongType。Cassandra的排序功能是允许我们自己实现的，只要你继承org.apache.cassandra.db.marshal.IType就可以了。
本文参考：/developerworks/cn/opensource/os-cn-cassandra/
　　　　　/ggzwtj/archive//2113350.html
　　　　　/art/153.htm
感谢以上文章作者的奉献和分享。研讨页面按键管理的各种方式 - Web前端当前位置:& &&&研讨页面按键管理的各种方式研讨页面按键管理的各种方式&&网友分享于：&&浏览：4次探讨页面按键管理的各种方式
以一个简单的播控页面（机顶盒上的播控页面）为例来探讨页面的按键管理方式（没有鼠标，不考虑组合键）。
简单的播控页面：这个播控页面由2个子页面组成：1）播放页面2）信息面板MINIEPG这2个页面的按键责任如下：1）播放页面： ·up：调出MINIEPG，在其中显示下一个频道的信息； ·down：调出MINIEPG，在其中显示上一个频道的信息； ·CH+：切台，播放下一个频道，并显示当前频道当前节目单的MINIEPG ·CH-：切台，播放上一个频道，并显示当前频道当前节目单的MINIEPG ·OK：显示miniepg ·vol+/-：音量加减2）MINIEPG： ·up：在其中显示下一个频道的信息； ·down：在其中显示上一个频道的信息； ·CH+：切台，播放下一个频道，并展示当前播放的频道和节目单的信息 ·CH-：切台，播放上一个频道，并展示当前播放的频道和节目单的信息 ·OK：隐藏MINIEPG，焦点到了“播放页面” ·vol+/-：音量加减//====页面层次关系可以有两种看法：·MINIEPG是“播放页面”的子页面；·MINIEPG和“播放页面”的同等级页面；//====按键责任分配 情景介绍完了，下面就是对每个页面实际的按键分工进行分析了：1）“MINIEPG”上的up/down、CH+/-、vol+/-其实是“播放页面”在实际起作用，也就是说，这些按键是传递给“播放页面”来执行的；//同样的道理：“SUBMENU”上的up、down、CH+/-、left/right、vol+/-也是最终传递给“播放页面”来执行的；当然，也可以换一个角度来分析。up/down、CH+/-实际是“MINIEPG”页面在起作用：“播放页面”实际只是调出了“MINIEPG”，然后由“MINIEPG”来真正执行；2）“MINIEPG”上的OK等按键却将“播放页面”的OK给屏蔽了；同理如“SUBMENU”对“MINIEPG”；3）在执行CH+/-的时候，“播放页面”需要播放新频道，同一时刻，“MINIEPG”需要展示新频道的信息；//====按键责任分配总结 到目前为止就可以总结出以下几种页面按键责任分配的情况：1、焦点在某个页面上，并响应某个按键；2、两个页面要同时响应某个按键；3、两个页面都有需要对某个按键有响应，但是同一时刻却只能在当前页面有响应；4、某一个按键只有某个页面有响应，但是当前焦点在别的页面上； 又有两种情况： 1)响应了这个按键之后，焦点会移动到这个响应焦点的页面 2)响应了这个按键之后，焦点不变这其中，比较困难的是后面3种情况；//====按键管理方式 我在实际中总结出以下几种按键管理的方式：1、状态模式；----按键独占方式2、责任链模式；----按键捕获和透传方式3、观察者模式；----按键广播方式//====状态模式按键管理方式的代码演示
页面层次关系：MINIEPG和“播放页面”的同等级页面；
可以解决所有的情况；
interface org.ideamarker.as2.keyhandle.example.state.IKeyCodeHandle {
function onUp():V
function onDown():V
function onChanUp():V
function onChanDown():V
function onOk():V
function onVolUp():V
class org.ideamarker.as2.keyhandle.example.state.LiveContext {
private var m_currFocus:IKeyCodeH
private var m_livePlayUI:LivePlayUI;
private var m_liveMiniEpgUI:LiveMiniEpgUI;
public function getCurrFocus():IKeyCodeHandle {
return m_currF
public function getLivePlayUI():IKeyCodeHandle {
return m_livePlayUI;
public function getLiveMiniEpgUI():IKeyCodeHandle {
return m_liveMiniEpgUI;
public function setCurrFocus(_focusUI:IKeyCodeHandle):Void {
m_currFocus = _focusUI;
public function onOk():Void {
m_currFocus.onOk();
public function onUp():Void {
m_currFocus.onUp();
public function onDown():Void {
m_currFocus.onDown();
public function onChanUp():Void {
TODO：“‘按键责任分配总结’中的第1种情况”；
m_livePlayUI.onChanUp();
m_liveMiniEpgUI.onChanUp();
// 焦点移动到了liveMiniEpgUI上；
m_currFocus = m_liveMiniEpgUI;
public function onChanDown():Void {
TODO：“‘按键责任分配总结’中的第1种情况”；
m_livePlayUI.onChanDown();
m_liveMiniEpgUI.onChanDown();
// 焦点移动到了liveMiniEpgUI上；
m_currFocus = m_liveMiniEpgUI;
public function onVolUp():Void {
m_currFocus.onVolUp();
// 或者直接在此处调用m_livePlayUI的onVolUp()；
// m_livePlayUI.onVolUp();
class org.ideamarker.as2.keyhandle.example.state.LivePlayUI implements IKeyCodeHandle {
private var m_context:LiveC
private var m_currPlayChannel:S
public function LivePlayUI(_context:LiveContext) {
m_context = _
public function onUp():Void {
// 调出MINIEPG，在其中显示下一个频道的信息；
// TODO：“‘按键责任分配总结’的第4种的第1种情况”，并且当前焦点被移动到LiveMiniEpgUI上
m_context.setCurrFocus(m_context.getLiveMiniEpgUI());
m_context.getCurrFocus().onUp();
public function onDown():Void {
// 调出MINIEPG，在其中显示上一个频道的信息；
TODO：“‘按键责任分配总结’的第4种的第1种情况”，并且当前焦点被移动到LiveMiniEpgUI上
m_context.setCurrFocus(m_context.getLiveMiniEpgUI());
m_context.getCurrFocus().onDown();
public function onChanUp():Void {
// 切台，播放下一个频道；
m_currPlayChannel = "play the next channel";
public function onChanDown():Void {
// 切台，播放上一个频道；
m_currPlayChannel = "play the pervious channel";
public function onOk():Void {
// 显示miniepg
// TODO：“‘按键责任分配总结’中的第4种的第1种情况”；
m_context.setCurrFocus(m_context.getLiveMiniEpgUI());
public function onInfo():Void {
// 显示miniepg, 同onOk()
// TODO：“‘按键责任分配总结’中的第4种的第1种情况”；
m_context.setCurrFocus(m_context.getLiveMiniEpgUI());
public function onVolUp():Void {
class org.ideamarker.as2.keyhandle.example.state.LiveMiniEpgUI implements IKeyCodeHandle {
private var m_context:LiveC
private var m_info:S
public function LiveMiniEpgUI(_context:LiveContext) {
m_context = _
public function onUp():Void {
// 在其中显示下一个频道的信息；
m_info = "the next channel info";
public function onDown():Void {
// 在其中显示上一个频道的信息；
m_info = "the previous channel info";
public function onChanUp():Void {
// 展示下一个播放的频道和节目单的信息；
m_info = "the next channel info";
public function onChanDown():Void {
// 展示上一个播放的频道和节目单的信息；
m_info = "the next channel info";
public function onOk():Void {
// ·OK/Info/back：隐藏MINIEPG，焦点到了“播放页面”
TODO：“‘按键责任分配总结’中的第2种情况”；
m_context.setCurrFocus(m_context.getLivePlayUI());
public function onVolUp():Void {
// 音量加，按键责任要传递给LivePlayUI
// TODO：“‘按键责任分配总结’中的第4种的第2种情况”；
// 其实在这种情况，完全无需要抽象出接口方法，只需要直接在LiveContext中调用LivePlayUI的onVolUp()方法即可
m_context.getLivePlayUI().onVolUp();
优点：·状态模式可以解决“按键责任分配总结”中的所有情况。但是入门有门槛，没有明显的固定的套路，在情况较为复杂的情况必须要coder有一定的分析能力；缺点：·所有具有对相同按键有响应的方法都需要抽象成相同的接口名称；·如果可以将状态模式再进一步抽象，总结出一个工具类来，那就更加好了----这是我一直在思考的问题；
//====责任链模式按键管理方式的代码演示页面层次关系：MINIEPG是“播放页面”的子页面；
interface org.ideamarker.as2.keyhandle.example.cor.IKeyControlItem {
* 该受控单元的按键处理函数;
public function keyHandle(_keyCode:String):V
* 获取该受控单元需要处理的按键列表;
public function getInterestingKeys():A
class org.ideamarker.as2.keyhandle.example.cor.KeyControlManager {
private var itemList:A
public function KeyControlManager() {
itemList = new Array();
* 向按键状态管理器里面添加一个受控单元;
* 如果一个受控单元被重复添加，则其优先级以最后一次添加的为准;
* @param item 要添加的按键受控单元;
public function regItem(_item:IKeyControlItem):Void {
unRegItem(_item);
itemList.unshift(_item);
* 从按键状态管理器里面移除一个受控单元;
* @param item 要移除的按键受控单元;
public function unRegItem(_item:IKeyControlItem):Void {
for(var i:Number = 0;i & itemList.i++) {
if(itemList[i] == _item) {
itemList.splice(i, 1);
* 按键按下的事件;
public function onKeyCodeHandle(_keyCode:String):Void {
for(var i:Number = 0;i & itemList.i++) {
var item:IKeyControlItem = IKeyControlItem(itemList[i]);
var interestKeys:Array = item.getInterestingKeys();
for(var j:Number = 0;j & interestKeys.j++) {
if(_keyCode == interestKeys[j]) {
item.keyHandle(_keyCode);
// 因为这个return，让这个例子是责任链模式，而不是观察者模式
class org.ideamarker.as2.keyhandle.example.cor.LivePlayUI implements IKeyControlItem {
// 焦点管理工具
private var m_keyControlManager:KeyControlM
// keyCode组的集合
private var m_keyCodeGroup:A
// 当前key组的index
private var m_nowGroupIndex:N
// 子页面 miniepg
private var m_liveMiniEpgUI:LiveMiniEpgUI;
// private var m_currChannel:O
public function LivePlayUI() {
m_keyControlManager = new KeyControlManager();
this.regKeyItem();
this.regKeyCodeGroup();
m_liveMiniEpgUI.setKeyControlManager(m_keyControlManager);
* 注册本页面
private function regKeyItem():Void {
m_keyControlManager.regItem(this);
* 注册本页面感兴趣的键值
private function regKeyCodeGroup():Void {
// 注册键值
m_keyCodeGroup.push([Const.UP, Const.DOWN, Const.CHAN_UP, Const.CHAN_DOWN
, Const.OK, Const.BACK, Const.VOL_UP, Const.VOL_DOWN]);
// 当此例子改成观察者模式的时候放开注释
// m_keyCodeGroup.push([Const.CHAN_UP, Const.CHAN_DOWN, Const.VOL_UP, Const.VOL_DOWN]);
m_nowGroupIndex = 0;
public function keyHandle(_keyCode:String):Void {
switch (_keyCode) {
case (Const.UP):
this.onUp();
case (Const.DOWN):
this.onDown();
case (Const.CHAN_UP):
this.onChanUp();
case (Const.CHAN_DOWN):
this.onChanDown();
case (Const.OK):
this.onOk();
case (Const.VOL_UP):
this.onVolUp();
public function getInterestingKeys():Array {
return m_keyCodeGroup[m_nowGroupIndex];
private function onUp():Void {
// 1.获取下一个频道信息，在miniepg上展示
// 2.展示miniepg
m_liveMiniEpgUI.show("the next channel info");
private function onDown():Void {
// 1.获取上一个频道信息，在miniepg上展示
// 2.展示miniepg
m_liveMiniEpgUI.show("the previous channel info");
private function onChanUp():Void {
// 1.播放下一个频道
// 2.展示miniepg
m_liveMiniEpgUI.show("the next channel info");
private function onChanDown():Void {
// 1.播放上一个频道
// 2.展示miniepg
m_liveMiniEpgUI.show("the previous channel info");
private function onOk():Void {
// 1.展示miniepg
m_liveMiniEpgUI.show("the current channel info");
private function onVolUp():Void {
class org.ideamarker.as2.keyhandle.example.cor.LiveMiniEpgUI implements IKeyControlItem {
private var m_keyControlManager:KeyControlM
// keyCode组的集合
private var m_keyCodeGroup:A
// 当前key组的index
private var m_nowGroupIndex:N
public function LiveMiniEpgUI() {
* 注册本页面
private function regKeyItem():Void {
m_keyControlManager.regItem(this);
* 注册本页面感兴趣的键值
private function regKeyCodeGroup():Void {
// 注册键值
m_keyCodeGroup.push([Const.UP, Const.DOWN, Const.OK]);
// 当此例子改成观察者模式的时候放开注释
// m_keyCodeGroup.push([Const.UP, Const.DOWN]);
m_nowGroupIndex = 0;
public function setKeyControlManager(_keyControlManager:KeyControlManager):Void {
m_keyControlManager = _keyControlM
regKeyItem();
regKeyCodeGroup();
public function show(_chanInfo:String):Void {
public function keyHandle(_keyCode:String):Void {
switch(_keyCode) {
case (Const.UP):
this.onUp();
case (Const.DOWN):
this.onDown();
case (Const.OK):
this.onOk();
public function getInterestingKeys():Array {
return m_keyCodeGroup[m_nowGroupIndex];
private function onUp():Void {
// do sth.
private function onDown():Void {
// do sth.
private function onOk():Void {
// 隐藏miniepg
m_keyControlManager.unRegItem(this);
优点：·抽象出了一个工具类，方便使用，易于理解；缺点：·无法实现“按键责任分配总结”中的第2种情况；
//====观察者模式按键管理方式的代码演示因为多了一个return，上个例子就是责任链模式；如果将这个return去掉，上个例子就可以变成观察者模式；但是，需要做点修改：1）需要添加更多的可能情况的key组；2）m_nowGroupIndex需要随着页面的跳转而改变；
疑惑：1、总是觉得现在这样的状态模式还是不够抽象，能够抽象出像责任链模式例子中的KeyControlManager类就更加好了；2、总是觉得这个责任链模式例子中的代码，不是那么和谐，尤其是keyHandle()方法中的内容（虽然可以使用map来关联keyCode和Function）；有没有更加好的改进方法？
1、本文属于原创文章，历时一周思考得出的结论；
2、由于工作原因，本文代码由Actionscript2实现，语法和Java很类似，请不要对语言的优劣性有任何微词；
12345678910
12345678910
12345678910 上一篇：下一篇：文章评论相关解决方案 12345678910 Copyright & &&版权所有966,690 八月 独立访问用户
语言 & 开发
架构 & 设计
文化 & 方法
您目前处于：
关于Cassandra的错误观点
关于Cassandra的错误观点
Jonathan Ellis
被首富的“一个亿”刷屏？不如定个小目标，先把握住的优惠吧！
相关厂商内容
相关赞助商
更多AWS最新精彩内容和活动，！
你也许还听到过其它这些说法：
&Cassandra是一种列数据库。&会将某个列的全部数据一起保存在磁盘上，这种方式对于数据仓库的检索方式是比较适合的，但对于那些需要对特定的行进行快速访问的应用程序来说就不太适合了。
&Cassandra是一种。&这种说法有一定的道理，因为Cassandra的存储引擎是由Bigtable所启发而设计的，而后者可以说是宽行数据库的祖先了。但宽行数据库的数据模型与存储引擎结合得太过紧密，虽然实现起来比较容易，但针对它进行开发就增加了困难，而且它还使变得不可行了。
我们之所以在开始的部分选择避开&表与行&这种方法，原因之一是因为Cassandra的表与你所熟的关系型数据库的表的确存在着某些微妙的差别。首先，主键的首个元素是分区键，在同一个分区中的所有行都会存储在同一台服务器上，而分区是中的。
其次，Cassandra不支持关联查询与子查询，这是因为在分布式系统中跨越硬件进行关联查询的性能很差。Cassandra的做法是鼓励你采用去正规化（denormalization）的方式，从一个单独的表中获取你所需的数据，同时提供等工具以简化操作。
举例来说，考虑一下以下代码所表示的users表：
CREATE TABLE users (
user_id uuid PRIMARY KEY,
name text,
state text,
birth_year int
目前多数主流服务都会考虑到一个用户可以拥有多个email地址的情况。在关系型数据库中，我们必需建立一个多对一的关系，随后使用关联查询将地址与用户关联起来，如以下所示：
CREATE TABLE users_addresses (
user_id uuid REFERENCES users,
email text
FROM users NATURAL JOIN users_
而在Cassandra中，我们会以去正规化的方式将所有email地址直接加入用户表中，使用一个set集合就可以完美地实现这一点：
ALTER TABLE users ADD email_addresses set&text&;
随后我们可以以如下方式为用户添加多个地址：
UPDATE users
SET email_addresses = {&&, &&}
WHERE user_id = &7e-11e2-8bbd-7cd1c3f676e3&
关于Cassandra数据模型的更多内容，包括自届满数据（self-expiring data）以及分布式计数器，请参考，
误解：Cassandra的读取速度较慢
Cassandra采用的意味着它不会在硬盘中寻找更新，也不会造成固态硬盘的写入放大，而同时它的读取速度也很快。
以下图示是关于随机访问读取、随机访问及顺序扫描，以及混合读写情况下的吞吐数据，它们来自于多伦多大学的NoSQL性能指标分析结果：
来自Endpoint公司的性能指标检测对Cassandra、HBase与MongoDB进行了比较，也。
Cassandra是怎样实现的呢？从一个较高的层次来看，Cassandra的存储引擎看起来与Bigtable很像，它们都使用了一些相同的术语。更新内容会添加到某个commitlog中，随后收集到某个&memtable&里，该表会最终将数据写入磁盘并进行索引，类似于一个&sstable&：
原生的日志结构存储系统确实会倾向于在读取时稍慢，而由于同样的原因，它们在写入时会比较快：因为新的数据不会替换每一行中的原始数据，而是在后台后再进行合并。因此在最坏的情况下，为了获取某个&碎片化&的行中的每一列的值，你将不得不检查多个sstable。
为了达到更好的读取性能，Cassandra对此基本设计方式进行了一些改善：
压缩策略是以插件形式提供的。例如LeveledCompactionStrategy。
Cassandra以时间倒序对sstable进行检查，如果你要求Cassandra执行SELECT x, y FROM foo WHERE key = 42语句，当Cassandra找到x和y对应的某个最新写入的数据时，。同样的原则也可以应用在对某个范围内的扫描上，虽然，但并非不可能实现。
在必须要从多个sstable中进行读取的情况下，我们，这样之后的读取操作就只需要访问一个单独的表了。
当某个分区被访问时，它的，因此只需（每个sstable）一次查找就可以访问分区中的所有行了。
存储引擎的元数据中，这样就避免了垃圾回收带来的影响问题。
误解：Cassandra的运行很麻烦
比起在一台独立的机器上运行数据库，在一个分布式系统上运行会在以下三个方面遇到更多的困难：
初始化时的部署与配置
日常维护工作，例如升级、添加新节点、或者替换故障节点
Cassandra是一个完整的分布式系统：因为Cassandra集群中的每一台机器都具有相同的角色，不存在专门的元数据服务器以调整内存中的各种信息，也不存在专门的配置服务器以进行分发，同样也不存在主服务器或者是故障转移服务器。这种特性使运行Cassandra从各方面而言都要比其它的一些替代产品来得更简单。这也意味着可以很方便地搭建一个单节点的集群以进行开发与测试任务，而它的功能表现与在一个包含大量节点的完整集群中的表现完全一样。
从某种意义上说，初始化时的部署工作其实是一项最不重要的任务，因为如果其它方面的表现相同，那么即使是初始化时的安装稍为复杂一些，随着系统生命周期的推移，这一点麻烦也不是很大的问题，并且自动化的安装工具能够为你隐藏大多数头疼的细节问题。但是！如果你因为对某个系统的了解太小而选择放弃手动安装，那么当你需要对某个问题进行故障诊断时就会遇到麻烦，因为解决问题需要你完全掌握系统中的各个部分是怎样在一起动作的。
因此我的建议是，如果你打算利用某些工具来进行安装，例如、Oracle的、或是，请确保你已经深刻理解了安装过程中的细节。你可以研究一下这个。
Cassandra的日常维护工作很简单。任一时刻都可以在某台节点上进行，而当某个节点停机时，其它节点会保留本应应用在该节点上的升级内容，并给它。此外，添加新节点的操作可以，在操作完成后也无需重新进行平衡。
即使是对那些时间较长的、计划之外的停机状态进行处理也非常方便。Cassandra可在，如同其它数据库中的rsync一样，它只需传输丢失的数据即可，这就将网络数据传输降至最低。如果你没有特别留意的话，也许根本不会意识到。
Cassandra在对方面在整个业界都处于领先地位，即使是，甚至是这些极端情况下，也可以顺利地进行恢复。
最后，能够让你随时看到集群的各种重要系统指标，这样就可以方便地将历史活动数据与造成服务性能下降的事故相关联起来，以达到简化故障检测的目的。自带了一个&轻量级&版本的OpsCenter，可以在生产环境中免费使用。而则包括了备份与恢复的调度，可配置的系统警告以及其它各种特性。
误解：在Cassandra上进行开发非常困难
早先的Cassandra Thrift API的目标是尽量减少用户开发一个跨平台的应用所付出的精力，而它也达到了这一目标，但现在业界已公认这套API是的。随后Cassandra推出了一套自己的SQL语言：CQL。它提供了一套更易于使用的接口，学习曲线更为平滑，同时还推出了，因此取代了Thrift API的使用。
CQL的早期使用者在两年前就可以使用0.8版本了，而今年1月份发布的1.2版本终于使CQL成为一个可用于生产环境的产品了。新版本包含了多种，。DataStax也为提供了官方支持，从此就可以不必再依赖来自社区的Thrift驱动程序的支持了，有时这种支持真的很差。
除了，Patrick McFadin的演讲&Next Top Data Model&（、）也是一个很好的CQL介绍。
误解：Cassandra依然是一种无人问津的边缘产品
从开源的角度来说，Apache Cassandra已有5年的历史，并且已经发布了多个版本，最新的版本2.0还是在今年七月刚刚发布的。而从企业的角度来说，DataStax提供了，其中包含了一个经过认证的Cassandra版本，该版本经过了特定的测试、性能指标衡量、并且得到认可在生产环境中进行使用。
各个商业机构都看到了Cassandra为他们的组织所带来的价值，财富榜上的百强内有20个机构都依赖于Cassandra为他们的关键应用程序提供服务，这些机构来自几乎每个行业，包括金融、医疗、零售、娱乐、在线广告与市场。
将应用迁移至Cassandra平台上的最常见原因之一，是现有技术的伸缩性已经不足以满足现代化大数据应用程序的需求了。Netflix，而Barracuda Networks也，因为MySQL已经不能够应对巨量的垃圾请求了。而Ooyala，它所使用的Cassandra已有超过两个PB的数据量了。
对于那些管理和维护成本过高的陈旧的关系型数据库，Cassandra也在逐步取而代之。Constant Contact的首个基于Cassandra的项目，而他们之前基于关系型数据库的方案则开发了九个月，花费了250万美元。如今，他们已经搭建了，共有超过100TB的数据存放于Cassandra中。
在DataStax的页面，以及Planet Cassandra的页面上还可以找到许多其它案例。
这一条并非误解：关于在旧金山举办的2013 Cassandra Summit大会
我们刚刚结束了本次会议，这可以说是学习更多Cassandra知识的最好机会了。，主讲者分别来自Accenture、Barracuda Networks、Blue Mountain Capital、Comcast、Constant Contact、eBay、Fusion-io、Intuit、Netflix、Sony、Splunk、Spotify、Walmart和其它一些公司。，而演讲视频也即将开放下载，具体时间请密切关注的公告。
Jonathan Ellis是DataStax公司的CTO兼联合创始人。在创办DataStax之前，他在受雇于Rackspace公司时在工作中大量使用了Apache Cassandra。而在Rackspace之前，他基于Reed-Solomon编码技术，为内容备份提供商Mozy编写了一个可容纳多个PB、伸缩性良好的存储系统。
查看英文原文：
Author Contacted
告诉我们您的想法
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
赞助商链接
InfoQ每周精要
通过个性化定制的新闻邮件、RSS Feeds和InfoQ业界邮件通知，保持您对感兴趣的社区内容的时刻关注。
架构 & 设计
文化 & 方法
<及所有内容，版权所有 &#169;
C4Media Inc.
服务器由 提供, 我们最信赖的ISP伙伴。
北京创新网媒广告有限公司
京ICP备号-7
注意：如果要修改您的邮箱，我们将会发送确认邮件到您原来的邮箱。
使用现有的公司名称
修改公司名称为：
公司性质：
使用现有的公司性质
修改公司性质为:
使用现有的公司规模
修改公司规模为：
使用现在的国家
使用现在的省份
Subscribe to our newsletter?
Subscribe to our industry email notices?