度量标准存储的关系数据库架构设计

Question

考虑具有以下特征的系统：

• 存储从多个传感器/输入收集的时间序列数据/度量。
• 在不同的时间从许多不同的系统收集数据点（指标）。
• 这些指标通常都是一个数据点（例如，温度和湿度不是同时报告的，而是单独报告的，并且时间戳会不同）
• 收集的指标类型将随着时间的推移而扩展-系统处于开放状态，并且随着时间的推移将支持其他输入（例如，今天我们收集温度，湿度和cpu，明天可能会添加监视CO2和RAM的传感器）。
• 给定时间段的所有指标摘要都需要通过查询获得，这很可能是最常见的查询方案。

我可以想到三种建模方法。

1.宽表-具有每个类别的表（已覆盖）

注意：由于数据点是单独收集的，因此具有很多稀疏值。存储新指标需要新列

2.窄表-带有每个指标的表（已覆盖）

注意：新指标的存储需要一个新表

3.类型表（未涵盖）-具有单个指标表（未涵盖）

注意：新指标的存储仅需要metricType表中的新行，而无需更改架构。尽管由于按时间段在所有指标上进行分组而不需要联接，因此可以担心由于块大小而对性能造成的影响，因此可以更快吗？

我想知道是否有人可以评论或提出选项，让我指出一些性能基准，包括3以及1和2，或者通常就每种方法的适用性提供任何建议。我计划对此进行自己的实验，完成后将发布结果，但在此阶段，您将不胜感激。:)

请注意，不建议使用nosql解决方案，我知道该领域的选项，并正在分别评估该选项

Answer 1

1项提案

“宽桌”

这有严重的规范化错误（如果认真对待，还会有大量的Null和完整性问题）。这是无法使用的，不需要进一步评论。

“窄表”

那没有错误，但是规范化尚未完成。

“类型表”

这很完整，是您三种情况中的“最佳”。但是它从狭义的角度来看问题，并且与问题存在的背景完全隔离。因此，由于您查询之外的其他原因，这是错误的。

2问题

1. 第一个问题是，您正在比较无法合理比较，彼此不合理相等的三件事。

2. 第二个问题是，EAV是当月的风潮，许多人对此深深着迷。但是，它存在重大问题，并且如果要以某些数据完整性实现它，则需要额外的一组“元数据”表。关键是，不需要EAV。

3解决方案

收集的指标类型将随着时间的推移而扩展-系统处于开放状态，并且随着时间的推移将支持其他输入（例如，今天我们收集温度，湿度和cpu，明天可能会添加监视CO2和RAM的传感器）。

这实际上是一个直接的关系数据库问题，可以通过一个完全普通的关系设计来解决，该设计可以提供完整的关系能力；关系完整性；和速度（其他设计没有）。

警告

但是，由于市场上所谓的“关系”不是关系的事实，有一些警告。

1. 摆脱Record ID领域，它们是反关系的。

   • Record IDs 将您的架构简化为1970年代风格的“记录归档”系统（为方便起见位于SQL容器中）。
   • Record IDs不提供关系模型要求的行唯一性。
   • 此外，它们每个文件需要一个附加字段和一个附加索引。

2. 在对数据库建模时（无论是否为关系型），将数据视为数据，仅将数据感知。不要根据您需要的GUI或某些查询或其他内容查看数据。

3. 在此（建模）阶段关注性能问题是错误的。首先正确。其次，使其快速。不要颠倒规定的顺序。

4. 关系键提供含义以及关系完整性（这是逻辑上的，与引用完整性（是SQL的物理功能）不同）。这解决的是对象存在的上下文。

   • A Sensor并不是孤立存在的（除非它在商店的货架上的包装中……但即使如此，它也存在于商店库存的上下文中）
   • 活动仅Sensor存在于其所在对象的上下文中。您尚未提供有关此信息。让我们将其称为通用标签。Article
   • 此外，它是对Article传感器正在测量的指标（出于超出范围的警报等目的）而不是传感器本身的要求。（传感器可能有一个范围，这是不同的。）
   • 同样，a Sensor存在于Location第二个向量a中。否则，Article存在于中Location，并且Article Key携带Location。我已经为后者建模。

