网易蜂巢 MongoDB服务重磅来袭

Posted 2021-05-01 网易云基础服务

编者按：

近日，网易云基础服务网易蜂巢进行了一次重大的版本更新，上线了 MongoDB数据库服务， Redis 3.0集群，4层负载均衡，云硬盘在线扩容，容器镜像保存等多项功能。

其中重磅推出 MongoDB数据库服务，使网易蜂巢成为业界首家上线 MongoDB 3.4版本的云服务提供商。

使用网易蜂巢的 MongoDB服务，用户不但能体验到MongoDB集关系型数据库和 NoSQL数据库精华于一身的强大功能，还能够进一步享受到蜂巢数据私网内安全访问、全面而灵活的实例监控、节点故障快速恢复、高效的数据自动备份等服务。

MongoDB是目前最为流行的 NoSQL数据库。在2017年1月新鲜出炉的数据库权威排行榜上，MongoDB超越 PostgreSQL，重回第四名的宝座，也是前五名中唯一的 NoSQL数据库，遥遥领先其他 NoSQL数据库。

MongoDB官方调查得出：“MongoDB is generally a good fit for 60%-80% of the applications you may be building today.” 

那么，为什么 MongoDB能够如此通用且受欢迎？原因就在于 MongoDB既有关系型数据库的强大查询功能、强一致性和丰富索引功能的优点，同时又具备 NoSQL数据库灵活的数据模式（JSON-Style）、更好的扩展性和更高的性能。

MongoDB集关系型数据库和 NoSQL数据库精华于一身

1

MongoDB具有灵活动态的文档模型（schema-free, document-oriented）

MongoDB是文档型的 NoSQL数据库，数据以文档的形式在 MongoDB中保存，文档实际上就是一个个 JSON/BSON字符串，非常直观易懂，主流的计算机语言如 Java、Python等对 JSON都有很好的支持。

2

提供了基于复制集（Replica Set）的高可用框架

复制集提供领先的服务高可用和读写负载均衡方案，新节点加入到复制集中会自动进行数据初始同步（Initial Sync），无需人工干预；若复制集的 Primary节点宕机，MongoDB会自动进行主从切换，在大多数节点在线的情况下，自动快速地选出新的 Primary并恢复写服务，同样无需人工干预。

3

提供了数据在线水平扩展机制（Sharding）

Sharding 提供了完善的业务数据和负载水平扩展的机制，每个 shard都保存业务的一部分数据，shard 可以配置为复制集，确保 shard上数据的高可用性。相比复制集，sharding在部署和管理上都复杂很多，只有当业务的数据量达到单个复制集无法支撑，或者业务的负载超过了复制集的服务能力的时候，才需将复制集平滑升级为Sharding。

此外，MongoDB还拥有强大的索引能力，支持创建唯一索引、二级索引、TTL索引和地理位置索引等。在此基础上，通过 explain()和 hint()命令还可以查看查询语句的执行计划，强制查询某个索引，这些特性又可媲美关系型数据库。

蜂巢MongoDB服务，安全有保障

使用蜂巢 MongoDB服务，除了能够体验到上述 所说的 MongoDB的强大功能外，还能够进一步享受到最新 MongoDB 3.4版本所带来的更新，以及蜂巢数据私网内安全访问、全面而灵活的实例监控、节点故障快速恢复、高效的数据自动备份等服务。

 

1

基于3.4版本的最新 MongoDB实例

在网易蜂巢云平台下，只需为 MongoDB实例取个名称，再点击一次鼠标就能够快速完成一个 MongoDB 3.4实例的创建。

MongoDB 3.4相比之前版本，提供更为强大的功能，修复了一直困扰用户的多个 Bug，提供更高更稳定的性能，是部署业务的最佳选择。

蜂巢 MongoDB实例为3个节点组成的复制集，1个 Primary节点，2个用户可见的 Secondary节点，通过三个副本保证数据的高可靠性。用户可以通过设置 Driver连接参数将业务读请求路由到 Secondary节点，分摊 Primary节点的读业务压力，提供更为强劲的性能表现。在 MongoDB实例控制台详情 Tab页，用户能够一目了然地获取实例信息。

蜂巢 MongoDB服务为每个实例提供一个浮动 IP，该浮动 IP作为 MongoDB Driver的 URI种子，用于业务访问 MongoDB服务。浮动 IP始终位于 Primary节点上，若 Primary发生变化，则浮动 IP会飘到新的 Primary节点。

实例除了浮动 IP外，复制集节点各有一个固定 IP，只有在节点重建场景下，固定 IP才会被更换。

 

2

数据私网内安全访问

最近“MongoDB赎金事件”令很多用户对其安全性存疑，但其实MongoDB提供了足够的安全机制来规避这类安全事件，只是需要用户进行比较细致的配置，否则，挂公网IP、不启用安全认证、不设置访问密码等疏漏，就很容易导致安全问题发生。网易蜂巢在这些方面做了严密的防范措施。

蜂巢 MongoDB的浮动 IP和固定 IP均位于蜂巢实例所属用户的私有网络中，无法通过公网进行访问，除非连上该用户的私有网 VPN，这确保了 MongoDB服务的安全性，让用户远离黑客的骚扰。

