本文主要是介绍高密集型数据服务--第2章 数据模型与查询语言,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
一、引言
数据模型可能是开发软件最重要的部分,而且还对如何思考待解决的问题都有深远的影响。
大多数应用程序是通过一层一层叠加数据模型来构建的。每一层都面临的关键问题是:如何将其用下一层来表示?
1.作为一名应用程序开发人员,观测现实世界(其中包括人员、组织、货物、行为、资金流动、传感器等),通过对象或数据结构,以及操作这些数据结构的API来对其建模。这些数据结构往往特定于该应用。
2.当需要存储这些数据结构时,可以采用通用数据模型(例如JSON或XML文档、关系数据库中的表或图模型)来表示。
3.数据库工程师接着决定用何种内存、磁盘或网络的字节格式来表示上述JSON/XML/关系/图形数据。数据表示需要支持多种方式的查询、搜索、操作和处理数据。
4.在更下一层,硬件工程师则需要考虑用电流、光脉冲、磁场等来表示字节。
复杂的应用程序可能会有更多的中间层,例如基于API来构建上层 API ,但是基本思想相同:每层都通过提供一个简洁的数据模型来隐藏下层的复杂性。这些抽象机制使得不同的人群可以高效协作
精通一种数据模型都需要很大功夫(试想有多少关于关系数据建模的书籍)。即使只使用一种数据模型且不用担心内部机制,构建软件也很有挑战.本章将介绍一系列用于数据存储和查询的通用数据模型.将比较关系模型、文档模型和一些基于图的数据模型
现在最著名的数据模型可能是SQL ,它基于Edgar Codd于 1970年提出的关系模型[ I]:数据被组织成关系( relations ),在SQL中称为表( table ),其中每个关系者J)是元组(tuples )的无序集合(在SQL 中称为行)。
关系数据库的核心在于商业数据处理, 20世纪60年代和70年代主要运行在大型计算机之上。从今天的角度来看,用例看起来很常见,主要是事务处理(包括输入销售和银行交易、航空公司订票、仓库库存)和批处理(例如客户发票、工资单、报告)。
二、关系模型与文档模型
如何在关系模式中表示简历,整个简历可以通过唯一的标识符 userid来标识。像first name和 lastname这样的字段在每个用户中只出现一次,所以可以将其建模为U sers表中的列。然而,大多数人在他们的职业(职位)中有一个以上的工作,并且可能有多个教育阶段和任意数量的联系信息。用户与这些项目之间存在一对多的关系,可以用多种方式来表示.
在传统的SQL模型( SQL : 1999之前)中, 最常见的规范化表示是将职位、教育和联系信息放在单独的表中 , 并二使用外键引用 users表.
之后的SQL标准增加了对结构化数据类型和XML数据的支持。这允许将多值数据存储在单行 内 ,井支持在这些文档中查询和索引。
第三个选项是将工作、教育和联系信息编码为JSON或XML文档,将其存储在数据库的文本列中,并由应用程序解释其结构和内容。对于此方峙,通常不能使用数据库查询该编码列中的值。
对于像简历这样的数据结构,它主要是一个自包含的文档( document ),因此用JSON表示非常合适, 参见示 17tl2- l 。与 XML相比, JSON的吸引力在于它更简单。 面向文档的数据库(女口MongoDB [9J 、 RethinkDB [ I OJ 、 CouchDB [IIJ和Espresso l121 )都支持该数据模型.JSON作为数据编码格式也存在问题。缺乏模式常常被认为是一个优势.
如果要在关系模式中读取一份简历,那么要么执行多个查询(通过user id查询每个表),要么在users表及其从属表之间执行混乱的多路联结。而对于ISON表示方毡,所有的相关信息都在一个地方,一次查询就够了。
如果用户界面是可以输入地区或行业的自由文本字段,则将其存储为纯文本字符串更有意义。但是,拥有地理区域和行业的标准化列表,并让用户从下拉列表或自动填充器中进行选择会更有优势.
无论是存储ID还是文本字符串,都涉及内容重复的问题。当使用 ID时,对人类有意义的信息(例如慈善这个词)只存储在一个地方,引用它的所有内容都使用ID (ID只在数据库中有意义)。当直接存储文本时,则使用它的每条记录中都保存了一份这样可读信息。
使用ID的好处是,因为它对人类没有任何直接意义,所以永远不需要直接改变:即使ID标识的信息发生了变化,它也可以保持不变。任何对人类有意义的东西都可能在将来某个时刻发生变更。如果这些信息被复制,那么所有的冗余副本也都需要更新。这会导致更多写入开销,并且存在数据不-致的风险.
数据规范化需要表达多对一的关系(许多人生活在同一地区,许多人在同一行业工作),这并不是很适合文档模型。对于关系数据库,由于支持联结操作,可以很方便地通过ID来引用其他表中的行。
如果数据库本身不支持联结,贝lj必须在应用程序代码中,通过对数据库进行多次查询来模拟联结(对于上述例子,地区和行业的列表很小且一段时间内不太可能发生变化,应用程序可以简单地将它们缓存在内存中。但无论如何,联结的工作其实从数据库转移到了应用层).
即使应用程序的初始版本非常适合采用无联结的文档模型,但随着应用支持越来越多的功能,数据也变得更加互联一体化。例如,考虑以下我们可能对简历进行的修改或扩充:
组织和学校作为实体,公司名称不是-个字符事,而星一个指向公司实体的链撞;
相比之下,关系模型所做的则是定义了所有数据的格式:关系(表)只是元组(行)的集合,仅此而已。。
数据查询语言
命令式编程语言、关系代数(其中 σ (希腊字母 σ )是选择操作构,只返回符合条件的那些动物)、sql
对于声明式查询语言(如SQL或关系代数),只需指定所需的数据模式,结果需满足什么条件,以及如何转换数据(例如,排序、分组和聚合),而不需指明如何实现这一目标。数据库系统的查询优化器会决定采用哪些索引和联结,以及用何种顺序来执行查询的各个语句。
声明式查询语言很有吸引力,它比命令式API更加简洁和容易使用。但更重要的是,它对外隐藏了数据库引擎的很多实现细节,这样数据库系统能够在不改变查询语句的情况下提高性能。
声明式语言通常适合于并行执行。现在CPU主要通过增加核,而不是通过比之前更高的时钟频率(31 ]来提升速度。而命令式代码由于指定了特定的执行顺序,很难在多核和多台机器上并行化。声明式语言则对于并行执行更为友好,它们仅指定了结果所满足的模式,而不指定如何得到结果的具体算住。所以如果可以的话,数据库都倾向于采用井行方式实现查询语言。
介绍js操作样式部分--忽略
MapReduce查询(第10章批处理系统--详细介绍)
MapR 巳 duce既不是声明式查询语言,也不是一个完全命令式的查询A凹,而是介于两者之间:查询的逻辑用代码片段来表示,这些代码片段可以被处理框架重复地调用。它主要基于许多函数式编程语言中的map(也称为collect )和reduce(也称为fold或inject)函数
图状数据模型--不深入
这篇关于高密集型数据服务--第2章 数据模型与查询语言的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!