性能优化相关

大量json储存的坑

MVP初版方案

在开发一个测评相关的功能时，有一个需求是生成N个测试用例，测试用例是使用json结构来储存的。
最早的MVP版本时，后端跟算法是放在一起使用命令行的形式来调用的，所以初版是直接把每一个测试用例保存为json文件，放入后端指定的目录下，后端只需要读取对应目录下的json文件列表就行。
这里有一个坑，就是后端返回测试用例数据给前端时需要进行分页，然后json文件名是根据自增编号进行命名的，但后端读取目录下的所有文件的列表就发生了编号不是连续的问题。为解决这个问题，当时后端还加了一个list列表变量，遍历文件名后插入再进行排序后，再根据这个list列表变量进行分页。

V1.0方案

后来需要将产品架构迭代到V1.0的分布式系统，后端跟算法服务需要分离开来，各自运行在一个容器中，中间采用gRPC协议进行交互调用。这时后端就不能直接读取算法服务生成的json文件了，所以也是改成了直接在gRPC消息中返回测试用例数据。
那这种情况下后端就需要储存测试用例了，目前定的方案下，每一次执行都会在关系型数据库中有对应的执行信息条目，其中也包括了生成的测试用例数据，以实现后期追溯执行历史的功能。
由于每一次执行都会产生N个测试用例，根据需求可能一次就有上千甚至上万个测试用例，所以就不能是一个测试用例一个数据库项了，当前采取的方案为在执行历史的数据库项的‘测试用例生成结果’字段中存入所有的测试用例数据。
但这种方案下就存在一个性能问题，因为前端获取测试用例生成结果需要分页获取，后端就需要读取到数据库字段内容后，解析为json，然后再取对应页数的元素返回，如果测试用例数量很大的话，会有很大的性能开销。

优化方案

新方案计划采用MongoDB这种文档型NoSql数据库来储存测试用例，其中的集合功能正好能满足目前的需求。