数据库设计架构

① 数据库表结构设计重要吗

数据库表结构设计重要。
当在决定开发一个数据库管理项目时，最先着手的工作就应是数据库表结构的设计。数据库表结构的设计是开发数据库管理项目的基石，一个糟糕的表结构设计，可能会严重延误项目开发周期，使大量的劳动时间为此付之东流。表结构设计是数据库逻辑设计的重要组成部分，会直接影响到数据库的性能。
设计数据库表的注意事项：不应该针对整个系统进行数据库设计，而应该根据系统架构中的组件划分，针对每个组件所处理的业务进行组件单元的数据库设计；不同组件间所对应的数据库表之间的关联应尽可能减少，如果不同组件间的表需要外键关联也尽量不要创建外键关联，而只是记录关联表的一个主键，确保组件对应的表之间的独立性，为系统或表结构的重构提供可能性。

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

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

比较有代表性的产品有开创性质的Amoeba、阿里开源的Cobar、社区发展比较好的 Mycat （基于Cobar开发）等。

优点

缺点

JDBC方案 ：无中心化架构，兼容市面上大多数关系型数据库，适用于开发高性能的轻量级 OLTP 应用（面向前台）。

Proxy方案 ：提供静态入口以及异构语言的支持，适用于 OLAP 应用（面向后台）以及对分片数据库进行管理和运维的场景。

混合方案 ：在大型复杂系统中存在面向C端用户的前台应用，也有面向企业分析的后台应用，这个时候就可以采用混合模式。

JDBC 采用无中心化架构，适用于 Java 开发的高性能的轻量级 OLTP 应用；Proxy 提供静态入口以及异构语言的支持，适用于 OLAP 应用以及对分片数据库进行管理和运维的场景。

ShardingSphere是一套开源的分布式数据库中间件解决方案组成的生态圈，它由 Sharding-JDBC 、 Sharding-Proxy 和 Sharding-Sidecar （计划中）这3款相互独立的产品组成，他们均提供标准化的数据分片、分布式事务和数据库治理功能，可适用于如Java同构、异构语言、容器、云原生等各种多样化的应用场景。

ShardingSphere提供的核心功能：

Sharding-Proxy

定位为透明化的 数据库代理端 ，提供封装了 数据库二进制协议的服务端版本 ，用于完成对 异构语言的支持 。

目前已提供MySQL版本，它可以使用 任何兼容MySQL协议的访问客户端 (如：MySQL Command Client, MySQL Workbench, Navicat等)操作数据，对DBA更加友好。

向 应用程序完全透明 ，可直接当做MySQL使用。

适用于任何兼容MySQL协议的客户端。

Sharding-JDBC

定位为 轻量级Java框架 ，在Java的JDBC层提供的额外服务。 它使用客户端直连数据库，以jar包形式提供服务，无需额外部署和依赖，可理解为 增强版的JDBC驱动，完全兼容JDBC和各种ORM框架 。

以电商SaaS系统为例，前台应用采用Sharding-JDBC，根据业务场景的差异主要分为三种方案。

分库（用户）

问题解析：头部企业日活高并发高，单独分库避免干扰其他企业用户，用户数据的增长缓慢可以不分表。

拆分维度：企业ID分库

拆分策略：头部企业单独库、非头部企业一个库

分库分表（订单）

问题解析：订单数据增长速度较快，在分库之余需要分表。

拆分维度：企业ID分库、用户ID分表

拆分策略：头部企业单独库、非头部企业一个库，分库之后用户ID取模拆分表

单库分表（附件）

问题解析：附件数据特点是并发量不大，只需要解决数据增长问题，所以单库IO足以支撑的情况下分表即可。

拆分维度：用户ID分表

拆分策略：用户ID取模分表

问题一：分布式事务

分布式事务过于复杂也是分布式系统最难处理的问题，由于篇幅有限，后续会开篇专讲这一块内容。

问题二：分布式ID

问题三：跨片查询

举个例子，以用户id分片之后，需要根据企业id查询企业所有用户信息。

sharding针对跨片查询也是能够支持的，本质上sharding的跨片查询是采用同时查询多个分片的数据，然后聚合结果返回，这个方式对资源耗费比较大，特别是对数据库连接资源的消耗。

假设分4个数据库，8个表，则sharding会同时发出32个SQL去查询。一下子消耗掉了32个连接；

特别是针对单库分表的情况要注意，假设单库分64个表，则要消耗64个连接。如果我们部署了2个节点，这个时候两个节点同时查询的话，就会遇到数据库连接数上限问题（mysql默认100连接数）