资料模型

解决方案如下： 传感器数据模型

嵌入式图形可能无法在某些浏览器中显示。在这种情况下，它在PDF中。

• 它将同时满足OLTP和OLAP（尺寸系数）要求。
  • 如果您提供更多背景信息，我们将为您提供精确建模的环境。这可能需要一些往返时间。
• 它仅限于提供的信息。
  • 我已采取MetricType并SensorType是同义词。
  • Article显示为依赖于（存在于）Location，或者它们可以是单独的向量。在任何情况下，Article与Location一起出线Sensor。
  • 由于SensorSerialNo是唯一的（AK2），因此Reading(SensorSerialNo, DateTime)是唯一的。不需要索引。但是，如果仅Reading via 上有许多查询SensorSerialNo，那么这样的索引将提高性能。

• 请随时提出问题，我会回答。

• 对于那些不熟悉IDEF1X的人，请参阅IDEF1X简介。

• 对于那些熟悉IDEF1X且只需要刷牙的人，请参阅IDEF1X Anatomy。

4表现

您对性能的关注是好的，但是在此阶段还不成熟。首先确定数据模型正确，其次快速获得数据结构。原因很多，但并非最不重要的原因是，当数据被规范化时，相对而言，结构已经非常快。此外，永远不要针对特定​​查询进行优化（如果需要，可以在第二阶段添加索引）。

不过，我会回应您的关注。

• 例如。规定的ReadingPK 上的ClusteredIndex 将：
  • 服务大多数查询，大多数维度（SensorSerialNo 单独使用的查询除外，在这种情况下，我建议使用其他索引）
  • 服务所有OLTP事务并确保最高的并发性，因为事务Sensors是按实际世界分布的：跨Locations和文章。
• 而Record ID担保指数可以保证每一个热点INSERT。非常适合创建死锁。

基准测试

在过去的40年中，我为OLTP和OLAP的使用收集了大约100个此类数据结构的基准。我的大多数客户都是银行（想想：传感器读数非常类似于一天中的股价变化；多个向量（维）；数十亿行）。银行对机密性非常严格，因此我无法按原样发布基准，而编辑基准将需要时间和精力。

对于非常相似的要求，我确实有一个基准，那就是公开。实际上，它已包含在“ 关于时间序列的SO问题” 答案中，但寻求者已邀请主持人将其删除（这对Oracle来说很尴尬）。这是针对固定DDL（时间序列数据）和填充的Sybase ASE vs Oracle 10.2基准测试的基准摘要。

最后，所需的结构和代码非常简单，足以让您运行自己的基准测试。

5对其他答案的回应

关于内维尔的评论：

但是，如果您还必须回答“在哪一天CPU高于30％而湿度低于56％超过3小时以上”之类的问题，则您的EAV模型将变得很难使用。这些查询将很快变得很难编写和理解-每个标准至少要有1个自我连接。

注意到他的评论涉及EAV，但Reading在这种情况下可能暗示它同样适用于主题表（普通的关系数据库表（non-EAV）），因为它涉及查询类型（而不是EAV概念与关系概念）：

• 该声明不适用于关系表（它很可能适用于EAV；由于记录ID引起的大量问题；等等）

• 只要你有

  1. 真正的关系数据库架构（如我所建议），以及
  2. 真正的SQL平台（不是伪装的“ sql”，它不符合要求但会欺诈地使用该名称），以及
  3. 您了解IN和NOT IN，以及如何比较SQL中的Set

• ...这样的查询直接编写代码。

6对问题的回答（在评论中）

您在record_id上是否有任何反联系的链接，我暂时不相信您，但我有兴趣了解更多有关此反模式为何如此流行的更多信息。

链接

