什么基础数据库建设是城市数据的底层支撑

什么基础数据库建设是城市数据的底层支撑,第1张

“智慧嘉禾”建设需要站在整个城市的高度,抽取公共的基础对象,“以基础对象为中心”进行相关数据的整合、组织和利用,才能真正科学合理的避免数据资源的分散重复,最大程度的发挥各部门和行业数据的整体优势。

你问的应该是数据库三级模式

引自百度百科,觉得里面解释的不错就转发来给你看看>

数据库领域公认的标准结构是三级模式结构,它包括外模式、概念模式、内模式,有效地组织、管理数据,提高了数据库的逻辑独立性和物理独立性。用户级对应外模式,概念级对应概念模式,物理级对应内模式,使不同级别的用户对数据库形成不同的视图

三种模式分别指:外模式:外模式又称子模式或用户模式,对应于用户级。它是某个或某几个用户所看到的数据库的数据视图,是与某一应用有关的数据的逻辑表示。外模式是从模式导出的一个子集,包含模式中允许特定用户使用的那部分数据。用户可以通过外模式描述语言来描述、定义对应于用户的数据记录(外模式),也可以利用数据 *** 纵语言(DataLanguage,DML)对这些数据记录进行 *** 作。外模式反映了数据库的用户观。

概念模式

模式又称概念模式或逻辑模式,对应于概念级。它是由数据库设计者综合所有用户的数据,按照统一的观点构造的全局逻辑结构,是对数据库中全部数据的逻辑结构和特征的总体描述,是所有用户的公共数据视图(全局视图)。它是由数据库管理系统提供的数据模式描述语言(DataDescriptionLanguage,DDL)来描述、定义的,体现、反映了数据库系统的整体观。

内模式

内模式又称存储模式,对应于物理级,它是数据库中全体数据的内部表示或底层描述,是数据库最低一级的逻辑描述,它描述了数据在存储介质上的存储方式和物理结构,对应着实际存储在外存储介质上的数据库。内模式由内模式描述语言来描述、定义,它是数据库的存储观。

在一个数据库系统中,只有唯一的数据库,因而作为定义、描述数据库存储结构的内模式和定义、描述数据库逻辑结构的模式,也是唯一的,但建立在数据库系统之上的应用则是非常广泛、多样的,所以对应的外模式不是唯一的,也不可能是唯一的。

关于数据库索引的数据结构,大多数数据库都是采用B树。可参照文章:

>

随着时间和业务的发展,数据库中的数据量增长是不可控的,库和表中的数据会越来越大,随之带来的是更高的 磁盘 IO 系统开销 ,甚至 性能 上的瓶颈,而单台服务器的 资源终究是有限 的。

因此在面对业务扩张过程中,应用程序对数据库系统的 健壮性 安全性 扩展性 提出了更高的要求。

以下,我从数据库架构、选型与落地来让大家入门。

数据库会面临什么样的挑战呢?

业务刚开始我们只用单机数据库就够了,但随着业务增长,数据规模和用户规模上升,这个时候数据库会面临IO瓶颈、存储瓶颈、可用性、安全性问题。

为了解决上述的各种问题,数据库衍生了出不同的架构来解决不同的场景需求。

将数据库的写 *** 作和读 *** 作分离,主库接收写请求,使用多个从库副本负责读请求,从库和主库同步更新数据保持数据一致性,从库可以水平扩展,用于面对读请求的增加。

这个模式也就是常说的读写分离,针对的是小规模数据,而且存在大量读 *** 作的场景。

因为主从的数据是相同的,一旦主库宕机的时候,从库可以 切换为主库提供写入 ,所以这个架构也可以提高数据库系统的 安全性 可用性

优点:

缺点:

在数据库遇到 IO瓶颈 过程中,如果IO集中在某一块的业务中,这个时候可以考虑的就是垂直分库,将热点业务拆分出去,避免由 热点业务 密集IO请求 影响了其他正常业务,所以垂直分库也叫 业务分库

优点:

缺点:

在数据库遇到存储瓶颈的时候,由于数据量过大造成索引性能下降。

这个时候可以考虑将数据做水平拆分,针对数据量巨大的单张表,按照某种规则,切分到多张表里面去。

但是这些表还是在同一个库中,所以库级别的数据库 *** 作还是有IO瓶颈(单个服务器的IO有上限)。

所以水平分表主要还是针对 数据量较大 ,整体业务 请求量较低 的场景。

优点:

缺点:

四、分库分表

在数据库遇到存储瓶颈和IO瓶颈的时候,数据量过大造成索引性能下降,加上同一时间需要处理大规模的业务请求,这个时候单库的IO上限会限制处理效率。

所以需要将单张表的数据切分到多个服务器上去,每个服务器具有相应的库与表,只是表中数据集合不同。

分库分表能够有效地缓解单机和单库的 性能瓶颈和压力 ,突破IO、连接数、硬件资源等的瓶颈。

优点:

缺点:

注:分库还是分表核心关键是有没有IO瓶颈

分片方式都有什么呢?

RANGE(范围分片)

将业务表中的某个 关键字段排序 后,按照顺序从0到10000一个表,10001到20000一个表。最常见的就是 按照时间切分 (月表、年表)。

比如将6个月前,甚至一年前的数据切出去放到另外的一张表,因为随着时间流逝,这些表的数据被查询的概率变小,银行的交易记录多数是采用这种方式。

优点:

缺点:

HASH(哈希分片)