问题四：分片扩容

随着数据增长，每个片区的数据也会达到瓶颈，这个时候需要将原有的分片数量进行增加。由于增加了片区，原先的hash规则也跟着变化，造成了需要将旧数据做迁移。

假设原先1个亿的数据，hash分64个表，现在增长到50亿的数据，需要扩容到128个表，一旦扩容就需要将这50亿的数据做一次迁移，迁移成本是无法想象的。

问题五：一致性哈希

首先，求出每个 服务器的hash值 ，将其配置到一个 0~2^n 的圆环上 （n通常取32）

其次，用同样的方法求出待 存储对象的主键 hash值 ，也将其配置到这个圆环上。

然后，从数据映射到的位置开始顺时针查找，将数据分布到找到的第一个服务器节点上。

一致性hash的优点在于加入和删除节点时只会影响到在哈希环中相邻的节点，而对其他节点没有影响。

所以使用一致性哈希在集群扩容过程中可以减少数据的迁移。

好了，这次分享到这里，我们日常的实践可能只会用到其中一种方案，但它不是数据库架构的全貌，打开技术视野，才能更好地把存储工具利用起来。

老规矩，一键三连，日入两千，点赞在看，年薪百万！

本文作者：Jensen

7年Java老兵，小米主题设计师，手机输入法设计师，ProcessOn特邀讲师。

曾涉猎航空、电信、IoT、垂直电商产品研发，现就职于某知名电商企业。

技术公众号 【架构师修行录】 号主，专注于分享日常架构、技术、职场干货，Java Goals：架构师。

交个朋友，一起成长！

③ 数据库架构是什么

问题一：sql server中的架构是什么意思? 通俗点说就是一个组，里面可以存放表、视图、存储过程等
主要是用于权限控制安全控制的

问题二：什么是架构，SQL中的架构有哪些 架构(Schema)是形成单个命名空间的数据库实体的 *** 。
命名空间是一个 *** ，其中每个元素的名称都是唯一的。
可以将架构看成一个存放数据库中对象的一个容器。
架构实际上在sqlserver2000中就已经存在，当我们使用查询分析器去查询一个表的时候，一个完整的表的名称应该包括服务器名.数据库名.用户名.对象名，而在sqlserver2005中一个表的完全限定名称应该为服务器名.数据库名.架构名.对象名
在2000中，假如有一个账户tt在test数据库中创建了一张表table1的时候，在服务器上对查询的语句应为select * from test.tt.table1,也就是说，在sqlserver 2000中一张表所属的架构默认就是表的创建者的登录名称，用户可以和修改他所创建的所有数据库对象。

问题三：数据库架构是什么 参考有一个声音再也不能的在耳边响起，有一双手再也握不住那手心的温度与舒适。

问题四：数据架构是什么 数据架构即数据库架构

数据库是相关数据的 *** ，一个数据库含有各种成分，包括表、记录、字段、索引等。
1．数据库(Database)
Visual Basic中使用的数据库是关系型数据库(Relational Database)。一个数据库由一个或一组数据表组成。每个数据库都以文件的形式存放在磁盘上，即对应于一个物理文件。不同的数据库，与物理文件对应的方式也不一样。对于dBASE,FoxPro和Paradox格式的数据库来说，一个数据表就是一个单独的数据库文件，而对于Microsoft Access、Btrieve格式的数据库来说，一个数据库文件可以含有多个数据表。
2．数据表(Table)
简称表，由一组数据记录组成，数据库中的数据是以表为单位进行组织的。一个表是一组相关的按行排列的数据；每个表中都含有相同类型的信息。表实际上是一个二维表格，例如，一个班所有学生的考试成绩，可以存放在一个表中，表中的每一行对应一个学生，这一行包括学生的学号，姓名及各门课程成绩。
3．记录(Record)
表中的每一行称为一个记消芦录，它由若干个字段组成。
4．字段(Field)
也称域。表中的每一列称为一个字段。每个字段都有相应的描述信息，如数据类型、数据宽度等。
5．索引(Index)
为了提高访问数据库的效率，可以对数据库使用索引。当数据库较大时，为了查找指定的记录，则使用索引和不使用索引的效困斗率有很大差别。索引实际上是一种特殊类型的表，其中含有关键字段的值(由用户定义)和指向实际记录位置的指针，这些值和指针按照特定的顺序(也由用户定义)存储，从而可以以较快的速度查找到所需要的数据记录。
6．查询(Query)
一条SQL(结构化查询语言)命令，用来从一个或多个表中获取一组指定的记录，或者对某个表执行指定的操作。当从数据库中读取数据时，往往希望读出的数据符合某些条件，并且能按某个字段排序。使用SQL，可以使这一操作容易实现而且更加有效。SQL是非过程化语言(有人称为第四代语言)，在用它查找指定的记录时，只需指出做什么，不必说明汪桥磨如何做。每个语句可以看作是一个查询(query)，根据这个查询，可以得到需要的查询结果。
7．过滤器(Filter)
过滤器是数据库的一个组成部分，它把索引和排序结合起来，用来设置条件，然后根据给定的条件输出所需要的数据。
8.视图(view)
数据的视图指的是查找到(或者处理)的记录数和显示(或者进行处理)这些记录的顺序。在一般情况下，视图由过滤器和索引控制

