MongoDB的标准体系结构是什么？

Question

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

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

Answer 1

从至少500 of的数据开始，每天以大约700 of的速度增长。您可能需要考虑从get开始进行切分(可能只是一个碎片)，这样就可以使每个服务器的数据易于管理。我们(MongoHQ)发现，对于单个服务器/副本集设置来说，500 We是一个很好的上限。切分将需要您运行至少一个mongos和3配置服务器，除了副本集，并做研究，以选择一个好的碎片密钥。

也就是说，你需要弄清楚你的工作装置有多大，并确保你有足够的内存来保存它。工作集被定义为“您在给定时间内访问的文档+索引的部分”，我们典型的经验法则是，每10 1GB的存储内存中有1GB的内存，存储速度较慢。但这在很大程度上依赖于您的数据和访问模式。当您有一个病态工作集时，SSD变得非常有用，并且将其全部保存在内存中将是非常昂贵的。对模拟负载运行蒙哥特，并查看“故障”列，以了解DB到磁盘的频率。

一个简单的复制集是一个好的开始。但是，如果您正在从次要部分进行读取，那么您实际上应该有一个3名成员的设置，而不仅仅是两个(无论如何，您需要一个两个成员的仲裁器)。当人们加载两台服务器时，会遇到麻烦，其中一台会死，而他们的应用程序会淹没剩下的一台服务器。拥有3台较小的服务器比2台更大的服务器更可取。

二次读取也会导致应用程序问题。您需要确保您的应用程序能够处理任何可能遇到的复制滞后。您可能不会马上遇到这种情况，但是如果您需要进行二次脱机维护，并在它有时间追赶之前阅读它，它就会发生。

Answer 2

这是一个相当模糊的问题，所以我会给出一个有点含糊的答案。几乎所有这些本身都是一个主题，所以如果有什么不清楚的地方，可以随意使用它来创建并提出更具体的问题。

1. 阅读密集-确保所有文档加索引都适合RAM。
2. 如果不能这样做，则获取SSD，以尽量减少磁盘故障时所受的命中。
3. 高可用性- RAID1或RAID10是您的朋友，可以以复制id以外的其他方式备份数据。
4. 不要使用主/从，使用副本集-主/从代码被废弃
5. Ubuntu11.04会很好，只要你是从10回购回购处安装，而不是Ubuntu
6. 确保您理解了什么是最终的一致性，以及它对您的应用程序在做从读/辅助读取时意味着什么(也看看在您选择的驱动程序中的写首选项)。

希望这能帮助你作为一个起点。

Answer 3

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

从我头上看，你的假设已经开始得很糟糕了。

副本集是最少3节点的集群.此外，不要被这样的假设所愚弄，即次要节点可以用较小的硬件构建；集群只读次要程序通常需要比只写的主节点更努力地工作，因为它们都是从主服务器中查询、接收和处理更新的。