NoSQL数据库中最好的文档存储策略是什么？

Question

像Couchbase这样的NoSQL数据库确实在内存中保存了大量文档，因此速度极快，但它对运行的服务器的内存大小也提出了更高的要求。

我正在寻找在NoSQL数据库中存储文档的几种相反策略之间的最佳策略。这些是：

• 优化速度

将整个信息放入一个（大）文档中的优点是，只需一次GET，就可以从内存或磁盘中检索信息（如果之前已从内存中清除过）。使用无架构的NoSQL数据库，这几乎是希望的。但最终文档会变得太大而占用大量内存，总共可以将更少的文档保存在内存中

• 优化内存

将所有文档拆分为多个文档（例如，使用复合键，如此问题中所述：Designing record keys for document-oriented database - best practice，尤其是当这些文档仅包含特定读取/更新操作中所需的信息时，将允许更多（临时文件将保存在记忆中。

我正在研究的用例是来自电信提供商的呼叫详细记录（CDR）。这些CDR通常每天都达到数亿。然而，这些客户中的许多客户并未在每个特定日期提供单一记录（我正在考虑其预付优势且数据饱和度较低的东南亚市场）。这意味着通常大量文档可能每隔一天进行一次读取/更新，只有一小部分文档每天会有多个读取/更新周期。

向我建议的一个解决方案是构建2个存储桶，将更多RAM分配给更多瞬态存储器，将更少RAM分配给容纳更大文档的第二个存储桶。这将允许更快地访问更多的瞬态数据，并且更慢地访问更大的文档，例如保持完全没有改变的简档/用户信息。我确实看到了这个提议的两个缺点，一个是你不能跨两个桶构建一个视图（Map / Reduce）（这是专门用于Couchbase，其他NoSQL解决方案可能允许这个），第二个是更多的开销在密切管理两个存储桶的内存分配之间的平衡作为用户群增长。

是否还有其他人受到此挑战，您解决该问题的方法是什么？您POV的最佳策略是什么？为什么？显然，这两种策略都处于中间状态，只有一个文档或一个大文档被分成数百个文档，不能成为IMO的理想解决方案。

编辑2014-9-14 好吧，虽然这接近回答我自己的问题但是到目前为止没有任何提供的解决方案并且在评论之后这里有更多的背景我现在计划如何组织我的数据，试图在速度和内存消耗之间实现最佳点：

Mobile_No：简介

• 这可以保存表格中的个人资料信息，而不是直接来自CDR。这里的瞬态数据较少，如年龄，性别和姓名。密钥是一个复合密钥，由移动电话号码（MSISDN）和单词配置文件组成，用“：”分隔。

Mobile_No：收入

• 这可以保存瞬态信息，例如使用计数器和累积客户总收入的变量。密钥又是一个复合密钥，由移动电话号码（MSISDN）和收入一词组成，用“：”分隔。

Mobile_No：OPTIN

• 这包含有关客户何时选择加入该计划以及何时再次选择退出该计划的半暂时信息。这可能会发生几次，并通过数组处理。密钥又是一个复合密钥，由移动电话号码（MSISDN）和单词optin组成，用“：”分隔

CONNECTION_ID

• 这包含有关通过语音或视频呼叫或SMS / MMS完成的特定A / B连接（发送方/接收方）的信息。密钥由两个连接的mobile_no组成。

在文档结构中的这些更改之前，我将所有配置文件，收入和optin信息放在一个大文档中，始终将connection_id保存为单独的文档。这个新的文档存储策略让我有希望在速度和内存消耗之间做出更好的折衷，因为我将主文档拆分成几个文档，这样每个文档都只包含在应用程序的一个步骤中读取/更新的重要信息。

这也会随着时间的推移而处理不同的变化率，其中一些数据非常短暂（例如计数器和累积收益字段随着每个CDR进入而更新），并且配置文件信息基本不变。我希望这能更好地理解我想要达到的目标，评论和反馈非常受欢迎。

Answer 1

感谢您更新原始问题。当你谈到在粗粒度文档和细粒度文档之间找到正确的平衡时，你是对的。

文档的最终体系结构实际上属于您特定的业务领域需求。你必须在你的用例中识别＆＃34; chunks＆＃34;整体上需要的数据，然后将存储的文档形状基于此。 以下是在设计文档结构时需要执行的一些高级步骤：

  

  
1. 确定您的应用/服务的所有文档消费用例。 （阅读，读写，可搜索的项目）
  
2. 设计你的文件（很可能你会得到几个较小的文件而不是一个拥有一切的大文件）
  
3. 设计可以在一个存储桶中共存的文档密钥，以用于不同的文档类型（例如，在密钥值中使用命名空间）
  
4. 做＆＃34;干运行＆＃34;根据您的用例看到的结果模型，您可以获得noSQL和all的最佳（读/写）事务   在交易中需要的文件数据。
  
5. 针对您的用例运行性能测试（尝试模拟预期负载至少高2倍）
  

注意：当您设计不同的文档时，可以使用某种冗余（请记住它不是具有规范化形式的RDBMS），将其视为面向对象设计。

注2：如果您的密钥之外有可搜索的项目（例如，按姓氏搜索客户＆＃34;以＆＃34开头;以及其他一些动态搜索条件），请考虑使用ElasticSearch与CB或您也可以尝试使用CB3.0附带的N1QL查询语言。

通过分成几个由MSISDN链接的较小文档，例如：MSISDN：个人资料，MSISDN：收入，MSISDN：optin，您似乎正朝着正确的方向前进。我会特别注意你的最后一个文件类型＆＃34; A / B＆＃34;连接。听起来它可能会产生大量的并且在本质上是瞬态的...所以你必须找出这些文件必须存在多久才能在Couchbase桶中存活。您可以指定TTL（生存时间），以便自动清除旧文档。

Answer 2

我同意你的资源有效利用技术（如果它们有限）。但另一方面，系统最终可能会非常健谈。如果我理解正确，您的“连接”文档设计过于细化，可能会在网络中引入太多I / O.根据我的经验，如果您正在设计一个能够做出实时决策的系统，那么这些网络I / O非常昂贵。您可以在数学上估计这些不同选择对平衡这些对立力量的影响：）

我确实认为可扩展大数据系统的精神是我们会对资源“约束”“减少”。这些no-sql数据库许可证不是通过CPU核心进行的。商品硬件很便宜。在我们讨论时，RAM越来越便宜。再一次，这些系统的投资回报也会影响架构决策。