【问题标题】:Table structures for large volume data imports大量数据导入的表结构
【发布时间】:2013-02-11 17:43:36
【问题描述】:

我有一个关于设置表以处理我每天导入的大量数据的最佳方法的一般性问题。 我将每天导入 10 个包含 1000 条记录的 csv 文件,以便此表快速扩展。

它由大约 15 列组成,范围从微型和中等整数到 30 个字符的 varchar。

没有 ID 字段 - 我可以连接 6 列来形成一个主键 - 这将是一个 var char 总长度约为 45。

导入后,我需要通过 Web 前端在摘要级别报告此数据,因此我发现自己必须在导入后从中构建报告表。

在这些数据中,许多字段在每天导入时都会重复出现 - 日期、地区、客户等,每天只有一半的列是特定于记录的。

问题:

  1. 我是否应该立即将其全部导入到一个表中作为转储表。
  2. 我是否应该通过导入过程转换数据并将导入拆分到不同的表中
  3. 我是否应该根据列形成一个 id 字段,以便在导入期间获得唯一键
  4. 我应该为此使用 auto inc id 字段吗?
  5. InnoDB 等应该是什么样的表

我担心此表上的数据过载,这会使得在构建时提取到报告表变得越来越困难?

建议真的很有帮助。谢谢。

【问题讨论】:

    标签: mysql


    【解决方案1】:
    1. 拥有 autoinc id 通常比没有它更有帮助
    2. 为确保数据完整性,您可以在构成 ID 的 6 列上设置唯一索引
    3. 如果您有足够的 RAM,MySQL 可以很好地处理数据库中的数百万条记录
    4. 如果您仍然担心数百万条记录 - 只需每月将您的数据汇总到另一个表中即可。如果不能 - 添加更多 RAM。
    5. 在导入过程中尽可能多地转换数据,只要不影响性能即可。在数据已经导入时转换数据会给 MySQL 服务器增加不必要的负载,如果可以避免这样做 - 避免。
    6. MyISAM (曾经?)通常更适合统计类型的数据,这种类型不会经常更新,但 InnoDB 在过去几年已经赶上(看看 percona 的 XtraDB 引擎)并且性能基本相同 -明智的。

    我认为这里最重要的一点是定义您的数据保留率 - 在一两年后您必须保留每日分辨率的情况很少见。

    如果您认为将来可能仍需要每日分辨率,请聚合成较低分辨率的帧和存档(mysqldump > bzip 非常有效)。

    【讨论】:

    • 谢谢 - 好点 - 我想我会发现在导入过程中添加 ID 很困难,这是主要问题。我看不出如何在逻辑上分解 csv 数据并能够使用生成的 id 作为表中的外键,我也在转换过程中添加到表中。我认为你肯定是对存档的事情。
    猜你喜欢
    • 2015-06-29
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2014-09-16
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多