烹饪肉类视频地址：
在上一课，我们完成了面向学费的组的存储。本课程从日志框的存储设计开始。
在这里，数据不会将数据存储在页面中，该数据只能存储日志记录，即我们通过日志插入的数据以及我们如何更新系统中的数据，包括：将语句日志插入到该系统中元组，删除量化的语句日志，更新语句日志日志。此描述很快编写，因为无需在页面上查找和更新页面上的单个组组，该组将在末尾添加。这是非常快的写作，也适合磁盘I/O。
但是阅读是很麻烦的。为了阅读记录，我们要做的就是从背面扫描此日志以重新创建我们要查询的元组。
当然，我们可以进行一些优化。例如，我们可以构建一个索引来查找每个组应用的不同日志记录，因此我们不需要扫描所有日志记录。但这会带来元数据存储消耗。
另一种优化方法是定期压缩这些日志，基本上只是将所有日志记录压缩到一个值中。该过程是获取锁定并锁定页面，然后执行压缩，然后发布锁。让我们讨论压缩方式如何更深入：
第一个是级别的压实：从顶层开始是级别0，我们根据执行顺序有此日志文件，它不断积累并随着时间的推移累积所有这些页面。我们要做的就是做一个周期性压缩，也就是说，当两个页面填充在0级时，它们内部的记录被合并和排序，并将其压缩到较大的文件并将其放置在下一级别。日志文件将在顶层的顶层建立。我们只是重复此过程。如果第一层有两页，我们将组合，分类并压缩为新的2级并推入各节。另一个是普遍的压实：也就是说，没有级别的概念，但是它已合并和组合带有压缩的相邻页面文件。
如果页面上有一个单独的金属组，我们如何存储它，如何解释存储在其中的数据以及如何使用其他DBMS使用或从Meta组存储中使用或提取所需的数据。- 组本质上是一个字节序列。DBMS目录将包含表模式信息。通过此模式信息，可以解析元组中的数据。
乌龟中的数据属性可以具有不同的类型。常见类型包括：
这里最棘手的是浮动点的处理 - 小数点或任何精度十进制。
对于十进制数字具有不确定的十进制准确性的小数，例如计算结果数量数量的十进制数字，因为精度不确定，因此很难通过某些计算机结构（例如相应的浮点）表达它，例如C/C中的双倍结构++/真实和其他类型，它们通过IEEE-754标准的实际存储十进制近似：
0.03125 + 0.0078125 = 0.2265625，再加上隐含的数字1为1.2265625，然后2的第6侧为1.2265625 * 64 = 78.5.55
使用倍更多，因此接近的错误较小。Float使用较少的位，并且可能的错误将更大。在这里，是由指定的精度显示程序引起的可能的错误，以显示此IEEE-754标准近似值。
如果您不需要这样的准确场景，则可以使用此IEEE-754标准近似值。如果您需要一个非常精确的场景，请不要使用此。您需要使用固定的编号类型（数字类型）
您可以为数字类型设置任意准确性和数字，这些事物在实际系统中的工作方式，有许多不同的实现。从总的来说，数据库的商业版本更为复杂，因为他们知道商业应用程序的需求很大对于固定的准确性值。但是在这里称重的是，您需要的准确性越高，在处理过程中的昂贵。
Postgres意识到其数字数据类型：
该结构包括：
MySQL的存储结构相似：
该结构包括：
大多数系统不允许超过单页的大小，因此列出或有限或两者都有限制，因此它们不能指定大于一个页面大小的元组，但是如果meta的值 -组大于一页的大小？页。
假设元组的C属性是VARCHAR类型并保存了一个较大的值，那么Meta组的内C的位置将保存指针，该指针将指向存储在溢出页面中的VARCHAR数据。溢出页面可能无法保存一个页面，一个以上的页面大小，因此它将是一个页面链接列表。不同系统中有不同的名称：
除了溢出页面外，还有另一种将其存储为外部文件的方法
一些DBMS允许您将此大价值存储到外部文件中，并将此数据处理为blob，例如:::
通常，我们不适合将数据库中存储在外部文件存储中的大型数据，例如视频，图片等。我们只是存储指向数据的指针。实际数据位于文件系统的其他部分。我们可以在需要时引用它。
但是，这将失去DBM的管理特征，例如在外界是否进行任何修改或删除此外部文件，并且无法保证交易的修改。
对于不适合数据库存储的大数据，例如Big JSON等，Jim Gray曾经有一项纸面研究，可以直接在溢出页面上评估BLOB的数据大小，或者最好将Blob存储在外部。影响力，这是15年前的一篇论文。本文的结论是，他们得出的结论是，256KB的大小在外部存储中更有利，现在这个数字可能会更大。但是我们需要记住，如果将其存储在DBMS中，我们必须写这些巨大每次都从许多页面写和阅读并从磁盘上读取对象。这是我们必须考虑的交易。
我们要谈论的下一步是系统级目录。DBMS需要在内部内部保存有关数据库的所有元数据，以方便他知道如何编码和解码代表组的字节中存储的数据。结构信息。DBMS通常会像访问权限一样存储有关用户和权限的信息，也就是说，用户应该能够查看或修改哪些数据。第一次，DBMS还存储了大量内部统计信息，例如不同值的数量，例如，或连接基础或数据范围。这些对于制定查询计划很重要。查询执行非常重要。
大多数DBMS存储数据库作为目录类型结构。我们之前说过，在此系统目录中，关于表，列，索引和视图的结构信息也将存储在此系统目录中。这些结构信息也像普通桌子一样存储。然后存在鸡蛋和鸡肉的问题。我们需要这些结构信息来分析和读取表数据，但是此信息也以表格的形式存储。因此，一般设计是它们具有这些特殊的元数据对象包装器，可用于直接编码和解码值存储在系统目录中。
用户可以查询此DBMS的内部目录，该目录通常存储在此信息_schema中，以获取有关数据库和各种统计信息的信息。该信息由ANSI标准定义为“仅查看”视图的集合。在标准化之前，这曾经是混乱的。每个系统都有自己的方法来公开这些元数据。现在，使用此标准，每个人都可以通过访问信息_schema.schema.schema.chem.ch.schema.ch.schema.ch.schema.ch.schema.ch.schema.ch.schema.ch.schema.schema。
这是在数据库中列出所有表的命令：
这是表的详细信息的命令：
我们主要有三种不同类型的数据库工作负载：
此坐标图可能更直观。X轴是从写作更多到阅读和阅读少。Y轴是请求复杂性，从简单的答案到复杂性。TOLTP的工作负载更为书面，更简单。OLAP的工作负载更多是阅读越来越复杂的请求。HTAP在两者之间。
在实际使用中，通用公司将建立OLAP和OLTP的独立环境：因此，您通常一端有多个OLTP数据管仓库。所有数据管仓库的数据都存储在数据仓库中，以进行分析。我们需要进行分析。将数据从数据仓库传输到数据仓库，主要通过此ETL（提取负载，提取，转换，负载）过程：我们从这些不同的数据管仓库中提取所有数据，这些数据格式可能与我们一起使用，我们最终的数据格式是不同的，因此我们需要转换这些数据并对数据进行一些处理，例如合并，删除重复等，并最终加载到数据仓库中。还有一些数据分析结果需要从数据仓库返回数据管仓库。例如，某些产品推荐信息，以及当您访问产品网页时建议您建议的产品。HTAP的想法是让这些交易与查询工作一起工作，并忽略许多中间同步操作。
为什么要区分不同类型的工作负载？回顾一下关系模型，它为我们的不同操作提供了某些规则和要求，但它并不告诉我们如何将数据存储在物理中。我们需要确定如何数据基于我们的业务，即工作负载的类型存储。我们主要谈论线路的存储，即某个金属组的所有属性的数据都被紧密地存储在一起。但是此设计并不应用所有的所有属性场景。让我们看一下维基百科的例子：
我们有一个UserAcct表，即Wikipedia，其中包含用户ID和用户名；然后有一个页面存储Wikipedia数据；然后是一个修订表，该表显示了哪个用户已编辑或修订。在同一时间，用户ID指向userAcct表，pageID指向页面表，页面表的revid指向修订表。
对于Wikipedia OLTP业务场景的几个示例，这些场景只会在查询表中修改或查询很少的数据：
Wikipedia Olap业务方案的一个示例是从上个月从不同的登录中查看.gov的用户数量。这将扫描表中的大多数数据。
我们介绍了存储模型的概念。第一个是基于行的存储模型。阵列，所有内容都是连续存储的。这种格式对OLTP业务请求更友好，因为查询倾向于操作单个记录或该行的所有数据都存储在一起。如果您不考虑溢出的页面，则一页将被操作。
使用以前的Wikipedia的OLTP示例，例如用户需要查询单个用户登录，此请求将采用索引（该索引将在第七次讲座中提及），并且该索引将告诉我们哪个页面要获取哪个页面以获取本用户元组的位置，读取插槽以获取用户元素组和页面的位置，然后读取用户的meta -group.at的所有信息同时，注册的新用户需要插入记录。此插入仅将其放置在一个页面上，所有用户都在一起。
但是，这种存储不适用于OLAP场景。它仍然使用前面提到的Wikipedia百科全书来检查上个月.gov的用户数量。过滤主机名是.gov，LastLogin是上个月，然后计算LastLogin字段，也就是说，我们实际上只需要两个主机名和LastLogin的字段，但实际上，我们加载并解析了整个群集组的所有属性。value.value。这些带来了磁盘I/O的浪费，以及整个群集数据的额外内存和CPU消耗。
我们总结了N Yuan存储模型的优势和缺点：
第二个是基于列的存储模型。这是SO值的分解存储模型或DSM（分解存储模型）。元组的单个属性的值将连续存储在一个页面中，而不是连续存储单个元素组，该元素组连续存储单个元素groupAll不同属性值。我们将提取Meta -group的所有配额值和连续存储它们，这也是名称“列存储”的来源。这对于仅读取查询的许多OLAP工作负载非常理想。通常，此查询需要分析大多数分支的某些属性值。如果我们将相同属性的值放在一起，我们就不需要扫描查询无法在查询中使用的查询。属性的值以及相同属性的值将更有效地运行属性的聚合功能窗口函数。我们返回前面提到的Wikipedia的OLAP示例，以检查上个月的.gov用户数量。此查询我们只需要主机名和LastLogin。我们不需要表单中的任何其他属性，因此我们现在就已。您可以找到与这两列相对应的页面，从而减少数据消耗以进行扫描。
但是，对于需要返回元组的所有属性的请求，例如，要查询某个金属组的所有属性，您需要查询每个属性所在的页面，然后汇总返回。那么，如何从每个属性所在的页面中找到相应的数据？
有两种方法可以：
我们总结了DSM存储模型的优势和缺点：
DSM系统不是新设计。它们已经存在一段时间。第一个是1970年代发布的康托尔。实际上它不是DBM，而是文件系统。在1980年代，有关于DSM存储的第一个理论基础或建议。在1990年代，有一种名为Sybaseiq的产品，就像Sybase一样他们做的是不流行的。要加速记忆中记忆中某些类型的查询的查询。从21世纪初到中间，这三个系统开始流行。vertica，vectorwise和monetDB。它们是第一个流行的商业成功的列存储，并为许多常见的常见列表存储技术铺平了道路。2010年，基本人将使用基于DSM的系统。
总而言之，尽管该课程一直在说DBM是在课程开始时由这些独立部分组成的，但它并非完全独立。例如，为目标工作负载选择正确的存储模型非常重要。对于OLTP，您想要商店，OLAP需要存储。
微信搜索“干货充满了张哈希”，请注意公共帐户，添加作者微信，每天一刷，轻松改善技术，并获得各种优惠
原始：https：//juejin.cn/post/7102213695324815390