【DDIA笔记】【ch2】 数据模型和查询语言 -- 关系模型与文档模型

简介: 【6月更文挑战第6天】关系模型是主流数据库模型,以二维表形式展示数据,支持关系算子。分为事务型、分析型和混合型。尽管有其他模型挑战,如网状和层次模型,但关系模型仍占主导。然而,随着大数据增长和NoSQL的出现(如MongoDB、Redis),强调伸缩性、专业化查询和表达力,关系模型的局限性显现。面向对象编程与SQL的不匹配导致“阻抗不匹配”问题,ORM框架缓解但未完全解决。文档模型(如JSON)提供更自然的嵌套结构,适合表示复杂关系,具备模式灵活性和更好的数据局部性。

关系模型与文档模型

关系模型

关系模型式当今最流行的数据库模型,统指这一类数据库,特点如下:

  1. 将数据以关系呈现给用户(比如:一组包含行列的二维表)

  2. 提供操作数据集合的关系算子

常见分类:

  1. 事务型(TP):银行交易、火车票

  2. 分析型(AP):数据报表、监控表盘

  3. 混合型(HTAP)

关系模型诞生很多年后,虽然不时有各种挑战者,比如上世纪七八十年代的网状模型和层次模型,但始终仍未有根本的能撼动其地位的新模型。直到近十年来,随着移动互联网的普及,数据爆炸性增长,各种处理需求越来越精细化,催生了数据模型的百花齐放。

NoSQL的诞生

NoSQL(Non-SQL,后来有人转解为Not only SQL),是对不同于传统的关系数据库的数据库管理系统的统称。根据DB-Engines Ranking - popularity ranking of database management systems ,现在最受欢迎的NoSQL前几名为:MongoDB、Redis、ElasticSearch、Cassandra。

催动因素有:

  1. 处理更大数据集:更强伸缩性、更高吞吐量

  2. 开源免费的兴起:冲击了原来把握在厂商的标准

  3. 特化的查询操作:关系数据库难以支持的,比如图中的多跳分析

  4. 表达能力更强:关系模型约束太严,限制太多

面向对象和关系模型的不匹配

目前大多数应用程序开发都使用面向对象的编程语言来开发,这导致了对 SQL 数据模型的普遍批评:如果数据存储在关系表中,那么需要一个笨拙的转换层,处于应用程序代码中的对象和表,行,列的数据库模型之间。模型之间的不连贯有时被称为 阻抗不匹配

ORM框架可以帮我们解决这个事情,但是仍然不太方便。

换另一个角度来说,关系模型很难直观的表示一对多的关系。比如简历上,一个人可能有多段教育经历和多段工作经历。

文档模型:使用JSON和XML的天然嵌套

关系模型:使用SQL模型就将职位、教育单独拿一张表,然后在用户表中使用外键关联。

在简历的例子里,文档模型还有几个优势:

  1. 模式灵活:可以动态增删字段,如工作经历

  2. 更好的局部性:一个人的所有属性被集中访问的同时,也被集中存储。

  3. 结构表达语义:简历与联系信息、教育经历、职业信息等隐含一对多的树状关系可以被JSON的树状结构明确表达出来。

