数据库架构选型与落地，看这篇就够了

随着时间和业务的发展，数据库中的数据量增长是不可控的，库和表中的数据会越来越大，随之带来的是更高的 磁盘 、 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转发的是>

所谓“数据库”是以一定方式储存在一起、能与多个用户共享、具有尽可能小的冗余度、与应用程序彼此独立的数据集合。

在计算机编程之中，数据库的定义和生活中有一定的区别。同样是数据的集合这没有变，但是多了一些条件限定，每一种类型数据集合里面的数据都有固定的内容结构。

扩展资料

计算机数据库的应用如下：

1、将面向对象方法及其技术同数据库技术逐步进行融入的主要目的是为了满足相关用户应用过程中的特定需求，确保用户在数据传输以及应用过程中的安全性。

2、在多媒体技术中融入计算机数据库技术，对于此类数据库技术的应用而言，不仅具有多媒体技术的特点，还综合了计算机数据库技术的优势。

参考资料来源：百度百科-数据库

目前，针对应用及其后台数据库的应用级入侵已经变得越来越猖獗，如SQL注入、跨站点脚本攻击和未经授权的用户访问等。所有这些入侵都有可能绕过前台安全系统并对数据来源发起攻击。

为了对付这类威胁，新一级别的安全脱颖而出，这就是应用安全。这种安全技术将传统的网络和 *** 作系统级入侵探测系统(IDS)概念应用于数据库(即应用)。与通常的网络或 *** 作系统解决方案不同的是，应用IDS提供主动的、针对SQL的保护和监视，可以保护数以千计的预先包装或自行开发的Web应用。例如，应用IDS可以监视和防护关键的数据，使那些针对数据库的攻击，如缓冲区溢出和Web应用攻击等无法对数据库造成真正的损害，而且应用IDS还可以对这些事件进行审查。

应用安全与网络和主机安全之间存在很大的区别。应用是千差万别的，但攻击的目标总是相同的，也就是入侵数据库。由于应用使用SQL与数据库进行通信，因此好的应用IDS应当能够解析SQL，并且提供一种能够理解流量的内容，且又能与应用划清界线的客观保护层。

多数应用IDS都有三个组件。第一个是基于网络或主机的传感器。网络传感器连接到交换机上的一个端口上，该端口的配置决定它可以查看到数据库内的所有流量。相比之下，主机传感器直接驻留在应用上。传感器可以收集SQL交易并对其进行解析，然后决定是否应当针对该流量发出警报。如果有必要发出警告，警告会被传递给下一个组件，即控制台服务器。这台服务器存储事件信息，并且是策略配置和升级等传感器维护活动的中心点。应用IDS中的第三个组件是Web浏览器，管理员可以利用它来修改IDS设置、实时监视事件并生成报告。

以SQL注入攻击为例，攻击者会试图绕过Web服务器定义的SQL语句，目的就是要注入自己的语句。假设要输入的用户名为Bob，口令为Hardtoguess。

当看到这些输入的内容后，数据库就会找到WebUsers 行中与之匹配的内容，然后该应用会对用户进行验证。为了入侵数据库，SQL注入攻击会欺骗应用，并使之相信自己已经提交了正确的证书。例如，攻击使用的口令是‘blah’或‘A’=‘A’，因此攻击时创建的SQL语句可能会是:SELECT FROM WebUsers WHERE Username=‘Bob’ AND Password=‘blah’ OR‘A’=‘A’。　

从逻辑上来分析‘A’=‘A’永远都是TRUE，而WHERE子句也可以匹配所有的行，就这样，攻击者在根本没有正确用户名或口令的情况下也能蒙混过关，得到验证。应用服务器会接受输入的信息并且允许攻击者通过。接下来，应用服务器会通过SQL命令从数据库中请求数据。　

如果有了应用IDS，传感器会收集SQL命令并对其进行解密，然后查看这些命令到底要访问数据库中的哪些表和列。利用这种方法，传感器就可以判断出到底是正常情况还是一次攻击行为。如果发现的行为是IDS策略不允许的，传感器会判断攻击的威胁水平并采取适当的措施，通常是向管理员的控制台和/或通过电子邮件发出警告。

这只是应用层攻击的一个简单例子，而且今天的许多公司都在面临这样的威胁。通过实施应用级IDS，企业就可以有效地保护易受攻击的数据，并且将最新的攻击和威胁拒之门外。

1B 2C 3B 4C 5D 6C 7C 8D 9C 10A

11A 12A 13A --不太确定 14B 15C 16A 17B 18A 19D 20C

