问python还是数据库？

EN

我不知道你到底在做什么。但是数据库只会改变数据的存储方式。事实上，这可能需要更长的时间，因为大多数合理的数据库可能会对列施加约束，并对检查进行额外的处理。在许多情况下，将整个文件放在本地进行计算将比查询并将其写回数据库更有效(受磁盘速度、网络和数据库争用等因素的影响)。但在某些情况下，数据库可能会加快速度，特别是因为如果您进行索引，则很容易获得数据的子集。

无论如何，你提到了日志，所以在你发疯数据库之前，我有以下想法给你看看。无论如何，我不确定你是否必须从一开始就一直浏览每个日志来下载图表，并且你希望它增长到2 GB，或者最终你希望每天/每周有2 GB的流量。

1. 归档--您可以归档旧日志，比如每隔几个月归档一次。将生产日志复制到归档位置，并清除实时日志。这将使文件大小保持合理。如果你正在浪费时间访问文件来找到你需要的小片段，那么这将解决你的问题。
2. 你可能想要考虑转换成Java或C。特别是在循环和计算上，你可能会看到30或更多的加速比。这可能会立即减少时间。但随着时间的推移，随着数据的不断增加，总有一天这一速度也会变慢。如果你对数据量没有限制，最终即使是世界上最伟大的程序员手工优化的汇编也会太慢。但它可能会给你10倍的时间...，

，

1. ，你可能还想找出瓶颈(是磁盘访问，还是cpu时间)，并在此基础上想出一个并行执行这项任务的方案。如果是在处理，请考虑多线程(最终是多台计算机)；如果是磁盘访问，请考虑在多个machines...It之间拆分文件，这取决于您的情况。
2. ，如果你一遍又一遍地做同样的计算，那就把它们存储起来吧。无论你使用的是数据库还是文件，这都会给你带来巨大的加速。
3. 如果您正在下载内容，并且这是一个瓶颈，请使用if modified请求查看条件gets。然后只下载更改过的项目。如果你只是在处理新的图表，那么忽略这个suggestion.
4. Oh，如果你正在顺序读取一个巨大的日志文件，逐行查找日志中的特定位置，只需创建另一个文件来存储你处理过的最后一个文件位置，然后每次运行一次查找。
5. 在整个数据库之前，你可能想要考虑SQLite.
6. Finally“几年”在程序员时间中似乎是很长的一段时间。即使只有2个，也会有很多变化。也许你的部门/部门会被裁掉。也许你已经离开了，而你的老板。也许系统会被其他东西取代。也许你正在做的事情就不再需要了。如果是6个月，我会说修好它。但几年来，在大多数情况下，我会说只使用你现在拥有的解决方案，一旦它变得太慢，就去做其他的事情。你可以在代码中评论你对这个问题的看法，甚至可以给你的老板发一封电子邮件，让他也知道这一点。但只要它能工作，并将在一段合理的时间内继续这样做，我现在就认为它是“完成的”。无论您选择哪种解决方案，如果数据变得无界，您都需要重新考虑它。添加更多的机器，更多的磁盘空间，新的算法/系统/开发。解决它“几年”可能是相当不错的。

只有在以下情况下，我才会将其放入关系数据库：

1. 数据实际上是关系型的，以这种方式表示数据有助于通过规范化数据来缩小数据集的大小。
2. 您可以利用触发器和存储过程来卸载您的Python代码现在正在执行的一些计算。
3. 您可以利用查询来仅对更改的数据执行计算，从而减少Python完成的工作量。

如果这两件事都不是真的，我看不出数据库和文件之间有多大的区别。两者最终都必须存储在文件系统中。

如果Python必须处理所有数据，而将其放入内存意味着加载整个数据集，那么数据库和平面文件之间没有区别。

内存中2 2GB的数据可能意味着应用程序的页面交换和颠簸。在将问题归咎于文件之前，我会小心地获取一些数据。仅仅因为访问数据库中的数据并不能解决分页问题。

如果你的数据是扁平化的，我认为数据库的优势较小，除非“扁平化”的==“高度非规范化”。

在进行更改之前，我建议您进行一些分析，以了解哪些资源在消耗CPU和内存。你现在正在猜测问题的根本原因。最好获取一些数据，这样您就可以知道时间都花在哪里了。

如果您每次执行“小提琴”时都需要遍历所有行，那么假设实际的“小提琴”就是消耗您的周期的东西，那么这不会有太大的区别。

也许你可以以某种方式存储你的计算结果，然后一个数据库可能会很好。此外，数据库也有保证数据完整性的方法，所以数据库通常是存储大量数据的好地方(废话！；)。