摘要：我一直在做社交网络的挖掘工作，深感目前的一些技术并不能满足社交挖掘的需要。我并没有用过太多的工具，而且图计算的平台也没有用过，涉及到大规模数据的离线分析，主要是依赖hadoop。不过，这并不妨碍，我从挖掘需求的角度来探讨：社交挖掘到底需要哪些技术基础，需要一些什么样的工具。题目中有一个词：large graph。也有很多人认为是big graph。我之所以改变称谓，主要的原因在我前面的博客中有体现。因为big data中的个体之间，往往具有关系，这个样就组成了一个graph，并且这是个超大的graph。元数据信息要比单纯的big data要高几个量级。所以，为了进一步体现graph之大，我称之 阅读全文

摘要：这篇文章，包含了一些技术，包含了一些回忆。今天看了360的有关Cassandra实践的ppt，有一些感想。让我想起了两年前的一些事情，不过那时，我做的不是存储，而主攻的分布式检索。后来一系列变化，我也经历了很多，后来安下心来，做存储优化，优化的对象就是Cassandra，这也有一年多的时间。理论深厚，心得颇丰，可是仍然缺乏一线经验积累。看到360这么大规模的应用Cassandra，我很高兴。尽管，没有一同战斗，但是我很欣慰，很开心。Cassandra终于摆脱阴影，站起来了。Cassandra在360部署有1500台服务器。国内首屈一指了，还有一家部署规模在这一半左右。不过，单个Cassandr 阅读全文

