最近做了一个版本，是数据迁移，我们的一项核心业务，阿姨简历数据保存，使用的存储方式是mongodb，但是后来发现这种方式不利于数据关联，不好开展后续的一些业务开发，于是我们进行拆表，将阿姨数据拆成一个主表和好几个附表。
先看下mongodb的数据结构，再对比下mysql的数据结构，由一张aunts表拆成了六张表
uc_aunt_resume 主表
uc_aunt_resume_ext 扩展表
uc_aunt_resume_attach 图片附件表
uc_aunt_resume_working_experiences 工作经历
uc_aunt_resume_family_member 家庭成员
uc_aunt_resume_train_experiences 培训经历
在这个迁移过程，测试主要参与验证，验证的内容主要是有关阿姨的功能。
测试的时候，主要将精力放在阿姨简历的添加和维护，以及使用阿姨的一些小功能，另外还有不同终端，比如app，h5,小程序等
但是这次出现问题的场景是数据权限，员工账号查看不到阿姨，原因是开发在拷贝代码的时候写错了变量。实际上跟数据存储方式已经没有太大关联，属于查询相关。
之前使用的mongodb 觉得更改数据比较麻烦，这次拆成mysql 多张表
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
盲猜可能会出现的问题：
查询阿姨信息慢，翻页的时候展示慢
其他交互接口，需要使用阿姨信息的，部分信息没有返回，因为之前基本都是全量
实际测试过程中出现的问题：
添加和编辑阿姨时，接口报错，通常存在于s端和aunt端，对于b端的接口反而没有什么问题。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
结论
1、相比较MySQL，MongoDB数据库更适合那些读作业较重的任务模型。MongoDB能充分利用机器的内存资源。如果机器的内存资源丰富的话，MongoDB的查询效率会快很多。
2、在带”_id”插入数据的时候，MongoDB的插入效率其实并不高。如果想充分利用MongoDB性能的话，推荐采取不带”_id”的插入方式，然后对相关字段作索引来查询。
3、MongoDB适合那些对数据库具体数据格式不明确或者数据库数据格式经常变化的需求模型，而且对开发者十分友好。
4、MongoDB官方就自带一个分布式文件系统，可以很方便地部署到服务器机群上。MongoDB里有一个Shard的概念，就是方便为了服务器分片使用的。每增加一台Shard，MongoDB的插入性能也会以接近倍数的方式增长，磁盘容量也很可以很方便地扩充。
5、MongoDB还自带了对map-reduce运算框架的支持，这也很方便进行数据的统计。
MongoDB的缺陷
1、事务关系支持薄弱。这也是所有NoSQL数据库共同的缺陷，不过NoSQL并不是为了事务关系而设计的，具体应用还是很需求。
2、稳定性有些欠缺，这点从上面的测试便可以看出。
3、MongoDB一方面在方便开发者的同时，另一方面对运维人员却提出了相当多的要求。业界并没有成熟的MongoDB运维经验，MongoDB中数据的存放格式也很随意，等等问题都对运维人员的考验。
————————————————
版权声明：本文为CSDN博主「光露」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_30070663/article/details/113271744
