MongoDB · 特性分析· Sharding原理与应用

MongoDB Sharded Cluster 原理

如果你还不了解 MongoDB Sharded cluster,可以先看文档认识一下

什么时候考虑用 Sharded cluster?

当你考虑使用 Sharded cluster 时,通常是要解决如下2个问题

  1. 存储容量受单机限制,即磁盘资源遭遇瓶颈。
  2. 读写能力受单机限制(读能力也可以在复制集里加 secondary 节点来扩展),可能是 CPU、内存或者网卡等资源遭遇瓶颈,导致读写能力无法扩展。

如果你没有遇到上述问题,使用 MongoDB 复制集就足够了,管理维护上比 Sharded cluster 要简单很多。

如何确定 shard、mongos 数量?

当你决定要使用 Sharded cluster 时,问题来了,应该部署多少个 shard、多少个 mongos?这个问题首富已经指点过我们,『先定一个小目标,比如先部署上1000个 shard』,然后根据需求逐步扩展。

回到正题,shard、mongos 的数量归根结底是由应用需求决定,如果你使用 sharding 只是解决 『海量数据存储』的问题,访问并不多,那么很简单,假设你单个 shard 能存储 M, 需要的存储总量是 N。

  numberOfShards = N / M / 0.75    (假设容量水位线为75%)
  numberOfMongos = 2+ (因为对访问要求不高,至少部署2个 mongos 做高可用即可)
时间: 2024-09-20 20:50:16

MongoDB · 特性分析· Sharding原理与应用的相关文章

MongoDB · 特性分析 · 索引原理

为什么需要索引? 当你抱怨MongoDB集合查询效率低的时候,可能你就需要考虑使用索引了,为了方便后续介绍,先科普下MongoDB里的索引机制(同样适用于其他的数据库比如mysql). mongo-9552:PRIMARY> db.person.find() { "_id" : ObjectId("571b5da31b0d530a03b3ce82"), "name" : "jack", "age" :

MongoDB · 特性分析 · Sharded cluster架构原理

为什么需要Sharded cluster? MongoDB目前3大核心优势:『灵活模式』+ 『高可用性』 + 『可扩展性』,通过json文档来实现灵活模式,通过复制集来保证高可用,通过Sharded cluster来保证可扩展性. 当MongoDB复制集遇到下面的业务场景时,你就需要考虑使用Sharded cluster 存储容量需求超出单机磁盘容量 活跃的数据集超出单机内存容量,导致很多请求都要从磁盘读取数据,影响性能 写IOPS超出单个MongoDB节点的写服务能力 如上图所示,Shardi

MongoDB · 特性分析 · MMAPv1 存储引擎原理

MongoDB 的 mongod 服务管理一个数据目录,可包含多个DB,每个DB的数据单独组织,本文主要介绍 MMAPv1 存储引擎的数据组织方式. Database 每个 Database(DB) 由一个.ns文件及若干个数据文件组成 $ll mydb.* -rw------- 1 ydzhang staff 67108864 7 4 14:05 mydb.0 -rw------- 1 ydzhang staff 16777216 7 4 14:05 mydb.ns 数据文件从0开始编号,依次

MongoDB · 特性分析 · 网络性能优化

从 C10K 说起 对于高性能即时通讯技术(或者说互联网编程)比较关注的开发者,对C10K问题(即单机1万个并发连接问题)应该都有所了解.『C10K』概念最早由 Dan Kegel 发布于其个人站点,即出自其经典的<The C10K problem>一文[1]. 于是FreeBSD推出了kqueue,Linux推出了epoll,Windows推出了IOCP.这些操作系统提供的功能就是为了解决C10K问题. 常用网络模型 方案 名称 接受连接 网络 IO 计算任务 1 thread-per-co

MongoDB Sharded cluster架构原理

为什么需要Sharded cluster? MongoDB目前3大核心优势:『灵活模式』+ 『高可用性』 + 『可扩展性』,通过json文档来实现灵活模式,通过复制集来保证高可用,通过Sharded cluster来保证可扩展性. 当MongoDB复制集遇到下面的业务场景时,你就需要考虑使用Sharded cluster 存储容量需求超出单机磁盘容量 活跃的数据集超出单机内存容量,导致很多请求都要从磁盘读取数据,影响性能 写IOPS超出单个MongoDB节点的写服务能力 如上图所示,Shardi

GPDB · 特性分析 · Segment 修复指南

问题背景 GPDB是中央控制节点式的架构,在一个 GreenPlum 集群中,有一个 Master 节点和多个 Segment 节点.Master 是中央控制节点,Segment 是数据存放节点.所有的Segment节点平等,均由Master管理.架构如下图: GreenPlum架构图 当GP Master出现问题的时候,可以通过外部的HA监控模块发现并激活备库,Standby Master 正常后删除原来的 Master 进行重建备库. 而 Segment 的修复与此不同!由上图可知,Segm

[WCF 4.0新特性] 路由服务[原理篇]

在一个典型的服务调用场景中,具有两个基本的角色,即服务的消费者和服务的提供者.从消息交换的角度讲前者一般是消息的最初发送者,而后者则是消息的最终接收者.在很多情况下,由于网络环境的局限,消息的最初发送者和最终接收者不能直接进行消息交换,这就需要一个辅助实现消息路由的中介服务,这就是我们接下来要介绍的路由服务. 目录 一.路由服务就是一个WCF服务       路由服务契约的定义       路由服务契约的定义 二.基于消息内容的路由策略       RoutingBehavior服务行为    

设计思想:需求特性分析新浪微博产品设计

闲聊几句新浪微博 刚刚看了麦田的<闲聊几句新浪微博>,我想从另外一个思维角度来看这个产品.其实我一向认为对于产品设计来说,最终是否能够成功,很大程度上取决于对需求特性的把握,而对需求特性的把握往往需要定性加定量的分析,而定量分析对于外部观察者来说,由于往往很难得到实际运营数据,所以无法得到有效的参考.另外一方面,对于互动型社区产品,产品功能设置和运营本身会对数据产生很大的影响,因此这部分影响也需要通过一些方法来定量分析,排除出去,最终才能够看清楚产品本身的逻辑和用户需求特性之间的真正关联性.麦

MySQL5.7杀手级新特性:GTID原理与实战

MySQL5.7杀手级新特性:GTID原理与实战 一.理论篇 1.1 GTID是什么(what) 1.1.1 GTID组成和架构 GTID 架构 a) GTID = server_uuid:transaction_id b) server_uuid 来源于 auto.cnf c) GTID: 在一组复制中,全局唯一 gtid_set: uuid_set [, uuid_set] ... | '' uuid_set: uuid:interval[:interval]... uuid: hhhhhh