问题五：数据库中的文件组和架构有什么不同？两者之间的关系是什么？ 文件组 是 管理 物理文件的. 多个物理文件, 放在一个组里面
架构 不知道你指的是不是 Schema.
如果是的话。

架构 是 逻辑上面的, 一个数据库， 可以划分为多个 架构， 每个 架构 存储其独有的业务数据。
SQL Server 默认使用一个 名为 dbo 的 构架。

问题六：数据库-架构和数据库-管理指的是什么 数据库架构：
下面是基于SQLserver数据库来谈的。贰
SQLServer经过这些年的发展，其实已经有很多很好的技术可以使用，如Replication、SSB、Cluster、Mirroring等（可以参考我在SQLServer DBA 三十问和SQLServer 高可用、高性能和高保护延伸 中的一些技术方面的知识），而且这些技术在可靠性方面已经通过了市场的认可，有很多公司在为提高其程序的可靠性、安全性和高效性等方面或多或少的采用了其中的某些技术，以下就我接触过的这些技术方面的应用，主要针对网站这种流量很大，读多写少的应用，就数据库架构方面做些探讨，希望对各位有所帮助，如有不对的地方，欢迎大家指正和交流。

数据库架构需要考虑的问题：
数据可靠和一致性；
数据容灾；
当数据量和访问压力变大时，方便扩充；
高度可用，出问题时能及时恢复，无单点故障；
不应因为某一台机器出现问题，导致整网性能的急剧下降；
方便维护。
数据库管理：
数据库管理(Database Manager)是有关建立、存储、修改和存取数据库中信息的技术，是指为保证数据库系统的正常运行和服务质量，有关人员须进行的技术管理工作。负责这些技术管理工作的个人或集体称为数据库管理员(DBA)。数据库管理的主要内容有：数据库的调优、数据库的重组、数据库的重构、数据库的安全管控、报错问题的分析和汇总和处理、数据库数据的日常备份. 数据库的建立：数据库的设计只是提供了数据的类型、逻辑结构、联系、约束和存储结构等有关数据的描述。这些描述称为数据模式。

问题七：oracle数据库的结构是什么？ Oracle数据库的体系结构包括四个方面：数据库的物理结构、逻辑结构、内存结构及进程。

1. 物理结构

物理数据库结构是由构成数据库的操作系统文件所决定，Oracle数据库文件包括：

数据文件（Data File）
数据文件用来存储数据库中的全部数据，例如数据库表中的数据和索引数据.通常以为*.dbf格式，例如:userCIMS.dbf 。

日志文件（Redo Log File）
日志文件用于记录数据库所做的全部变更（如增加、删除、修改）、以便在系统发生故障时，用它对数据库进行恢复。名字通常为Log*.dbf格式，如：Log1CIMS.dbf,Log2CIMS.dbf 。

控制文件（Control File）
每个Oracle数据库都有相应的控制文件，它们是较小的二进制文件，用于记录数据库的物理结构，如：数据库名、数据库的数据文件和日志文件的名字和位置等信息。用于打开、存取数据库。名字通常为Ctrl*ctl 格式，如Ctrl1CIMS.ctl。

配置文件
配置文件记录Oracle数据库运行时的一些重要参数，如：数据块的大小，内存结构的配置等。名字通常为init*.ora 格式，如：initCIMS.ora 。

2 逻辑结构

Oracle数据库的逻辑结构描述了数据库从逻辑上如何来存储数据库中的数据。逻辑结构包括表空间、段、区、数据块和模式对象。数据库的逻辑结构将支配一个数据库如何使用系统的物理空间.模式对象及其之间的联系则描述了关系数据库之间的设计.

