cassandra

介绍

多年来， Grid Dynamics拥有许多与NoSQL相关的项目，尤其是Apache Cassandra。 在这篇文章中，我们要讨论一个给我们带来挑战的项目，而我们在该项目中试图回答的问题今天也仍然适用。

数字营销和在线广告在2012年很受欢迎，并且对它们的需求仅在增加。 实时出价（RTB）是领域的组成部分。 实时出价工具假设通过数字广告的实时拍卖来放置（购买和出售）广告。 如果中标，买方的广告将立即显示在发布商的网站上。 实时出价需要服务器端的低延迟响应（<100ms），否则出价将丢失。 我们的客户之一，一家美国媒体公司，对实时出价和用户跟踪（即对网站访问者的行为及其偏好的分析）感兴趣。

最初，客户用于处理RTB请求的基础结构包括安装Kyoto Cabinet 。 在下图（图片1）上，您可以看到RTB和第三方请求的来源。 所有请求都发送到实时应用程序，该应用程序在数据库中执行查找和更新请求。 Kyoto Cabinet会将整个数据集保存在内存中，而自定义附件提供了保留管理和持久性功能。

从延迟的角度来看，上述架构足够好，但是它有几个缺点：

1. 可扩展性。 该架构假定仅安装了京都橱柜的服务器就可以垂直扩展。 当时，每台服务器都配备了约50GB的内存。 众所周知，增加内存量可以长期解决该问题。
2. 坚固性。 如果发生故障，仅安装京都橱柜可能会导致非常严重的后果。
3. 跨数据中心复制。 该体系结构在数据中心之间没有自动同步。 手动同步确实令人头疼，因为它需要大量其他操作。

我们的任务是为系统创建一个新的体系结构，该体系结构不具有上述缺点，同时使我们能够在响应延迟方面获得良好的结果。 换句话说，我们需要一个数据存储区，该数据存储区将允许我们保留用户个人资料以及对其进行查找和更新，并且所有操作都将在特定时间间隔内执行。 该体系结构应该围绕这样的数据存储构建。

要求

新的体系结构旨在解决所有这些问题。 对新体系结构的要求如下：

• 持久性（一个或两个数据中心停电时，任何数据都不应丢失）
• 高可用性（应该没有单点故障）
• 可伸缩性（通过添加更多节点，数据库量应该相对容易增加）
• 跨数据中心复制（两个数据中心之间的数据应同步）
• 数据的TTL（过期的用户配置文件应自动清除）
• 数据量（约10亿个具有多个属性的同类记录，其中一个记录约为400字节）
• 吞吐量（每个数据中心每秒5000次随机读取+每秒5000次随机写入）
• 响应延迟（平均3毫秒，对于99％的请求，处理时间不应超过10毫秒）

此外，我们还有一些与基础架构有关的限制。 限制之一是每个数据中心最多只能为每个数据库安装八台服务器。 同时，我们可以选择某些服务器硬件，例如内存量，存储类型和大小。 客户的其他要求之一是使用复制因子TWO，由于数据的统计性质，该因子是可以接受的。 这样可以降低硬件成本。

我们研究了几种可能满足我们要求的解决方案，最后选择了Cassandra。 Cassandra的新体系结构成为一种更为优雅的解决方案。 它只是两个数据中心之间同步的Cassandra集群。 但是有关其硬件规格的问题仍未得到解答。 最初，我们有两个选择：

• SDD，但内存较少（少于整个数据集）
• HDD和更多内存（足以保留整个数据集）

实际上，还有一个选项暗示使用硬盘驱动器和更少的内存，但是这种配置不能提供我们所要求的可接受的读取延迟，因为从HDD随机读取甚至需要10ms RPM的硬盘也需要8毫秒。 结果，它从一开始就被拒绝了。

因此，我们有两种配置。 经过一些调整（调整本身将在下一节中讨论），它们都满足了我们的需求。 他们每个人都有自己的优点和缺点。 SSD配置的主要缺点之一是成本。 当时，企业级SDD相当昂贵。 此外，一些数据中心提供商对使用SSD维护服务器收取额外费用。

