报告存储的最佳解决方案是什么?

发布于 2024-09-12 01:35:36 字数 371 浏览 2 评论 0原文

我目前正处于报告系统的设计阶段,该系统将为一组 ATM 创建屏幕比较报告(正在 Ruby on Rails 中开发)。

从每台 ATM 收集的数据都存储在 XML 中,其中包含文件名、修改日期、大小和校验和。然后将这些文件与主文件进行比较,并报告每个 ATM 的额外、丢失或不匹配的文件。

问题是如何存储生成的报告。该报告将包含所有 ATM 的索引及其总数,然后包含每个 ATM 的单独详细信息/文件列表报告(大约 1000 个)。每天都会创建一份报告,保留 60 天。

我考虑过使用 CouchDB 或 MongoDB 等文档存储,并将所有信息作为单个文档存储在数据库中。

粗略估计 60 天的数据将占用大约 30 GB。

你会如何应对这种情况?

I'm currently in the design stage of a reporting system which will create comparison reports of screens for a fleet of ATM's (being developed in Ruby on Rails).

The data collected from each ATM is stored in XML which contain File Name, Date Modified, Size and Check-sum. These files are then compared with a Master file and report on extra, missing or mismatched files per ATM.

The question is how to store the generated report. The report will contain an index of all ATM's with total and then a separate detail/file-list report for each ATM (around 1000). There will be a report created each day with a 60 day retention.

I've considered using a document store like CouchDB or MongoDB and store all information as a single document in the database.

A rough estimate of 60 days worth of data will take up around 30 GB.

How would you tackle this situation?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

最好是你 2024-09-19 01:35:36

“粗略估计 60 天的数据将占用大约 30 GB。”

所以? 30Gb是一个小到可以忽略不计的大小。举个例子,1Tb 是一个值得花时间思考的大小。

30Gb 的尺寸非常小,任何可行的解决方案都可以。快速实施并继续前进。

"A rough estimate of 60 days worth of data will take up around 30 GB."

So? 30Gb is a size so small that it can be ignored. As an example, 1Tb is a size where time should be spent thinking about it.

30Gb is a size so small that any solution that works is fine. Implement it quickly and move on.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文