本文记录了一次使用tf_idf算法进行文本分析时遇到的速度和内存问题，以及针对性的改进措施。作者发现单个文档处理、数据结构设计不当和对数据量预估不足导致效率低下。通过批处理、表结构重构、设置索引、优化数据结构和使用多进程等手段，显著提升了处理速度。同时，作者强调了数量级增长带来的挑战，并分享了在处理大数据时的经验教训。
上回写的是使用消息队列来做这个项目，这次完全抛弃了它。
为什么抛弃呢？
我当初设想的是，步骤很明确，完全可以独立开，这样消息队列正好适配。
但是，我对处理速度和吞吐量没有明确的概念，导致如果用之前的方案的话，屈屈30w文章就能跑上好几天。
为什么会这么慢呢？
原因一，处理的个体太小。
按照我的设想每个文档每个步骤都会往队列里塞一个消息，结果导致处理的数据量巨大无比。如果能够批量处理，能够有效减少同MongoDB的connect耗时。
原因二，数据结构不对。
在之前的TF collection中，每条记录的索引是word，如果有一篇文章中出现了该word，就会在TF中增加一个以该文章的document_id的字段。那么最极端情况下，一个word在所有文章中都出现了，那么这个word就会有30w个字段！这样做利于后续步骤的查询，并且我以为mongo这种文档型数据库做这种操作消耗很低，但是事实是残酷的：Some update operations can increase the size of the document; for instance, if an update adds a new field to the document.。
原因三，对数据量没有概念。
我想当然地以为，30w文章就是一个小case，上亿的才需要去考虑
最低0.47元/天 解锁文章
扫一扫
1013
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