一个数据库从逻辑上说是由一个或多个表空间所组成，表空间是数据库中物理编组的数据仓库，每一个表空间是由段(segment)组成，一个段是由一组区(extent)所组成，一个区是由一组连续的数据库块(database block)组成，而一个数据库块对应硬盘上的一个或多个物理块。一个表空间存放一个或多个数据库的物理文件（即数据文件）.一个数据库中的数据被逻辑地存储在表空间上。

表空间（tablespace）
Oracle数据库被划分为一个或多个称为表空间的逻辑结构，它包括两类表空间，System表空间和非System表空间，其中，System表空间是安装数据库时自动建立的，它包含数据库的全部数据字典，存储过程、包、函数和触发器的定义以及系统回滚段。除此之外，还能包含用户数据。。

一个表空间包含许多段，每个段有一些可以不连续的区组成，每个区由一组连续的数据块组成，数据块是数据库进行操作的最小单位。

每个表空间对应一个或多个数据文件，每个数据文件只能属于一个表空间。

数据库块（database block）
数据库块也称逻辑块或ORACLE块，它对应磁盘上一个或多个物理块，它的大小由初始化参数db-block-size（在文件init.ora中）决定，典型的大小是2k。Pckfree 和pctused 两个参数用来优化数据块空间的使用。

区（extent）
区是由一组连续的数据块所组成的数据库存储空间分配的逻辑单位。

段（segment）
段是一个或多个不连续的区的 *** ，它包括一个表空间内特定逻辑结构的所有数据，段不能跨表空间存放。Oracle数据库包括数据段、索引段、临时段、回滚段等。

模式对象（schema object）
Oracle数据库的模式对象包括表、视图、序列、同意词、索引、触发器、存......>>

问题八：sql server中架构是什么意思 架构（Schema）是一组数据库对象的 *** ，它被单个负责人（可以是用户或角色）所拥有并构成唯一命名空间。你可以将架构看成是对象的容器。
在 SQL Server 2000 中，用户（User）和架构是隐含关联的，即每个用户拥有与其同名的架构。因此要删除一个用户，必须先删除或修改这个用户所拥有的所有数据库对象。
在 SQL Server 2005 中，架构和创建它的数据库用户不再关联，完全限定名（fully-qualified name）现在包含4个部分：server.database.schema.object
1. 体系结构（Architecture）
体系结构亦可称为架构，所谓软件架构，根据Perry 和Wolfe之定义：Software Architecture = {Elements,Forms, Rationale / Constraint }，也就是软件主架构 = {组件元素，元素互助合作之模式，基础要求与限制}。Philippe Kruchten采用上面的定义，并说明主架构之设计就是：将各组件元素以某些理想的合作模式组织起来，以达成系统的基本功能和限制。体系结构又分为多种样式，如Pipes and Filters等。
2. 框架(Framework)
框架亦可称为应用架构，框架的一般定义就是：在特定领域基于体系结构的可重用的设计。也可以认为框架是体系结构在特定领域下的应用。框架比较出名的例子就是MVC。
3. 库(Library)
库应该是可重用的、相互协作的资源的 *** ，供开发人员进行重复调用。它与框架的主要区别在于运行时与程序的调用关系。库是被程序调用，而框架则调用程序。比较好的库有JDK。
4. 设计模式（Design Pattern）
设计模式大家应该很熟悉，尤其四人帮所写的书更是家喻户晓。“四人帮”将模式描述为“在一定的环境中解决某一问题的方案”。这三个事物 ― 问题、解决方案和环境 ― 是模式的基本要素。给模式一个名称，考虑使用模式将产生的结果和提供一个或多个示例，对于说明模式也都是有用的。
5. 平台（PlatForm）
由多种系统构成，其中也可以包含硬件部分。
对于以上的概念有一个比较清楚的认识之后，就可以在软件的开发过程中进行应用。理论和实践是缺一不可的，相辅相成的。没有理论的指导，实践就缺乏基础；没有实践的证明，理论就缺乏依据，因此我一直认为：对于当代的程序员，在有一定的实践基础后，必须学习更深的理论知识。无论你是从那方面先开始学习的。
在软件的开发过浮中，从许多过程实践和方法中，大致可以提炼出五大步骤：需求、分析、设计、编码、测试。而体系结构是软件的骨架，是最重要的基础。体系结构是涉及到每一步骤中。一般在获取需要的同时，就应该开始分析软件的体系结构。体系结构现在一般是各个大的功能模块组合成，然后描述各个部分的关系。
我一般认为框架是体系结构中每个模块中更细小的结构。如需要表示web技术，就会用到MVC框架，而web功能只是整个软件体系中的一个功能模块。每个框架可以有许多个实例，如用java实现的MVC框架structs。
而在框架之下就是设计模式，设计模式一般是应用中框架之中的，也可以说是对框架的补充。因为框架只是提供了一个环境，需要我们我里面填入更多的东西。无论是否应用了设计模式，你都可以实现软件的功能，而正确应用了设计模式，是我们对前人软件的设计或实现方法的一种继承，从而让你的软件更软。
体系结构是可以从不同视角来进......>>