1试述事务的概念及事务的四个特性。

答：

事务是用户定义的一个数据库 *** 作序列，这些 *** 作要么全做要么全不做,是一个不可分割的工作单位。

事务具有四个特性：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持续性（Durability）。这个四个特性也简称为ACID特性。

原子性：事务是数据库的逻辑工作单位，事务中包括的诸 *** 作要么都做，要么都不做。

一致性：事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。

隔离性：一个事务的执行不能被其他事务干扰。即一个事务内部的 *** 作及使用的数据对其他并发事务是隔离的，并发执行的各个事务之间不能互相干扰。

持续性：持续性也称永久性（Permanence），指一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。接下来的其他 *** 作或故障不应该对其执行结果有任何影响。

2为什么事务非正常结束时会影响数据库数据的正确性，请列举一例说明之。

答：

事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。如果数据库系统运行中发生故障，有些事务尚未完成就被迫中断，这些未完成事务对数据库所做的修改有一部分已写入物理数据库，这时数据库就处于一种不正确的状态，或者说是不一致的状态。

例如某工厂的库存管理系统中，要把数量为Q的某种零件从仓库1移到仓库2存放。

则可以定义一个事务T，T包括两个 *** 作；Q1=Q1-Q，Q2=Q2+Q。如果T非正常终止时只做了第一个 *** 作，则数据库就处于不一致性状态，库存量无缘无故少了Q。

3数据库中为什么要有恢复子系统？它的功能是什么？

答：

因为计算机系统中硬件的故障、软件的错误、 *** 作员的失误以及恶意的破坏是不可避免的，这些故障轻则造成运行事务非正常中断，影响数据库中数据的正确性，重则破坏数据库，使数据库中全部或部分数据丢失，因此必须要有恢复子系统。

恢复子系统的功能是：把数据库从错误状态恢复到某一已知的正确状态（亦称为一致状态或完整状态）。

4．数据库运行中可能产生的故障有哪几类？哪些故障影响事务的正常执行？哪些故障破坏数据库数据？

答：数据库系统中可能发生各种各样的故障，大致可以分以下几类：

（1）事务内部的故障；

（2）系统故障；

（3）介质故障；

（4）计算机病毒。

事务故障、系统故障和介质故障影响事务的正常执行；介质故障和计算机病毒破坏数据

库数据。

5．据库恢复的基本技术有哪些？

答：

数据转储和登录日志文件是数据库恢复的基本技术。

当系统运行过程中发生故障，利用转储的数据库后备副本和日志文件就可以将数据库恢复到故障前的某个一致性状态。

6 数据库转储的意义是什么？ 试比较各种数据转储方法。

答：

数据转储是数据库恢复中采用的基本技术。所谓转储即DBA定期地将数据库复制到磁带或另一个磁盘上保存起来的过程。当数据库遭到破坏后可以将后备副本重新装入，将数据库恢复到转储时的状态。

静态转储：在系统中无运行事务时进行的转储 *** 作。静态转储简单，但必须等待正运行的用户事务结束才能进行。同样，新的事务必须等待转储结束才能执行。显然，这会降低数据库的可用性。

动态转储：指转储期间允许对数据库进行存取或修改。动态转储可克服静态转储的缺点，它不用等待正在运行的用户事务结束，也不会影响新事务的运行。但是，转储结束时后援副本上的数据并不能保证正确有效。因为转储期间运行的事务可能修改了某些数据，使得后援副本上的数据不是数据库的一致版本。

为此，必须把转储期间各事务对数据库的修改活动登记下来，建立日志文件（log file）。这样，后援副本加上日志文件就能得到数据库某一时刻的正确状态。

转储还可以分为海量转储和增量转储两种方式。

海量转储是指每次转储全部数据库。增量转储则指每次只转储上一次转储后更新过的数据。从恢复角度看，使用海量转储得到的后备副本进行恢复一般说来更简单些。但如果数据库很大，事务处理又十分频繁，则增量转储方式更实用更有效。

7 什么是日志文件？为什么要设立日志文件？

答：

（1）日志文件是用来记录事务对数据库的更新 *** 作的文件。

（2）设立日志文件的目的是： 进行事务故障恢复；进行系统故障恢复；协助后备副本进行介质故障恢复。

8 登记日志文件时为什么必须先写日志文件，后写数据库？

答：

把对数据的修改写到数据库中和把表示这个修改的日志记录写到日志文件中是两个不同的 *** 作。有可能在这两个 *** 作之间发生故障，即这两个写 *** 作只完成了一个。