不，但是您不需要它们。问题的一半是，科学已经恶化到无法接受。伪科学 反科学。在科学中，真理是绝对的，不容争议，而在当前流行的反科学中，没有绝对真理，只有相对真理，无休止的“辩论”，没有解决之道。此外，在这种混乱的反科学中，“学术”制造并设计了关系模型中不存在的各种“问题”来解决“问题”，然后，您需要进行第二级无休止的“辩论”，以进行更正到无问题是好是坏。

您不需要链接，因为没有什么可“辩论”的，而您可能碰到的任何“辩论”都忽略了以上几点。

唯一的权威是伟大的EF Codd博士，我是他的门徒。所有书籍和教科书的所有作者（是的，教育，也被摧毁了），都声称是关于关系模型的，除了Codd之外，实际上都是错误的，他们是要实现1970年的风格的Record Filing Systems，以及anti-Relational（没有关系能力；没有关系完整性；没有关系速度）。从1970年开始，他们就犯了一个错误，那就是试图将RM纳入他们1970年的RFS思维方式，而不是发布并采用RM思维方式。他们花了最后五个十年来加强这一点，甚至用“数学定义”来证明这一点。17个“关系代数”；42个异常的“正常形式”。一切完全反关系。他们互相引用，因此被发表。

第二个问题是，诸如SO之类的场所是根据民粹主义来确定的。流行的答案不是最佳或正确的答案。为此，您需要一个权威（民粹主义者非常害怕）和客观的绝对真理（真理不会改变，它是永久的）。（人们喜欢他们的相对或主观的“真相”，这些真相一直在变化）。

1. 因此，您只需要一个单一的权威性定义，原始论文，Relational模型。

   • 是的，这些天这些条款已经过时了，人们对此还不太了解。
   • 是的，这是开创性的（每个单词都很重要，含义很深）。
   • 不，您无需阅读第2节（数学）。

2. 您需要从中收集以下信息：

   • 关系密钥是“由数据组成的”（我的解释是RM中的几个条目），这是逻辑上的
   • 代理不仅（a）不符合该定义，（b）它们是关系前的范式，即物理指针，是RM所取代的东西，并且（c）明确禁止。

   • 非常重要的是，您不仅需要了解关系密钥的定义，而且还需要了解其原因和原因。

   • 例如。它克服了基于指针的系统所具有的导入/导出问题。

   • 例如。时间定义（符号； 8个字母；令人恐惧）。

3. 因此，没有争论，也没有“辩论”。

   • 任何反对这一观点的人都是反关系的。不是因为我这么说，而是因为它与证据事实和单一机构相抵触。
   • 我已经列举了正确使用RM的显着技术优势（关系力量；关系完整性；关系速度），但是要进行扩展，需要付出大量的努力。
   • 不遵守RM的后果是，您将（a）没有获得任何好处，并且（b）您将收到关系记录归档系统在1970年之前遇到的全套问题，并且（c）人为设计的“解决方案由从未成功的“学术界”提供。

4. 如果您需要扩展RM的那些好处，那么您当然需要一定程度地理解这些好处，因为每一项都是非常深刻且非常重要的，我能提供的就是这一点。您可以想象，这是我必须在与该主题相关的每个答案上进行的战斗，因此，多年来，我在许多答案中发布了相当数量的文章。

   • 转到我的个人资料，选择所有答案，然后阅读与此主题相关的任何内容。

为什么这种反模式如此普遍？

简短的答案是，人们喜欢他们的无知和主观的“真相”，并且会与牙齿和指甲搏斗以保护牙齿。他们迅速接受并重复任何理由维持原样。学习一些与他们所知道的相去甚远的范例，这是非常令人恐惧的，因为它威胁着他们舒适的无知，并将其暴露给真正的真实。他们将不得不承认他们为五个十年编写的内容是错误的。这就是民粹主义兴旺的原因。无知。

