【问题标题】:Managing huge transaction records?管理庞大的交易记录?
【发布时间】:2010-10-31 16:35:45
【问题描述】:

我有一个应用程序计划并从另一个数据库表中获取一些数据并转储到我的主应用程序数据库表中,该表中的记录数每天都在增加,我假设它会每天增加,因为它是事务事件数据主应用程序使用此数据进行处理,该应用程序获取每条记录并进行所需的分析并将每条记录标记为已处理。

我可以提供什么样的解决方案,以便将来可以减小数据库的大小?

在这种情况下你会怎么做?

根据我对一些企业应用程序的观察,其中一个提供了一个选项,用户可以 将“超过 60 天”的记录等存档到文本文件中。好吧,我可以提供一个选项将处理过的记录存档到文本文件并从数据库中删除记录,如果需要,可以稍后导入文本文件?这是一个解决方案吗?

【问题讨论】:

    标签: c# database archive


    【解决方案1】:

    如果您偶尔需要访问旧数据,那么构建一个流程将其归档为文本,然后从文本加载回来可能不是一个很好的解决方案。硬盘很便宜。

    您可以汇总旧数据。例如,如果事务数据现在是毫秒级的,但是当您报告较旧的数据时,您会按天获得它,然后考虑将数据聚合到“每日”作为您的归档过程。您可以每天将数十万行折叠成几行。

    还可以考虑一个良好的分区方案,您可以将最近的事务保存在一组磁盘上,并将存档数据保存到其他磁盘上,希望在这个过程中您可以轻松地添加新磁盘并为这些磁盘创建表。

    【讨论】:

      【解决方案2】:

      贵公司有什么样的过去数据报告需求?假设您将来不需要能够报告该数据,那么将存档数据放入文本文件是一件好事。但是,将其保存在文本文件中意味着您必须通过手动过程在需要时将其按需导入数据库。

      更好的选择是将档案数据移至不用于事务处理 (OLTP) 的数据仓库数据库,而是用作分析处理数据库 (OLAP) 的基础。当需要报告这些归档数据时,它就可以开始了。如果您仔细考虑如何在此归档数据库中构建数据,那么将所有数据聚合到一个 OLAP Cube 中应该非常容易,这样可以更快、更灵活地报告这些数据。

      但同样...取决于您是否报告数据,以及报告可能会追溯到多长时间。

      【讨论】:

        【解决方案3】:

        这确实取决于将对过去的数据进行多少分析,但是有一种方法可以将其全部保存在数据库中而不会成为性能问题。

        想到的解决方案是对有问题的表进行分区。我的公司有一个数据库表,它的数据按月分区,每个表包含大约 2000 万行。分区使得使用这些数据比将其存储在单个表中更实用。现在唯一真正的限制是磁盘空间,考虑到现在它有多便宜,这不是问题。

        不过,我知道有些数据库不支持分区。如果是这种情况,我认为将数据存储在分隔文件中将是一个合适的解决方案。

        【讨论】:

          【解决方案4】:

          恕我直言,这取决于用户需要分析过去数据的可能性有多大。如果可能,只需创建良好的索引并将所有数据保存在主数据库中。

          如果不是,则将其放入 TXT。当然,它发生的时间必须是可配置的。

          【讨论】:

            猜你喜欢
            • 2020-02-04
            • 2019-03-16
            • 1970-01-01
            • 2013-02-14
            • 2018-06-18
            • 1970-01-01
            • 1970-01-01
            • 1970-01-01
            • 2014-11-19
            相关资源
            最近更新 更多