本周学习了MongoDB的一个专栏，原因有两点：在最近开发过程中，也意识到MySQL分库分表有其局限性，第三范式也让整个应用程序复杂度变高，数据处理的联动性非常多，所以至少要有一个非关系数据库软件，相信MongoDB在某些场景下是个很好的补充；第二就是未来可能有用户画像或行为数据需求，在这方面MongoDB也是一种解决方案。

第二个事情还是搜索，在《 logstash grok filter插件实战 》文章中描述了logstash的一些运用，其实logstash也能将数据导入到MongoDB中。另外简单说说一种搜索需求，比如一个品牌有很多别名，比如阿迪达斯、addidas，如果用户纯粹搜索阿迪达斯这个词，匹配度会少了很多，在这种情况下，如果是品牌文章搜索，先根据关键字搜索出一个品牌的所有别名，然后使用multi_match进行多字段值查询，匹配的文章数量会更高。

第三这周一直在进行业务开发，前几天看到一台副库 show slave status 报 Slave_SQL_Running_State: System lock 错误，导致同步延时，但当时的线程query运行并不多，这提示我，MySQL还是我们服务的根本，需要进一步挖掘。

说到业务开发，其实一线写代码某种程度上并不是那么容易的，毕竟每个人及周围的情况不是那么完美的，所以需要体谅、洞察，尽量去做好每件事情即可。我们需要理解每件事情的重要性和紧急性，但也必须尊重客观规律。

新工作四个月了，有两个项目让我挺紧张的，一个就是街区街文的改造，另外一个就是这次的父子话题改造，如果理解的太复杂，那结构性就会有大的破坏，对于后续的开发、维护会有很大的影响。这也提示我们，需要突破原有思维，未来需要更灵活的实现方式，比如说选择更好的数据存储软件，MongoDB可能就是一个补充。而且类似这样的项目，一定要在开始说清楚，否则一边开发一边妥协，到后面就难办了，事情的判断需要有一定的界限。

昨天一个客户端同事一起讨论，意思就是API提供的数据能不能模块化，比如很多接口会涉及到 话题 数据结构，如果数据结构完全一样，客户端开发的时候就会更加方便，效率会更高。

这是一个非常普遍的需求，和小伙伴们商量了下，有几点想法：

API看上去好像就是一个个接口，但它后面的实现逻辑千变万化，在需求快速迭代的过程中，数据结构会经常变化，甚至还要兼容很多老的版本（这是APP开发的一个痛点），历史包袱也很重，既要往前跑还要擦屁股，实现模块化真的很难。

不说实现逻辑层的模块化，就实现数据层的模块化很难，很难写出完全通用的模块，基本上是一个需求就一个模块，到最后越来越多的模块，这就不是模块化了。即使写出来也是在性能上做了很多妥协，比如为了实现一个通用的模块，调用方可能仅仅用到其中的一小部分，可最终却查询了很多数据，这肯定不合适。

那这是开发语言层面的问题吗？比如PHP是不是就比Java弱？我想Java可能有更多的规范去保证代码质量，但本质上还是人的技术实现占主导因素，和开发语言没有关系。

那怎么办呢？我也没想到好的方法，只能说尽力去想办法。

比如说客户端希望API模块化，就要想到API有很多历史版本问题，就要配合着API去优化，比如这个字段已经废弃不用了，这个接口不用了，这个接口能不能合并，这个接口不用考虑性能问题（客户端去做缓存），多多反馈给API提供者，把自己当成API的实现者。当做一个整体才能达到共赢，只要多多协作，结果就会越来越好。

而对于我们来说，要有更多的解决方案，不能纯粹依靠MySQL、缓存，要想更优秀的解决方案，比如将很多“数”同步到Redis中就是一种优化方案，依赖于Redis的高效和简洁，就可以摆脱MySQL复杂的关系查询，也能摆脱缓存一致性更新的问题，从而让代码更轻量。

同时也要不断的迭代，迭代需要经验的积累，需要互相理解，因为系统是由我们自己维护的，如果系统像一辆破车，那自己骑的时候也很费劲。

最后也不要妄自菲薄，很多大公司一个个高深技术，可出问题的时候，才发现写的代码那么的低级，完全颠覆你的认知，这个世界上没有银弹。