Skip to content

Storage Mongo

Jump to bottom
WinChua edited this page Jun 18, 2020 · 2 revisions

Data Model

  1. key challenge: 在以下三者寻找一个平衡:

    • the needs of the application;
    • performance of db engine;
    • data retrieval pattern;

  2. 灵活的表结构: collection 里面的document不需要, 保持相同的结构; 可以在文档中增加, 删除, 更新document的表结构; 当然也可以配置某一个collection中的所有document使用相同的表结构;

  3. mongo中document的结构:

    • embedded document 建模了不同数据之间的关系;(capture relationship)
    • 这种denormalized的设计, 允许应用通过一次db操作获取所需要的数据, 但是会增加存储需要的量;
    • denormalized的好处跟坏处
      • 包含关系的数据能够在一次读操作中完成；
      • 能够保证某些写操作是原子的
    • The maximum BSON document size is 16 megabytes; 单个文档的大小不能超过16MB, 如果需要超过, 考虑使用GridFS;
    • denormalized建议用来建模: one-to-one, one-to-many的关系, 如果设置many-to-many还是使用normalized来建模数据;

  4. 一些建模的例子: 使用embedded 或者 reference的方式建模, one-to-one, one-to-many, many-to-many

    • embedded:
      • one-to-one:
        • Embedded Document Pattern: 如果某些外键关系指向的document需要经常被读取, 使用refernce的方式来读的话, 需要两次读取操作, 第一次读取外键, 第二次通过外键读取对应的字段信息; 这种情况下可以将外键关系Embedded到文档中;
        • Subset pattern: Embedded的方式, 最大的短板是可能会导致, 单个文档过大, 同时包含了某些实际并不需要的数据; 可以考虑只把需要到的字段embedded到文档中;
      • many-to-many:
        • 建模成某个字段是数组, 同样会有上面的单文档过大的问题, 也可以通过SubSet缓解, 包括: 使用部分数据(最近几条数据)

  5. 写操作的原子性:

    • 写操作在单个文档的级别上是原子的; 但是单次更新多个文档, 这些文档的更新操作并不是原子的, 多个文档的写操作不论是通过单次网络还是多次网络操作, 都可能在所有文档没有被更新完成之前插入了别的操作;
    • 如果应用对读写多个文档有原子性的要求, mongo提供了事务进行支持

Replication

Sharding

读写操作需要考虑:

  1. Atomicity: 使用Embed保证单个文档写操作的原子性; 使用事务保证多个文档更新的原子性;

  2. Sharding: mongo提供的水平扩展能力, 将一个collection的中的文档分不到不同的mongod中;

    • shard key: 文档根据shard key决定要存储在哪一个mongod中; shard key可以是一个建了索引的field,或者组合field, 但必须确保collection的所有document包含这个field.

  3. Indexes: 使用索引来提升性能

    • 通常需要在进场查询的field上面简历索引; mongo

Clone this wiki locally