问题九：oracle数据库的架构是什么？ oracle 数据库架构本质上是C/S结构的。 服务器与客户端是分开的，即时服务器和客户端是在同一机器上，他们也是按照客户端/服务器模式运行的，他们之间的进程是分开的。 希望能帮助你。

问题十：数据库中拥有的架构与成员身份有什么区别？ 不同权限组合或单独就构成常角色。
不同用户创建的数据库对象不可能放在放在一起，因此就出现了容器就是所谓的架构，架构就是单个命名空间的数据实体的 ***

④ 数据库软件架构设计的要点

数据库软件架构设计，要关注哪些要点？
方法/步骤
在IT系统架构设计中，数据库的设计，占据着很重要的地位。那么主要面临哪些问题，需要考虑哪些因素呢？
面对数据量过大的问题，通常需要通过分片技术来解决，目前应用较多的是哈希分片。
因为通过范围简单分片，可能造成各库的压力不均；而统一路由，会增加访问前查询的压力。
通过主从复制的分组备笑，既可以解决可用性的问题，还可以实现一定的性能提升。
数据库的软件架构设计，要关注可用性、性能、一致性和扩展性四个方面。
解决可用性的主要思路就是冗余——站点冗余、服务冗余、数据冗余……
冗余带来的可用性问题，就是数据一致性的问题，要保证数据一致性，可以考虑双写同步。
扩展性能仿漏含一般有三种方式——增加索引、增加从库和增加缓存，要结合实际情况分析应用。
架构的设计是一个动态优化的过程，要综合考虑几搜配个方面的因素，寻找合适的平衡点。

⑤ 什么叫做数据库的“三层架构

三层架构可以说是一种设置模式，他的作用只是让我们更加有效的利用资源，有利于以后的修改和查看，依次分为视图层，逻辑层，数据层；

试图层顾名思义就是我们所看到的，他的原代码并没有关于处理和连库等代码，只是简单的跳转页面，我们没有办法看到真正的代码；

逻辑层就是我们从页面层发回的问题等请求，从字面意思来看，你可以将他视为一个过渡层，只是连接是图层和数据层；进行一些连库，删除数据等操作了；从试图层跳转过来的问题在这里进行处理，并提交给数据层，再返回页面层共读者查看；

数据层就不用说了吧！这里存放着所有的数据也就是一个工程的大本营一样芹帆扒；

三层架构已经不仅仅属于.net了，他是一种设计形式，从某种意义上来说，所有的轿旁开发设计几乎都已经以三层架构为基础，三层架构及有效嫌昌的处理问题，将数据和试图也有效的分开，这样防止耦合度过高，有利于处理和修改，（你不会是想将代码全部写在视图页面上，这样有一个小小的变动，我们就要翻看几十万句代码，从中找出，那我要替你的眼睛抱不平了）当你将程序做好后，从这台机子移动到另一台机子时，大大减少了出错的问题；

通俗一点就是，这样看上去很有层次感，我们查看时，可以减少时间的浪费，也不用在代码堆里翻来覆去找不到北

⑥ 大数据量的系统的数据库结构如何设计

