【发布时间】：2012-07-16 05:24:15
【问题描述】：
我有一个每天大约有 700 万条记录的 Oracle 数据库，我想切换到 MongoDB。 (~300Gb)
要设置 POC，我想知道我需要多少个节点？我认为 2 个分片中的 3 个节点的 2 个副本就足够了，但我想知道你的想法:)
我想要一个 HA 设置 :)
提前致谢！
【问题讨论】：
标签： oracle mongodb capacity-planning
【发布时间】：2012-07-16 05:24:15
【问题描述】：
要让 MongoDB 高效工作，您需要知道您的工作集大小。您需要知道每天 700 万条记录相当于多少数据。这是需要保留在 RAM 中以获得高性能的活动数据。
此外，请务必确定您迁移到 Mongo 的原因。我猜..在你的情况下，它是可扩展性的..
但在这样做之前要充分了解您的数据。
对于您的 POC，保留两个分片意味着每个分片大约 150GB。如果您有这么多可用磁盘，没问题。
【讨论】：
-
实际上，每个 MongoDB shard 都是一个副本集.. 所以至少应该是两个副本（有数据）加上一个仲裁器。所以这实际上是每个分片 300-450Gb，因为原始问题引用了 HA。其次 .. 数据的均匀分布依赖于choosing a good shard key，所以你实际上不能假设分布是平衡的。
-
你是对的。我的假设是，应该以这样一种方式选择分片键，使数据均匀分布在所有分片中，这样就没有热点了。但我认为每个分片都不需要有存储整个数据库的能力。或者是是这样吗？就 POC 而言，不需要复制。但是，如果您正在谈论生产数据库，则必须进行复制，并且建议每个分片至少三个节点（奇数以避免在主节点选举中出现平局）。
-
每个分片不需要存储整个数据库的容量，但是如果目标是 HA，那么应该为分片配置适当的支持副本集。对于副本集，您需要在该副本集中至少有一个（理想情况下是两个）辅助节点，其中包含 该分片 的数据的完整副本。如果 POC 不需要复制，那么分片也不应该是 .. 否则您没有测试具有冗余和故障转移的预期环境。
-
嗯……猜猜这取决于 POC 的目标。如果它的目标是测试 MongoDB 的数据模型而不是 Oracle 中的数据模型，那么您不需要考虑那些复杂性。但是在这种情况下，如果 POC 旨在测试 Mongo 的故障转移功能，那么是的，应该尝试复制。
考虑一下您的分片键，您在哪些字段上共享您的数据集是有意义的？这将影响部署多少分片的决定，以及每个分片的容量。如果您的数据可以很容易地分成一半或三分之一，您可能会使用相对较少的分片，可能会使用两个或三个大的深分片，或者如果您可以在更多样化的键上分片，则可以使用几个更轻更薄的分片。
【讨论】：
从 MongoDB replica set 配置升级到 sharded cluster 相对简单（每个分片实际上是一个副本集）。与其预先确定分片是正确的解决方案，不如考虑一下您进行分片的原因是什么（例如，您的应用程序需求是否会超出单台机器的资源；您的数据集有多少是活动的工作集？查询等）。
值得从副本集开始，并将其作为规划架构和 POC 的一部分进行基准测试。
一些帮助您入门的注意事项：
MongoDB 的 journaling 从 1.9.2 开始默认启用，在存储引擎中提供崩溃恢复和持久性。
Replica sets 是高可用性、自动故障转移和数据冗余的构建块。每个副本集至少需要三个节点（例如，三个数据节点或两个数据节点和一个仲裁器）才能启用failover to a new primary via an election。
Sharding 在您的数据或写入超出单个服务器的资源时可用于水平扩展。
其他注意事项包括根据您的应用程序使用情况规划您的文档。例如，如果您的文档会经常更新并随着时间的推移而增大，您可能需要考虑manual padding 以防止过度的文档移动。
如果这是您的第一个 MongoDB 项目，您绝对应该阅读Replica Sets 和Sharding with MongoDB 以及Application Developers 上的常见问题解答。
请注意，您的用例中的choosing a good shard key 是一个重要的考虑因素。如果您计划删除大量数据，则选择不当的分片键可能会导致数据写入“热点”或分片不平衡。
【讨论】：