使用HDD的方法意味着从磁盘缓存中读取数据。 该配置的大多数缺点与高速缓存有关，例如，冷启动问题。 这是由于在系统重新引导后清除了缓存而造成的。 结果，从HDD读取未缓存的数据会导致额外的超时。 实际上，超时是在10毫秒内没有响应的请求。 此外，由于在启动时从Cassandra服务器复制了大量数据，可能会意外清理磁盘缓存。 最后一个问题与内存大小有关，而不是与缓存有关。 增加单个节点的数据量非常困难。 可以添加一个额外的HDD或几个HDD，但是单台计算机的内存大小是有限的，并且不是很大。

最后，我们设法解决了大多数上述HDD配置问题。 通过使用cat实用程序读取数据并将其输出重定向到启动时的/ dev / null，解决了冷启动问题。 修补了用于创建备份的rsync后，与磁盘缓存清理相关的问题就消失了。 但是内存限制问题仍然存在，并在以后引起了一些麻烦。

最后，客户端选择了HDD + RAM配置。 每个节点在RAID 5 + 0中配备了96GB内存和8个HDD。

调整卡桑德拉

我们开始使用的Cassandra版本是1.1.4。 进一步，在开发过程中我们尝试了不同的版本。 最后，我们决定批准使用1.2.2版，因为它包含我们已承诺对Cassandra存储库进行的更改。 例如，我们添加了一项改进 ，该改进使我们可以为每个列族分别指定populate_io_cache_on_flush选项（它将在内存表刷新和压缩时填充磁盘缓存）。

我们必须测试其余两种配置，以选择一种更好的配置。 在我们的测试中，我们使用了一个Cassandra群集，该群集包含3个节点，每个节点具有64GB内存和8个内核。 我们从写操作开始测试。 在测试期间，我们以每秒7000次写入的速度将数据写入Cassandra。 选择的速度与群集大小和所需的吞吐量成正比（将写入速度加倍，以考虑跨数据中心复制的开销）。 这种方法论适用于所有测试。 值得一提的是，我们使用了以下首选项：

• 复制因子= 2
• write_consistency_level =两个
• 分层压缩策略

之所以使用LeveledCompactionStrategy（LCS），是因为该客户端的工作流应该具有很多更新操作。 使用LCS的另一个原因是整体数据集大小和读取延迟减小。 两种配置的测试结果均相同：

• 平均延迟时间：〜1ms
• 超时：0.01％
• CPU使用率：<5％

两种配置都满足了我们的需求，尽管在此阶段我们没有花时间调查超时的性质。 超时将在后面讨论。 据推测，大多数响应时间是由网络传输占用的。 另外，我们尝试增加每秒的写查询次数，并产生了良好的结果。 没有明显的性能下降。

之后，我们进入下一步，即测试读取操作。 我们使用了相同的集群。 所有读取请求均以read_consistency_level = ONE发送。 写入速度设置为每秒3500个查询。 每个服务器上大约有40GB的数据，单个记录的大小约为400字节。 因此，整个数据集适合内存大小。 测试结果如下：

查看两种配置的测试结果，我们发现超时值的百分比不令人满意，它们是所需值的2-3倍（2-3％对1％）。 此外，我们还担心CPU负载过高（约20％）。 至此，我们得出的结论是我们的配置有问题。

找到与超时相关的问题的根源并不是一件容易的事。 最终，我们修改了Cassandra的源代码，并为所有读取请求返回了一个固定值（跳过从SSTables，memtables等进行的任何查找）。 之后，再次对读取操作执行相同的测试。 结果是完美的：GC活动和CPU使用率显着降低，并且几乎没有检测到超时。 我们恢复了更改，并尝试为GC找到最佳配置。 在尝试了其选项之后，我们确定了以下配置：

• -XX：+ UseParallelGC
• -XX：+ UseParallelOldGC
• -XX：MaxTenuringThreshold = 3
• -Xmn1500M
• -Xmx3500M
• -Xms3500M

