我正在编写一个具有以下数据库结构的应用程序。
具有多个子主题的主题，这些子主题是密钥对映射。由于我需要具有高度可扩展性和高响应性的Db，因此我转向了NOSQL，基于文档的MongoDB。我不完全确定数据模式和建模设计，即使它是无模式的。
以下是我想到的以下实现 -
a）多个主题数据库 - 具有简单键值对模式的多个子主题集合。
b）1应用程序数据库 - 一个集合中子主题的所有键对值。也许是识别子主题的关键“类型”。
c）1个应用程序数据库 - 主题的多个集合 - 以及它们各自的键值对作为模式。
d）主题的多个数据库 - 每个数据库中的1个集合，其中必要时在模式中使用“类型”键转储键值对。
基本上，是的，许多，1多，1,1-1结构。
如果有人对我必须继续进行的架构有所了解并且理由相同，那将是非常好的。
更多详情 1）访问查找 - ＆gt;我只需要按键查找，所以是索引将完成。如果具有“type”键的模式，将继续使用复合索引。 2）数量 - 就像我说的，这将是高度可扩展的，每周将增加数百万的新密钥。
我已经经历了多种良好实践和其他架构设计问题的来源，但是，没有足够的亮点来决定何时选择哪种。 StackOverflow中的其他问题也变得非常不同。