【问题标题】:Store huge data in MySQL?在 MySQL 中存储大量数据?
【发布时间】:2010-11-28 16:08:02
【问题描述】:

我正在尝试在 MySQL 中创建一个数据库表来存储我的产品统计数据。几乎每天的统计数据都应该在数据库中。问题是速度。

目前,我正在为每种产品存储以下值: 时间、已售商品、PRODUCT_ID、HIT、OTHER_ID

我想到了两种不同的数据存储方式:

  • 连续每个产品的日复一日(序列化)
  • 逐年连续每个产品(序列化)

还是你的想法?

我做的速度测试没有那么差,几乎不错。但是您对这个问题有更好的想法或经验吗?

【问题讨论】:

  • 多少数据,例如多少行?您可以以批处理模式加载(可以更快)还是需要实时查询?您将针对数据运行什么样的查询?
  • 这样做的目的是什么?最后你想用这些数据做什么?双?数据挖掘?只是显示它们...?
  • 如果是年复一年,每个产品只有一行。如果是一天一天,对于每个产品 360 ROW。我有 10.000 个产品,我计划了 10 年的统计数据。它也可以是实时查询。但不是每秒,而是每 2 分钟查询一次,并且最多。 2 个用户。
  • 收集数据的速度或查询数据库的速度?
  • 有了序列化数据,你总会遇到麻烦。

标签: php mysql database storage product


【解决方案1】:

实际上取决于您的报告需求 - 即,如果您只按产品/天报告,那么将交易统计信息作为批处理的一部分滚动到汇总表中是有意义的。

无论如何,我建议将您的交易数据和报告数据分离到一个单独的数据库中,这样您就可以优化交易数据以进行写入,并优化报告数据库以进行读取(并在不压缩的情况下生成大型报告您的事务处理能力)。

【讨论】:

  • 正如 Bob 所说,我将在事务数据中实现 E-R 模式,并为报告数据库实现星型模式。我还会使用触发器,以便查询的数据库具有实时更新。
【解决方案2】:

我假设您将该数据库仅用于静态数据,它与首先存储事务的“实时”数据库不同。

可能会出现速度问题:

  • 将数据插入数据库时​​
  • 当您查询数据库时(即从 Web 应用程序)

让您的数据库专门用于统计数据,开始设计您想要生成的报告是明智的;这样你就可以定义:

  • 您必须插入数据库的数据
  • 您要对数据库执行的查询

在 Excel 中草拟报告(但您实际上可以使用任何工具)并用虚假数据填充报告是了解您想要实施的内容的良好开端。

当您对 fake 结果感到满意时,您可以识别需要挤入数据库的数据、您必须实现的查询以及与您想要提供给用户的报告的交互,如果有的话。

如何用数据填充数据库

  1. 首先,您可能拥有大量详细的数据,例如描述购买的行。开始寻找在您的报告中真正有用的维度;维度是您关心的衡量标准,例如什么你卖了,什么时候最初卖了它。
  2. 对于每个维度,找到您希望在报告中使用的最小详细级别:您关心购买的时间,还是只关心年份?您关心所售产品的类别还是只关心其 SKU?

这将告诉您必须从原始数据库传输到统计数据的数据。

如何使您的数据保持最新

这在很大程度上取决于您希望更新统计信息的频率。您可以设置一个触发器来实时更新您的统计数据库或定期运行脚本来升级您的统计数据库。

备注

  1. 只要原始数据库的架构发生更改,或者更微妙地存储数据的方式发生更改,您就必须考虑这些更改对您的更新过程(触发器或外部脚本)的影响
  2. 如果您的统计信息有一些交互(例如,来自网络应用程序),我建议使用Data Cubes 来定义您的统计数据库。
  3. 请记住,您不能轻易对序列化数据进行排序、选择或分组。

【讨论】:

    【解决方案3】:

    将问题作为数据仓库/数据集市解决方案(星形/雪花模式)来处理,并带有汇总(聚合/物化视图)之类的表,以将复杂的长时间运行的查询减少为更快的简单选择语句。

    建议在填充事实和维度表之前将数据批量加载到暂存(临时)架构中,对其进行清理、验证和映射 :)

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2011-07-25
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2019-07-28
      相关资源
      最近更新 更多