列式
数据库专栏
一个由多名专家撰稿的关于数据库技术和创新的博客。
曾经
...
当今关系型数据库体系结构的起源
当今关系型数据库管理系统很大程度上是基于二十世纪
80
年代的设计理念而构建的。相对于今天的系统而言，那个时候的计算机价格不菲，而且速度很慢。最大程度上减少昂贵的
CPU
周期
–
而不考虑
I/O
吞吐
–
是早期关系型数据库管理系统
(DBMS)
设计的驱动力。市场追逐的有利卖点是事务处理以及与之相配的简单决策支持，只要能够访问有限的属性（维度）集，用户往往就感到满意了。
事务处理通过主键或其它键来检索行，并在这些行上执行适当的插入、更新和删除操作。可以通过索引或散列进行直接访问，其提供的快速访问只占用小部分处理能力，还具有足够的并发性。在大多数系统中，平均起来每个表有一到两个散列或索引。这减轻了在执行删除和插入操作时必须维护大量结构的压力 －会占用相当大的处理器周期的操作。
吸取 IBM 的经验教训
在 IBM 早期开发 DB2 的时候，我们的重点是最大限度地减少用于事务处理占用的处理器周期，并与我们的硬件同行一起合作优化了比较相关的几个部分。相对于前一代非关系型数据库管理系统（ IMS 、 IDMS 、 DATACOM 等等）而言， DB2 的成本增加了两到三倍以上，主要是由处理器消耗产生。很多人容易忽略的事实是，在 DB2 上开发和部署应用程序，比在现有的数据库管理系统上要明显快得多。
尽管关系型的指令只是想检索应用程序真正需要的一行中的某些属性，但应用程序倾向于检索整行（所有属性）。应用程序拥有标准的表格映射，它们是由应用程序代码中的数据字典生成的。编写 SELECT * 并添加谓词比在复杂应用中确定是否与其它部分共享检索行要简单得多。将行的属性从存储缓冲区移到应用程序的空间将占用很多处理能力，并且在分布式系统中占用还会加大，因为首先需要将数据从存储缓冲区移到网络空间，然后再移到应用程序空间。优化这种烦琐活动以及其它许多在处理器通道、高速缓存优化和指令集中的活动，会使得用于事务的处理器消耗有明显改观。搜索只是一个较小的活动；要想获得成功，必须关注混合行处理、序列化、 扩展性和可用性等各方面。到了 80 年代中期， DB2 的价格与现在的数据库管理系统不相上下。
这些系统已扩展到处理更大范围的商务智能问题，这就要求访问非预期属性的数据并通过函数来分析这些过滤的数据。
设法提高查询速度
为了提高在关系型系统中的查询速度，我们的重点放在改进并行全表扫描、更智能化的索引技术，以及对压缩对象的压缩搜索。 在数据库中增加了很多功能来减少处理器周期，并利用物化视图进行预计算。但是，维护大量的索引和物化视图无论是在时间（处理）还是空间（存储）方面成本都很高。虽然这种方法在可预见的访问情况下是非常有效的，但无法满足真正随机访问的应用，在这种情况下全表扫描是唯一的解决方法。
在二十世纪 80 年代，数据库的行很小（实际上，模型是 80 列穿孔卡片，平均每条记录有 20 个字段），而且实体（表）的数量也很小（ 100 个算是很大了）。当时通常是双向和三向连接。而今天，每个表的属性数量都能达到数百个，更有甚者达到数千个。数据库中的表的数量已经上升到了数千个。六路和七路连接司空见惯；十路和十二路连接也屡见不鲜。只有跟踪了 SAP 模式的发展的人，才能见证到这种变化。因为涉及到的查询参数（属性）和关系的数量，查询已显得更为复杂。
列式体系结构强调属性和关系
要解决这些问题，设计 逆向数据库非常有必要，因为其重点强调属性列表和实体间的关系。 这正是列式数据库能够做到的。其余是决定成功与否的细节：压缩效率；连接链表；用时间戳标记的数据元素以 提供历史记录详细信息，还包括减轻 加载和更新操作的压力；添加所有关系型的功能等等。
一个简单的事实是，这种类型的数据库能根本满足当今商业智能的关键需求；即，查询包含大量属性和关系的集合，并在其上使用业务函数。
事务处理通过主键或其它键来检索行，并在这些行上执行适当的插入、更新和删除操作。可以通过索引或散列进行直接访问，其提供的快速访问只占用小部分处理能力，还具有足够的并发性。在大多数系统中，平均起来每个表有一到两个散列或索引。这减轻了在执行删除和插入操作时必须维护大量结构的压力 －会占用相当大的处理器周期的操作。
吸取 IBM 的经验教训
在 IBM 早期开发 DB2 的时候，我们的重点是最大限度地减少用于事务处理占用的处理器周期，并与我们的硬件同行一起合作优化了比较相关的几个部分。相对于前一代非关系型数据库管理系统（ IMS 、 IDMS 、 DATACOM 等等）而言， DB2 的成本增加了两到三倍以上，主要是由处理器消耗产生。很多人容易忽略的事实是，在 DB2 上开发和部署应用程序，比在现有的数据库管理系统上要明显快得多。
尽管关系型的指令只是想检索应用程序真正需要的一行中的某些属性，但应用程序倾向于检索整行（所有属性）。应用程序拥有标准的表格映射，它们是由应用程序代码中的数据字典生成的。编写 SELECT * 并添加谓词比在复杂应用中确定是否与其它部分共享检索行要简单得多。将行的属性从存储缓冲区移到应用程序的空间将占用很多处理能力，并且在分布式系统中占用还会加大，因为首先需要将数据从存储缓冲区移到网络空间，然后再移到应用程序空间。优化这种烦琐活动以及其它许多在处理器通道、高速缓存优化和指令集中的活动，会使得用于事务的处理器消耗有明显改观。搜索只是一个较小的活动；要想获得成功，必须关注混合行处理、序列化、 扩展性和可用性等各方面。到了 80 年代中期， DB2 的价格与现在的数据库管理系统不相上下。
这些系统已扩展到处理更大范围的商务智能问题，这就要求访问非预期属性的数据并通过函数来分析这些过滤的数据。
设法提高查询速度
为了提高在关系型系统中的查询速度，我们的重点放在改进并行全表扫描、更智能化的索引技术，以及对压缩对象的压缩搜索。 在数据库中增加了很多功能来减少处理器周期，并利用物化视图进行预计算。但是，维护大量的索引和物化视图无论是在时间（处理）还是空间（存储）方面成本都很高。虽然这种方法在可预见的访问情况下是非常有效的，但无法满足真正随机访问的应用，在这种情况下全表扫描是唯一的解决方法。
在二十世纪 80 年代，数据库的行很小（实际上，模型是 80 列穿孔卡片，平均每条记录有 20 个字段），而且实体（表）的数量也很小（ 100 个算是很大了）。当时通常是双向和三向连接。而今天，每个表的属性数量都能达到数百个，更有甚者达到数千个。数据库中的表的数量已经上升到了数千个。六路和七路连接司空见惯；十路和十二路连接也屡见不鲜。只有跟踪了 SAP 模式的发展的人，才能见证到这种变化。因为涉及到的查询参数（属性）和关系的数量，查询已显得更为复杂。
列式体系结构强调属性和关系
要解决这些问题，设计 逆向数据库非常有必要，因为其重点强调属性列表和实体间的关系。 这正是列式数据库能够做到的。其余是决定成功与否的细节：压缩效率；连接链表；用时间戳标记的数据元素以 提供历史记录详细信息，还包括减轻 加载和更新操作的压力；添加所有关系型的功能等等。
一个简单的事实是，这种类型的数据库能根本满足当今商业智能的关键需求；即，查询包含大量属性和关系的集合，并在其上使用业务函数。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