如果先写了数据库修改，而在运行记录中没有登记这个修改，则以后就无法恢复这个修改了。如果先写日志，但没有修改数据库，在恢复时只不过是多执行一次UNDO *** 作，并不会影响数据库的正确性。所以一定要先写日志文件，即首先把日志记录写到日志文件中，然后写数据库的修改。

9 针对不同的故障，试给出恢复的策略和方法。（即如何进行事务故障的恢复？系统故障的恢复？介质故障恢复？）

答：

事务故障的恢复：

事务故障的恢复是由DBMS自动完成的，对用户是透明的。

DBMS执行恢复步骤是：

（1）反向扫描文件日志（即从最后向前扫描日志文件），查找该事务的更新 *** 作。

（2）对该事务的更新 *** 作执行逆 *** 作。即将日志记录中“更新前的值”写入数据库。

（3）继续反向扫描日志文件，做同样处理。

（4）如此处理下去，直至读到此事务的开始标记，该事务故障的恢复就完成了。

答：

系统故障的恢复：

系统故障可能会造成数据库处于不一致状态：

一是未完成事务对数据库的更新可能已写入数据库；

二是已提交事务对数据库的更新可能还留在缓冲区，没来得及写入数据库。

因此恢复 *** 作就是要撤销(UNDO)故障发生时未完成的事务，重做(REDO)已完成的事务。

系统的恢复步骤是：

（1）正向扫描日志文件，找出在故障发生前已经提交的事务队列（REDO队列）和未完成的事务队列（UNDO队列）。

（2）对撤销队列中的各个事务进行UNDO处理。

进行UNDO处理的方法是，反向扫描日志文件，对每个UNDO事务的更新 *** 作执行逆 *** 作，即将日志记录中“更新前的值”（Before Image）写入数据库。

（3）对重做队列中的各个事务进行REDO处理。

进行REDO处理的方法是：正向扫描日志文件，对每个REDO事务重新执行日志文件登记的 *** 作。即将日志记录中“更新后的值”（After Image）写入数据库。

解析：

在第（1）步中如何找出REDO队列和UNDO队列？请大家思考一下。

下面给出一个算法：

1） 建立两个事务队列:

· UNDO-LIST: 需要执行undo *** 作的事务集合；

· REDO-LIST: 需要执行redo *** 作的事务集合；

两个事务队列初始均为空。

2） 从日志文件头开始，正向扫描日志文件

· 如有新开始（遇到Begin Transaction）的事务Ti，把Ti暂时放入UNDO-LIST队列；

· 如有提交的事务（遇到End Transaction）Tj，把Tj从UNDO-LIST队列移到REDO-LIST队列；

直到日志文件结束

答：

介质故障的恢复：

介质故障是最严重的一种故障。

恢复方法是重装数据库，然后重做已完成的事务。具体过程是：

（1）DBA装入最新的数据库后备副本（离故障发生时刻最近的转储副本），使数据库恢复到转储时的一致性状态。

（2）DBA装入转储结束时刻的日志文件副本

（3）DBA启动系统恢复命令，由DBMS完成恢复功能，即重做已完成的事务。

解析

1）我们假定采用的是静态转储，因此第（1）步装入数据库后备副本便可以了。

2）如果采用的是静动态转储，第（1）步装入数据库后备副本还不够，还需同时装入转储开始时刻的日志文件副本，经过处理后才能得到正确的数据库后备副本。

3）第（2）步重做已完成的事务的算法是：

a 正向扫描日志文件，找出故障发生前已提交的事务的标识，将其记入重做队列

b 再一次正向扫描日志文件，对重做队列中的所有事务进行重做处理。即将日志记录中“更新后的值”写入数据库。

10 具有检查点的恢复技术有什么优点？

答：

利用日志技术进行数据库恢复时，恢复子系统必须搜索日志，确定哪些事务需要REDO，哪些事务需要UNDO。一般来说，需要检查所有日志记录。这样做有两个问题：

一是搜索整个日志将耗费大量的时间。

二是很多需要REDO处理的事务实际上已经将它们的更新 *** 作结果写到数据库中了，恢复子系统又重新执行了这些 *** 作，浪费了大量时间。

检查点技术就是为了解决这些问题。

11 试述使用检查点方法进行恢复的步骤。

答：

① 从重新开始文件中找到最后一个检查点记录在日志文件中的地址，由该地址在日志文件中找到最后一个检查点记录。

② 由该检查点记录得到检查点建立时刻所有正在执行的事务清单ACTIVE-LIST。

这里建立两个事务队列:

· UNDO-LIST: 需要执行undo *** 作的事务集合；

