在关于NoSQL数据库的选型上，需要结合自身数据模型、访问方式以及成本等方面的考虑作一个权衡(trade off)。

那么经过研究MongoDB（2.6.4版本）有如下特点：

可用性：
1.支持高可用灵活的服务集群配置，有主从、副本集、自动分片模式。
2.基于文档的查询，高性能，简单查询上万的QPS。
3.支持全文检索。

一致性：
1.支持文档内更新模式，效率高。
2.当前最新的2.6版本采用读写锁、写锁优先，锁的粒度为collection级别。

易用性：
1.近似传统关系型数据库的SQL使用。
2.丰富的管理配置工具。
3.支持基于用户角色的权限管理体系。

存储机制：
采用mmap file + 内存索引的方式。内存与缓存管理由操作系统负责，当使用数据集大小超出时，性能下降。

Linux下内存控制可以通过配置用户ulimit -u 实现。

现实需求：

1. 需要存储字段灵活的半结构化数据。

2. 1~2亿条记录的存储规模，平均每条记录20k上限。

3. 读需求远大于写(以8:2计算)，写以批量写入的方式，读需支持灵活复杂的查询方式。

4. 写性能：5000qps 读性能：2W qps

由于MongoDB灵活的存储和访问方式，以及良好的查询性能与伸缩性及维护成本，故想到利用MongoDB来存储这约2亿的数据量。

根据需求分析如下：

1. 以2亿规模计算，总存储量约4TB。现在市面上服务器硬盘最大有2TB规格的，部署时可以考虑以LVM方式，先安装1~2TB磁盘，待容量增长时根据需求方便地做扩容。

2. 在已存在1亿数据量的情况下插入1000W条记录，每次写入4条索引，qps能达到8000满足写性能的5000 qps需求。

3. 单线程简单读情况下qps能达到8W qps，换做多线程并发读取总性能也接近8W qps可满足2W qps的查询性能，后续若对读性能有增长需求可考虑从节点开启读权限分摊读压力。在测试中，读延迟 < 1ms。

根据需求论证的结果，利用MongoDB来存储这2亿条记录的方案是可行的。在实际部署当中，MongoDB支持多种方式有主从、副本集、分片。其中副本集相对于主从模式有自动故障迁移的优势，但是其也带来了复杂性和机器成本增加的劣势。

故综合考虑后，选用主从模式进行部署，选用服务器配置为16物理核 + 256G内存 + 2TB硬盘的机器两台搭建主备节点。

其中，从节点开启读权限，一方面应用层在主不可读时可向从节点发起读请求，另一方面前端可根据负载把部分读请求分摊到从节点上。

由于数据的写入求属于离线操作，故只需监控好主从节点的状态，能够及时恢复好服务状态即可。

通过以上实践，即完成了利用MongoDB快速搭建满足上亿级别存储的需求。