7

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

我并不关心从其他来源引入数据的想法(从而为每个新来源将数据库的大小增加 500 万条记录)。

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

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

我在这一点上折腾的其他选项: 1. 多个数据库(每个产品一个),其中每个数据源都有单独的表。(即数据库:ProductA,表:Source_A,Source_B,Source_C) 2. 一个数据库,多个表(每个产品/数据源一个)(即数据库:产品,表:ProductA_SourceA,ProductA_SourceB 等。 ) 3.factual数据库中的所有或特定产品信息以及statistical单独目录中的 csv、xml、json、(平面文件)中的所有数据。

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

4

3 回答 3

2

您可以尝试使用基于列的数据库。这些类型的数据库在您描述的那种分析查询方面要好得多。有几种选择:

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

我们在 InfiniDB 方面有很好的经验:

http://infinidb.org/

Infobright 看起来也不错:

http://www.infobright.com/

InfiniDB 和 Infobright 都有免费的开源社区版本,所以我建议使用它们来获得一些关于你可能获得的性能优势的基准。

您可能还想查看对数据进行分区以提高性能。

于 2011-04-20T02:21:02.060 回答
2

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

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

各种商业智能工具也能够提供帮助,这实际上相当于在检索之前预先聚合数据。正如建议的那样,这基本上是一个面向列的数据库。(数据仓库和 OLAP 结构可以帮助提前按摩和聚合数据集)。

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

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

如果数据不是很结构化,那么使用 Hadoop 或 Mongo 等 NoSQL 数据库可能会更好,尽管我承认我对数据库的了解更多地集中在关系格式上。

于 2013-11-13T23:52:40.197 回答
0

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

于 2021-12-18T00:05:22.203 回答