「总结」非关系型数据库的设计

前言

• 大家想必都知道非关系型数据库（MongoDB、Redis）等等的了。 他们不同于传统的关系型数据库（Mysql）最大的一点就是不依赖于泛式，每个应用的设计都是随意的，自由的，不必被拘束的
• 也正因如此，我们必须针对自身的应用，对数据库的结构进行最实用的设计。而不是把关系型数据库的生搬硬套过来，造成不必要的开销 最大的例子就是关系型数据库中的「引用」，这是不被推荐的。在开销上很大，在分布式系统中更是恐怖如斯。
• ...本文章是根据MongoDB团队的一次公开沙龙总结而来的。 我本人在做的NothingLeft就有用到MongoDB作为数据库。
• 听完课，我还是很庆幸自己没有使用老一套的设计，而是根据自己的需求进行设计，符合了那次沙龙的基本原则「一切从实用出发，衡量代价与利益」。 但是也还有很多不足，因此想跟大家分享一下收获

嵌入，不引用

• 我们最忌讳的就是追求数据结构上的好看，而不在乎实际需求，如下：
  • 一个生产电脑配件的公司想在首页展示三款产品的数据，分别包括他们的名称、生产代号、优缺点、使用了哪些零件等，这些零件还可以点开查看其详细信息。
  • 如果一味地追求完美，那很有可能会把每款产品的基本信息放在一个document里面，然后零件采用引用的方式join过去。 这样，当我需要展示一款产品的信息，就需要查询两次，获取基本信息与零件的信息。
• 但，如果使用嵌入的方法，把零件的一部分信息（如在首页展示中肯定会用到的「名称」）嵌入到产品基本信息的document里面去就更加实用了。 这就是「一切从实用出发」
• 虽然增加了存储开销，但是获得了速度上的优势。这就是「衡量代价与利益」

一对多关系的优化

• 一对一些 一对很多
• 都可以采用
  • 多个嵌入到一个中(零件(多)与产品(一)）
  • 一个嵌入到多个中（log信息(多)与log_host(一)）
  • 双向嵌入

聚合

• 分桶存储的原理。 将批量使用的数据放在一个document里面（温度传感器数据每分钟采集一次，按一个小时为一桶，存在一个document里）
• 去掉那些为了展示规律而保存的信息，能够简单计算获得的信息，以此提高查询速度，减少存储开销。

一张有用的图