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 回答