网站互动推广,美食电子商务网站建设规划书,移动 网站 素材,哪里有培训网cassandra介绍 多年来#xff0c; Grid Dynamics拥有许多与NoSQL相关的项目#xff0c;尤其是Apache Cassandra。 在这篇文章中#xff0c;我们要讨论一个给我们带来挑战的项目#xff0c;而我们在该项目中试图回答的问题今天也仍然适用。 数字营销和在线广告在2012年很受… cassandra 介绍 多年来 Grid Dynamics拥有许多与NoSQL相关的项目尤其是Apache Cassandra。 在这篇文章中我们要讨论一个给我们带来挑战的项目而我们在该项目中试图回答的问题今天也仍然适用。 数字营销和在线广告在2012年很受欢迎并且对它们的需求仅在增加。 实时出价RTB是领域的组成部分。 实时出价工具假设通过数字广告的实时拍卖来放置购买和出售广告。 如果中标买方的广告将立即显示在发布商的网站上。 实时出价需要服务器端的低延迟响应100ms否则出价将丢失。 我们的客户之一一家美国媒体公司对实时出价和用户跟踪即对网站访问者的行为及其偏好的分析感兴趣。 最初客户用于处理RTB请求的基础结构包括安装Kyoto Cabinet 。 在下图图片1上您可以看到RTB和第三方请求的来源。 所有请求都发送到实时应用程序该应用程序在数据库中执行查找和更新请求。 Kyoto Cabinet会将整个数据集保存在内存中而自定义附件提供了保留管理和持久性功能。 图1.以前的体系结构。 从延迟的角度来看上述架构足够好但是它有几个缺点 可扩展性。 该架构假定仅安装了京都橱柜的服务器就可以垂直扩展。 当时每台服务器都配备了约50GB的内存。 众所周知增加内存量可以长期解决该问题。 坚固性。 如果发生故障仅安装京都橱柜可能会导致非常严重的后果。 跨数据中心复制。 该体系结构在数据中心之间没有自动同步。 手动同步确实令人头疼因为它需要大量其他操作。 我们的任务是为系统创建一个新的体系结构该体系结构不具有上述缺点同时使我们能够在响应延迟方面获得良好的结果。 换句话说我们需要一个数据存储区该数据存储区将允许我们保留用户个人资料以及对其进行查找和更新并且所有操作都将在特定时间间隔内执行。 该体系结构应该围绕这样的数据存储构建。 要求 新的体系结构旨在解决所有这些问题。 对新体系结构的要求如下 持久性一个或两个数据中心停电时任何数据都不应丢失 高可用性应该没有单点故障 可伸缩性通过添加更多节点数据库量应该相对容易增加 跨数据中心复制两个数据中心之间的数据应同步 数据的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 两个 分层压缩策略 之所以使用LeveledCompactionStrategyLCS是因为该客户端的工作流应该具有很多更新操作。 使用LCS的另一个原因是整体数据集大小和读取延迟减小。 两种配置的测试结果均相同 平均延迟时间〜1ms 超时0.01 CPU使用率5 两种配置都满足了我们的需求尽管在此阶段我们没有花时间调查超时的性质。 超时将在后面讨论。 据推测大多数响应时间是由网络传输占用的。 另外我们尝试增加每秒的写查询次数并产生了良好的结果。 没有明显的性能下降。 之后我们进入下一步即测试读取操作。 我们使用了相同的集群。 所有读取请求均以read_consistency_level ONE发送。 写入速度设置为每秒3500个查询。 每个服务器上大约有40GB的数据单个记录的大小约为400字节。 因此整个数据集适合内存大小。 测试结果如下 表1.读取操作的初始测试结果 查看两种配置的测试结果我们发现超时值的百分比不令人满意它们是所需值的2-3倍2-3对1。 此外我们还担心CPU负载过高约20。 至此我们得出的结论是我们的配置有问题。 找到与超时相关的问题的根源并不是一件容易的事。 最终我们修改了Cassandra的源代码并为所有读取请求返回了一个固定值跳过从SSTablesmemtables等进行的任何查找。 之后再次对读取操作执行相同的测试。 结果是完美的GC活动和CPU使用率显着降低并且几乎没有检测到超时。 我们恢复了更改并尝试为GC找到最佳配置。 在尝试了其选项之后我们确定了以下配置 -XX UseParallelGC -XX UseParallelOldGC -XXMaxTenuringThreshold 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读取不会导致其他超时。 图2.改进之前混合模式读写中的磁盘使用情况。 我们尝试修改Cassandra配置选项即populate_io_cache_on_flush如上所述。 默认情况下此选项是关闭的这意味着文件系统缓存未填充新的SSTables。 因此当访问来自新SSTable的数据时将从HDD中读取数据。 将其值设置为true可解决此问题。 下图图3显示了改进后的磁盘读取数。 图3.改进后混合模式下的磁盘使用情况读写。 换句话说在整个数据集缓存在内存中后即使在混合模式下Cassandra也停止了从磁盘读取数据。 值得注意的是虽然从配置文件中排除了该选项但是从2.1版开始默认情况下在Cassandra中populate_io_cache_on_flush选项处于打开状态。 下面的摘要表2描述了我们尝试的更改及其影响。 表2.对Cassandra和系统本身的更改及其对延迟的影响。 最后应用了本文中描述的更改之后我们在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.htmlcassandra