我们设法减少了GC对Cassandra性能的影响。 值得注意的是，读取操作的超时次数超过了写入操作的超时次数，因为Cassandra在读取过程中在堆中创建了很多对象，这又导致大量的CPU使用率。 至于等待时间，它足够低，并且可以很大程度上归因于数据传输时间。 与更密集的读取一起执行相同的测试表明，与写入操作相比，增加读取操作的数量会显着影响超时的数量。 据推测，这一事实与GC的生长活性有关。

众所周知，应该为每种情况分别配置GC。 在这种情况下，并发标记扫描（CMS）效果不如Parallel Old GC。 将堆大小减小到相对较小的值也很有帮助。 尽管上面的配置可能不是最好的配置，但它是满足我们需求的一种。 另外，我们尝试了不同版本的Java。 Java 1.7使我们相对于Java 1.6有了一些性能改进。 相对超时数减少了。 我们尝试的另一件事是在Cassandra中启用/禁用行/键缓存。 禁用缓存会略微减少GC活动。

下一个产生令人惊讶结果的选项是池中处理Cassandra中的读/写请求的线程数。 由于我们的基准测试模拟了多个客户端（最多500个线程），因此将该值从32增加到128会对性能产生重大影响。 另外，我们尝试了不同版本的CentOS和SELinux的各种配置。 切换到更高的6.3版本后，我们发现Java期货在较短的时间内通过超时返回了控制权。 SELinux的配置更改对性能没有影响。

解决读取性能问题后，我们便以混合模式（读取+写入）进行了测试。 在这里，我们观察到一种情况，如下图所示（图2）。 每次刷新到SSTable之后，Cassandra开始从磁盘读取数据，这又导致客户端超时增加。 此问题与HDD + RAM配置有关，因为从SSD读取不会导致其他超时。

我们尝试修改Cassandra配置选项，即populate_io_cache_on_flush（如上所述）。 默认情况下，此选项是关闭的，这意味着文件系统缓存未填充新的SSTables。 因此，当访问来自新SSTable的数据时，将从HDD中读取数据。 将其值设置为true可解决此问题。 下图（图3）显示了改进后的磁盘读取数。

换句话说，在整个数据集缓存在内存中后，即使在混合模式下，Cassandra也停止了从磁盘读取数据。 值得注意的是，虽然从配置文件中排除了该选项，但是从2.1版开始，默认情况下在Cassandra中populate_io_cache_on_flush选项处于打开状态。 下面的摘要（表2）描述了我们尝试的更改及其影响。

最后，应用了本文中描述的更改之后，我们在SSD和HDD + RAM配置上均取得了可接受的结果。 在调整Cassandra客户端（我们使用Astyanax）以使其在复制因子为2的情况下正常运行并在超时的情况下可靠地按时返回控制方面也付出了很多努力。 我们还希望分享一些有关操作自动化，监控以及确保跨数据中心复制正常工作的细节，但是很难在一个帖子中涵盖所有方面。 如上所述，我们已经开始使用HDD + RAM配置进行生产，并且可以毫无意外地可靠地工作，包括在不停机的情况下在活动集群上进行Cassandra升级。

结论

卡桑德拉（Cassandra）在引入项目时对我们来说是新手。 我们不得不花费大量时间来探索其功能和配置选项。 它使我们能够实现所需的体系结构并按时交付系统。 同时，我们获得了丰富的经验。 我们进行了大量工作，将Cassandra集成到我们的工作流程中。 我们对Cassandra源代码的所有更改都已反馈给社区。 我们的数字营销客户受益于拥有更稳定，可扩展的基础架构以及自动同步功能，从而减少了他们维护系统所需的时间。

关于网格动力学

Grid Dynamics是为Tier 1零售提供开放，可扩展的下一代商业技术解决方案的领先提供商。 Grid Dynamics在商务技术方面拥有深入的专业知识，并广泛参与开源社区。 伟大的公司与Grid Dynamics合作，通过在全渠道平台，产品搜索和个性化以及持续交付领域中实施和管理解决方案，获得了可持续的业务优势。 要了解更多关于网格动态，找到我们在www.griddynamics.com或者按照我们的Twitter @GridDynamics。

翻译自: https://www.javacodegeeks.com/2015/02/apache-cassandra-low-latency-applications.html

cassandra