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 

你至less要有500GB的数据,并以每天700MB的速度增长。 你可能要考虑分拆(也许只是一个分片),所以你可以保持每个服务器的数据可pipe理。 我们(MongoHQ)发现,对于单个服务器/副本集安装,500GB是一个很好的上限。 分片需要你至less运行一个mongos和3个configuration服务器以及副本集,并且进行研究以select一个好的分片密钥。

也就是说,你需要弄清楚你的工作集有多大,并确保你有足够的内存来保存它。 工作集被定义为“在一定时间内访问的文档+索引的部分”,我们的典型经验法则是每10GB存储caching容量大约为1GB内存。 尽pipe如此,这非常依赖于您的数据和访问模式。 当你有一个病态的工作集,并将其全部保存在内存中时,固态硬盘会变得非常有用。 运行mongostat对抗模拟负载,查看“故障”列以了解数据库进入磁盘的频率。

一个简单的副本集是一个好的开始。 如果你正在从中学读取,你真的应该有一个3人的设置,而不是两个(无论如何你需要一个仲裁器)。 当两台服务器加载到一台服务器上时,人们会遇到麻烦,一台服务器死机,另一台服务器则压倒一切。 拥有3个更小的服务器比2个更大的服务器更可取。

次要读取也可能导致您的应用程序问题。 您需要确保您的应用程序可以处理您可能遇到的任何复制滞后。 你可能不会马上遇到这种情况,但是如果你有一个二级脱机维修的时候,它会发生,并且在它有时间赶上之前就读完。

这是一个非常模糊的问题,所以我会给出一个含糊不清的答案。 几乎所有这些都是自己的话题,所以如果不清楚的话,随便用这个来创build和提出更具体的问题。

  1. 阅读密集 – 确保所有文档和索引适合RAM
  2. 如果无法完成,请使用固态硬盘将发生故障时的命中最小化
  3. 高可用性 – RAID1或RAID10是您的朋友,可以使用其他方式备份您的数据,但不能使用复制ID
  4. 不要使用主/从,使用副本集 – 主/从代码已弃用
  5. Ubuntu 11.04将会很好,只要你从10gen安装,而不是Ubuntu 安装
  6. 确保你知道什么是最终的一致性是什么,它对你的应用程序进行从属/次要读取时的意义(也可以看你select的驱动程序中的写入首选项)。

希望能帮助你作为一个出发点。

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

从我的头顶来看,你的假设已经开始不利了。

副本集是至less3节点的集群。 另外,不要被假设辅助节点可以用较less的硬件构build出来, 群集只读副本经常需要比只写初级更努力,因为它们都被查询,并接收和处理来自主要更新。