有哪些好方法可以将性能统计信息存储在数据库中以供以后查询？答案

【问题标题】：What are some good ways to store performance statistics in a database for querying later?有哪些好方法可以将性能统计信息存储在数据库中以供以后查询？
【发布时间】：2013-05-30 20:08:12
【问题描述】：

目标：在数据库中存储您关心的内容的任意性能统计信息（当前登录的客户数量、正在处理的小部件数量等），以便您了解什么您的服务器在一段时间内的表现如何。

假设：数据库已经可用，并且您已经知道如何收集您想要的信息，并且能够根据需要将其放入数据库中。

解决方案的一些理想属性

不会对受监控的服务器造成明显的性能影响
具有非常高的测量精度
不存储无用或冗余信息
易于查询（有助于收集/显示有用信息）
易于绘制图表
准确
优雅

主要问题

1) 触发统计数据存储的良好设计/方法/方案是什么？

2) 对于如何实际存储数据，什么是好的数据库设计？

示例答案...有点模糊和蹩脚...

1) 我可以在每个 [固定时间间隔] 中存储一行数据，其中包含我关心的所有性能测量结果，该数据行包含一个由时间戳和/或索引的大平面表的每一列中服务器。

2) 我可以有一个守护进程监控我关心的性能内容，并在某些情况发生变化时（而不是固定时间间隔）添加一行到平面表中，如 #1。

3) 我可以像在 #2 中那样触发，但我可以将关于我正在测量的性能的各个方面的信息存储在单独的表中，从而可以为经常更改的项目添加大量行，并且很少很少更改项目的行。

等等

最后，我会实现一些东西，即使这是我自己编造的一些超级脑残方法，但我敢打赌，那里有一些非常聪明的人愿意分享他们的经验和好主意！

【问题讨论】：

标签： database-design statistics

【解决方案1】：

作为记录，我有点同意 KM，很难就所提供的信息提供具体答案；通常情况下 - 在这种情况下，您可能会从思考问题而不是最终结果中获得更多价值。

对于数据的存储 - 最好的报告将由设计用于报告的数据库完成 - OLAP 类型架构。

您如何获取其中的数据将是另一回事 - 我们正在谈论多少数据以及您希望如何移动它？我问的原因是，如果您要以同步方式插入它，您会希望它快速 - OLTP 样式的 DB 模式。

严格来说，如果您追求最前沿的性能，您可能需要为每个部分创建一个单独的数据库（捕获数据/报告数据）。

在你开始之前 - 如果你想要优雅 - 你需要仔细考虑你想要提取的数据的逻辑数据模型。你的优先级列表应该是核心@ 987654323@：时间、来源（组件等）等。这是关于 BI/基于数据的项目最重要的事情之一——您想回答什么问题？

这也是您开始确定要捕获的内容的地方。确保你对这些数据有很好的定义（它来自哪里，它意味着什么等）。通过“它来自哪里”，我不仅指的是方法/类/组件/系统，还指的是您记录的值的实际来源及其含义；这对于诸如登录用户数量之类的东西尤其重要，这个数字到底意味着什么？如果它是一个网络应用程序，如果您记录每个请求，您将能够报告“登录”的用户数量，无论您想要什么：平均值、一天中的时间、峰值并发等。

最后一点 - 取决于您正在做什么（以及如何），由于捕获太多数据而导致性能损失的风险很低；拥有它而不需要它通常比需要它而不拥有它要好。仅仅因为你拥有它并不意味着你必须报告它。

准确性：使用现有的广泛使用的行业组件来捕获/记录数据。
MS Ent Libs 非常适合这一点，它们拥有庞大的用户群 - 因此它们的质量很高。它们包括一个 Trace 语句，用于将执行时间记录到精细水平。它们还具有高度可配置性 - 这有助于实现优雅的解决方案。

【讨论】：