目录
相关文章
|
7月前
|
存储 SQL 自然语言处理
ClickHouse查询执行与优化
本文详细介绍了SQL语法扩展、执行计划分析及优化策略,涵盖特殊函数与子句(如`WITH`、`ANY JOIN`)、聚合函数扩展(如`uniqCombined`、`quantileTDigest`)以及执行计划优化技巧。同时深入解析了ClickHouse的索引原理,包括主键索引和跳数索引的工作机制与优化方法。针对查询优化,文章提供了过滤条件下推、分布式查询优化和数据预聚合等策略,并探讨了资源管理与并发控制的核心参数(如`max_memory_usage`、`max_threads`)及队列优先级调度机制,助力高效使用ClickHouse。
|
存储 SQL 缓存
优化ClickHouse查询性能:最佳实践与调优技巧
【10月更文挑战第26天】在大数据分析领域,ClickHouse 以其卓越的查询性能和高效的列式存储机制受到了广泛的关注。作为一名已经有一定 ClickHouse 使用经验的开发者,我深知在实际应用中,合理的表设计、索引优化以及查询优化对于提升 ClickHouse 性能的重要性。本文将结合我的实践经验,分享一些有效的优化策略。
1372 3
|
负载均衡 数据管理
ClickHouse的分布式查询流程
ClickHouse的分布式查询流程
|
存储 关系型数据库 数据库
【DDIA笔记】【ch2】 数据模型和查询语言 -- 多对一和多对多
【6月更文挑战第7天】该文探讨数据模型,比较了“多对一”和“多对多”关系。通过使用ID而不是纯文本(如region_id代替"Greater Seattle Area"),可以实现统一、避免歧义、简化修改、支持本地化及优化搜索。在数据库设计中,需权衡冗余和范式。文档型数据库适合一对多但处理多对多复杂,若无Join,需应用程序处理。关系型数据库则通过外键和JOIN处理这些关系。文章还提及文档模型与70年代层次模型的相似性,层次模型以树形结构限制了多对多关系处理。为克服层次模型局限,发展出了关系模型和网状模型。
144 6
|
SQL 人工智能 关系型数据库
【DDIA笔记】【ch2】 数据模型和查询语言 -- 文档模型中Schema的灵活性
【6月更文挑战第8天】网状模型是层次模型的扩展,允许节点有多重父节点,但导航复杂,需要预知数据库结构。关系模型将数据组织为元组和关系,强调声明式查询,解耦查询语句与执行路径,简化了访问并通过查询优化器提高效率。文档型数据库适合树形结构数据,提供弱模式灵活性,但在Join支持和访问局部性上不如关系型。关系型数据库通过外键和Join处理多对多关系,适合高度关联数据。文档型数据库的模式灵活性体现在schema-on-read,写入时不校验,读取时解析,牺牲性能换取灵活性。适用于不同类型或结构变化的数据场景。
212 0
|
28天前
|
存储 监控 大数据
探究ClickHouse数据库的Mutation机制
ClickHouse的Mutation机制提供了一种高效的方式来处理大数据集上的修改操作。然而,需要注意的是,由于其异步和资源密集的特性,应当谨慎地进行规划和优化,以确保系统的整体性能。通过合理地使用Mutation操作,可以在保证数据一致性的同时,有效地管理和分析大规模数据集。
99 18
|
4月前
|
存储 监控 分布式数据库
ClickHouse分布式数据库动态伸缩(弹性扩缩容)的实现
实现ClickHouse数据库的动态伸缩需要持续的维护和精细的操作。从集群配置到数据迁移,再到监控和自动化,每一步都要仔细管理以确保服务的可靠性和性能。这些活动可以显著提高应用的响应性和成本效率,帮助业务根据实际需求灵活调整资源分配。
278 10
|
6月前
|
关系型数据库 MySQL 定位技术
MySQL与Clickhouse数据库:探讨日期和时间的加法运算。
这一次的冒险就到这儿,期待你的再次加入,我们一起在数据库的世界中找寻下一个宝藏。
261 9
|
存储 关系型数据库 MySQL
一个项目用5款数据库?MySQL、PostgreSQL、ClickHouse、MongoDB区别,适用场景
一个项目用5款数据库?MySQL、PostgreSQL、ClickHouse、MongoDB——特点、性能、扩展性、安全性、适用场景比较
|
11月前
|
SQL Unix OLAP
ClickHouse安装教程:开启你的列式数据库之旅
ClickHouse 是一个高性能的列式数据库管理系统,适用于在线分析处理(OLAP)。本文介绍了 ClickHouse 的基本使用步骤,包括下载二进制文件、安装应用、启动服务器和客户端、创建表、插入数据以及查询新表。还提到了图形客户端 DBeaver 的使用,使操作更加直观。通过这些步骤,用户可以快速上手并利用 ClickHouse 的强大性能进行数据分析。
1179 4

推荐镜像

更多