· REDO-LIST: 需要执行redo *** 作的事务集合；

把ACTIVE-LIST暂时放入UNDO-LIST队列，REDO队列暂为空。

③ 从检查点开始正向扫描日志文件

· 如有新开始的事务Ti，把Ti暂时放入UNDO-LIST队列；

· 如有提交的事务Tj，把Tj从UNDO-LIST队列移到REDO-LIST队列，直到日志文件结束；

④ 对UNDO-LIST中的每个事务执行UNDO *** 作, 对REDO-LIST中的每个事务执行REDO *** 作。

12 什么是数据库镜像？它有什么用途？

答：

数据库镜像即根据DBA的要求，自动把整个数据库或者其中的部分关键数据复制到另一个磁盘上。每当主数据库更新时，DBMS自动把更新后的数据复制过去，即DBMS自动保证镜像数据与主数据的一致性。

数据库镜像的用途有：

一是用于数据库恢复。当出现介质故障时，可由镜像磁盘继续提供使用，同时DBMS自动利用镜像磁盘数据进行数据库的恢复，不需要关闭系统和重装数据库副本。

二是提高数据库的可用性。在没有出现故障时，当一个用户对某个数据加排它锁进行修改时，其他用户可以读镜像数据库上的数据，而不必等待该用户释放锁。

数据库是面向事务的设计，数据仓库是面向主题设计的。数据库一般存储在线交易数据，数据仓库存储的一般是历史数据。

“与时间相关”：数据库保存信息的时候，并不强调一定有时间信息。数据仓库则不同，出于决策的需要，数据仓库中的数据都要标明时间属性。决策中，时间属性很重要。同样都是累计购买过九车产品的顾客，一位是最近三个月购买九车，一位是最近一年从未买过，这对于决策者意义是不同的。

“不可修改”：数据仓库中的数据并不是最新的，而是来源于其它数据源。数据仓库反映的是历史信息，并不是很多数据库处理的那种日常事务数据（有的数据库例如电信计费数据库甚至处理实时信息）。因此，数据仓库中的数据是极少或根本不修改的；当然，向数据仓库添加数据是允许的。

：

数据仓库的出现，并不是要取代数据库。数据仓库，是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它决不是所谓的“大型数据库”。

目前，大部分数据仓库还是用关系数据库管理系统来管理的。可以说，数据库、数据仓库相辅相成、各有千秋。

主从复制理论上支持无穷大的从库个数，实际情况下，受服务器带宽和读写能力的影响

请参考MySQL官方手册的建议：

理论上，通过使用单个主服务器/多从服务器设置，可以通过添加更多的从服务器来扩充系统，直到用完网络带宽，或者你的更新负载已经增长到主服务器不能处理的点。

在获得的收益开始吃平之前，为了确定可以有多少从服务器，以及可以将你的站点的性能提高多少，需要知道查询模式，并且要通过基准测试并根据经验确定一个典型的主服务器和从服务器中的读取（每秒钟读取量，或者max_reads）吞吐量和写（max_writes）吞吐量的关系。通过一个假设的带有复制的系统，本例给出了一个非常简单的计算结果。

假设系统负载包括10%的写和90%的读取，并且我们通过基准测试确定max_reads是1200_2×max_writes。换句话说，如果没有写 *** 作，系统每秒可以进行1,200次读取 *** 作，平均写 *** 作是平均读 *** 作所用时间的两倍，并且关系是线性的。我们假定主服务器和每个从服务器具有相同的性能，并且我们有一个主服务器和N个从服务器。那么，对于每个服务器（主服务器或从服务器），我们有：

reads=1200_2×writes

reads=9×writes/(N1)(读取是分离的,但是写入所有服务器)

9×writes/(N1)2×writes=1200

writes=1200/(29/(N1))

最后的等式表明了N个从服务器的最大写 *** 作数，假设最大可能的读取速率是每分钟1,200次，读 *** 作与写 *** 作的比率是9。

如上分析可以得到下面的结论：

·如果N=0（这表明没有复制），系统每秒可以处理大约1200/11=109个写 *** 作。

·如果N=1，每秒得到184个写 *** 作。

·如果N=8，每秒得到400个写 *** 作。

·如果N=17，每秒得到480个写 *** 作。

复制表结构及数据到新表

CREATE TABLE 新表 SELECT FROM 旧表

insert into 新表 （select from 旧表）

前提是表结构相同

以上就是关于数据库架构选型与落地，看这篇就够了全部的内容，包括:数据库架构选型与落地，看这篇就够了、什么是数据库、数据库总是被攻击，怎样解决等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！