NoSQL数据库应用实践(下)

MongoDB应用场景

• 基于位置的移动搜索应用(基于自身的地理空间索引)

• 日志分析平台(MongoDB本身自带的高性能聚合框架)

• 可以存储简历、或者投递关系等相对复杂的数据结构，比如简历库

• 可以存储用户数据，或者帖子信息，比如用户中心

MongoDB可扩展存储

• 默认的WiredTiger存储引擎：对于许多应用而言，WiredTiger的更细粒度的并发控制和原生的压缩功能将会为最大范围的应用提供最全面的性能和存储效率

• 新增的加密存储引擎，保护高度敏感的数据，避免了单独文件系统加密带来的性能影响或管理支出

• 新增的内存存储引擎，为大部分实时分析要求最高的应用提供绝佳的性能和可预测的延迟

MongoDB文档设计

• _id选择

• _id生成

    对于_id的选择，首先其是Collection级doc的唯一标示，_id在每个集合内部唯一并且是Collection的主键，不能缺少，其类型默认是Object ID类型。长度为12个字节，由4字节时间戳＋3字节机器ID+2字节进程ID＋3字节计数器组成，每个字节是2位16进制数字，是一个24位字符串。但是如果我们选择默认的_id，那么其实就跟关系型数据中的自增主键类似，_id是在MongoDB服务端生成的，这样会对服务端造成一定的开销，而且对于数据库来说，不管是关系型数据库还是NoSQL还是我们后面会提到的NewSQL，其最优秀的能力是存储而不是计算，所以我们应该尽可能在客户端生成_id，那么同用的id生成器有以下：

• Twiter Snowflake

• 美团的Leaf

Free Schema

{
  "id":ObjectId("4b2349854kjsdffoo2d"),
  "title":"My Blog Post",
  "content":"Here's my blog post.",
  "date":"Sat Dec 12 2009 11:23:21 GMT-0500 (EST)"
}

{name:xx,address:xx}

{n:xx,a:xx}

#define COLLECTION _USER_INFO ("user_info")
  #define USER_INFO_COLEMN_UID ("_id") //("uid")
  #define USER_INFO_COLEMN_LOGIN_NAME ("ln") //("login_name")

Schema设计

• 一对较少场景

• 一对较多场景

• 需要单独访问对象场景

• 不需要单独访问对象场景

• 优先考虑内嵌

• 如果我们需要单独访问一个对象那么就不适合内嵌到其他对象中

• 数组不应该无限制增长

• 反范式设计时需要谨慎

MongoDB压缩算法

• Snappy

• Zlib