他们说生活中的每一件事都值得至少尝试一次。 而且，如果您习惯使用关系型DBMS，那么首先熟悉NoSQL是值得的，首先，至少对于一般开发而言。 现在，由于这项技术的飞速发展，对此主题存在许多矛盾的意见和激烈的辩论，这尤其引起了人们的兴趣。
如果您深入研究所有这些争端的实质，您会发现它们是由于错误的方法而产生的。 那些完全在需要的地方使用NoSQL数据库的人会感到满意，并从此解决方案中获得所有优点。 而依靠这项技术作为根本无法使用的灵丹妙药的实验者，对于失去关系数据库的优势而又未获得重大收益感到失望。
我将向您介绍我们在基于Cassandra DBMS的解决方案实施中的经验：我们必须面对的问题，如何摆脱困境，如何通过使用NoSQL来获得收益以及在哪里必须投入额外的精力/金钱。
最初的任务是构建一个将呼叫记录到特定存储的系统。
系统的原理如下。 具有描述调用结构的特定结构的文件进入输入。 然后，应用程序确保将此结构保存在适当的列中。 将来，保存的呼叫将用于显示有关订户流量消耗的信息（费用，呼叫，余额历史记录）。
为什么选择卡桑德拉（Kassandra）的原因是可以理解的-她写的是机关枪，易于扩展且具有容错能力。
所以，这就是经验给我们的
是的，崩溃的节点不是悲剧。 这就是卡桑德拉容错的本质。 但是该节点可以处于活动状态，同时开始降低性能 。 事实证明，这立即影响了整个群集的性能。
Cassandra不使用其常量对冲Oracle保存的位置 。 而且，如果应用程序的作者事先不了解这一点，那么Cassandra的飞行体验就不会比原始版本差。 他来之后，我们将其插入。
免费的“开箱即用”的Kassandra并不十分喜欢信息安全性： 既没有记录用户操作，也没有权限区分 。 有关呼叫的信息与个人数据有关，这意味着应记录所有以任何方式请求/更改请求的尝试，并可能进行后续审核。 另外，您需要意识到需要为不同的用户在不同级别上分离权限。 可以自由删除整个键空间的简单操作工程师和超级管理员是不同的角色，不同的职责和能力。 如果没有访问权限的这种区分，则与ANY一致性级别相比，数据的价值和完整性将立即受到质疑。
我们没有考虑到呼叫需要认真的分析以及针对各种情况的定期采样。 由于应该将所选记录删除并重写（作为任务的一部分，当数据循环中的数据不正确地传给我们时，我们必须支持更新数据的过程），因此Kassandra在这里不是我们的朋友。 像储钱罐一样，卡桑德拉（Cassandra）可以很方便地放入其中，但是您将无法依靠它。
面临将数据传输到测试区域的问题（测试中有 5个节点，而舞会中只有 20个节点）。 在这种情况下，不能使用转储。
更新写入Kassandra的应用程序的数据模式的问题。 回滚将产生许多墓碑，这些墓碑以不可预测的方式会降低我们的生产率 。 卡桑德拉（Cassandra）针对录音进行了优化，在录音之前并不会考虑太多。 其中包含现有数据的任何操作也是一条记录。 也就是说，删除多余的记录后，我们仅产生了更多的记录，只有其中一部分会被标记为墓碑。
插入超时。 卡桑德拉在录音中很漂亮，但有时传入的音乐流会使她非常困惑 。 当应用程序开始循环几个由于某种原因而无法插入的记录时，就会发生这种情况。 而且，我们将需要一个真正的DBA，它将遵循gc.log，系统日志和调试日志以进行慢速查询，并提供待处理的压缩指标。
集群中的几个数据中心。 在哪里阅读和在哪里写？
也许分为阅读和写作？ 如果是这样，是否应该有一个DC可以在应用程序附近进行读写操作？ 如果我们错误地选择一致性级别，我们是否会真正分裂大脑？ 很多问题，很多未探索的设置，我真的想扭转的功能。
我们如何决定
节点不浪费，禁用SWAP 。 而现在由于内存不足，该节点必须躺下，并且不会产生较大的gc暂停。
因此，我们不再希望数据库中的逻辑。 应用程序开发人员重新学习并开始积极使用自己的代码来确保安全性。 数据存储和处理的完美清晰分离。
我们从DataStax购买了支持。 盒装的Kassandra已停止开发（2018年2月的最后一次提交）。 同时，Datastax提供了出色的服务，并且对现有的IC解决方案进行了大量修改和调整。
我还想指出，Kassandra对于查询样本不是很方便。 当然，CQL是向用户迈出的一大步（与Trift相比）。 但是，如果您拥有整个部门，并且习惯了这种便捷的联接，通过任何字段进行免费过滤和查询优化选项，并且这些部门正在努力解决索赔和事故，那么对他而言，对卡桑德拉（Kassandra）的决定似乎是敌人和愚蠢的。 我们开始解决同事如何制作样品的问题。
我们考虑了两个选项：在第一个选项中，我们不仅在C *中编写调用，而且还在Oracle归档数据库中编写调用。 仅与C *不同，呼叫仅在当月存储在该数据库中（足够的呼叫存储深度用于重新认证的情况）。 在这里，我们立即看到以下问题：如果同步编写，那么我们将失去与快速插入相关的C *的所有优势；如果异步编写，则不能保证所有必要的调用通常都能到达Oracle。 有一个优点，但很大：对于开发，仍然存在相同的熟悉的PL / SQL Developer，也就是说，我们实际上实现了“外观”模式。 我们实现了一种机制，该机制卸载来自C *的调用，从Oracle中的对应表中提取一些数据以进行充实，加入接收到的样本并提供结果，然后以某种方式使用（回滚，重复，分析，欣赏）。 缺点：过程相当多，而且没有操作人员界面。
结果，我们仍然选择第二种选择。 Apache Spark用于来自不同罐头的样品。 该机制的实质在于Java代码，该Java代码使用指定的键（订户，呼叫时间-部分键）从C *中提取数据，并从其他任何数据库中提取必要的数据。 然后，它将它们连接到其内存中，并在结果表中显示结果。 一个网络枪口被火花遮住了，事实证明它非常容易维修。
解决数据更新问题时，促销测试再次检查了几种解决方案。 既可以通过Sstloader进行传输，也可以将测试区域中的群集分为两部分，每个部分都与促销部分交替进入同一群集中，从而由推广提供动力。 更新测试时，计划更改它们的位置：清除测试中起作用的部分并输入到舞会中，另一部分开始分别处理数据。 但是，再想一想，我们更加合理地评估了应该传输的数据，并意识到调用本身是测试的不一致实体，必要时可以快速生成，并且促销数据集不值得传输到测试中。 有几个值得移动的存储对象，但这实际上是几个表，而不是很重的表。 因此，Spark再次为我们提供了解决方案，在我们的帮助下，我们编写并开始积极使用表Prom-Test脚本之间的数据传输。
我们当前的部署策略使我们能够在没有回扣的情况下工作。 在舞会之前，必须进行强制性的测试过渡，因为错误的代价并不高。 如果发生故障，您始终可以删除案例空间并从头开始滚动整个方案。
为了确保Cassandra的持续可用性，您不仅需要dba，而且还需要dba。 使用该应用程序的每个人都应该了解在哪里以及如何查看当前情况以及如何及时诊断问题。 为此，我们积极使用DataStax OpsCenter（工作负载的管理和监视），Cassandra Driver系统指标（写入C *的超时次数，读取C *的超时次数，最大延迟等），监视与Kassandra合作的应用程序本身的工作。
当我们想到上一个问题时，我们意识到我们的主要风险可能在哪里。 这些是数据显示形式，可从几个彼此独立的存储请求中输出数据。 这样我们可以得到非常不一致的信息。 但是，如果我们仅与一个数据中心合作，那么这个问题将同样重要。 因此，这里最合理的事情当然是执行批处理功能，以读取第三方应用程序上的数据，这将确保在单个时间段内接收到数据。 至于性能方面的读写分离，这里我们被风险阻止了，因为DC之间失去一些连接，我们可以得到两个完全不一致的群集。
结果，此刻我们停在记录EACH_QUORUM的一致性级别上，以供读取-LOCAL_QUORUM
简短的印象和结论
为了从运营支持和进一步发展的前景的角度评估解决方案，我们决定考虑在其他方面可以应用这种发展。
如果在移动中，则为“方便时付款”之类的程序评分（我们将信息加载到C *中，使用Spark脚本进行计算），按说明汇总索赔，存储角色并使用角色矩阵计算用户访问权限。
如您所见，曲目丰富多样。 如果我们选择NoSQL的支持者/反对者阵营，那么我们将加入支持者的行列，因为我们得到了加分，而且正是我们的预期。
甚至开箱即用的Cassandra选项都可以实时进行水平缩放，从而绝对轻松地解决了增加系统中数据的问题。 我们设法将一个非常高负荷的机制放入一个单独的电路中，以计算调用的聚合，并分离了应用程序的方案和逻辑，从而摆脱了在数据库本身中编写自定义作业和对象的恶性做法。 我们有机会选择和配置（以加速）我们将在哪个DC上进行计算以及在哪些数据记录上进行保险，我们为自己的单个节点和整个DC的丢失进行了保险。
将我们的体系结构应用于新项目并已经有一定的经验，我想立即考虑到上述细微差别，防止出现一些错误，消除一些最初无法避免的尖锐角落。
例如， 及时跟踪Cassandra的更新 ，因为已经知道并纠正了许多我们收到的问题。
不要将数据库本身和Spark放在同一节点上 （或严格按照可接受的资源使用量除以它们），因为Spark可以吃到比预期的OP更多的东西，因此我们将从列表中迅速得出问题1。
在项目测试阶段提高泵的监控和操作能力。 最初，请考虑我们解决方案的所有潜在使用者的最大值 ，因为数据库结构最终将取决于此。
多次扭曲生成的电路以进行可能的优化。 选择可以序列化的字段。 了解我们可以做哪些其他表以便最正确和最佳地考虑，然后根据请求返回所需的信息（例如，假设我们可以将相同的数据存储在不同的表中，并根据不同的标准考虑了不同的细分，则可以显着节省读取请求的处理器时间）。
立即安装TTL并清除过时的数据是一个好主意。
从Cassandra卸载数据时， 应用程序逻辑应根据FETCH原理工作，以便并非一次将所有行都加载到内存中，而是分批选择。
在将项目转移到上述解决方案之前，建议通过执行一系列崩溃测试来检查系统的容错能力 ，例如，一个数据中心的数据丢失，一段时间内损坏的数据的恢复以及数据中心之间的网络中断。 这样的测试不仅使您能够评估所提议体系结构的优缺点，而且还可以为执行它们的工程师提供良好的预热实践，并且如果在舞会中重现系统故障，那么所获得的技能也将是多余的。
如果我们使用关键信息（例如用于计费的数据，订户债务的计算），则还应注意那些将减少由于DBMS特性而引起的风险的工具。 例如，使用已开发出一种最佳使用策略的nodesync（Datastax）实用程序，以便为了保持一致，不要在Cassandra上形成过多的负载，并且仅在特定时期内将其用于某些表。
好吧，六个月的生命后，和Cassandra在一起？ 通常，没有未解决的问题。 严重的事故和数据丢失，我们也不允许。 是的，我不得不考虑补偿一些以前没有出现过的问题，但最终并没有使我们的体系结构解决方案蒙上阴影。 如果您想要并且不害怕尝试新的事物，同时又不想让自己感到失望，那么请准备好免费免费发生任何事情。 与旧的旧解决方案相比，您将不得不弄清楚，深入研究文档并收集自己的耙子，并且没有理论可以提前准确地告诉您哪个耙子正在等待您。