存储趋势数据的最佳方式是什么？

Question

我目前正在构建一个应用程序，我正在导入(当前)大约15,000种产品的统计数据。目前，如果我为每天来自一个源的统计数据维护一个数据库表，那么每天将增加15,000行数据(假设每行5-10个字段，主要是浮点型，int)。这显然相当于每年将超过500万条记录放入一个表中。

我不太关心从其他来源引入数据的想法(因此，对于每个新来源，数据库的大小增加了500万条记录)。

现在数据是基于统计/趋势的数据，基本上每个记录每天有1次写入和多次读取。然而，出于动态报告和绘图的目的，我需要基于规则(日期范围、值范围等)快速访问数据的子集。

我的问题是，这是存储数据(MySQL InnoDb表)的最佳方法，还是有更好的方法来存储和处理统计/趋势数据？

我在这一点上考虑过的其他选择: 1.多个数据库(每个产品一个)，其中每个数据源都有单独的表。(ie数据库: ProductA，表:Source_A，Source_B，Source_C) 2.一个数据库，多个表(每个产品/数据源一个) (ie数据库:产品，表: ProductA_SourceA，ProductA_SourceB等) 3.数据库中的所有factual或特定产品信息和csv，xml，json，(平面文件)中的所有statistical数据。

到目前为止，这些选项都不是非常容易管理的，每个选项都有其优缺点。在进入开发的alpha阶段之前，我需要一个合理的解决方案。

Answer 1

您可以尝试使用基于列的数据库。这些类型的数据库在您所描述的类型的分析查询中要好得多。有几个选项：

http://en.wikipedia.org/wiki/Column-oriented_DBMS

我们对InfiniDB有很好的体验：

http://infinidb.org/

Infobright看起来也不错：

http://www.infobright.com/

InfiniDB和Infobright都有免费的开源社区版本，所以我建议您使用这些版本来对您可能获得的性能优势进行一些基准测试。

您可能还希望考虑对数据进行分区以提高性能。

Answer 2

这有点取决于你的数据是什么样子的，以及你想要运行的聚合/趋势的类型。大多数关系数据库都可以很好地处理这种按时间顺序排列的数据。即使有数十亿条记录，适当的索引和分区也可以快速找到您需要的记录。数据库，如Oracle，MySQL，SQL-Server都属于这一类。

假设您使用的产品是股票，对于每个股票，您每天都会获得一个新的价格(这是一个非常现实的情况)。新的交易所、股票和交易频率将以指数级的速度快速增长。但是，您可以通过交换对数据进行分区。或区域。

各种商业智能工具还能够帮助在检索之前有效地预先聚合数据。按照建议，这基本上是一个面向列的数据库。(数据仓库和OLAP结构可以帮助提前处理和聚合数据集)。

类似于数据仓库的想法，如果只是聚合耗时太长的问题，您可以在一夜之间将聚合处理成一个更快进行查询的结构。在我前面的示例中，您可能只需要非常不频繁地检索大块数据，但更多情况下需要一些聚合，例如52周高点。你可以用一种格式存储大量的原始数据，然后每天晚上让一个工作只把你需要的东西放到一个表中，而不是每个股票有数千个数据点，现在有3个或4个。

如果您正在跟踪的趋势确实无处不在，或者是复杂的算法，那么可能需要研究一个完整的BI解决方案，以便您可以使用预先构建的类比和数据挖掘算法。

如果数据不是非常结构化，那么使用Hadoop或Mongo这样的NoSQL数据库可能会更好，尽管我的数据库知识更侧重于关系格式。

Answer 3

将数据从关系型转变为非关系型，将数据转换为更好、更有组织的形式，如使用数据集市和数据湖。使用数据挖掘算法。使用map reduce等技术一起处理数据。将ACID属性转换为BASIC。