1.【超详细】手把手教你搭建MongoDB集群搭建
2.MongoDB详解
3.mongodb分片集群-chunk&balancer
4.MongoDB自动分片介绍

【超详细】手把手教你搭建MongoDB集群搭建

       超详细手把手教你MongoDB集群搭建

       MongoDB集群搭建主要包括两种有效方式：副本集和分片。码分副本集作为基础组件之一，码分而分片则解决高并发和大数据量下的码分性能挑战，通过将数据分布在多个节点上实现扩展和可用性。码分

       分片机制详解

       分片将数据库切割成小块，码分分散到多台服务器（shard）上，码分vlmscd源码通过mongos协调，码分简化应用层面的码分路由。关键组件包括：

mongos：请求分发中心，码分负责路由操作至对应shard，码分为高可用性，码分通常需要配置HA。码分

config server：存储元数据，码分如分片配置，码分与mongos保持同步，码分多个配置服务器保证数据冗余。

shard：处理部分数据，应对海量数据，每个shard可分摊大负载。

replica set：在shard节点中，用于保证数据可靠性的源码阅读能力名词副本集，生产环境通常有2个副本加1个仲裁节点。

       整体架构与步骤

       搭建一个高可用集群需要个节点，包括Docker环境的准备、网络创建，以及ConfigServer、shard和mongos的逐步部署。以下是关键步骤：

       基础环境：安装Docker，创建Docker网络。

       搭建配置：创建ConfigServer副本集，涉及密钥文件、配置文件和容器启动。

       搭建分片：创建shard分片组，设置密钥文件、配置文件，启动shard节点，初始化并创建用户。

       部署mongos：创建挂载目录，配置文件，启动mongos集群，配置分片信息。ideal查看源码快捷

       使用docker-compose方式配置并启动整个环境。

       全文详细描述了从环境配置到分片和mongos部署的整个过程，确保集群的可靠性和扩展性。

MongoDB详解

       MongoDB 是一个基于分布式文件存储的开源 NoSQL 数据库系统，采用 C++ 编写，提供面向文档的存储方式，操作简单，支持无模式数据建模，适用于存储复杂数据类型。在高负载场景下，MongoDB 支持水平扩展和高可用性，易于添加更多节点以保证服务性能和可用性。

       MongoDB 的数据存储结构类似传统关系型数据库，主要由文档、集合和数据库组成。文档以 BSON（Binary JSON）格式存储，可以嵌套其他文档、数组和文档数组。集合无固定结构，可以存储不同格式和类型的linux编译git源码数据。数据库用于存储所有集合，每个数据库包含集合和权限。MongoDB 支持多种存储引擎，如 MMAPv1 和 WiredTiger，后者默认自 MongoDB 3.2 版本起使用，基于 B+ 树结构。

       MongoDB 的主要优势在于其灵活的数据模型、可扩展的架构和强大的索引支持。适合应用场景包括存储日志、实时存储和离线分析，但具体需求需结合实际情况决定是否使用 MongoDB。

       在存储引擎方面，MongoDB 支持不同类型的存储引擎以适应不同场景需求。WiredTiger 存储引擎默认自 MongoDB 3.2 版本起使用，支持 B+ 树和 LSM(Log Structured Merge) Tree 结构，提供高效的数据存储与检索能力。

       MongoDB 的聚合操作用于汇总多个文档或集合进行计算分析，提供求和、取最大值等功能。聚合操作有两种执行方式，freertos源码如何阅读其中聚合管道提供比 map-reduce 更好的性能和可用性。聚合管道由多个阶段组成，每个阶段转换文档，按顺序处理数据。

       MongoDB 支持事务操作，具备 ACID 特性，允许对多文档进行原子性操作。从 MongoDB 4.0 版本起支持多文档 ACID 事务，而在 MongoDB 4.2 版本后，分布式事务和多文档事务成为同一概念。事务使用场景需考虑性能成本和数据模型设计。

       MongoDB 提供数据压缩功能，借助 WiredTiger 存储引擎，可对所有集合和索引进行压缩，减少存储空间使用。默认使用 Snappy 压缩算法，提供较高压缩效率。其他压缩算法可选，包括 LZ4、LZO、Zstd、Zlib 等。

       MongoDB 索引用于提高查询效率。索引通过限制需要检查的文档数量，加速查询过程，并允许按特定顺序返回结果。支持多种索引类型，如单字段索引、复合索引、多键索引、哈希索引、文本索引和地理索引。复合索引中的字段顺序影响查询方式，遵循左前缀原则。TTL 索引提供数据过期机制，用于管理需要存储有限时间的数据。覆盖索引查询无需在数据文档中检索匹配条件和结果，显著提升查询性能。

       MongoDB 的高可用性主要通过复制集群和分片集群实现。复制集群（副本集）由主节点和从节点组成，主节点负责写操作，从节点进行读操作。主节点故障时，自动选举新的主节点以确保集群连续性。分片集群将数据分布到不同服务器上，解决数据容量和吞吐量增长带来的瓶颈问题，支持水平扩展，适用于处理大量数据和高并发读写场景。分片键是数据分区的关键，影响数据在集群中的分布。

       MongoDB 的复制集群和分片集群提供了高可用性和水平扩展性，适用于大规模数据存储和处理需求。选择 MongoDB 应考虑其优势、应用场景以及与特定业务需求的匹配度。

