总结-非关系型数据库的设计
前言
- 大家想必都知道非关系型数据库（MongoDB、Redis）等等的了。
他们不同于传统的关系型数据库（Mysql）最大的一点就是不依赖于泛式，每个应用的设计都是随意的，自由的，不必被拘束的 - 也正因如此，我们必须针对自身的应用，对数据库的结构进行最实用的设计。而不是把关系型数据库的生搬硬套过来，造成不必要的开销
最大的例子就是关系型数据库中的「引用」，这是不被推荐的。在开销上很大，在分布式系统中更是恐怖如斯。 - ...本文章是根据MongoDB团队的一次公开沙龙总结而来的。
我本人在做的NothingLeft就有用到MongoDB作为数据库。 - 听完课，我还是很庆幸自己没有使用老一套的设计，而是根据自己的需求进行设计，符合了那次沙龙的基本原则「一切从实用出发，衡量代价与利益」。
但是也还有很多不足，因此想跟大家分享一下收获
嵌入，不引用
我们最忌讳的就是追求数据结构上的好看，而不在乎实际需求，如下：
- 一个生产电脑配件的公司想在首页展示三款产品的数据，分别包括他们的名称、生产代号、优缺点、使用了哪些零件等，这些零件还可以点开查看其详细信息。
- 如果一味地追求完美，那很有可能会把每款产品的基本信息放在一个document里面，然后零件采用引用的方式join过去。
这样，当我需要展示一款产品的信息，就需要查询两次，获取基本信息与零件的信息。
- 但，如果使用嵌入的方法，把零件的一部分信息（如在首页展示中肯定会用到的「名称」）嵌入到产品基本信息的document里面去就更加实用了。
这就是「一切从实用出发」 - 虽然增加了存储开销，但是获得了速度上的优势。这就是「衡量代价与利益」
一对多关系的优化
- 一对一些
一对很多 都可以采用
- 多个嵌入到一个中(零件(多)与产品(一)）
- 一个嵌入到多个中（log信息(多)与log_host(一)）
- 双向嵌入
聚合
- 分桶存储的原理。
将批量使用的数据放在一个document里面（温度传感器数据每分钟采集一次，按一个小时为一桶，存在一个document里） - 去掉那些为了展示规律而保存的信息，能够简单计算获得的信息，以此提高查询速度，减少存储开销。
