如果要执行行级数学运算，是否将数据系列存储在文件或数据库中？

Question

我正在开发一个应用程序，可以处理金融系列数据集（以csv或open document的形式输入），一组数据可以是10×1000，高达两倍精度的数字（简化，但这才是最重要的）。在

我计划对这些数据进行操作（例如求和、差、平均值等），包括根据输入计算生成另一列。这将是在一个集合的列（行级操作）之间，以及行级别的多个（可能是所有）集合上的列之间。我计划用Python编写它，它最终将需要一个面向intranet的界面来显示结果/图形等。目前，基于一些输入参数的csv输出就足够了。在

存储和操作数据的最佳方式是什么？到目前为止，我认为我的选择要么是（1）将csv文件写入磁盘，然后搜索它们来计算；要么（2）我可以将它们放入数据库，依靠数据库来处理数学问题。我主要关心的是速度/性能，因为数据集的数量会随着数据集的增长而增长，因为需要进行数据集间的行级计算。在

-有人在这两条道路上都有经验吗？我应该注意哪些陷阱/陷阱？
-为什么要选择一个而不是另一个？
-在开始之前，是否有任何可能影响设计的潜在速度/性能缺陷/提升？
-是否有任何项目或框架可以帮助完成此类任务？在

-编辑- 更多信息： 这些行都将按顺序读取，但我可能需要进行一些重新采样/插值，以匹配不同的输入长度以及每行的不同时间戳。由于每个数据集的长度总是不同的，并且不是固定的，所以我将在某个地方有一些暂存表/内存来保存插值/重采样的版本。我不确定是否应该尝试存储这个（并尝试向上采样/插入到一个普通的更高的长度），或者只是在每次需要时重新生成它。在

Answer 1

“我计划对这些数据进行操作（例如求和、差、平均值等），包括根据输入计算生成另一列。”

这是数据仓库星型模式设计的标准用例。购买Kimball的数据仓库工具包。在做其他事情之前，先阅读（并理解）星型模式。在

“存储和操作数据的最佳方式是什么？“

星图。在

您可以将其实现为平面文件（CSV很好）或RDBMS。如果使用平面文件，则编写简单的循环来计算。如果使用RDBMS，则编写简单的SQL和简单循环。在

“随着数据集数量的增长，我主要关心的是速度/性能”

没有什么比平锉快。句号。RDBMS比较慢。在

RDBMS的价值主张源于SQL是一种相对简单的指定SELECT SUM(), COUNT() FROM fact JOIN dimension WHERE filter GROUP BY dimension attribute的方法。Python没有SQL那么简洁，但是它同样快速和灵活。Python与SQL竞争。在

“我应该注意的陷阱/陷阱？”

数据库设计。如果你不了解星型模式以及如何将事实与维度区分开来，那么所有的方法都是注定要失败的。一旦你把事实和维度分开，所有的方法都是近似相等的。在

“为什么要选择一个而不是另一个？”

RDBMS速度慢且灵活。平面文件速度快（有时）不太灵活。Python使比赛场地变得平坦。在

“在开始之前，是否有任何可能影响设计的潜在速度/性能缺陷/提升因素需要注意？”

星型模式：由维度表包围的中心事实表。没有什么能比得上它。在

“是否有任何项目或框架可以帮助完成此类任务？”

不是真的。在

Answer 2

为了实现速度优化，除了更改底层存储机制外，我还建议另外两种调查方法：

1）使用中间数据结构。

如果最大化速度比最小化内存使用更重要，那么使用不同的数据结构作为计算的基础，而不是专注于底层的存储机制，可能会获得良好的结果。在实践中，这一策略极大地减少了我所从事项目的运行时间，而不管数据是存储在数据库还是文本中（在我的例子中是XML）。在

虽然求和和和平均数只需要O(n)的运行时间，但更复杂的计算可以很容易地将其推到O（n^2）中，而无需应用此策略。O（n^2）会对性能造成影响，它可能会比从CSV或数据库读取数据带来更大的速度影响。例如，如果数据行引用其他数据行，则需要基于这些引用聚合数据。在

因此，如果你发现自己在做比求和或平均数更复杂的计算，你可以探索可以在O（n）中创建的数据结构，并将计算操作保持在O（n）或更好的位置。正如Martin指出的，听起来你的整个数据集都可以轻松地保存在内存中，因此这可能会带来一些大的胜利。您将创建什么样的数据结构将取决于您正在进行的计算的性质。在

2）预缓存。

根据数据的使用方式，可以提前存储计算值。一旦生成/加载数据，就执行求和、求平均值等操作，并将这些聚合与原始数据一起存储，或在程序运行期间将其保存在内存中。如果此策略适用于您的项目（即，如果用户没有在运行中提出不可预见的计算请求），则读取数据不应过于长时间运行，无论数据来自文本还是数据库。在

Answer 3

如果所有数据都能同时放入内存，那么最重要的是什么。从你给出的大小来看，这似乎很容易（最坏的情况是几兆字节）。在

如果是这样，我就不鼓励使用关系数据库，而是直接用Python执行所有操作。根据您需要的其他处理，我可能宁愿使用二进制pickle，而不是CSV。在