1、把你表中经常查询的和不常用的分开几个表，也就是横向切分
2、把不同类型的分成几个表，纵向切分
3、常用联接的建索引
4、服务器放几个硬盘，把数据、日志、索引分盘存放，这样可以提高IO吞吐率
5、用优化器，优化你的查询
6、考虑冗余，这样可以减少连接
7、可以考虑建立统计表，就是实时生成总计表，这样可以避免每次查询都统计一次
mrzxc 等说的好，考虑你的系统，注意负载平衡，查询优化，25 万并不大，可以建一个表，然后按mrzxc 的3 4 5 7 优化。 速度，影响它的因数太多了，且数据量越大越明显。
1、存储 将硬盘分成NTFS格式，NTFS比FAT32快，并看你的数据文件大小，1G以上你可以采用多数据库文件，这样可以将存取负载分散到多个物理硬盘或磁盘阵列上。
2、tempdb tempdb也应该被单独的物理硬盘或磁盘阵列上,建议放在RAID 0上，这样它的性能最高,不要对它设置最大值让它自动增长
3、日志文件 日志文件也应该和数据文件分开在不同的理硬盘或磁盘阵列上，这样也可以提高硬盘I/O性能。
4、分区视图 就是将你的数据水平分割在集群服务器上，它适合大规模OLTP,SQL群集上，如果你数据库不是访问特别大不建议使用。
5、簇索引 你的表一定有个簇索引，在使用簇索引查询的时候，区块查询是最快的，如用between，应为他是物理连续的，你应该尽量减少对它的updaet,应为这可以使它物理不连续。
6、非簇索引 非簇索引与物理顺序无关，设计它时必须有高度的可选择性，可以提高查询速度，但对表update的时候这些非簇索引会影响速度，且占用空间大，如果你愿意用空间和修改时间换取速度可以考虑。
7、索引视图 如果在视图上建立索引,那视图的结果集就会被存储起来，对与特定的查询性能可以提高很多，但同样对update语句时它也会严重减低性能，一般用在数据相对稳定的数据仓库中。
8、维护索引 你在将索引建好后，定期维护是很重要的，用dbcc showcontig来观察页密度、扫描密度等等，及时用dbcc indexdefrag来整理表或视图的索引,在必要的时候用dbcc dbreindex来重建索引可以受到良好的效果。 不论你是用几个表1、2、3点都可以提高一定的性能，5、6、8点你是必须做的，至于4、7点看你的需求，我个人是不建议的。打了半个多小时想是在写论文，希望对你有帮助。

⑦ 微服务开发中的数据架构应该怎样设计

前言

微服务是当前非常流行的技术框架，通过服务的小型化、原子化以及分布式架构的弹性伸缩和高可用性，可以实现业务之间的松耦合、业务的灵活调整组合以及系统的高可用性。为业务创新和业务持续提供了一个良好的基础平台。本文分享在这种技术架构下的数据架构的设计思想以及设计要点，本文包括下面若干内容。

• 微服务技术框架中的多层数据架构设计

• 数据架构设计中的要点
  

• 要点1：数据易用性

• 要点2：主、副数据及数据解耦

• 要点3：分库分表

• 要点4：多源数据适配

• 要点5：多源数据缓存

• 要点6：数据集市

为了容易理解，本文用一个简化的销售模型来阐述，如下图。图1显示了客户、卖家、商品、定价、订单的关系（这里省略支付、物流等其他元素）。

图1 销售模型

在这个销售模型中，卖家提供商品、制定价格，客户选择产品购买、形成销售订单。根据微服务的理念设计，可以划分为客户服务、卖家服务、商品服务、定价服务、订单服务，以及公共服务（比如认证、权限、通知等），如图2所示。



图9 数据缓存

要点6：数据集市

数据集市是一个很大的话题。当现有的数据不能简单地通过几个表数据关联以及简单加工后就可以供业务使用的时候，就需要考虑构建数据集市。数据集市以数据运用的观点来分析加工数据，通过多源数据的导入、清洗、加工、视图做成等一系列的数据操作后，为业务提供可用的、稳定的数据源。例如，对销售分析中、什么样的客户喜欢什么样的商品、价格对销售金额的影响、销售金额跟地区日期的关联关系等多维度分析，就要用数据集市的概念，如图10所示。

图10 数据集市

数据承载着信息，好的数据架构设计会使业务系统变得更加流畅、更加容易理解和维护。本文只是总结一些在实际工程中的体会，供大家分享。如果有不足之处、也请大家补充、赐教。

（此文转载至GitChat技术杂谈）

⑧ 数据表关系比较多的数据库三层架构应该怎么设计

实体类，也就是把数据库表的字段映射为码野你的对象的迟物喊各个属性如你A表有，id,name,password三个属性你Model里面新建Aclass给他ID,Name,Password三个属性然后做和数据表字段映射LINQTOSQL的时候就会自动读取映射的字段并蚂亩转换为实体类的属性值

⑨ 数据库设计和数据库架构一样吗

