用于重定时数据记录的数据库设计答案

【问题标题】：Database design for heavy timed data logging用于重定时数据记录的数据库设计
【发布时间】：2011-01-27 16:42:56
【问题描述】：

我有一个应用程序，我在其中接收每个数据 40.000 行。我有 500 万行要处理（500 Mb MySQL 5.0 数据库）。

实际上，这些行存储在同一个表中 => 更新缓慢、难以备份等。

在这样的应用程序中使用哪种方案来允许长期访问数据而不会出现太大的表、易于备份、快速读/写的问题？

postgresql 是否比 mysql 更好？

【问题讨论】：

【解决方案1】：

1 - 40000 行/天并不大

2 - 根据插入日期对数据进行分区：您可以通过这种方式轻松删除旧数据。

3 - 毫不犹豫地完成数据集市步骤。（计算中间表中的常用指标）

仅供参考，我已将 PostgreSQL 与包含几 GB 数据的表一起使用，没有任何问题（并且没有分区）。 INSERT/UPDATE 时间是恒定的

【讨论】：

1.目前，它不是很大，但资产的数量增长非常快......我必须为那个项目找到一个 1.000.000 / 天的工作架构。 2. 跨分区选择数据难吗？我认为 Postgres 对于这类项目会更稳定
由于我不是专家，请查看postgresql.org/docs/8.4/interactive/ddl-partitioning.html 以查看分区示例：设置似乎不太复杂且易于选择

【解决方案2】：

我们现在有 100-2 亿行的日志表，这很痛苦。

到目前为止，我们只看到了以下解决方案：

备份，设置 MySQL 从站。备份从站不会影响主数据库。（我们还没有这样做——因为我们加载和转换的日志来自平面文件——我们会备份这些文件并在出现故障时重新生成数据库）
清除旧数据，我们发现唯一没有痛苦的方法是引入一个新的整数列来标识当前日期，并每天在该键上对表进行分区（需要 mysql 5.1）。删除旧数据就是删除一个分区，速度很快。

如果您还需要在这些表上进行连续事务（而不是不时加载数据并主要查询该数据），您可能需要查看 InnoDB 而不是默认的 MyISAM 表。

【讨论】：

【解决方案3】：

一般的答案是：您可能并不总是需要所有这些细节。

例如，您可以在 DailySales 表中创建记录（每天一条记录），甚至是一组表（DailySalesByLocation = 每天每个位置一条记录，DailySalesByProduct = 一条每天记录每个产品等）

【讨论】：

【解决方案4】：

首先，庞大的数据量并不总是在关系数据库中得到很好的处理。

有些人所做的是将大量数据集放入文件中。普通的旧文件。快速更新，易于备份。

文件已格式化，以便数据库批量加载器能够快速运行。

其次，没有人分析庞大的数据量。他们很少汇总 5,000,000 行。通常，他们想要一个子集。

因此，您编写简单的文件过滤器来删除它们的子集，将其加载到“数据集市”并让他们查询。您可以构建他们需要的所有索引。观点，一切。

这是处理“数据仓库”的一种方法，你的问题听起来像。

【讨论】：

【解决方案5】：

首先，确保您的日志记录表没有过度索引。我的意思是每次您从表中插入/更新/删除时，您还需要更新任何索引，这会减慢进程。如果您在日志表上指定了很多索引，您应该仔细查看它们并确定它们是否确实有必要。如果没有，请丢弃它们。

您还应该考虑一个归档过程，以便将“旧”日志信息以任意间隔（例如每月一次或每年一次）移动到单独的数据库中。这完全取决于您的日志的使用方式。

【讨论】：

【解决方案6】：

这可能是 NoSQL 数据库有用的那种事情，如果您不进行需要复杂连接的那种报告。

CouchDB、MongoDB 和 Riak 是面向文档的数据库；它们没有 SQL 的重量级报告功能，但如果您要存储大型日志，它们可能就是问题所在，因为它们比 SQL 数据库更简单并且更容易扩展。

它们比 Cassandra 或 HBase（不同类型的 NoSQL）更容易上手，您也可以研究一下。

【讨论】：