稍长的答案是这个。看看互联网。在过去，对于任何特定主题，我们只有一个来源，一个绝对权威：例如 购买《大英百科全书》；花整个童年吞噬它。永恒的真理。诚实的历史。但是现在任何人只要有一个键盘和两个手指加上一些结缔组织（不需要大脑）就可以张贴。作为即时的“权威”。网络上塞满了（a）表面答案（“现在就是答案”的反义词）（b）许多口味的（c）由于民粹主义而被推崇的（d）远远没有正确的答案或完整答案。大众容易理解的声音叮咬声。很少有人想要完整答案的深度。

即使建立了某种权限（例如Wiki； SO），它也很容易被颠覆，因为从字面上看，有数以百万计的人在更改，更改和更改条目（因此，只要某件事发生，事实就不会更改）在改变，这不是事实）。主要是为他们的政治职位服务；他们的思想；他们改写历史以使过去成为错误（不是，它已经发生了），而现在的精神错乱则是“好”。

明确的答案是这样。学术羡慕。Codd的关系模型花了整整十年的时间才被理解和接受。即使这样，也只有少数几个。IBM和Britton-Lee（已成为Sybase）在精神和言语上实现了Codd的RM。（Digital Equipment Corp也做过，但是已经倒闭了。）那些似乎与Codd合作的“学术界”竟然实际上是在与他合作（根据证据）。他们讨厌这样的事实：他们自己没有提出，一个人提出了第一个真实的模型，并带有声音。逻辑 数学基础，以及相关代数。全部集成。满足了当天的所有要求（例如物料清单问题）。这经受了时间的考验：

通常，他们会错误地声明：“但是Codd并未对此进行定义，所以在这里我对其进行定义...”。因此，他们提出了自己的RA。现在他们有17个，都是无关紧要的。异常的“正常形式”将其记录归档系统的零散位提升为“关系”。现在他们有42个，都是无关紧要的。和许多书，声称是“关系的”，但事实证明是反关系的。每个“学术”都试图增强其“学术”地位，以对抗其他所有学科。

即便如此，学术上的嫉妒及其各种替代形式的存在，仅仅是因为科学已经被颠覆为糊糊的，在那里允许存在矛盾的论点（在过去，这会被嘲笑）。它存在于对单一权威概念的反叛中。而且因为逻辑已从科学中删除。

这就是为什么我要再说一次，去唯一的当局。不要从反关系人群那里读任何东西，因为它会（最好）减少您对RM的理解，或者（最坏的情况）使您的思想中毒。

一澄清

如果您检查“关系PK”（例如）Location.Location，可能看起来很奇怪。这是一个%Code或者%ShortName是数据，用户实际使用。通常为4到6个字符，最多12个字符。与long不同Name，后者必须存在，并且是备用键。当然，它绝对不是任何种类的数字（不是数据，不是用户使用的东西）。用户也很喜欢他们的简短表格。显然，请使用任何存在的国际标准。

密钥必须是稳定的（不是静态的，Universe中的任何事物都不是静态的），并且必须在现实世界中用于唯一标识对象（数据行）。

• 例如。因为Security，这是一家在美国证券交易所上市的公司，在美国也可能是TickerSymbol在澳大利亚ASXCode。ISO代码an ISINCode是一个AlternateKey。

• 对于城市，请使用以下地理位置标准之一：ISO；FIPS；等等（我使用Statoids是因为它比其他人早很多，但是那几天已编号）。最坏的情况是使用机场代码。

您认为什么是真正的sql？SQL Server，Postgres，mysql，oracle我猜都是这样吗？

不。我的意思是任何实际上符合已发布的SQL标准的平台，因此实际上可以支持关系表。集合的关系处理；和ACID交易。

• 这会自动排除免费软件/蒸气软件/无处/“开放源代码”，因为这些代码是由10,000名分布在整个宇宙中的开发人员编写的，没有任何管理原则。例如。每个代码段中都不需要ACID事务或它所需的结构。现在插入该文件为时已晚，因为它将需要100％重写，并且禁止使用...服务器体系结构。