摘要：一个多月没有更新博客了。我在积累，频繁更新的话，就没有东西写了-_-。不过还是要定期的总结，以备忘，以分享，以交流，以提高。这篇博客说的问题是Cassandra在memtable flush为sstable的时候，大小是如何计算的，以及flush的阈值是如何确定的。这个过程是动态的，并不是设定某个内存的大小，或者qps多少的时候，进行flush。一方面计算过程可能并不那么直接，另一方面1.1.3版本之前，这里隐藏了比较严重的bug：可能会造成内存溢出（很严重）可能会造成L0层的sstable文件很小（长期来看，也比较严重，严重影响读性能）可能会有以下的日志：WARN[MemoryMeter:1 阅读全文

摘要：有关Cassandra Compaction，我写了好多的博客。这是为什么呢？原因很简单，因为Compaction在实际应用中，影响巨大。而且似乎探讨这方面的文章还比较少。 这篇文章不是翻译的，而是要写我自己的经验，我悲催的发现，凡是写自己总结的经验，文章就会很短。我本来打算Leveled Compaction和SizeTiered Compaction的改进分开些，可是自己掂量了一下，都很少，几句话、甚至一句话就搞定了。所以我不得以把原本两篇文章合到一起写。尽管也不错，但是绝对是我的实践经验，希望对大家有帮助。 SizeTiered Compaction改进 SizeTierd Compac 阅读全文

摘要：这篇博客需要对SSD有一定了解，我这里没有详细讨论SSD相关的问题，某些概念不了解自行google，或者留言讨论。Cassandra最大的特点就是将随机写巧妙的转换为顺序写。memtable达到一定大小之后，flush到磁盘（可以是SSD，通常是HDD）。这个特性，对Cassandra在SSD上的应用，带来了天然的优势。现在Cassandra部署情况，较常用的方式是内存+HDD，或者有钱一些的公司内存+SSD。后者主要是想通过SSD随机读的优异表现提升读的性能（大概是HDD的100倍）。但是，我们知道，根据数据局部性原理，数据的热点是永远存在的。所以，全部数据放在SSD上是比较浪费的。除了数据 阅读全文

摘要：当启动一个Cassandra集群的时候，必须选择如何在集群中的不同节点之间划分数据。这是由Cassandra的partitioner来完成的。 在Cassandra中，Cassandra所管理的数据构成了一个环。这个环根据节点的数量划分成相等的区间，这样一个节点就可以负责存储一个区间或者几个区间中的数据。在一个节点能够加入到环中之前，它必须被分配一个token（中文翻译为令牌）。token决定了节点在环中的位置，从而也决定过了节点负责管理的数据范围。 数据根据行键（row key）被划分到不同的节点上。为了确定第一个复本所在的节点，需要在换上顺时针的查找，直到找到一个token的值大于等于行键 阅读全文

摘要：前些日子有同学问如何生成token，原来做Voldemort的时候，官方提供了一个脚本，自动生成，Voldemort只是一致性hash很方便，考虑的因素也少。而Cassandra考虑的就多了，跨机架，跨数据中心，都有很多需要注意的。上次我说了在同一个数据中心很实用，可控的方法。下面讲讲DataStax推荐的一些方法。 【正文开始】 Token是为数据中心中某一特定节点分配某一范围的数据的依据。 当启动一个Cassandra的集群，必须选择数据在集群中节点是如何分布的。partitioner是根据数据的key来决定这行数据存储在哪个节点上。token是独立与partitioner的。每一个节点都 阅读全文

摘要：Cassandra的读写请求，主要包括两部分，client端如何找到节点，请求何时成功返回，以及本地的读写是如何完成的，本地的读写，会在后续的博客中不断给出。本文主要解析前面两个问题。 【正文开始】 Cassandra集群中的所有节点都是对等的。客户端的读写请求可能会发送给集群中的任一节点。当客户端连接了某一个节点，并且开始发送读写请求，那个这个节点因为承担了客户端的操作，就被称为“协调者”。 协调者的工作是充当客户端应用和存储实际请求数据的节点之间的代理。协调者根据数据划分、复制的策略来决定，将实际的读写请求发送到确定的节点。 写请求 协调者会将些请求发送到所有应该存储这条数据的节点（也就是 阅读全文

摘要：这是一篇Jonathan Ellis写的文章，与DynamoDB进行比较，突出Cassandra的优点，但似乎后面的评论，大家并不那么接收Cassandra，尤其是在云主机的环境下。原文在这儿。这篇文章就不详细的翻译了，因为有很多的废话，捡重要的说吧。 Cassandra和DynamoDB有什么关系呢？按照文章的说法儿，这简直就是一个轮回。Cassandra最初的实现，很大程度上借鉴了Dynamo那篇论文的实现。但是数据存储模型等并没有采用。今年，Amazon推出DynamoDB，除了Dynamo基础之外，更是从Cassandra学习了很多内容。很有意思。以至于作者最后开玩笑说，Cassand 阅读全文

摘要：一年的时间很快就过去了，这一年，工作上好像只是围绕这Cassandra。前面也写了不少文章，不过都比较浅，原因种种。从明天开始，我除了翻译一些Cassandra的文章之外，还要把这一年的所得逐渐写出来。和大家分享，讨论，也为Cassandra在国内推广，出点力。尽管不如Hbase那般火热，但是我仍旧十分看好Cassandra。尤其是1.0版本以后的发展，越来越给力。 这篇博客主要列出以后会写的一些点。如果不列出来，不强迫自己，恐怕拖一拖就过去了，对自己对后来搞Cassandra的同学，都不好。所以，我要先列出来：SizeTired Compaction的改进——主要效果会提升读性能【done】 阅读全文

摘要：Cassandra使用叫做Gossip的协议发现集群中其他节点的位置和状态信息。Gossip是一个点对点的通信协议，节点之间会周期进行状态信息交换——这些信息包括当前节点本身信息，以及当前节点存储的其他节点的状态信息。 在Cassandra中，gossip进程每秒钟都会和集群中的其他三个节点交换状态消息。状态信息包括节点自身的信息、以及所存储的其他节点的信息，这样集群中的节点，很快就能够互相了解。gossip消息都有一个版本信息，随着交换的进行，旧的信息会逐渐被旧的信息覆盖。 集群成员和种子节点 当节点第一次启动，它会从配置文件中确定所属Cassandra集群的名字，以及确定seeds nod 阅读全文

摘要：下面，我会尝试翻译一些文章，不会十分按照原文，会加入自己的理解。有不恰当的地方，请大家指正。【正文】 Leveled Compaction策略是1.0版本提出的，主要为了在某些场合克服SizeTiered Compaction策略的缺点。不过很不幸，什么时机选择适用Leveled Compaction策略，并不是那么明朗。下面的内容会给出一些选择Compaction策略的指导建议。 SizeTiered Compaction策略与Leveled Compaction策略的不同 Leveled Compaction有一个基本的特征，可以帮助开发人员确定它是否适合：为了保障，一行数据不会分布在更多 阅读全文

摘要：国内研究使用Cassandra的似乎并不多，远没有Hbase那般火热。偏巧，我就在这块儿并不火热的地方，耕耘了一年多。这一年，有深入研究，有实际运维。我打算把这些东西总结出来(前面也写了一些)，希望对后来使用的同学有帮助。而且，我坚信，使用Cassandra的团队会越来越多。这篇博客我来解释以下SizeTiered策略，这是一个Cassandra1.0之前的比较简单的Compaction策略。我之前的博客有粗略讲过leveled策略（后面会找时间丰富以下）。SizeTiered策略比较简单，可是尽管简单，如果不深入代码，在实际运维的时候，还是会出现异常现象而无法解释，找不到解决办法。SizeT 阅读全文

摘要：最近一直在做Cassandra优化相关的工作，大的方面就是主要考虑如何提升Cassandra的读性能。我主要集中在两点上：索引的优化Cassandra在多级存储介质的环境下的改进这 两点改进目前都已经做完，这里我的师弟也做出了突出的贡献。但是，还有一点，是我除了以上两点以外思考比较多的：就是Compaction操作。现在的 NoSQL数据库必须要有Compaction操作。但是似乎研究界，工业界对于Compaction的关注没有那么多。也可能是这个问题比较简单，大家 不愿意关注。也可能这个问题想要得到好的结果与实际付出不相符合。不管怎样，我还想结合这些天的测试和自己的思考，和大家一起讨论以下的 阅读全文

摘要：这篇博客，对Cassandra配置-cassandra.yaml的配置项进行重点解释。 OptionDefaultValueauthenticatororg.apache.cassandra.auth.AllowAllAuthenticatorauthorityorg.apache.cassandra.auth.AllowAllAuthoritybroadcast_addresssameaslisten_addresscluster_nameTestCluster(这个名字修改了，cassandra-cli连接的时候，需要指定，默认就是连的这个。)column_index_size_in_.. 阅读全文

摘要：有关Cassandra的Compaction机制写了好几篇博客了。好像像我这么纠结Compaction机制的比较少吧。我比较了不同Compaction策略对写性能的影响、读性能的影响，以及compaction本身的性能我也有测试。就是想以具体的数字，来证实Compaction机制的特点，从而找到合适的应用场景。 LeveledCompaction是1.0以后，参考Leveldb实现的一个机制。确实有很多好处，如下：保证90%的读只读一个sstable文件，最坏的情况，当单机有10T数据的时候，7（7层）个sstable无用数据（删除的，过期的）比较少，最多占到10%Compaction空间开销 阅读全文

摘要：在8000w数据规模上，跑了10w个查询，因为数据生成是有YCSB完成的，而且，key也是随机生成的。重复程度不能够模拟真实的应用。测试的结果无法真实表现出Compaction策略之间的差异。不过，我会验证以下。这次是对SizeTiered影响的测试。SSD随机读真的太给力了。是粗略估计HDD的100倍。测试结果如下：冷启动综合数据 RunTime(ms)103728Throughput(ops/sec)9640.598Operations1000000AverageLatency(us)10313.15MinLatency(us)237MaxLatency(us)142498895thP.. 阅读全文

摘要：之前测试过在HDD上的表现，接下来的一组数据是在SSD上表现。这篇博客主要是测试写性能，众所周知，顺序写在SSD上，与HDD上对比，并没有太多的优势，不过，顺序写可以充分的利用SSD，延长SSD的寿命。数据如下：综合数据 RunTime(ms)4381994Throughput(ops/sec)15974.46Operations100000000AverageLatency(us)6237.33MinLatency(us)107MaxLatency(us)660471595thPercentileLatency(ms)1299thPercentileLatency(ms)58OPS情况延迟. 阅读全文

摘要：一直只是看到官方有关LeveledCompactionStrategy优于SizeTieredCompactionStrategy的说法，主要有：节省空间，在做Compaction操作过程中，最多需要预留10%的额外空间，而不是SizeTieredCompactionStrategy做major compaction需要的一倍空间，提高了磁盘的利用率。读性能的提升。主要是因为level内部数据有序，没有重叠。重复数据只会在不同的level之间出现。据说可以保证90%读，只需要读一个sstable。我想这也要在一定的读写比例之下，才能实现。具体有待测试。对于写性能，我没看到什么说明，如果有，大家 阅读全文

摘要：cassandra优化的工作还继续，而且效果不错。等待海量规模数据检验。平时在测试优化cassandra的时候，经常会用到一些命令，有些还挺不好记的，记录到这里，以备查找：修 改CompactionStrategy update column family data with compaction_strategy=LeveledCompactionStrategy and compaction_strategy_options=[{sstable_size_in_mb:10}];设置压缩失效 update column family data with compression_options 阅读全文