蜂巢 MongoDB提供 readWriteAnyDatabase权限的账号，满足对 MongoDB进行的集合进行增删改查（CRUD）、创建集合/索引等日常操作。用户只能在蜂巢 MongoDB云控制台修改账号密码。

 

3

节点故障快速修复

蜂巢 MongoDB提供故障自动修复能力，能够处理节点宕机、节点数据过旧、节点网络分区等各种复制集故障。

节点宕机包括 mongod宕机、系统宕机、Agent宕机等。mongod宕机原因可能是 mongod本身 bug导致，mongod所在系统 OOM导致进程被 kill掉；系统宕机指的是 OS宕机，导致整个复制集节点无法访问；Agent宕机指的是部署在复制集节点用于执行管理操作的 Agent进程宕机或 OOM导致 Agent无法正常执行操作命令。在这之中， mongod宕机最容易发生。

节点数据过旧发生在 Secondary节点，原因是由于 opLog集合设置过小使部分 oplog未应用到该 Secondary节点就已经被覆盖，导致该节点无法再跟上其他节点进行复制，数据变得 stale不可访问。

节点网络分区是由于复制集中不同节点将网络通信出现挂载，导致相互间或单向无法连通。该场景可能是网络设置的问题，或者是网络故障导致。在生产环境中时有发生，但在蜂巢 MongoDB下，网络分区出现概率很小，蜂巢底层网络服务能够确保网络连通。

针对上述不同故障，蜂巢 MongoDB服务采取不同的故障恢复方法，对于最常见的 mongod宕机场景，通过重启进行修复。下图所示为 Primary mongod进程宕机重启修复的场景。

其他场景，无法通过重启来解决，则直接进行重建。下图所示为 Primary 系统宕机重建的场景。

总之，通过对故障节点进行重启、重建等方式进行处理，确保 MongoDB复制集快速恢复到 3节点均可用的正常状态。

 

4

全面的实例监控

蜂巢 MongoDB提供了国内公有云服务中最为全面和灵活的实例监控功能。复制集的每个节点均有30余种监控指标，包括系统资源、数据库资源、性能、复制集和日志等多个监控维度。相比业界其他公有云服务，蜂巢 MongoDB的监控粒度更细，覆盖更全面。

用户可以选择查看复制集中任一节点的监控数据，还可以选择查看自己关心的某一时间段的数据，调整监控数据点的时间间隔，数据的统计指标。

更为贴心的是，用户还可以根据业务需求，自定义监控视图版面，自由组合监控指标，仅呈现对业务最为重要的监控数据。

5

数据备份和恢复

蜂巢 MongoDB基于 LVM snapshot进行数据物理备份，相比使用 mongodump的逻辑备份方式，基于 LVM的物理备份优势明显：物理备份不会因为逻辑查询导致  WiredTiger Cache中的热点数据被污染、直接拷贝数据文件性能更高、数据恢复时无需进行请求重放等。

通过在创建 LVM snapshot前后使用 db.fsyncLock()/db.fsyncUnlock()命令，物理备份能够非常方便的获取一致性数据快照。而 mongodump由于在完成数据全量备份后，还需要拷贝备份期间产生的 opLog才能达到一致性备份点，如果此时有部分 opLog已经被覆盖，那么就会导致本次备份失败。

为了进一步减小备份对业务的影响，蜂巢 MongoDB的备份操作只允许在 Secondary节点进行，默认情况下，我们会选取数据最新的 Secondary节点作为备份源。

用户除了随时能够对实例进行手动备份外，还可以设置在业务低峰期对实例进行周期性的自动备份，将这一切托管给蜂巢 MongoDB的备份模块。基于已有的备份，通过点击“恢复”可以快速恢复出一个新的 MongoDB实例（而不是覆盖当前的 MongoDB实例）。需要强调的是，蜂巢 MongoDB的备份是免费的，这进一步降低了客户的使用成本。

除此之外，用户还可通过实例管理控制台修改账号密码、实例名称、自动备份参数、查看 mongod运行日志和对实例进行的操作等。

应用场景

蜂巢 MongoDB服务由业界著名的数据库专家姜承尧负责产品和架构设计，免费提供售前技术支持。为用户提供最好的 MongoDB服务的同时，蜂巢的服务价格也是业界最具竞争力的。

如果用户的业务满足下面一个或多个特点，那么选择 MongoDB是个正确的决定：

○

无需要跨文档或跨表的事务及复杂的join查询支持

○

敏捷迭代的业务，需求变动频繁，数据模型无法确定

○

存储的数据格式灵活，不固定，或属于半结构化数据

○

业务并发访问量大，需数千的QPS

○

TB级以上的海量数据存储，且数据量不断增加

○

要求存储的数据持久化、不丢失

○

需要99.999%的数据高可用性

○

 需要大量的地理位置查询、文本查询

-END-

欢迎大家点击 “阅读原文” 注册试用蜂巢 MongoDB服务。有任何意见和建议，请随时联系我们。