我很欣赏指向 OLAP 的指针。我以前从未听说过这种数据库结构。在我的具体情况下，我们可能不需要快速访问结果，所以我应该能够摆脱单个数据库。我是否应该做一个 RDBMS 或 OLAP（或其他东西）显然需要一些研究......
"dimensions" - 这是对“你想要存储的东西”的一个很好的正式定义解释。终于给它起了个名字真是太好了。
在我们的例子中，我们有 1 台 windows 服务器，以及大约 49 台运行其他操作系统（各种 linux、opensolaris、freebsd、os x）的服务器，所以“使用现有的、常用的... " 对我不起作用。
我觉得令人困惑的一件事是，首先要弄清楚如何测量，然后我需要存储哪些数据（或数据集）才能在稍后报道。例如，假设我想存储“CPU 使用率”的统计信息。显然，我可以很容易地测量大多数服务器上某个时间实例的当前 CPU 使用率，但是当我尝试在一天中的不同时间绘制“总 CPU 使用率”图表时，存储一系列瞬时测量值可能没有帮助。当然，这是具体的，我问的是一般......
也许这是我能做到的，我应该只谈细节。

【解决方案2】：

我认为Does not store useless or redundant information 和Is easy to query (lends itself to gathering/displaying useful information) 是相互排斥的。如果您非常有效地存储数据，就像在示例 #2 中一样，您将需要复杂的查询来重新创建在某个范围或时间点内发生的事情，因为您只存储更改。

你真的没有提供任何细节，所以很难给出具体的建议。例如，在您的示例 #1 中，您会考虑每分钟多少次间隔？这可能会影响您的 Causes no noticeable performance hit on the server being monitored 可能不会，取决于每小时 1 次或每分钟 30 次。

您没有提供有关您收集的统计数据种类的信息，因此无法进行表格设计。

无论您做什么，都将统计信息发送到不同服务器上的数据库。这将使您对生产数据库的性能影响最小。

【讨论】：

回应你的第一点，1）我不同意所有无用的信息都很难查询（对于那些互斥的信息来说，这需要是真的），但你的观点是真的这两个原则是冲突的，所以 2）我同意。原则冲突。由于缺乏细节，我有大约 50 台服务器要设置监控，并且服务器的特性（用途、设计、工作负载、操作系统、硬件等）千差万别，所以我特意寻找有关统计数据收集的任何一般原则。我从来没有收集过统计数据...
该评论应该在两个单独的段落中很好地格式化，但显然评论格式化与问题和回复的工作方式不同。
我绝对同意数据库应该在单独的服务器上，并且我确实计划这样做。试图将每台服务器的统计信息保留在每台服务器本地会很痛苦。

【解决方案3】：

在开始之前，请记住准备好通用监控工具。 Zabbix 或 Munin 可以告诉您一般资源瓶颈在哪里（例如内存、CPU、I/O），PgBadger 等特定于数据库的日志分析工具可以告诉您哪些查询很慢等等。

我将通过可用的技术和实施时间来间接回答：

1) 如果您有许多不同的指标想要尽快开始记录，并且以后可能会担心检索数据（例如，您不知道要测量的确切内容，所以您只想倾倒所有你能做的），你可以使用一些 NoSQL 数据库，比如 MongoDB 或 Redis。

稍后，您可以使用数据。检索效率不高。

2) 如果您喜欢敏捷方法，请从小处着手。选择任何后端（SQL、文本文件），只转储一些数据，然后根据第一次调查显示的内容使用更多列扩展它。表格设计仅取决于您的应用程序。对于 MVC Web 应用程序，它可以是控制器 / 操作 / user_id / total_pageload_time / memory_used。然后你可以简单地按控制器分组，看看哪些部分是慢的。根据我的经验，SQLite 适用于像这样的只写数据。

3) 如果您需要进行微优化，您可能应该为您的服务器软件寻找官方或非官方的插件或外部工具（例如 PgBadger for PostgreSQL 等）。

无论如何，考虑到您的“理想属性”，我会首先使用某种带有小表的 SQL 服务器，逐步添加跟踪参数，而不是试图提出一个完美的永久表设计。

【讨论】：