mongodb分片集群-chunk&balancer

       MongoDB在分片集群中的数据管理机制采用分片(chunk)与balancer策略，以实现高效的数据分布与迁移。在分片模式下，数据通过哈希分片算法分散至不同的分片中，每个分片负责特定的数据范围。具体过程如下：

       1）数据写入时，通过哈希算法确定其所属的分片，并写入相应的chunk。

       2）当分片发生变化，MongoDB更新chunk的元数据信息至config server，并缓存于mongos本地。

       3）查询请求在config server上查找对应的chunk信息，确定需要查询的分片。

       4）数据查询通过分片执行，结果合并后返回客户端。

       5）当chunk超过正常大小或无法再进行分裂时，标记为jumbo chunk，更新config server中的信息。

       6）数据分布不均时，触发chunk的搬迁，更新config server。

       分片(chunk)是MongoDB sharding模式下的核心概念，将集合的数据按照shardKey划分为多个数据子集，每个子集负责特定的数据范围。同一子集的数据存储在同一分片上，数据分布通过记录在config server中的路由信息决定。

       处理chunk大小和数量不均衡问题，MongoDB提供了调整策略，如改变chunk大小和均衡数据搬迁间隔。4.4版本引入了RefineCollectionShardKey命令和balancer设置，支持更灵活的迁移选项，4.2和4.0版本提供了清除jumbo chunk标识的命令。

       数据分裂是解决chunk过大问题的机制，可以手动触发（sh.splitAt, sh.splitFind命令），或自动在插入和更新操作中触发。分裂逻辑上将chunk分割为更小的部分，以实现数据的更均匀分布。

       数据迁移则通过moveChunk命令实现，balancer负责定期检测并触发，或由用户手动发起。迁移过程包括发送方和接收方的数据交换，分为七个步骤：发起迁移、初始化接收方、拉取增量修改、等待接收方完成、发送方进入临界区、接收方执行commit、configsvr执行commit。

       Balancer作为后台进程，确保集合的chunk在各个分片上均衡分布，它运行在config server的主节点，自动从chunk数量最多的分片向数量最少的分片迁移。当遇到性能问题，如movechunk导致的性能抖动，可通过调整均衡时间窗口、控制迁移数据条数和迁移后删除旧chunk的速度等方法优化。

