Python还是数据库？
我正在用Python把一个CSV文件读入一个列表中，这个文件现在大约有100MB。过几年，这个文件会变成2到5GB。我在这些数据上做很多日志计算。现在这个100MB的文件，脚本运行大约需要1分钟。脚本处理完数据后，会生成一些指向谷歌图表的URL，然后把这些图表下载到本地。
我可以继续用Python处理一个2GB的文件吗，还是应该把数据放到数据库里去？
5 个回答
如果每次你进行“调整”时都需要检查所有的行，那其实并没有太大区别，前提是实际的“调整”才是让你耗费时间的地方。
也许你可以以某种方式保存你的计算结果，这样的话，使用数据库可能会比较好。而且，数据库有一些方法可以确保数据的完整性之类的，所以数据库通常是存储大量数据的好地方（当然啦！;）
我只会把数据放进关系型数据库，如果：
- 数据确实是有关系的，并且用这种方式表达可以通过规范化来减少数据集的大小。
- 你可以利用触发器和存储过程，把一些现在在Python代码中进行的计算转移到数据库里去。
- 你可以利用查询，只对那些发生变化的数据进行计算，这样可以减少Python的工作量。
如果以上这些都不成立，我觉得数据库和文件之间没什么区别。最终这两者都得存储在文件系统上。
如果Python需要处理所有数据，而把数据加载到内存里意味着要加载整个数据集，那么数据库和普通文件就没有区别了。
如果内存里有2GB的数据，可能会导致你的应用程序频繁换页和崩溃。在我把问题归咎于文件之前，我会先小心地获取一些数据。仅仅因为你是从数据库访问数据，并不能解决换页的问题。
如果你的数据是平面的，我觉得用数据库的优势就小了，除非“平面”意味着“高度非规范化”。
我建议先做一些性能分析，看看是什么在消耗CPU和内存，然后再考虑做改变。现在你只是猜测根本原因。最好先获取一些数据，这样你才能知道时间花在哪里了。
我不太清楚你具体在做什么。不过，数据库只是改变了数据的存储方式。实际上，这可能会更慢，因为大多数合理的数据库在列上可能会有一些限制，并且需要额外的处理来进行检查。在很多情况下，把整个文件放在本地，逐个计算会比查询数据库并把结果写回去更有效率（这还要看硬盘速度、网络和数据库的竞争情况等）。但在某些情况下，数据库可能会加快速度，特别是如果你做了索引，就很容易获取数据的子集。
无论如何，你提到了日志，所以在你疯狂使用数据库之前，我有以下几点建议供你参考。我不太确定你是否需要从头到尾查看每个日志来下载图表，并且你预计它会增长到2GB，还是你预计每天/每周会有2GB的流量。
归档——你可以每隔几个月归档旧日志。把生产日志复制到一个归档位置，然后清理掉实时日志。这样可以保持文件大小在合理范围内。如果你在访问文件时浪费时间去找需要的小部分，这样做可以解决你的问题。
你可能想考虑转换到Java或C语言。特别是在循环和计算方面，你可能会看到30倍或更多的速度提升。这可能会立即减少处理时间。但随着数据的增加，总有一天这也会变慢。如果你没有数据量的限制，最终即使是世界上最优秀程序员手动优化的汇编代码也会变得太慢。但这可能会给你节省10倍的时间……
你还可以考虑找出瓶颈（是磁盘访问，还是CPU时间），然后根据情况设计一个并行处理的方案。如果是处理速度慢，可以考虑多线程（最终可能需要多台计算机）；如果是磁盘访问慢，可以考虑把文件分割到多台机器上……这真的要看你的具体情况。不过我怀疑归档可能会消除这个需求。
如果你反复进行相同的计算，那就把结果存起来。无论你是用数据库还是文件，这样都能大大提高速度。
如果你在下载东西时遇到瓶颈，可以考虑使用条件获取（if modified request）。这样只下载那些有变化的项目。如果你只是处理新的图表，那就忽略这个建议。
哦，如果你在顺序读取一个巨大的日志文件，逐行查找特定位置，可以创建另一个文件来存储你上次处理的文件位置，然后每次运行时进行定位。
在考虑整个数据库之前，你可能想先考虑使用SQLite。
最后，“几年”在程序员的时间里似乎很长。即使只有2年，很多事情都可能改变。也许你的部门会裁员，也许你会离开，或者你的老板会换人。也许系统会被其他东西取代，或者你所做的事情将不再需要。如果只是6个月，我会说修复它。但对于几年来说，在大多数情况下，我会建议你继续使用现在的解决方案，一旦变得太慢再考虑其他办法。你可以在代码中留下你的想法的注释，甚至给你的老板发封邮件，让他也知道。但只要它能正常工作，并且在合理的时间内继续这样，我认为现在可以算是“完成”了。无论你选择什么解决方案，如果数据不断增长，你都需要重新考虑。增加更多的机器、更多的磁盘空间、新的算法/系统/开发。解决“几年”的问题可能已经相当不错了。