我目前正在构建一个应用程序，我正在为（目前）大约15,000种产品导入统计数据。目前，如果我要从一个来源为每天的统计数据维护一个数据库表，那么每天将增加15,000行数据（假设每行5-10个字段主要是浮点数，int）。显然，每年将超过500万条记录等同于一个表格。
这与我关注的问题不在于从其他来源引入数据（因此每个新来源的数据库大小增加了500万条）。
现在数据是基于统计/趋势的数据，每条记录每天基本上写入1次，并且读取数量很多。出于动态报告和绘图的目的，我需要根据规则（日期范围，值范围等）快速访问数据子集。
我的问题是，这是存储数据的最佳方式（MySQL InnoDb表），还是有更好的方法来存储和处理统计/趋势数据？
此时我抛出的其他选项：
1.多个数据库（每个产品一个），每个数据源都有单独的表。
（即数据库：ProductA，表：Source_A，Source_B，Source_C）
2.一个数据库，多个表（每个产品/数据源一个）
（即数据库：产品，表格：ProductA_SourceA，ProductA_SourceB等）
3.数据库中的所有factual或特定产品信息以及csv，xml，json，（平面文件）中不同目录中的所有statistical数据。
到目前为止，这些选项中没有一个是可管理的，每个选项都有其优缺点。在进入alpha开发阶段之前，我需要一个合理的解决方案。
答案 0 :(得分：2)
您可以尝试使用基于列的数据库。这类数据库在您所描述的那种分析查询方面要好得多。有几种选择：
http://en.wikipedia.org/wiki/Column-oriented_DBMS
我们对InfiniDB有很好的经验：
和Infobright也很好看：
InfiniDB和Infobright都有免费的开源社区版本，因此我建议使用这些版本来获得有关您可能获得的各种性能优势的基准测试。
您可能还希望查看对数据进行分区以提高性能。
答案 1 :(得分：2)
它有点依赖于您的数据的样子，以及您希望运行的聚合/趋势的类型。对于这种按时间顺序排列的数据，大多数关系数据库都可以正常工作。即使有数十亿条记录，正确的索引和分区也可以快速完成查找所需记录的工作。 DB就像Oracle，MySQL，SQL-Server属于这一类。
让我们说你使用的产品是股票，每个股票你每天都会得到一个新的价格（非常现实的情况）。新的交易所，股票，交易频率将以指数方式快速增长。但是，您可以通过交换对数据进行分区。或地区。
各种商业智能工具也能够提供帮助，有效地相当于在检索之前预先聚合数据。这基本上是建议的面向列的数据库。 （数据仓库和OLAP结构可以帮助提前按摩和聚合数据集）。
与数据仓库的概念类似，如果只是聚合花费的时间太长，您可以在一夜之间将聚合转换为更快速查询的结构。在我之前的示例中，您可能只需要很少检索大块数据，但更常见的是一些聚合，例如52周高。您可以以一种格式存储大量原始数据，然后每晚只需要将工作量放在表中，而不是每个库存数千个数据点，现在有3或4个。
如果您正在跟踪的趋势确实存在，或者是复杂的算法，那么可能需要研究完整的BI解决方案，以便您可以使用预先构建的异构和数据挖掘算法。
如果数据结构不是很好，你可能会对Hadoop或Mongo这样的NoSQL数据库运气好，尽管我对数据库的了解更多地集中在关系格式上。