☰

MongoDB的标准系统架构是什么

tag-icon • tag-icon linux ubuntu database mongodb architecture
MongoDB的标准系统架构是什么

我知道这个问题太模糊了，所以我想添加一些关键数字来深入了解情况

Size of each document size - 360KB
Total documents - 1.5 million
Document created/day - 2k
read intensive - YES
Availability requirement - HIGH

考虑到这些要求，我认为架构应该是这样的，但不太确定，请分享您的经验并为我指明正确的方向。

2 Linux Boxes (Ubuntu 11 each on a different rack setup for availability)
64-bit Mongo Database 
1 master (for read/write) and 1 slave (read-only with replication ON)
Sharding not needed at this point in time

答案1

您一开始至少有 500GB 的数据，并且以每天约 700MB 的速度增长。您可能希望从一开始就考虑分片（也许只有一个分片），以便您可以管理每个服务器的数据。我们（MongoHQ）发现 500GB 是单个服务器/副本集设置的良好上限。分片需要您除了副本集之外还运行至少一个 mongos 和 3 个配置服务器，并进行研究以选择一个好的分片键。

也就是说，您需要确定您的工作集有多大，并确保有足够的 RAM 来容纳它。工作集定义为“您在给定时间内访问的文档 + 索引的部分”，我们的典型经验法则是，对于速度较慢的磁盘，每 10GB 的存储空间需要大约 1GB 的内存。不过，这在很大程度上取决于您的数据和访问模式。当您的工作集非常庞大，并且将其全部保存在内存中会很昂贵时，SSD 就派上用场了。运行蒙哥斯塔特针对模拟负载，查看“故障”列以了解数据库进入磁盘的频率。

一个简单的副本集是一个好的开始。但是，如果您从辅助服务器读取数据，那么您确实应该设置 3 个成员，而不是只有 2 个（无论如何，您需要一个仲裁器来处理两个成员）。当人们用读取数据加载两台服务器时，其中一台服务器死机，而他们的应用程序压垮了剩下的一台服务器，那么他们就会陷入麻烦。拥有 3 台较小的服务器比拥有 2 台较大的服务器更可取。

二次读取也可能导致应用程序出现问题。您需要确保您的应用程序可以处理您可能遇到的任何复制延迟。您大概不会立即遇到这种情况，但如果您因维护而使辅助服务器离线并且在它有时间赶上之前从中读取数据，就会发生这种情况。

答案2

这是一个相当模糊的问题，所以我会给出一个稍微模糊的答案。几乎所有这些都是他们自己的主题，所以如果有不清楚的地方，请随意使用它来创建和询问更具体的问题。

  1. 读取密集型 - 确保所有文档和索引都适合 RAM
  2. 如果无法做到这一点，请使用 SSD 来最大程度地减少磁盘故障造成的损失
  3. 高可用性 - RAID1 或 RAID10 是你的朋友，除了复制 ID 之外，还可以使用其他方式备份数据
  4. 不要使用主/从，使用副本集 - 主/从代码已弃用
  5. Ubuntu 11.04 没问题，只要你从 10gen repo 安装而不是 Ubuntu 的
  6. 确保您了解最终一致性是什么，以及在执行从属/辅助读取时它对您的应用意味着什么（还请查看您选择的驱动程序中的写入首选项）。

希望这可以作为您的起点提供帮助。

答案3

您确实需要阅读 MongoDB 文档。 https://docs.mongodb.com/manual/administration/

我一眼就看出，你的假设已经有一个糟糕的开始。

副本集至少包含 3 个节点。另外，不要误以为辅助节点可以用较少的硬件构建；集群只读辅助节点通常需要比只写主节点更努力地工作，因为它们既要接受查询，又要接收和处理来自主节点的更新。

相关内容