Category: Database

0

关系型数据库进阶之总体架构

一提到关系型数据库,我们可以看到它被在各个地方使用。有很多不同的关系型数据库,从最小的SQLite到复杂的Teradata。有很多文章在介绍如何使用数据库,但是很少有问题去深入地介绍它是如何工作的。假如你搜索“关系型数据库是如何工作的”这样的关键词,你会发现很少有问题进行深入详细的介绍。有时候,我们不禁会问,关系型数据库是不是太旧了,以至于都没有什么人来深入分析其中的内容? 作为一个开发者,我们需要有一点好奇心去深入看看我们每天使用的数据库内部是怎么样,假如你一直没有时间或者机会去深入了解其中的原理,那么本文将会是你的一个很好的选择。本文之所以称之为“进阶”是因为我们不会介绍如何去使用一些Query,而是假设你已经有了这些基础的知识,我们更注重其中的机理讲解。 一个数据库其实是信息的集合,而这个集合是可以很方便地访问和修改的。假如往简单的方面来想,那么它就是一系列的文件。事实上,最简单的数据库,比如SQLite其实就是一堆文件。当然SQLite又不是简简单单的一堆文件,因为它允许你: 使用transaction来保证数据的安全和连贯 能够很快的处理数据,哪怕是很大的百万量级的数据 总得来说,一个数据库可以由下图几个部分组成: 从这张图可以看出,总得核心有一下几个部分: 核心的组件: 进程管理: 很多数据库都有一个进程/线程池需要管理。更有甚者,为了做到纳秒级的效率,很多数据库都使用他们自己的线程而不是系统的线程。 网络管理:网络的I/O其实对数据库来说很重要,尤其是在分布式数据库中更为明显。这也是为什么很多数据库都有他们自己的管理者。 文件系统管理:数据库的第一个瓶颈就在于磁盘的I/O。需要一个文件系统管理来处理相关的内容,甚至取代系统的文件系统。 内存管理:为了避免磁盘I/O的损失,就需要大量的RAM。随之而来的就是,当你处理大量的内存的时候,你就需要一个高效的内存管理。尤其是你同时有很多query在使用内存的时候。 安全管理:主要管理用户的认证。 客户端管理:管理客户端的连接 工具: 备份管理:保存和还原数据库。 恢复管理:在数据库奔溃后能够以一致的状态启动数据库。 监测管理:记录数据的运行log,并且提供相应的检测工具。 Admin管理:用于存储元数据比如表的名字,结构,以及管理数据库,schema,表格空间等等。 Query管理: Query的解析:检查一个query是否有效 Query的重写:预先优化一个query Query的优化:优化一个query Query的执行:编译和执行query 数据的管理: Transaction管理:处理transcation cache的管理:在使用数据在前把数据放到内存,以及在写到磁盘之前把数据放到内存中 数据访问的管理:如何从磁盘访问数据 本文就从宏观介绍了数据库的组成部分,我们将在后面的文章中来分别主要介绍以下的内容: 客户端管理 查询管理 数据管理 参考文章:http://coding-geek.com/how-databases-work/

0

如何在SQL中得到两个表的不同行

有时候,我们需要比较两个表的差异,希望能够返回两个表不同的行,那怎么才能有效快速地得到这个结果,本文就来做一个简单的介绍: 表格准备 我们来假设有下面两个表(PostgreSQL 语法): 使用UNION 我们的第一反应大概就是看看能不能使用UNION,我们先得到表1-表2的内容,然后再得到表2-表1的内容,再把两者union起来,如下面的语法所示: 这样之后,就会得到下面这样的结果: a |b |c |–|–|–| 1| 2| 3|10|11|12| 但是这样有一个问题,就是每一个表格我们都访问两次。有没有更好的方法呢? 使用NATURAL FULL JOIN 我们可以使用下面的语句来实现: 这时候的返回值是这样的: 为什么呢,因为NATURAL FULL JOIN其实是使用相同的列值就行join的,这里我们两个表各产生了一个新的列t1和t2,在相同值的行,t1和t2列的值就会都存在,而在不同值的行,则只会有一列存在,可能是t1列或者有可能是t2列。我们只要把这种情况过滤出来就可以了。 这里需要注意的是,当值是NULL的时候,判断的时候会遵循下面这个表格: 这里我们可以看到R IS NULL和NOT R IS NOT NULL其实是不同的,所以我们上面提到的natural full join其实等同于下面这样: 另外一种写法是我们使用JOIN …...

0

MongoDB和Couchbase analytics(解析)的对比分析

计算的目的是背后的洞察而不是数据本身 — Richard Hamming 所谓的商业运行就是一个分析哪些需要改变,该改变成什么然后据此改变商业本身的螺旋上升的过程。作正确的分析,你就如滚雪球般不停上升,反之,则不断的螺旋下降。 Couchbase, 是一个诞生在web 2.0世界中的一个新NoSQL系统,能够满足高扩展性,高性能以及高可靠性的要求。从最简单的键值对到复杂的大规模查询,搜索以及解析,Couchbase都可以很好的处理。而这些都是通过在Couchbase的多维架构中集成特定的引擎来实现的。其中查询和解析服务都是通过N1QL来进行交互的,为什么要用同样的语言来建造两个完全不同的引擎?这是因为: “一刀切”的时代已经一去不复返了 — Michael Stonebraker 查询引擎是为了正常的操作工作来设计的,而解析引擎则是为分析操作来设计的。我们在之前的文章中曾对这两者进行过比较并给出了对应的建议。MongoDB也是通过同样的路径来处理类似的查询和解析操作的。 去年,MongoDB也官宣了它们为分析流程而实现的解析节点,本文将对两种解析引擎的使用场景进行比较和分析。 Couchbase的高层架构 Couchbase内建解析器:高层架构 MongoDB解析节点: 下面我们来比较一下MongoDB解析节点和Couchbase解析所支持的特性:   MongoDB解析节点 Couchbase解析 文档 https://docs.atlas.mongodb.com/reference/replica-set-tags/ https://docs.couchbase.com/server/6.5/analytics/introduction.html 架构 使用一个次要的备份节点拷贝所有的操作数据,查询的语言是一样的(MQL),查询的过程和真实的操作过程是一致的 解析的节点是独立的,它拥有的数据是支持用户自定义的一个真实数据的子集。查询的语言也是一样的(N1QL)。查询的过程是专为更大的数据而设计的(具体见下面) 架构细节 Atlas Mapped Analytics Nodes Couchbase Analytics:...