MongoDB自动分片介绍

        1. 片键介绍

        　　数据划分（partitioning）关键问题是怎么样将一个集合中的数据均衡的分布在集群中的节点上。 MongoDB 数据划分的是在集合的层面上进行的，它根据片键来划分集合中的数据。

        （1）使用片键的取值范围指定数据块

        　　设置分片的时候，需要从集合里选出一个字段，用该字段的值作为数据拆分的依据，这个字段称为片键（shard key)，文档中的数据按照这个字段排序切分成块，分布到各个片上。比如说有个表示人员的集合，如果选择名字(“name”)字段作为片键，第一片可能会存放名字以A F开头的文档，第二个存放的是以G P开头的文档，第三个存的Q～Z的名字。随着添加（删除）片，MonogDB会重新平衡数据，使每片的流量都比较均衡，数据量也在合理范围内。

        按照片键取值范围来作为数据块划分的区间依据，优点是按范围查询的时候它的效率很高，当给定一个查询范围，根据mongos中的映射表可以很快的定位到分片上的数据块。除此之外当两个分片的键取值比较靠近的时候，会被放到相近的块中，由于数据的局部性原理，这样的话可以加快查询效率，同时也可以减少内存换页次数。

        缺点是可能会导致数据分布不均衡，如果选择的片键具有线性的性质，例如时间，将其作为片键的话 ，在某个时间段的写请求（读请求）都会被映射到同一个分片的同一个数据块上， 这样的话不仅会降低系统的读写性能，而且也会因写操作过于集中导致片间的不平衡。

        （2）按照片键哈希值来作为数据块的划分区间依据

        　　优点是可以确保一个比较均衡的数据分布，因为即使当两个文档的片键取值很接近的时候，例如上面例子中一个x=，一个x=，它们的哈希结果也会有很大的差别，这样的话数据会随机的分布到集群中，有利于数据的均衡的分布，减少数据块的移动次数，同时由于数据分散会减少单个数据块的写操作的压力，提高写入速度。

        缺点是随机划分导致数据过于分散，当要查询某个范围内的数据时比如年龄大于小于的所有男生信息，如果直接使用范围划分的话，由于其具有良好的数据局部性特点，可能只要访问几个相邻的数据块就行了， 但是如果要使用哈希划分的方法很可能要访问所有的数据块。

        （3）取值有限的片键

        　　这是一种粗力度的片键，比如上边说的用户ID。如果按照用户ID分片，你可以预料到插入会分布在各个分片上，因为无法预知哪个用户何时会插入数据。这样一来，粗粒度分片键也能拥有随机性，还能发挥分片集群的优势。而且粗粒度的片键还能使用局部性带来的效率提升。当某个用户上传个文件，基于用户ID字段的分片建能确保这些插入都落到同一个分片上，并几乎能写入索引的同一部分，这样效率很高。粗粒度分片键在分布性和局部性上都表现很好，但是它也有一个很难解决的问题：块有可能无限制的增长。想想基于用户ID的片键，假如有几个特殊用户，他们上传了上百万个文件，那么一个块里就可能只有一个用户ID，这个块能拆分么？不能，因为用户ID是最小的粒度，拆分了查询就没法路由到数据。这就造成分片之间数据量不均衡。更典型的就是type，status这类的字段，因为它们的选择性实在是太低，导致无法拆分。片键基比较小时，所有的键值相同导致MongoDB不能分裂Chunk，迁移这些不可分裂的Chunk将更加耗时，即使迁移后也难以保证数据在各个分片上的平衡。Chunk数量被基约束住后，我们就不能利用MongoD分片集群特性将集合部署到更多的机器。

        2. 片键的选取原则

        　　在Sharding结构中，分片策略，片键选择是影响性能的关键因素，片键不仅影响数据分布，而且影响业务逻辑，所以片键的选择不单单是均匀的将数据分布到各个片上，而且要考虑查询的性能。坏的片键有时候会导致数据分布很差，有时候会导致无法使用局部性原理，还有一些会影响数据块的拆分。

        　　上边我们讨论了低效片键的问题和原因，理想的片键应该结合粗粒度分片键与细粒度片键两者的优势。

        一个好的片键必须包含的特性：

        1、保证CRUD能利用局限性 ＝＝》升序片键的优点

        2、将插入数据均匀分布到各个分片上 ＝＝》随机片键的优点

        3、有足够的粒度进行块拆分 ＝＝》粗粒度片键的优点

        满足这些要求的的片键通常由两个字段组成，第一个是粗粒度，第二个是粒度较细。那么我们需要使用复合片键。例如对上面的例子，选取{ userid：1，_id:1}作为片键，当用户同时插入数据时，我们可以预见大多数情况下，这些数据会被均匀的分布到所有的片上，而且分片里的唯一字段_id能保证对任意一个文档的查询和更新始终都能指向单个分片。如果对用户ID执行更复杂的查询，那么路由也只会将查询路由包含此用户ID存在的片上，而不会发到所有分片。由于_id（升序）的存在，保证了块始终是能继续拆分的，哪怕用户创建了大量文档，情况也是如此。

        所以在选择片键时尽量能保持良好的数据局部性而又不会导致过度热点的出现，很多时候，组合片键是一种比较常用的做法。

        除此之外，也可以选择我们经常查询的字段作为片键，这类分片键可以使得查询时mongos仅仅将查询发送给特定的mongod实例，不需要等待多个实例返回数据后再进行合并。