不一样，数据库设计和数据库架构是不一样的，可以先设计出数据库的架构，然后再深化完善设计。

⑩ 怎样的架构设计才是真正的数据仓库架构

一直想整理一下这块内容，既然是漫谈，就想起什么说什么吧。我一直是在互联网行业，就以互联网行业来说。
先大概列一下互联网行业数据仓库、数据平台的用途：

• 整合公司所有业务数据，建立统一的数据中心；

• 提供各种报表，有给高层的，有给各个业务的；

• 为网站运营提供运营上的数据支持，就是通过数据，让运营及时了解网站和产品的运营效果；

• 为各个业务提供线上或线下的数据支持，成为公司统一的数据交换与提供平台；

• 分析用户行为数据，通过数据挖掘来降低投入成本，提高投入效果；比如广告定向精准投放、用户个性化推荐等；

• 开发数据产品，直接或间接为公司盈利；

• 建设开放数据平台，开放公司数据；

• 。。。。。。



• 上面列出的内容看上去和传统行业数据仓库用途差不多，并且都要求数据仓库/数据平台有很好的稳定性、可靠性；但在互联网行业，除了数据量大之外，越来越多的业务要求时效性，甚至很多是要求实时的 ，另外，互联网行业的业务变化非常快，不可能像传统行业一样，可以使用自顶向下的方法建立数据仓库，一劳永逸，它要求新的业务很快能融入数据仓库中来，老的下线的业务，能很方便的从现有的数据仓库中下线；


• 其实，互联网行业的数据仓库就是所谓的敏捷数据仓库，不但要求能快速的响应数据，也要求能快速的响应业务；


• 建设敏捷数据仓库，除了对架构技术上的要求之外，还有一个很重要的方面，就是数据建模，如果一上来就想着建立一套能兼容所有数据和业务的数据模型，那就又回到传统数据仓库的建设上了，很难满足对业务变化的快速响应。应对这种情况，一般是先将核心的持久化的业务进行深度建模（比如：基于网站日志建立的网站统计分析模型和用户浏览轨迹模型；基于公司核心用户数据建立的用户模型），其它的业务一般都采用维度+宽表的方式来建立数据模型。这块是后话。


• 整体架构下面的图是我们目前使用的数据平台架构图，其实大多公司应该都差不多：


• 逻辑上，一般都有数据采集层、数据存储与分析层、数据共享层、数据应用层。可能叫法有所不同，本质上的角色都大同小异。


• 我们从下往上看：


• 数据采集数据采集层的任务就是把数据从各种数据源中采集和存储到数据存储上，期间有可能会做一些简单的清洗。



• 数据源的种类比较多：



• 网站日志：



• 作为互联网行业，网站日志占的份额最大，网站日志存储在多台网站日志服务器上，


• 一般是在每台网站日志服务器上部署flume agent，实时的收集网站日志并存储到HDFS上；



• 业务数据库：



• 业务数据库的种类也是多种多样，有Mysql、Oracle、SqlServer等，这时候，我们迫切的需要一种能从各种数据库中将数据同步到HDFS上的工具，Sqoop是一种，但是Sqoop太过繁重，而且不管数据量大小，都需要启动MapRece来执行，而且需要Hadoop集群的每台机器都能访问业务数据库；应对此场景，淘宝开源的DataX，是一个很好的解决方案（可参考文章 《异构数据源海量数据交换工具-Taobao DataX 下载和使用》），有资源的话，可以基于DataX之上做二次开发，就能非常好的解决，我们目前使用的DataHub也是。


• 当然，Flume通过配置与开发，也可以实时的从数据库中同步数据到HDFS。



• 来自于Ftp/Http的数据源：



• 有可能一些合作伙伴提供的数据，需要通过Ftp/Http等定时获取，DataX也可以满足该需求；



• 其他数据源：



• 比如一些手工录入的数据，只需要提供一个接口或小程序，即可完成；



• 数据存储与分析毋庸置疑，HDFS是大数据环境下数据仓库/数据平台最完美的数据存储解决方案。



• 离线数据分析与计算，也就是对实时性要求不高的部分，在我看来，Hive还是首当其冲的选择，丰富的数据类型、内置函数；压缩比非常高的ORC文件存储格式；非常方便的SQL支持，使得Hive在基于结构化数据上的统计分析远远比MapRece要高效的多，一句SQL可以完成的需求，开发MR可能需要上百行代码；


