数字化转型是大型企业的全球趋势，对于使企业适应现代客户需求至关重要。 除了为大型公司集中系统，将计费系统和订户数据库组合在一起的常见问题外，行业领导者（谷歌，亚马逊，Netflix）已经习惯了客户对高可用性和实时操作模式的要求。
新的挑战需要新的技术和方法，这些新技术和方法必须减少为客户提供方便的功能，个性化的商业报价，对竞争对手报价的快速响应以及控制系统，IT基础架构，数据中心和合格人员的成本的时间。 这些趋势也是一个很大的缺点：架构的复杂性和庞大的事务数据库无法应对信息的流动和处理。 上一代技术具有垂直扩展上限。 例如，一个Oracle DBMS实例在x86处理器上以功能最强大的服务器的极限运行，每天负载十亿次事务。
为了承受Internet行业长期以来一直面临的类似负担，使用了新的技术堆栈，例如内存中缓存和NoSQL数据库。 因此，苹果使用Cassandra，Sberbank-Ignite（GridGain），在MegaFon中使用Couchbase和Tarantool。
MegaFon对内存DBMS使用不同的架构模式：
- 简单的缓存，可以按计划或通过事件从数据库和应用程序中进行更新
- 对数据库的所有更改都是通过缓存（直写脚本）进行的，例如，将Oracle客户端连接到DCP Couchbase
对于我们一个用于订户生命周期的决策系统，我们使用第一个模板，因为只有一个应用程序可以对全部数据进行决策，并将其发送给所有系统，包括Oracle数据库。 使用订户生命周期最聪明的情况之一是在负余额上锁定和解锁。 毕竟，移动运营商的所有订户在补充余额后都希望立即联系并拨打电话。 由于使用了单独的应用程序和Couchbase，我们能够将退出锁定的时间从90秒减少到30秒，这不是限制。 只有有关订户状态变化的记录才会进入主数据库（图1）。
图1（交互示例）通过使用新技术，我们能够将退出财务锁定的时间减少3倍。 但是为了获得当前结果，我们在计费电路的体系结构转换和选择NoSQL数据库方面已经走了很长一段路。
我们为什么选择Couchbase？ 这有几个原因。
性能要求
- 每秒处理多达200,000个请求。
- 平均响应时间（50％）最长为5 ms（在单个数据中心内）。
- 最大响应时间（99％）最长为15 ms（在一个数据中心内）。
- 最大插入性能500 MB /秒
- 最大插入操作次数100,000 / s
- 更改操作的最大数量（文档更新）100,000 / s
- 最高更改性能（文档更新）500 MB /秒
- 最大读取操作次数100,000 / s
- 最高读取速度500 MB /秒
高性能密钥搜索和数据访问
Couchbase的核心是分布式密钥库（KV）。 KV存储库是一种非常简单的数据管理方法，它存储唯一标识符（密钥）以及一条任意信息。 KV存储库本身可以接受任何数据，无论是二进制Blob还是JSON文档。 由于KV实施的简单性，可以确保以最小的延迟进行数据访问。 正如我们的经验所示，网络延迟通常比在Couchbase端提供关键数据要高2-3倍。
动态存储架构（ JSON）
文档以JSON格式存储在Couchbase服务器上。 该格式既支持数字，字符串和复杂类型等基本数据类型，也支持内置字典和数组。
Couchbase中的数据模式是由应用程序和开发人员定义的逻辑结构。 由于其灵活性和使用多个选项的能力，我们可以在文档中使用标签，例如带有版本信息。 这使应用程序可以确定将以哪种模式处理文档，并确保将数据库顺利迁移到新的数据方案。
高可用性
信息系统的组成参数之一是其可用性。 Couchbase具有许多不同功能，可提供高数据可用性。 其中之一是数据复制（在不同的群集服务器上分布多个数据副本），它使您能够在日常维护或某些服务器故障期间提供服务。
图2（Couchbase服务器副本）高可用性的第二个重要功能是内部DCP（数据库更改协议）。 它提供对所有数据副本，二级索引（GSI），跨集群复制（XDCR）和外部使用者的高速更改传输。
双向复制
公司的良好做法是对所有业务流程和设备使用冗余。 理想情况下，当在问题节点之间自动切换时，这是主动-主动模式下的备份。 Couchbase中的双向复制启用AA模式。 但是测试复制表明，复制仅在附近的数据中心有效。 间距超过100公里时，就会出现冲突。 Couchbase具有冲突解决机制：基于时间戳和序列号。 但是，由于网络上的时间延迟，过时的数据会进入数据库。 我们放弃了双向复制（跨集群一致性）的使用。 所有更改仅在一个群集上执行。 所有数据中心（AA）均提供读取模式下的数据可用性。
水平缩放
大多数NoSQL数据库的重要特征之一是水平缩放（图3）。 当我们在集群中只能增加所需服务的性能时，Couchbase的主要区别是对多维扩展的支持。 例如，游戏《 Pokemon GO》使用拆分架构。 在项目开始时，使用了5台具有组合服务的服务器。 在增加负载之后，他们使用了多种架构：5台数据服务器和55台服务器用于处理查询和索引。 使用Couchbase进行扩展的缺点之一是，当群集中有超过50个日期节点时，协调器会出现问题。
图3 MDS
IS要求
信息安全要求在较小程度上影响了我们的选择，但是它们在系统中的存在又增加了支持一个或另一个数据库的论点。 由于缓存可能包含个人数据，因此我们必须遵守监管机构的要求。 值得做出决定：我们将使用其他设备还是为数据库本身提供此设备？
在企业版中，Couchbase支持流量加密，数据加密和个性化访问。 这样可以在诸如Cisco ASA的设备上节省资金。
轻松升级
Couchbase的重要优势之一是其透明的更新机制以及对API较早版本的支持。 在群集升级期间，它以兼容模式工作。 新机制只有在完整的集群升级后才能起作用。 由于支持旧版API，因此对运行中的应用程序的影响很小。
PS：仅在相邻的主要版本上允许升级/降级
附加功能
逻辑分布
另一个有趣的功能是将群集中的服务器组合为逻辑组，并为其附加副本。 这使您可以将同一群集的副本的完整副本分发到不同的自动门。 这使得其中一个汽车经销店无法在第二个汽车经销店拥有完整的数据副本
图4服务器Gropus备份与还原
Couchbase包含现成的备份和恢复工具。 备份过程可以在三种模式下工作：完整，差异和累积。 在某些情况下，这可以节省磁盘空间和处理器资源。
Couchbase和Mongo
选择替代NoSQL数据库的问题很难回答，通常，最好的Unix是您的管理员所知道的。 让我们尝试说明为什么我们偏爱Couchbase，而不是另一个非常流行的平台MongoDB。
比较具有不同体系结构和功能的两个不同项目是非常困难的。 我们关注的参数之一是易于维护，以及能够快速重新配置系统以满足业务需求的能力。
表1比较
| Couchbase
| Mongodb
|
缩放比例
| 整个数据集自动
| 手动键选择
|
资料分配
| 数据始终均匀地分布在所有数据节点上。
| 错误的标记可能会导致数据分布偏斜
|
添加/删除主机或副本
| 通过GUI一步添加它，并进行重新平衡
| 每个集合的权重计算是一项相当困难的任务
|
机架/数据中心分布分布
| 通过逻辑组实施
| 未执行
|
自动负载均衡
| 每个节点具有可用于读取和写入的相同数量的活动记录。
| 不平衡。 辅助节点不支持录制
|
索引缩放
| 灵活，由于架构的多样性，您可以添加单独的节点索引
| 索引的硬缩放与数据缩放相关。
|
集群元数据
| 分布在所有群集节点上
| 需要配置服务器
|
综合搜索
| N1LQ（SQL ++）
| JSON请求
|
表2复制比较
| Couchbase
| Mongodb
|
建筑学
| 集群间复制没有依赖关系，集群彼此独立
| 仅集群内扩展
|
配置灵活性
| 灵活（设置单个存储桶，过滤器，调整）
| 调速
|
拓扑结构
| 双向复制，星形，链形等
| 星号
|
主动主动模式
| 支持者
| 不支援
|
总体而言，Couchbase在我们的任务和快速变化的混合体系结构所需的设置中更灵活，更简单。
操作经验
首先，我们想提供系统和集群现在在Couchbase上运行的编号。
- 超过8000万订户[i]
- 3.8亿个JSON客户信息文档
- 3.5 TB硬盘（我们使用memcached，磁盘上的信息已存储，可快速启动）
- 3 TB内存
- 每秒5万次操作（图5）
- 50个微服务处理整个消息流
图5负载转换的第一个里程碑是从Couchbase的第三版开始的。 在项目开始的第一阶段，所有应用程序都稳定运行。 但是，当将其他逻辑转换为新的机制时，我们面临的事实是View机制开始无法预测地起作用。 即 在某个时候，进程冻结，并且来自此类节点的这些视图停止返回。 同时，对数据的访问及其处理没有中断。 通过重新启动节点可以很容易地解决该问题，这通常会降低服务的可用性。 在与Couchbase技术支持进行通信的过程中，我们获得了一条未记录的命令，该命令仅重新启动查看过程
curl -s --data'cb_couch_sup：restart_couch（）。” -u管理员：通过http://127.0.0.1:8091/diag/eval [ii]
该命令仅在版本3.x中有效。
curl -s --data'couch_server_sup：restart_core_server（）。' -u管理员：管理员 http://127.0.0.1:8091/diag/eval
该命令仅在4.x版本中有效。
第三个版本的另一个问题是破坏数据压缩机制（压缩）。 必须根据触发的监视指标手动启动它。 这两个问题不仅困扰着工作转移，还困扰着功能工程师。
在这方面，我们决定迁移到第四版。 迁移对服务的影响最小，耗时约两周。 更新过程本身不需要复杂的操作和控制，但是在添加或删除节点时，将启动重新平衡，这至少需要两个小时。 在此过程中，我们找到了一种通过缓冲服务器加速更新过程的方法：在这种情况下，它不是启动干净的重新平衡过程，而是将数据从一个节点传输到另一个节点。 这样将更新过程减少到30分钟。
在更新工业集群时，必须考虑以下细微差别：当集群以最新版本的软件运行时，以兼容模式工作。 从积极的一面来说，升级过程可以顺利，轻松地进行，但是，在整个集群完全更新之前，您将无法使用新功能，例如新的压缩机制N1QL。
更新后，我们仅解决了一个问题-压缩。 它开始正常工作。 使用View机制，问题仍然存在，尽管重复的频率要低得多。 只有通过4.6.4版中的Couchbase开发人员的力量才能纠正它。
作为解决技术支持问题的一部分，很明显，视图机制将不再更新。 这样做的依据是，大多数Couchbase客户端都不使用视图的创建目的，而Couchbase则创建了一种新的N1QL机制。 它由单独的服务执行，现在不依赖于数据节点（图7）。
图7节点角色我们关闭了4.6.4版中的所有关键问题。 但是由于数据量的增加，他们决定迁移到第五版，在那里他们为索引添加了一个新的数据库，并且在我们的数据上，内存和磁盘的数量减少了一半半。 但是，不幸的是，我们没有看到数据节点上的数据量减少。
结论
总的来说，Couchbase被证明是一个成熟的系统，即使在非特定情况下（Viber-用作数据库），它也具有很高的负载。 在MegaFon混合体系结构内，可以轻松地将集群适应于任何目的，而无需停机，也无需进行严重的服务器重新配置，这通常使公司能够减少人员成本并为订户提供尽可能方便的服务。
宝兆丰
2018 Kovalchuk埃戈尔
[i]该系统不仅处理订户，而且还处理具有内置SIM卡，调制解调器等的设备。
[ii]使用前请咨询专家