Atlas 集群大小调整和层级选择
选择正确的 Atlas 集群层和配置是建立成功的生产 MongoDB 部署的重要步骤。您始终可以稍后修改集群,但只需根据数据集大小和网络要求进行一些计算,就可以开始使用正确的配置。
您还可以将集群配置为根据集群使用情况自动伸缩其集群层和/或存储容量,从而减少集群所需的手动维护工作。要了解更多信息,请参阅集群自动伸缩。
注意
对于生产用途,推荐 M30 或更大的集群
建议在生产环境中使用 M30 及更高版本的集群。 您可以将 M10 和 M20 集群用作低流量应用程序的生产环境。 随着时间的推移,M10 和 M20 层级上 具有持续负载的集群可能会遇到性能下降的情况。
集群自动伸缩
专用集群支持Cluster Auto-Scaling 。在用户界面中创建新集群时,默认启用集群层级自动伸缩。 如果您在API中创建新集群,则默认禁用此功能。 启用自动伸缩后, Atlas可根据集群使用情况自动扩展集群层和/或存储容量。 通过自动伸缩,您的集群可以适应当前的工作负载,并减少手动优化的需要。
90% 的磁盘容量已使用后,集群存储扩展会自动增加集群存储容量。该设置默认启用,确保集群始终能够支持突然涌入的数据。要选择禁用集群存储伸缩,请取消选中 Auto-scale 部分中的 Storage Scaling 复选框。
集群层伸缩会根据各种集群指标,自动向上扩展或向下缩减集群层。要选择禁用集群层自动伸缩,请在 Auto-scale(自动伸缩)部分中取消选中 Cluster Tier Scaling(集群层伸缩)复选框。
如需控制 Atlas 自动扩展集群的方式,需要设置:
集群可以自动扩展到的最大集群层。 默认情况下,此设置为与当前集群层 相比的下一个集群。
集群可以缩减到的最小集群层。 默认情况下,此设置为当前集群层。
内存
内存是指Atlas 集群的每个数据承载节点上可用的总物理RAM 。示例, M30
标准副本集在每个 3 数据承载节点上配置有 8 GB RAM 。
Atlas 使用 WiredTiger 存储引擎。
默认情况下,对于 M40 或更大的集群,WiredTiger 将 50% 或更多物理 RAM 用于 WiredTiger 缓存。剩余内存保留用于以下用途:
内存中操作,例如排序和计算
底层操作系统和其他系统服务
默认情况下,对于 M30 和更小的集群, WiredTiger 将 25% 的物理 RAM 用于 WiredTiger 缓存。
如需了解有关内存使用的更多信息,请参阅 WiredTiger 和内存使用。
MongoDB 使用 WiredTiger 缓存来保存最近使用的数据和索引。 工作集是所有索引加上经常访问的文档集的总和。 如果您的工作集 适合在 RAM 中运行,那么 MongoDB 可以从内存中提供查询服务, 从而实现最快的查询响应时间。
要估计工作集的大小,您可以使用从 db.stats()
获取的总索引空间信息进行计算,并假设数据空间中的一定百分比会被频繁访问,或者也可以使用有根据的假设。
示例:Atlas 样本数据集
我们将使用 Atlas 样本数据集计算在单个 Atlas 集群中运行所有这些数据库所需的内存。以下 JavaScript 程序返回集群的的数据库信息:
var totalIndexSize = 0; var totalDataSize = 0; var reservedDBs = ["admin","config","local"]; // Switch to admin database and get list of databases. db = db.getSiblingDB("admin"); dbs = db.runCommand({ "listDatabases": 1 }).databases; // Iterate through each database and get its stats. dbs.forEach(function(database) { if (reservedDBs.includes(database.name)) return; db = db.getSiblingDB(database.name); print("Obtaining stats for " + database.name); var stats = db.stats(); totalIndexSize += (stats.indexSize / (1024*1024*1024)) ; totalDataSize += (stats.dataSize / (1024*1024*1024)) ; }); print ("Total data size in GB: " + totalDataSize.toFixed(2)); print ("Total index size in GB: " + totalIndexSize.toFixed(2));
此程序返回以下结果:
Obtaining stats for sample_airbnb Obtaining stats for sample_geospatial Obtaining stats for sample_mflix Obtaining stats for sample_supplies Obtaining stats for sample_training Obtaining stats for sample_weatherdata Total data size in GB: 0.32 Total index size in GB: 0.02
要完全在内存中运行这些数据库,您至少需要 0.68 GB 的物理 RAM, 因为 WiredTiger 会使用 50% 的物理 RAM, 我们还至少需要 0.34 GB 才能在内容中容纳工作集。
实际生产集群的数据和索引大小要高得多, 在内存中运行完整的数据集和索引可能不切实际,也可能不符合业务或性能要求。 让我们看看另一个场景。
示例:移动应用
一款流行手游一般有 512 GB 的数据和 32 GB 的索引。 游戏的内部系统数据会占用 16 GB,其余的是玩家个人资料数据。 当玩家在游戏中处于活动状态时,其个人资料需要保存在内存中。 约 25% 的玩家在任何时间点都处于活动状态。 系统数据会频繁使用,并且必须将其全部保存在 RAM 以获得最佳游戏性能。 所有索引也必须保存在 RAM 中,以实现最快的查询响应时间。 内存大小如下:
数据 | RAM 要求 | 用于 WiredTiger 缓存的 RAM |
---|---|---|
系统:16 GB | 100% RAM | 16 GB |
Index: 32 GB | 100% RAM | 32 GB |
数据库资料:496 GB | 25% 在 RAM 中 | 124GB |
考虑到这些要求,您可以预期每个工作集平均需要 172 GB 的 RAM。
WiredTiger 将 50% 的物理 RAM 专用于 WiredTiger 缓存, 因此容纳工作集所需的最小物理 RAM 总量是工作集的两倍。
在此示例中,您需要至少 344 GB 的物理 RAM 来容纳 WiredTiger 缓存和 172 GB 的工作集。 下表列出了合适的 Atlas 集群层级:
服务提供商 | 可能的集群层 | 注意 |
---|---|---|
AWS |
| M300 有足够的 RAM,并且有空间
可以垂直扩展到更高的集群层。 |
GCP |
| M300 有足够的 RAM,但如需纵向扩展,
则没有可用的更高层级。 |
AZURE |
| M300 有足够的 RAM,并且有空间可以垂直扩展到更高的集群层。
|
注意
如果您选择的集群层没有足够的 RAM,例如只有 256 GB RAM 的 Azure M200
,则需要分片。
网络流量
集群节点之间以及消耗 Atlas 集群数据的客户端之间的所有网络流量 都会影响网络带宽。 确定集群大小时,应考虑集群上任何节点所能承载的最大流量, 然后以此为基础选择合适的 Atlas 集群层级。
从集群到客户端应用程序的下游数据传输速率可以计算为一段时间内返回的文档总数的总和。如果仅从主节点读取,则这是唯一需要进行的计算。如果应用程序还从从节点读取,则可以将该数字除以可以提供读取操作的节点数。
您可以使用 db.stats()
方法找到数据库的平均文档大小。将平均文档大小 (avgObjSize
) 乘以每秒提供的文档数量来估算带宽要求。
例子
平均文档大小 10 KB
每秒处理 100,000 份文档
10 KB * 100,000 = 1 GB/秒
Atlas 实例在较高的层级提供更快的带宽速度。AWS 支持的实例在 M30
级别提供高达每秒 10 GB 的速度,而在 M200
级别提供高达每秒 25 GB 的速度。
连接
一个 Atlas 集群可以支持多个客户端连接,具体由集群层决定。例如,M30
集群最多支持 3000 个并行连接,M200
集群最多支持 128,000 个并行连接。要了解详情,请参阅连接限制和集群层。