将订单作为主表,然后将其相关的业务表作为附表,取用户id然后 hash取模 ,分配到不同的数据表或者数据库上。

优点:

缺点:

讲到这里,我们已经知道数据库有哪些架构,解决的是哪些问题,因此, 我们在日常设计中需要根据数据的特点,数据的倾向性,数据的安全性等来选择不同的架构

那么,我们应该如何选择数据库架构呢?

虽然把上面的架构全部组合在一起可以形成一个强大的高可用,高负载的数据库系统,但是架构选择合适才是最重要的。

混合架构虽然能够解决所有的场景的问题,但是也会面临更多的挑战,你以为的完美架构,背后其实有着更多的坑。

1、对事务支持

分库分表后(无论是垂直还是水平拆分),就成了分布式事务了,如果依赖数据库本身的分布式事务管理功能去执行事务,将付出高昂的性能代价(XA事务);如果由应用程序去协助控制,形成程序逻辑上的事务,又会造成编程方面的负担(TCC、SAGA)。

2、多库结果集合并 (group by,order by)

由于数据分布于不同的数据库中,无法直接对其做分页、分组、排序等 *** 作,一般应对这种多库结果集合并的查询业务都需要采用数据清洗、同步等其他手段处理(TIDB、KUDU等)。

3、数据延迟

主从架构下的多副本机制和水平分库后的聚合库都会存在主数据和副本数据之间的延迟问题。

4、跨库join

分库分表后表之间的关联 *** 作将受到限制,我们无法join位于不同分库的表(垂直),也无法join分表粒度不同的表(水平), 结果原本一次查询就能够完成的业务,可能需要多次查询才能完成。

5、分片扩容

水平分片之后,一旦需要做扩容时。需要将对应的数据做一次迁移,成本代价都极高的。

6、ID生成

分库分表后由于数据库独立,原有的基于数据库自增ID将无法再使用,这个时候需要采用其他外部的ID生成方案。

一、应用层依赖类(JDBC)

这类分库分表中间件的特点就是和应用强耦合,需要应用显示依赖相应的jar包(以Java为例),比如知名的TDDL、当当开源的 sharding-jdbc 、蘑菇街的TSharding等。

此类中间件的基本思路就是重新实现JDBC的API,通过重新实现 DataSource PrepareStatement 等 *** 作数据库的接口,让应用层在 基本 不改变业务代码的情况下透明地实现分库分表的能力。

中间件给上层应用提供熟悉的JDBC API,内部通过 sql解析 sql重写 sql路由 等一系列的准备工作获取真正可执行的sql,然后底层再按照传统的方法(比如数据库连接池)获取物理连接来执行sql,最后把数据 结果合并 处理成ResultSet返回给应用层。

优点

缺点

二、中间层代理类(Proxy)

这类分库分表中间件的核心原理是在应用和数据库的连接之间搭起一个 代理层 ,上层应用以 标准的MySQL协议 来连接代理层,然后代理层负责 转发请求 到底层的MySQL物理实例,这种方式对应用只有一个要求,就是只要用MySQL协议来通信即可。

所以用MySQL Navicat这种纯的客户端都可以直接连接你的分布式数据库,自然也天然 支持所有的编程语言

在技术实现上除了和应用层依赖类中间件基本相似外,代理类的分库分表产品必须实现标准的MySQL协议,某种意义上讲数据库代理层转发的就是MySQL协议请求,就像Nginx转发的是>

所谓三层体系结构,是在客户端与数据库之间加入了一个中间层。三层体系不是指物理上的三层,不是简单地放置三台机器就是三层体系,三层是指逻辑上的三层,即使这三个层放置到一台机器上。三层体系结构的应用程序将业务规则、数据访问、合法性校验等工作放到了中间层进行处理。通常情况下,客户端不直接与数据库进行交互,而是通过与中间层通讯建立连接,再经由中间层与数据库进行交互。

在基于B/S的三层体系结构中,表示层、中间层、数据层被分割成三个相对独立的单元。

表示层(Browser)位于客户端,一般没有应用程序,借助于Javaapplet、Actives、Javascript、vbscript等技术可以处理一些简单的客户端处理逻辑。它负责由Web浏览器向网络上的Web服务器(即中间层)发出服务请求,把接受传来的运行结果显示在Web浏览器上。

中间层(WebServer)是用户服务和数据服务的逻辑桥梁。它负责接受远程或本地的用户请求,对用户身份和数据库存取权限进行验证,运用服务器脚本,借助于中间件把请求发送到数据库服务器(即数据层),把数据库服务器返回的数据经过逻辑处理并转换成HTML及各种脚本传回客户端。

数据层(DBServer)位于最底层,它负责管理数据库,接受Web服务器对数据库 *** 纵的请求,实现对数据库查询、修改、更新等功能及相关服务,并把结果数据提交给Web服务器。

在三层结构中,数据计算与业务处理集中在中间层,只有中间层实现正式的进程和逻辑规则。

以上就是关于什么基础数据库建设是城市数据的底层支撑全部的内容,包括:什么基础数据库建设是城市数据的底层支撑、数据库的基本结构、数据库包含的三级模式分别是什么等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!

欢迎分享,转载请注明来源:内存溢出

原文地址:https://54852.com/sjk/10101663.html

(0)
打赏 微信扫一扫微信扫一扫 支付宝扫一扫支付宝扫一扫
上一篇 2023-05-05
下一篇2023-05-05

发表评论

登录后才能评论

评论列表(0条)

    保存