cassandra的读速度为什么这么慢？
我首先写入一行数据，这一行有个super column，写入就是往super column里面插入1000条数据，每条数据都是64 KB大小。写入的速度大概是3秒，我不知道这个写入速度对比其它数据库的速度怎么样，我反正还比较满意。
但是当我读取数据的时候，问题就来了。我尝试读取固定的100条数据，居然要18秒甚至30秒，你没看错，单位是秒。而且我每次读数据时，cassandra占用的内存就上升到1G多，要知道这数据库里只有我前面插入的1000条数据啊。
我用的hector的createSubColumnQuery进行的查询，集群只有一台节点，其它配置都是默认配置。其它运行环境我不列了，我觉得这种几十秒的查询速度和这些都没关系，估计是我哪里没配置好。
我哪里搞错了？
下面是一点日志，我觉得可疑的（有一段时间一直在GC FOR PARNEW）：
INFO [ScheduledTasks:1]
20:37:50,770 GCInspector.java (line 122) GC for ParNew: 1310 ms for 1 collections,
&INFO [ScheduledTasks:1]
20:37:56,770 StatusLogger.java (line 50) Pool Name & & & & & & & & & &Active & Pending & Blocked
&INFO [ScheduledTasks:1]
20:37:58,208 StatusLogger.java (line 65) ReadStage & & & & & & & & & & & & 1 & & & & 1 & & & & 0
&INFO [ScheduledTasks:1]
20:37:58,317 StatusLogger.java (line 65) RequestResponseStage & & & & & & &0 & & & & 0 & & & & 0
&INFO [ScheduledTasks:1]
20:37:58,317 StatusLogger.java (line 65) ReadRepairStage & & & & & & & & & 0 & & & & 0 & & & & 0
&INFO [ScheduledTasks:1]
20:37:58,317 StatusLogger.java (line 65) MutationStage & & & & & & & & & & 0 & & & & 0 & & & & 0
&INFO [ScheduledTasks:1]
20:37:58,333 StatusLogger.java (line 65) ReplicateOnWriteStage & & & & & & 0 & & & & 0 & & & & 0
&INFO [ScheduledTasks:1]
20:37:58,379 StatusLogger.java (line 65) GossipStage & & & & & & & & & & & 0 & & & & 0 & & & & 0
&INFO [ScheduledTasks:1]
20:37:58,379 StatusLogger.java (line 65) AntiEntropyStage & & & & & & & & &0 & & & & 0 & & & & 0
&INFO [ScheduledTasks:1]
20:37:58,379 StatusLogger.java (line 65) MigrationStage & & & & & & & & & &0 & & & & 0 & & & & 0
&INFO [ScheduledTasks:1]
20:37:58,379 StatusLogger.java (line 65) StreamStage & & & & & & & & & & & 0 & & & & 0 & & & & 0
&INFO [ScheduledTasks:1]
20:37:58,442 StatusLogger.java (line 65) MemtablePostFlusher & & & & & & & 0 & & & & 0 & & & & 0
&INFO [ScheduledTasks:1]
20:37:58,442 StatusLogger.java (line 65) FlushWriter & & & & & & & & & & & 0 & & & & 0 & & & & 0
&INFO [ScheduledTasks:1]
20:37:58,442 StatusLogger.java (line 65) MiscStage & & & & & & & & & & & & 0 & & & & 0 & & & & 0
&INFO [ScheduledTasks:1]
20:37:58,442 StatusLogger.java (line 65) InternalResponseStage & & & & & & 0 & & & & 0 & & & & 0
&INFO [ScheduledTasks:1]
20:37:58,442 StatusLogger.java (line 65) HintedHandoff & & & & & & & & & & 0 & & & & 0 & & & & 0
&INFO [ScheduledTasks:1]
20:37:59,114 StatusLogger.java (line 70) CompactionManager & & & & & & & & 0 & & & & 0
&INFO [ScheduledTasks:1]
20:37:59,176 StatusLogger.java (line 82) MessagingService & & & & & & & &n/a & & & 0,0
&INFO [ScheduledTasks:1]
20:37:59,176 StatusLogger.java (line 86) ColumnFamily & & & & & & & &Memtable ops,data &Row cache size/cap &Key cache size/cap
&INFO [ScheduledTasks:1]
20:37:59,223 StatusLogger.java (line 89) system.NodeIdInfo & & & & & & & & & & & & 0,0 & & & & & & & & 0/0 & & & & & & & & 0/1
&INFO [ScheduledTasks:1]
20:38:00,270 StatusLogger.java (line 89) system.IndexInfo & & & & & & & & & & & & &0,0 & & & & & & & & 0/0 & & & & & & & & 0/1
&INFO [ScheduledTasks:1]
20:38:00,333 StatusLogger.java (line 89) system.LocationInfo & & & & & & & & & & & 0,0 & & & & & & & & 0/0 & & & & & & & & 3/3
&INFO [ScheduledTasks:1]
20:38:00,333 StatusLogger.java (line 89) system.Versions & & & & & & & & & & & & 3,103 & & & & & & & & 0/0 & & & & & & & & 0/1
&INFO [ScheduledTasks:1]
20:38:00,364 StatusLogger.java (line 89) system.Migrations & & & & & & & & & & & & 0,0 & & & & & & & & 0/0 & & & & & & & & 0/2
&INFO [ScheduledTasks:1]
20:38:00,379 StatusLogger.java (line 89) system.HintsColumnFamily & & & & & & & & &0,0 & & & & & & & & 0/0 & & & & & & & & 0/1
&INFO [ScheduledTasks:1]
20:38:00,426 StatusLogger.java (line 89) system.Schema & & & & & & & & & & & & & & 0,0 & & & & & & & & 0/0 & & & & & & & & 0/2
&INFO [ScheduledTasks:1]
20:38:00,426 StatusLogger.java (line 89) fyk.file_list & & & & & & & & & &371, & & & & & & & & 0/0 & & & & & &1/200000
就是这样，不断的GC。Cassandra1.1.2调优笔记 续 --阿里云资讯网
Cassandra1.1.2调优笔记 续 -
发布时间：
更新时间：
来源：网络
作者：焦圈
一个数据存储项目，考虑到Cassandra卓越的写性能，决定使用Cassandra作为数据存储服务器。使用前进行了若干/zixun/aggregation/14356.html&&性能测试：分别为写性能和读性能。版本：1.1.2。服务器集群：三台服务器，8核，8G内存，局域网。
结果：写性能测试，复制因子(replication_factor)=2，成功写入一份即可，共测试了4个多小时，写入1亿余条记录，平均每秒6400多条。读性能测试，使用二级索引，成功一份即可，平均每秒多条记录。
-------------------------------------以上结果有待进一步优化------------------------------------
记录下调优主要的几个方面：1）表创建（使用了CQL），配置相关参数：compression_parameters:sstable_compression = 'DeflateCompressor'AND compression_parameters:chunk_length_kb = 64AND caching='KEYS_ONLY';
&其中，compression可以减少使用量，对读写效率一定的提升效果；caching设置为KEYS_ONLY，只对关键字缓存，需要注意的是虽然设置为ALL可以缓存行数据，命中减少两次查找，由于数据量大，内存有限，会导致查询效率很低。2）设置两块物理硬盘，路径分别对应的data_file_directories和commitlog_directory3）cassandra.yaml中commitlog_directory设置为16。4）concurrent_writes：64（并没有比较修改前后写性能变化，不确定优化效果）cassandra.yaml中，其余参数不变。
问题：1）当Cassandra关闭后，内存占用还高达5G，不清楚具体原因。2）使用主键进行查询，性能比第二主键快的不是一点半点，原因还有待研究。
&--------------------------------------------------------后续 优化-------------------------------------------------------
这又做了一些调整，如下，
1）修改JDK，改用JDK7,64位。
2）表创建（使用了CQL），配置相关参数修改为：
&compression_parameters:sstable_compression = 'SnappyCompressor'AND compression_parameters:chunk_length_kb = 64AND caching='KEYS_ONLY'AND read_repair_chance = 0.000001;
测试结果：
写平均每秒8400多条。读平均每秒2000多条记录。
有一定的提升。
PS：对上面第一个问题，我用的是top命令查看， 有以下结果：Mem: 7772048k total, 5703856k used, 2068192k free, 24992k buffers
是我理解有误，used并不表示使用了，而是linux内核当前可控制的内存数，这个和windows是不同的。
本站所有文章全部来源于互联网，版权归属于原作者。本站所有转载文章言论不代表本站观点，如是侵犯了原作者的权利请发邮件联系站长（yanjing@），我们收到后立即删除。
网站主机空间
摘要： 我们知道搜索引擎蜘蛛在访问网站的时候，有个判断因素就是网站打开速度是否快速，所以站长们在选择网站主机空间就要注意了。如果网站主机空间不稳定也会给seo带来一定影响的。 我们知道搜索引擎蜘蛛在访问网站的时候，有个判断因素就是网站打开速度是否快速，所以站长们在选择网站主机空间就要注意了。如果网站主机空间不稳定也会给seo带来一定影响的。 当搜索引擎蜘蛛来访问网站的时候，发现主机死机，无法...
摘要： 心态篇 其实做个人站长自己的心态很重要，不论你是新手站长还是经验丰富的老站长。都该把自己的心态摆正了，网上有很多什么月收入过万的软文，其实真正有几个呢。多数高手都是 心态篇 其实做个人站长自己的心态很重要，不论你是新手站长还是经验丰富的老站长。都该把自己的心态摆正了，网上有很多什么月收入过万的软文，其实真正有几个呢。多数高手都是低调赚钱的。那么个人站长要具备那些心态呢? 第一： 学会...
产品网站订单
摘要： 企业营销已经不再是传统的模式，越来越多的企业英雄通过seo优化的方法做行业关键字排名，希望可以通过关键词获得流量和订单销量，不过很多企业网站的IP流量上涨，订单销量却不 企业营销已经不再是传统的模式，越来越多的企业英雄通过seo优化的方法做行业关键字排名，希望可以通过关键词获得流量和订单销量，不过很多企业网站的IP流量上涨，订单销量却不尽如人意。 很多卖产品的网站存在的一个问题是有流...
2012年的苏宁正面临着同样的挑战。做了二十多年零售的张近东，其面临的现实挑战已经不是让苏宁如何避免撞上冰山，而是已经撞上了冰山，如何让这艘巨轮前行，而不是坐等沉没。 “泰坦尼克号”是如何沉没的? 泰坦尼克号设计中，如果船上的16个防水舱只有4个进水的话，船还可以浮在水上，但不幸的是有5个底舱的外壁被冰山撕裂了，弃船是必然的选择。 苏宁作为中国最优秀的连锁零售商，如果在线零售只是占所有社会商...
网站策划方案
摘要： 要建立一个网站，需要从网站定位，到设计、网站结构、内容准备、内外链的建设等等，是一个复杂繁琐的过程，需要准备一份网站的策划方案。本文将简要描述，从网站的定位到最终 要建立一个网站，需要从网站定位，到设计、网站结构、内容准备、内外链的建设等等，是一个复杂繁琐的过程，需要准备一份网站的策划方案。本文将简要描述，从网站的定位到最终的网站建成，整个过程。 一、网站的定位 分析：给网站定位，策...
行业网站编辑
摘要： 我们需要做一个什么样的网站?很多时候大家感觉做行业网站比较简单容易，于是越来越多的朋友涉足行业网站这一块，加上一些传统行业慢慢向互联网转移，一批批的行业网站建立起来 我们需要做一个什么样的网站?很多时候大家感觉做行业网站比较简单容易，于是越来越多的朋友涉足行业网站这一块，加上一些传统行业慢慢向互联网转移，一批批的行业网站建立起来了。然而不少朋友都问到守护一个很重要的问题是：行业网站到...
售前咨询热线
服务与支持
账号与支持
关注阿里云
Internationalcassandra读性能
相关文档 共3407条,当前页显示
贡献者：| 下载:
文件：4.98KB
贡献者：| 下载:
文件：187.69KB
贡献者：| 下载:
文件：662.97KB
贡献者：| 下载:
文件：43.00KB
贡献者：| 下载:
文件：3.30MB
贡献者：| 下载:
文件：379.00KB
贡献者：| 下载:
文件：1.57MB
贡献者：| 下载:
文件：8.47MB
贡献者：| 下载:
文件：1.13MB
贡献者：| 下载:
文件：449.19KB
贡献者：| 下载:
文件：1.40MB
贡献者：| 下载:
文件：4.26MB
贡献者：| 下载:
文件：576.70KB
贡献者：| 下载:
文件：1.16MB
贡献者：| 下载:
文件：20.63KB
贡献者：| 下载:
文件：62.50KB
贡献者：| 下载:
文件：19.00KB
贡献者：| 下载:
文件：1.46MB
贡献者：| 下载:
文件：759.58KB
贡献者：| 下载:
文件：3.35MB
贡献者：| 下载:
文件：28.00KB
贡献者：| 下载:
文件：194.50KB
贡献者：| 下载:
文件：16.50KB
贡献者：| 下载:
文件：178.03KB
贡献者：| 下载:
文件：190.25KB
贡献者：| 下载:
文件：174.95KB
贡献者：| 下载:
文件：232.60KB
贡献者：| 下载:
文件：180.63KB
贡献者：| 下载:
文件：205.39KB
贡献者：| 下载:
文件：202.36KB
相关标签：
随心阅读：IT人的最佳阅读工具
诚邀优质文档资源者入驻
阅读/下载：20/0 | 25.00KB
阅读/下载：7/0 | 204.49KB
阅读/下载：15/0 | 18.00KB
阅读/下载：88/0 | 44.28KB
阅读/下载：77/0 | 2.11MB
阅读/下载：48/0 | 3.56MB
阅读/下载：114/0 | 554.93KB
阅读/下载：53/0 | 454.27KB
阅读/下载：2389/15 | 12.70MB
阅读/下载：514/6 | 4.98KB
阅读/下载：20/0 | 25.00KB
阅读/下载：7/0 | 204.49KB
阅读/下载：15/0 | 18.00KB
阅读/下载：88/0 | 44.28KB
阅读/下载：77/0 | 2.11MB
阅读/下载：48/0 | 3.56MB
阅读/下载：114/0 | 554.93KB
阅读/下载：53/0 | 454.27KB
阅读/下载：2389/15 | 12.70MB
阅读/下载：514/6 | 4.98KBCassandra评测：突破大数据壁垒的利器
　作者: 核子可乐 编译　编辑:
　　【IT168 专稿】Apache Cassandra是一款免费的开源NoSQL数据库，其设计目的在于管理由大量商用构建起来的庞大集群上的海量数据集(数据量通常达到PB级别)。在众多显著特性当中，Cassandra最为卓越的长处是对写入及读取操作进行规模调整，而且其不强调主集群的设计思路能够以相对直观的方式简化各集群的创建与扩展流程。对于希望寻求一套足以支持快速且规模化增长的数据存储方案的企业用户来说，Cassandra绝对是备选名单中的优先选项之一。　　Cassandra拥有相当骄人的优秀血统。它在数据架构的继承方面不仅受到谷歌Bigtable的巨大影响，同时也从Amazon Dynamo身上汲取到了分布式机制的精髓。与Dynamo类似，Cassandra当中的集群节点完全对称，各自承担相同的处理职责。Cassandra还借用Dynamo风格的统一散列法对数据进行划分与复制。(Dynamo是Amazon推出的一套高可用性键-值存储系统，并以此为基础建立起DynamoDB数据库。)　　Cassandra如何运作　　Cassandra、拥有令人印象深刻的缓存机制与经过精心打造的磁盘I/O分层结构，旨在确保数据的读写速度与内容安全。其存储架构与日志结构合并树颇为相似：写入操作首先被发送到一份持久性提交日志当中(确保写入内容持久性)，而后被回写至“memtable”的缓存当中。当指向memtable的写入过程结束后，对应数据会被发往磁盘上的SSTable当中(即排序字符串表)。所有磁盘写入都属于追加操作——即大型连续写入而非随机写入——因此执行效率很高。每隔一段时间，系统都会对SSTable文件进行合并与压缩。　　Cassandra的集群采取环状组织方式，并利用分区策略保证数据均匀分布到每个节点之上。目前较好的分区工具要数RandomPartitioner，它能够生成一组128位一致性散列以实现数据位置确定。这款分区工具还需要另一款名为“snitch”组件的辅助，后者负责将节点的IP地址与其在机架或者内的物理位置加以映射。　　当Cassandra进行数据写入时，对应数据会被同时写入至多个节点之上、从而保证节点出现故障时这部分数据仍然处于可用状态。这些写入了特定数据元素的节点被称为“副本节点”。Cassandra利用snitch来确保这些承载着任意信息组成部分的副本节点分别处于不同机架当中。否则一旦某台机架发生故障，相应数据元素及其全部复制副本都会丢失。测试中心记分卡易用性管理性说明文档安装难度性价比总体评分<span style="font-size:12font-family:宋体;color:#%<span style="font-size:12font-family:宋体;color:#%<span style="font-size:12font-family:宋体;color:#%<span style="font-size:12font-family:宋体;color:#%<span style="font-size:12font-family:宋体;color:#%Apache Cassandra 2.0<span style="font-size:12font-family:宋体;color:#<span style="font-size:12font-family:宋体;color:#<span style="font-size:12font-family:宋体;color:#<span style="font-size:12font-family:宋体;color:#<span style="font-size:12font-family:宋体;color:#7.8GOOD　　为了在节点发生故障时保证写入能力持续有效，Cassandra采用了“hinted handoffs”机制。简单来说，某个节点在接收到写入请求时、会首先尝试将该请求提交给负责对应数据的副本节点进行处理。如果因为故障而无法正确写入，对应的副本节点(官方给出的名称为‘协调节点’)将把该请求保存为一条“hint”——用于在无法正常运作的副本节点得到修复后再次对其执行写入操作。如果该协调节点事先已经发现副本节点存在问题，则会直接保存hint信息而不再作出无谓的尝试。　　如果集群中的一个或者多个节点利用率过高，Cassandra会利用“虚拟节点”或者叫作“vnodes”功能对负载进行重新分配。在一套完全逻辑化的结构当中，每个虚拟节点在本质上都是一个容器、用于容纳一系列数据库行。由于每个物理节点都会被分配至多个虚拟节点当中，Cassandra能够借此通过将某个虚拟节点从一个负载过高的集群成员迁移至负载较低的集群中去、从而轻松实现负载平衡调整。　　Hinted handoffs属于Cassandra一致性修复功能集中的组成部分。除此之外，另一项名为“read repair”的功能则在读取请求的处理流程中发挥重要作用。根据所选取的一致性级别的不同(我们将在下文中详细阐述)，Cassandra会通过只从单一副本节点中读取信息来满足该读取请求。即便如此，Cassandra仍然要在后台向全部副本节点进行读取，从而验证全部数据副本是否都已经得到正确更新并保持内容一致。　　一致性与速度间的取舍　　RDBMS(即关系型数据库管理系统)的突出优点之一在于始终坚持 ACID四大原则——即原子性、一致性、性与持久性——从而保证各类多客户环设置下的操作确定性;这同样有助于确保系统故障状况下的数据安全。Cassandra这类非关系型数据库会从根本层面上回避ACID原则，这主要是为了避免这几类原则在数据库数据量及I/O请求规模不断拓展时所引发的性能局限。　　Cassandra号称拥有“最终一致性。”当数据被写入到Cassandra当中时，这部分数据并不一定需要被同时写入至各个副本节点。正如我们之前所提到，某些集群成员可能暂时处于不可用状态。不过hinted handoffs的存在能够确保所有节点最终都能具备同样的内容，并由此实现系统一致性。与此同理，read repair机制可以在数据向方向传输时——例如由Cassandra移动至外部环境——追踪内容变更并保持其一致性。　　集群的不同节点中可能存在与特定节点有所不同的数据元素，这种状况很可能引起大家的担忧。好消息是，我们可以对Cassandra的一致性级别加以调整。举例来说，大家可以控制写入操作所遵循的一致性级别——包括向多少个副本节点写入对应数据——然后再向客户应用程序进入实际写入。　　同理可知，我们也能在读取操作中控制相关副本节点的数量、而后再将响应结果返回到客户端。其一致性级别的调整范围可以设定为“Any”，也就是说在任意节点返回响应结果后认定为请求完成。在“Any”与“All”之间大家还可以选择其它一致性级别，例如“Quorum”，即当多数副本节点作出响应时视为请求完成。Cassandra提供的可调整一致性机制堪称一项强大的功能，足以帮助我们在速度与一致性之间作出均衡选择。希望拥有出色的速度表现?请选择“Any”。想要将一致性级别提升至最高点?请选择“All”。　　由于Cassandra是一套分布式方案，因此单一集群成员需要相应机制来识别彼此并进行状态信息沟通。为了实现这一目的，Cassandra的Gossip协议应运而生。与大家猜想的一样，Gossip(即‘绯闻’)这一名称源自人与人之间通过谈话传递一组人类活动信息的随机行为。　　集群中的特定节点被设计为“seed”节点。作为Cassandra节点活动的基本计时单位，其每一秒都会随机与集群内的选定节点进行通信——而所涉及的节点中至少有一个需要是seed节点。有鉴于此，seed节点往往拥有最为实时化的集群内容视角。(当新节点被添加到集群中时，它也需要首先与seed节点进行接触。)　　Cassandra致力于提高Gossip协议的通信效率。每一个节点都保有两种状态类别。其中HeartBeatState用于追踪节点的版本号——版本号会在节点信息发生变更时实施递增——以及节点的重启频率。而ApplicationState负责追踪节点的操作性状态(例如当前负载)。不同节点彼此之间会交换HeartBeatState信息，如果存在差异、这些节点会交换ApplicationState信息并最终交换ApplicationState数据本身。除此之外，Gossip算法还会首先寻求“远端”差异的解决办法(这里的‘远端’是指版本号差异较大的两个节点)，这是因为一般说来版本差异越大、节点内容的一致性冲突就越严重。　　如何使用Cassandra　　熟悉SQL的RDBMS用户应该不会对CQL——也就是Cassandra查询语言——感到陌生，这种语言能够通过基于Python的Cassandra shell程序(即cqlsh)或者其它几种客户端驱动加以运行。大家可以通过Planet Cassandra等网站下载客户端驱动，在这里我们可以找到适用于Java、C#、Node.js、PHP以及其它语言的CQL驱动程序。　　过去，驱动程序与Cassandra集群需要依靠Thrift API实现通信——Thrift是一款用于创建面向客户端及的远程程序调用数量的框架，而且与语言类型无关。Cassandra的Thrift API如今已经成为一项遗留功能，这是因为CQL规范怕定义的已经不仅仅是CQL语言、也包括一套在线通信协议。　　CQL的语法与其关系型表亲颇为相似。它同样拥有SELECT、INSERT、UPDATE以及DELETE语句，而且这些语句都会与FROM及WHERE等子句配合使用。大家可以使用整数、浮点数、双精度以及二进制等数据类型。当然，二者之间也存在差别。其一，CQL已经取消了JOIN操作。而且在我们写入FROM子句时可以指定column family(列族)——强调一句，在CQL最新版本当中用“table”取代了原本的“column family”。CQL还允许我们为任意操作指定需要的一致性级别，不过其真正优势在于、这是一款能够为关系型程序员快速掌握的数据管理语言，而且独立于特定编程API之外。　　Cassandra的安装流程非常简单，特别是在大家下载了DataStax Community版本的情况下——该版本绑定了一款名为OpsCenter的Web管理应用。我在自己的Ubuntu Linux系统上下载并安装了Cassandra的压缩包版本(这是由于apt-get版本由于某种原因而无法安装)，并发现真正的难点在于Cassandra集群的配置。所有与节点及其集群相关的可调节参数都被保存在configuration.yaml文件当中。　　举例来说，大家可以设置分配给对应节点的令牌数量，这一数量决定了该节点负责处理的数据比例(相对于其它节点)。(如果大家的集群由异构式硬件组成，这项将相当实用，因为我们可以通过配置让更多集群成员处理较为繁重的负载。)令人振奋的是，对于小规模试验性安装环境，大家只需要对当前节点以及集群seed节点的IP地址监听机制进行配置即可。　　OpsCenter会在我们的管理主机上运行一项服务器进程，旨在与运行在各集群节点上的代理进程进行通信。这些代理进程负责收集资源利用率及性能信息，并将结果发送至服务器端;服务器则通过一套基于浏览器的用户界面、旨在帮助管理员查看汇总结果。在OpsCenter的帮助下，大家可以完成浏览数据、检查工作量图表、管理列族以及启用集群负载平衡等工作。(顺带一提，我无法让OpsCenter在自己的Linux系统环境下成功运作。虽然DataStax Community版本在Windows环境下能够正常运行，但仍有部分功能无法实现——举例来说，它无法与代理服务相连接。)　　虽然Apache Cassandra以及Planet Cassandra网站上提供说明文档——其中大部分属于常见问题解答、维基百科以及博文内容——但DataStax仍然是最具综合性的Cassandra说明文档及相关教程来源。事实上，Planet Cassandra网站的起始页面或多或少倾向于将访问者引导至DataStax页面。　　DataStax同时提供当前及前续版本的说明文档;当Cassandra获得版本更新时，大家可以借此对尚在使用的任何前续版本进行故障排查。文档页面当中包含丰富的超链接，并提供大量图表帮助各位理解。在视频教程的引导下，大家也可以找到关于Java及C#驱动程序的相关指南以及Cassandra的内部开发者博客。　　就目前来说，Cassandra尚不提供任何交易型功能。不过Cassandra的最新版本(也就是2.0版本)添加了“轻量级交易”机制，从而实现了原子性“比较及设置”架构。这项新特性在CQL中的实际表现就是在INSERT以及UPDATE命令中出现了条件性IF子句。如果特定条件判定为true，那么数据就会得到修改。大家可以由此想见，一条CQL INSERT语句能够只在某行不存在的情况下添加该行，而交易性IF测试的存在能够保证INSERT对于数据库而言始终具备原子性。　　Cassandra 2.0还利用“eager retries”机制改进了响应性能。如果特定副本的读取请求响应速度太低，Cassandra就会将请求发送至其它副本节点处——前提是其它副本节点能够在响应超时之前返回结果。在2.0版本中，Cassandra会以“较为消极”的方式处理陈旧索引消除工作。在过去，陈旧索引会被立即清除，这就要求系统利用同步锁定机制保持一致性。新版本中的新技术避免了由锁定机制带来的生产能力下降。　　尽管Cassandra是一套复杂的系统，但其对称性集群节点设计大大降低了其部署及运行的操作难度。具备大量SQL类特性的CQL同样带来巨大优势，使得原本熟悉RDBMS环境的开发人员能够更快、更轻松地在新领域中获得生产能力。　　不过平心而论，Cassandra的学习曲线仍然不容小觑。大家最好先设置一套规模适中的小型开发集群，并以此为基础进行大量试验、特别是针对数据架构及配置参数的尝试。随着应用程序的不断扩展，性能问题可能会成为大家面临的主要障碍。Apache Cassandra 2.0总体评价优势对称架构使大型集群的创建及扩展变得相对容易与SQL相似的Cassandra查询语言降低了RDBMS开发人员的过渡门槛允许大家调整优先取向：一致性、性能还是二者均衡，由您决定Community版本提供管理GUI良好的说明文档（由Datastax提供）缺点配置过程相当复杂现有触发机制/存储流程机制尚处于实验性阶段管理GUI难于启用及运行适用系统平台CentOS, 红帽, Debian, Ubuntu, Mac OS X, Windows使用成本基于Apache License 2.0版本的免费开源项目　　原文链接：
大学生分期购物销量榜
IT168企业级