• 当然，使用Hadoop框架自然而然也提供了MapRece接口，如果真的很乐意开发Java，或者对SQL不熟，那么也可以使用MapRece来做分析与计算；Spark是这两年非常火的，经过实践，它的性能的确比MapRece要好很多，而且和Hive、Yarn结合的越来越好，因此，必须支持使用Spark和SparkSQL来做分析和计算。因为已经有Hadoop Yarn，使用Spark其实是非常容易的，不用单独部署Spark集群，关于Spark On Yarn的相关文章，可参考：《Spark On Yarn系列文章》


• 实时计算部分，后面单独说。


• 数据共享这里的数据共享，其实指的是前面数据分析与计算后的结果存放的地方，其实就是关系型数据库和NOSQL数据库；



• 前面使用Hive、MR、Spark、SparkSQL分析和计算的结果，还是在HDFS上，但大多业务和应用不可能直接从HDFS上获取数据，那么就需要一个数据共享的地方，使得各业务和产品能方便的获取数据；和数据采集层到HDFS刚好相反，这里需要一个从HDFS将数据同步至其他目标数据源的工具，同样，DataX也可以满足。


• 另外，一些实时计算的结果数据可能由实时计算模块直接写入数据共享。



• 数据应用

• 业务产品
  



• 业务产品所使用的数据，已经存在于数据共享层，他们直接从数据共享层访问即可；



• 报表



• 同业务产品，报表所使用的数据，一般也是已经统计汇总好的，存放于数据共享层；



• 即席查询



• 即席查询的用户有很多，有可能是数据开发人员、网站和产品运营人员、数据分析人员、甚至是部门老大，他们都有即席查询数据的需求；


• 这种即席查询通常是现有的报表和数据共享层的数据并不能满足他们的需求，需要从数据存储层直接查询。


• 即席查询一般是通过SQL完成，最大的难度在于响应速度上，使用Hive有点慢，目前我的解决方案是SparkSQL，它的响应速度较Hive快很多，而且能很好的与Hive兼容。


• 当然，你也可以使用Impala，如果不在乎平台中再多一个框架的话。



• OLAP



• 目前，很多的OLAP工具不能很好的支持从HDFS上直接获取数据，都是通过将需要的数据同步到关系型数据库中做OLAP，但如果数据量巨大的话，关系型数据库显然不行；


• 这时候，需要做相应的开发，从HDFS或者HBase中获取数据，完成OLAP的功能；


• 比如：根据用户在界面上选择的不定的维度和指标，通过开发接口，从HBase中获取数据来展示。



• 其它数据接口
  



• 这种接口有通用的，有定制的。比如：一个从Redis中获取用户属性的接口是通用的，所有的业务都可以调用这个接口来获取用户属性。



• 实时计算现在业务对数据仓库实时性的需求越来越多，比如：实时的了解网站的整体流量；实时的获取一个广告的曝光和点击；在海量数据下，依靠传统数据库和传统实现方法基本完成不了，需要的是一种分布式的、高吞吐量的、延时低的、高可靠的实时计算框架；Storm在这块是比较成熟了，但我选择Spark Streaming，原因很简单，不想多引入一个框架到平台中，另外，Spark Streaming比Storm延时性高那么一点点，那对于我们的需要可以忽略。


• 我们目前使用Spark Streaming实现了实时的网站流量统计、实时的广告效果统计两块功能。


• 做法也很简单，由Flume在前端日志服务器上收集网站日志和广告日志，实时的发送给Spark Streaming，由Spark Streaming完成统计，将数据存储至Redis，业务通过访问Redis实时获取。


• 任务调度与监控在数据仓库/数据平台中，有各种各样非常多的程序和任务，比如：数据采集任务、数据同步任务、数据分析任务等；



• 这些任务除了定时调度，还存在非常复杂的任务依赖关系，比如：数据分析任务必须等相应的数据采集任务完成后才能开始；数据同步任务需要等数据分析任务完成后才能开始；这就需要一个非常完善的任务调度与监控系统，它作为数据仓库/数据平台的中枢，负责调度和监控所有任务的分配与运行。


• 前面有写过文章，《大数据平台中的任务调度与监控》,这里不再累赘。


• 总结在我看来架构并不是技术越多越新越好，而是在可以满足需求的情况下，越简单越稳定越好。目前在我们的数据平台中，开发更多的是关注业务，而不是技术，他们把业务和需求搞清楚了，基本上只需要做简单的SQL开发，然后配置到调度系统就可以了，如果任务异常，会收到告警。这样，可以使更多的资源专注于业务之上。