程序原本(一百零五):系统的基本组织方法与原理——领域间的组织(关系型数据库的原罪:序列关系 + 键关系)

阅读数:20 2019 年 10 月 5 日 13:50

程序原本(一百零五):系统的基本组织方法与原理——领域间的组织(关系型数据库的原罪:序列关系 + 键关系)

一般性的数据处理的思路,是通过多次的数据筛选将待处理数据层层精化;在得到所需的处理数据之后,将这些处理数据从数据层迁移到应用层;最后,由应用层来处理之。关系型数据的基本原则,是根据“应用需要”来构建库中数据项次之间的关系,并规格化存储(包括索引与键等)。这一原则其实是有利于实现上述的“一般性思路”。例如我们通常通过在数据库中执行 SQL 语句来得到一个数据子集,然后通过应用程序中的数据库客户端得到它,并转换为应用程序识别的数据对象再加以处理。

不过,这个思路有一个致命的问题:如果“应用逻辑所需要的处理数据”本身就是一个极大的数据量呢?例如搜索,无论用户输入怎样简略的一个关键字,他的原始意图都得是在整个数据全集中检索之。事实上,搜索的特殊性就在于任何一个应用逻辑都是面向数据全集的。关系型数据库对这一问题的解释是,检索行为应当交给数据库端来实现,进而相类似的、基于数据全集的应用逻辑也都应当交给数据库端来实现。

于是我们看到了基于关系型数据的数据处理得以进化的动力:由于数据从数据层迁移到应用层的成本过高(这包括数据本身的传输成本,以及在应用层实现相关处理逻辑的成本),因此将相关处理作为独立技术在数据层实现是必然之选。在这一层次上的需求已经不是传统的基于数据库管理(DBMS)技术所能应付的,例如联机事务处理(OLTP)试图在一个事务中完成对数据的切片、加锁与运算过程,而这往往导致整个应用层需要花大量时间来“等待”数据层的运算结果。

反思这个运算瓶颈的核心,关键在于关系型数据库对数据规划的理解,它本质上是强调数据项(Rows)间存在序列关系,以及数据列(Cols)间存在的键关系。这两类关系使得大数据处理时,无论基于列的纵向拆分或是基于行的横向拆分都面临“如何处理关系”的问题。例如将一个类似于日志数据的大表(Rows 项次过大)作横向拆分,我们必须在处理层——无论是数据库的事务或是应用层的逻辑代码——中解决对“基于年、月、日或季度、周等时间区段”的数据的归并以及跨区段处理的问题。又例如将一个类似于订单数据的宽表(Cols 项次过大)作纵向拆分,我们就必须通过多表的 Join 来得到最终所需的运算数据,这又涉及 Keys 的维护,从而加大了应用端或数据库端的逻辑复杂程度。在这个问题上,联机分析处理(OLAP)在本质上也只是通过多次的、渐增的数据规划来强化数据关系,通过需求规划来增加中间数据,从而减少单次处理的时间。

那么是否需要将这两类关系“解锁”?去除掉这两类关系的数据,又是何种数据呢?

评论

发布