商业，这意味着付费和支持，也很重要。您是否有维护合同并且立即获得支持，或者发布了错误报告，并在接下来的一年或三年中每天检查更新。

如果需要可伸缩性或性能（高吞吐量，高并发，低延迟），则服务器体系结构最为重要。同样，这不包括免费软件和Oracle，因为它们没有体系结构，因此它们获得了操作系统来执行数据库服务器通常会执行的所有功能。

检查一下Oracle与Sybase体系结构的比较。

• 完全相同适用于PostGres NON sql和其他免费软件。PooGres（Ingres的失败者）是著名的压力大手笔，大量的锁定问题和非常低的并发性。

高端，商业，SQL兼容
大约5％的市场份额，但95％的金融服务和自动化市场。伟大的建筑，绝望的营销。

• Sybase ASE
• IBM DB2

商业化，SQL兼容
轻松实现最常见。良好的体系结构（最初是从Sybase窃取的），然后以通常的疯狂MS风格“升级”。

• MS SQL Server
  使用痛苦；大量开销 与各种附加组件和必须使用的集成不良。
  （我仅在Sybase或DB2中提供系统，客户可以自由地将其转换为MS。）

商业，SQL不合规的
无望架构，出色的营销。

• Oracle
  通常，Oracle开发人员非常擅长以使产品正常工作所需的方式使用该产品，但这意味着他们与“ 关系模型”相去甚远。

  • 例如。在时间序列基准中，重点是，当请求子查询时，Oracle会自动填充，因此必须使用“内联视图”。OP所称的速度与子查询一样快（这避免了它需要更多代码的事实，并且编码人员必须走出关系思维方式的事实）。其基准被证明是欢快假，在测试的每个方案（甲骨文为3〜4.8 倍比的Sybase慢上的COUNT()，26至36 倍于较慢的SUM()
  • ...并且120分钟后必须放弃子查询（Sybase 2.1秒）。
  • 例如。Oracle是不合规的re ACID事务处理程序，开发人员在一定程度上解决了该障碍，但是根本无法防止Phantom Update和Lost Updates（技术术语）。如果解决方法未正确编写，则整行（UPDATES或INSERTS丢失）。
  • 所有适用于以下内容的...

非商业SQL不合规
这些人花了很多时间来开发“关系数据库”不需要的“功能”，但这些功能对反关系记录ID归档系统非常有吸引力。

• 例如。“递延约束检查”；ENUMs; 等等
• 他们缺乏SQL合规性的基础。例如。没有真正的ACID交易。

此外，如上所述，零体系结构。这导致系统在一次性使用下表现出色，而在并发性或可伸缩性带来的任何压力顺序下均会严重失败。

由于他们不遵守SQL要求（典型的欺诈和小偷），因此他们不厌其烦地在Commands手册的每一页上发布了符合性通知。（只需要在手册的开头声明一个符合性声明。）当然，缺少的命令只是缺失了，所以，天哪，它们没有符合性声明。

• PostGres NON sql
  自从Ingres时代以来，我就不得不检查最糟糕的污水。深受“学术”人群的喜爱，仅仅是因为它被“学术”同伴所raw草。
  最多5个用户，或处理并发问题（只粗略地看一下SO上报告的问题）。

• 我的NON sql
  高于PoS，但仍属于此类。

  • InnoDB引擎在性能部门上明显更好，但与Sybase / DB2级别相差甚远（仍然没有真正的服务器体系结构）。SQL不合规部门没有喘息的机会。

摘要

• 你得到你所付出的。

  • 服务器架构，最明显的是在每种情况下的性能。
  • SQL合规性，经过深思熟虑，并在每个适用的代码段中实现。
  • 最后但并非最不重要的一点是支持。

• 请记住，无论选择什么，将其移植到另一个平台时，您的SQL代码都需要进行完整的检查和更改，因为SQL（或NON-sql）的“风格”非常不同。因此，请谨慎选择，并牢记长期的实施方案。