257 lines
11 KiB
Markdown
257 lines
11 KiB
Markdown
|
# 数据库设计
|
|||
|
|
|
|||
|
|
## 数据库设计说明
|
|||
|
|
|
|||
|
|
### 编写目的
|
|||
|
|
|
|||
|
|
数据库设计说明书是软件系统中数据库部分的概念设计、逻辑设计、物理设计、分布数据设计、数据处理设计的文档表示。用于为系统设计师、程序开发人员、数据库维护人员提供信息。
|
|||
|
|
|
|||
|
|
### 设计原则
|
|||
|
|
|
|||
|
|
1. **数据一致性**
|
|||
|
|
|
|||
|
|
在统一规划的前提下，统一方法、统一指标、统一操作流程、统一精度进行空间数据的组织，使用统一的坐标系、投影方式、比例尺和通用的数据格式，以方便数据的无缝拼接、数据共享与应用。
|
|||
|
|
|
|||
|
|
2. **数据规范化**
|
|||
|
|
|
|||
|
|
数据库的设计遵循规范化理论。规范化数据库设计，减少数据库插入、删除、修改等操作时的异常和错误，降低数据冗余度等。
|
|||
|
|
|
|||
|
|
3. **数据专业化**
|
|||
|
|
|
|||
|
|
充分考虑现有行业数据、国家标准数据以及山洪灾害相关标准数据的联系与区别，把基础地理空间数据按业务需要转化为符合行业标准相关的图层和属性信息，确保数据的专业性。
|
|||
|
|
|
|||
|
|
### 设计方法
|
|||
|
|
|
|||
|
|
本系统在数据存储上不但涵盖了常规信息管理系统所涉及的数据类型，同时还包括了文本、图片等非结构化数据以及地理信息数据等。因此在设计方法上应当先对数据类型进行归纳，然后针对不同的数据类型进行多元化设计，以便保证数据库平台最终的数据完整性、准确性、扩展性。系统从数据类型上主要分为结构化与非结构化两大类，地理信息数据是结构化数据中较为特殊的一种类型，对其也将采用单独的设计方法。
|
|||
|
|
|
|||
|
|
## 运行环境
|
|||
|
|
|
|||
|
|
1. **硬件设备**
|
|||
|
|
|
|||
|
|
CPU:16vCPU
|
|||
|
|
|
|||
|
|
内存：128GBDRAM
|
|||
|
|
|
|||
|
|
硬盘：40GSSD系统盘/2TBSSD数据盘
|
|||
|
|
|
|||
|
|
2. **软件运行环境**
|
|||
|
|
|
|||
|
|
操作系统：麒麟系统V10
|
|||
|
|
|
|||
|
|
数据库系统：Postgresql11
|
|||
|
|
|
|||
|
|
## 数据库安全设计
|
|||
|
|
|
|||
|
|
1. **安全措施**
|
|||
|
|
|
|||
|
|
采用安全措施如下：
|
|||
|
|
|
|||
|
|
1. 修改数据库用户的默认密码。
|
|||
|
|
|
|||
|
|
2. 设置数据库用户的操作权限。
|
|||
|
|
|
|||
|
|
3. 通过相关配置，能够对系统的重要事件进行安全审计。
|
|||
|
|
|
|||
|
|
4. 及时更新数据库bug和安全补丁。
|
|||
|
|
|
|||
|
|
5. 设置最大并发连接数，资源控制主要保证数据库的资源不被非法的占用。
|
|||
|
|
|
|||
|
|
<!-- -->
|
|||
|
|
|
|||
|
|
2. **数据备份**
|
|||
|
|
|
|||
|
|
系统采用如下备份策略：
|
|||
|
|
|
|||
|
|
1. 每日凌晨，系统自带定时任务自动使用Postgresql提供的工具pg_dumpall和pg_dump来进行数据冷备份；
|
|||
|
|
|
|||
|
|
2. 2、采用双机主备模式，基于tcp流的数据传输方式，备机同步主机最新数据。实时备份主机数据。
|
|||
|
|
|
|||
|
|
## 规范性引用文件
|
|||
|
|
|
|||
|
|
以水利部颁布的《实时雨水情数据库表结构与标识符标准》(SL323-2011)为标准。
|
|||
|
|
|
|||
|
|
## 水利项目特殊规范
|
|||
|
|
|
|||
|
|
1. 表中所使用水利部标准字段按《实时雨水情数据库表结构与标识符标准》中字段使用。
|
|||
|
|
|
|||
|
|
2. 各表中自建共有字段按照标准字段统一，如创建人、创建时间、更新人、更新时间。
|
|||
|
|
|
|||
|
|
## 业务命名规范
|
|||
|
|
|
|||
|
|
可以采用26个英文字母(区分大小写)和0-9的自然数(一般不需要)加上下划线'\_'组成，命名简介明确(student_union)，多个单词用下划线'\_'分隔
|
|||
|
|
|
|||
|
|
### 表命名规范
|
|||
|
|
|
|||
|
|
1. 采用26字母和0-9的自然数（一般不使用）加上下互相'\_'组成，命名简洁明确，多个单词用下划线'\_'隔开；
|
|||
|
|
|
|||
|
|
2. 全部小写命名，尽量避免出现大写（因为在我目前使用过的数据库里都不区分大小写）；
|
|||
|
|
|
|||
|
|
3. 禁止使用关键字，如：select、table、show等等；
|
|||
|
|
|
|||
|
|
4. 表名称不要取得太长（一般不超过三个英文单词）；
|
|||
|
|
|
|||
|
|
5. 表的名称一般使用名词或者动宾短语；
|
|||
|
|
|
|||
|
|
6. 也要注意单词形式，列如：使用user，而不是users（因为用户表是一个的而不是多个）；
|
|||
|
|
|
|||
|
|
7. 表必须填写描述信息（建表时可以用注释详细写出表细节的作用，不同数据库的注释都不一样）。
|
|||
|
|
|
|||
|
|
8. 各表按照域划分添加命名前缀。如基础域（basic\_）、预案域（plan\_）。
|
|||
|
|
|
|||
|
|
### 字段命名规范
|
|||
|
|
|
|||
|
|
1. 采用26字母和0-9的自然数（一般不使用）加上下互相'\_'组成，命名简洁明确，多个单词用下划线'\_'隔开
|
|||
|
|
|
|||
|
|
2. 全部小写命名，尽量避免出现大写
|
|||
|
|
|
|||
|
|
3. 字段必须填写描述信息
|
|||
|
|
|
|||
|
|
4. 禁止使用数据库关键字
|
|||
|
|
|
|||
|
|
5. 字段名称一般采用名词或动宾短语
|
|||
|
|
|
|||
|
|
6. 采用字段的名字必须是易于理解，一般不超过三个英文单词
|
|||
|
|
|
|||
|
|
7. 在命名表的列时，不要重复表的名称（如：在user表中，出现user_name字段）
|
|||
|
|
|
|||
|
|
8. 字段命名使用完整名称
|
|||
|
|
|
|||
|
|
## 部署架构
|
|||
|
|
|
|||
|
|
数据库采用主备架构，主机做读写使用，备机只同步主机的数据，不提供对外服务，采用keepalived+VIP做主备切换。解决单点问题，保障数据库高可用性，避免主机宕机导致数据库不可用问题。
|
|||
|
|
|
|||
|
|
{width="5.7659722222222225in"
|
|||
|
|
height="3.3055555555555554in"}
|
|||
|
|
|
|||
|
|
## 数据库设计
|
|||
|
|
|
|||
|
|
1. **分析成果域库**
|
|||
|
|
|
|||
|
|
{width="5.754922353455818in"
|
|||
|
|
height="5.403869203849519in"}
|
|||
|
|
|
|||
|
|
2. **基础数据域库**
|
|||
|
|
|
|||
|
|
<figure>
|
|||
|
|
<img src="media/image834.png" style="width:5.93813in;height:7.35238in"
|
|||
|
|
alt="1667819818692" />
|
|||
|
|
<figcaption><p>图6.3基础数据域库架构图</p></figcaption>
|
|||
|
|
</figure>
|
|||
|
|
|
|||
|
|
<figure>
|
|||
|
|
<img src="media/image835.png" style="width:5.76458in;height:6.00417in"
|
|||
|
|
alt="1667819953050" />
|
|||
|
|
<figcaption><p>图6.4基础数据域库架构图</p></figcaption>
|
|||
|
|
</figure>
|
|||
|
|
|
|||
|
|
{width="5.781504811898513in"
|
|||
|
|
height="2.6021117672790903in"}
|
|||
|
|
|
|||
|
|
3. **调查成果域**
|
|||
|
|
|
|||
|
|
{width="5.7652777777777775in"
|
|||
|
|
height="2.9993055555555554in"}
|
|||
|
|
|
|||
|
|
<figure>
|
|||
|
|
<img src="media/image838.png" style="width:5.66667in;height:2.975in"
|
|||
|
|
alt="1667820114175" />
|
|||
|
|
<figcaption><p>图6.6调查成果域库架构图</p></figcaption>
|
|||
|
|
</figure>
|
|||
|
|
|
|||
|
|
4. **系统管理域**
|
|||
|
|
|
|||
|
|
<figure>
|
|||
|
|
<img src="media/image839.png" style="width:6.03819in;height:4.15833in"
|
|||
|
|
alt="1667820182301" />
|
|||
|
|
<figcaption><p>图6.7系统管理域库架构图</p></figcaption>
|
|||
|
|
</figure>
|
|||
|
|
|
|||
|
|
5. **预报域**
|
|||
|
|
|
|||
|
|
<figure>
|
|||
|
|
<img src="media/image840.png" style="width:6.0445in;height:3.61784in"
|
|||
|
|
alt="1667820228703" />
|
|||
|
|
<figcaption><p>图6.8预报域库架构图</p></figcaption>
|
|||
|
|
</figure>
|
|||
|
|
|
|||
|
|
6. **预警域**
|
|||
|
|
|
|||
|
|
<figure>
|
|||
|
|
<img src="media/image841.png" style="width:6.05903in;height:3.75833in"
|
|||
|
|
alt="1667820263981" />
|
|||
|
|
<figcaption><p>图6.9预警域库架构图</p></figcaption>
|
|||
|
|
</figure>
|
|||
|
|
|
|||
|
|
7. **预演域**
|
|||
|
|
|
|||
|
|
<figure>
|
|||
|
|
<img src="media/image842.png" style="width:6.22418in;height:3.0922in"
|
|||
|
|
alt="1667820324547" />
|
|||
|
|
<figcaption><p>图6.10预演域库架构图</p></figcaption>
|
|||
|
|
</figure>
|
|||
|
|
|
|||
|
|
8. **预案域**
|
|||
|
|
|
|||
|
|
<figure>
|
|||
|
|
<img src="media/image843.png" style="width:6.28656in;height:3.72801in"
|
|||
|
|
alt="1667820355541" />
|
|||
|
|
<figcaption><p>图6.11预案域库架构图</p></figcaption>
|
|||
|
|
</figure>
|
|||
|
|
|
|||
|
|
## 数据库访问优化设计
|
|||
|
|
|
|||
|
|
### 减少数据访问
|
|||
|
|
|
|||
|
|
1. **数据库索引**
|
|||
|
|
|
|||
|
|
在没有索引的世界中，对数据库的每个请求都将导致对整个表进行全面扫描，以查找相关的结果。索引会向数据库引擎提供有关系统中您要查找的数据的大致位置的信息。可用的索引有B-树（默认索引）、哈希、gist、spgist和gin。PostgreSQL将在创建主键或唯一键约束时创建隐式索引。主键及外键通常都要有索引，其它需要建索引的字段应满足以下条件：
|
|||
|
|
|
|||
|
|
1）字段出现在查询条件中，并且查询条件可以使用索引；
|
|||
|
|
|
|||
|
|
2）语句执行频率高，一天会有几千次以上；
|
|||
|
|
|
|||
|
|
3）通过字段条件可筛选的记录集很小，那数据筛选比例是多少才适合？
|
|||
|
|
|
|||
|
|
这个没有固定值，需要根据表数据量来评估，以下是经验公式，可用于快速评估：
|
|||
|
|
|
|||
|
|
小表(记录数小于10000行的表)：筛选比例\<10%；
|
|||
|
|
|
|||
|
|
大表：(筛选返回记录数)\<(表总记录数\*单条记录长度)/10000/16；
|
|||
|
|
|
|||
|
|
单条记录长度≈字段平均内容长度之和+字段数\*2。
|
|||
|
|
|
|||
|
|
2. **只访问索引数据**
|
|||
|
|
|
|||
|
|
有时只是访问表中的几个字段，并且字段内容较少，可以为这几个字段单独建立一个组合索引，这样就可以直接只通过访问索引就能得到数据，一般索引占用的磁盘空间比表小很多，所以这种方式可以大大减少磁盘IO开销。
|
|||
|
|
|
|||
|
|
在实际数据库中我们不可能把每个SQL请求的字段都建在索引里，所以这种只通过索引访问数据的方法一般只用于核心应用，也就是那种对核心表访问量最高且查询字段数据量很少的查询。
|
|||
|
|
|
|||
|
|
3. **优化sql执行计划**
|
|||
|
|
|
|||
|
|
执行计划是SQL在数据库中执行情况的客观反映，也是SQL性能分析和优化的参考。当一条SQL下发到数据库的时候，怎么扫描表、怎样使用索引这些行为对用户来说是不知道的，能够明显感受到的是查询的时间。而执行计划可以提前预估SQL究竟需要运行多长时间、查询中需要涉及到哪些表、走了哪些索引，这些通过优化器经过基于成本和规则的优化后生成的执行计划能够用来进行性能分析和优化。我们在查询sql语句前，添加explain关键字，数据库会在查询上设置一个标记，执行查询时，会返回执行计划的信息，而不是执行这一条sql语句。研发人员可通过执行计划优化SQL执行速度。
|
|||
|
|
|
|||
|
|
4. **慢查询日志分析**
|
|||
|
|
|
|||
|
|
假设您有一个正在运行的数据库，并且希望调试应用程序中的缓慢性能。一种方法是通过日志来实现。日志是应用程序在执行操作时留下的简短信息语句。然后，您可以收集这些操作，并在日志管理工具（如retrace）中对它们进行分析，以了解系统的行为。默认情况下，应用程序不会记录所有数据。这是因为日志记录的增加也会影响数据库性能。因此，在我们介绍如何更改日志设置以分析性能时，请记住日志设置本身实际上会影响性能。日志会发送到系统中的一个文件，具体取决于您的配置。当您找到日志所在的位置时，您可以使用诸如retrace之类的工具来分析这些日志。RETRACE将告诉您一些统计信息，例如最频繁运行的查询、查询平均花费的时间等。这些聚合度量可以让您更好地了解系统中哪些地方可能存在性能瓶颈。通过分析获得执行速度慢的SQL，可优化SQL执行速度。
|
|||
|
|
|
|||
|
|
### 返回更少数据
|
|||
|
|
|
|||
|
|
1. **数据分页处理**
|
|||
|
|
|
|||
|
|
对数据库中数据查询采用SQL分页查询，避免一次性查询数据量过大数据，减少数据交互大小，优化数据查询速度。
|
|||
|
|
|
|||
|
|
2. **只返回需要的字段**
|
|||
|
|
|
|||
|
|
查询SQL语句去除不必要字段提高查询性能。减少数据在网络上传输开销；减少服务器数据处理开销；减少客户端内存占用；如果访问的所有字段刚好在一个索引里面，则可以使用纯索引访问提高性能。
|
|||
|
|
|
|||
|
|
### 减少交互次数
|
|||
|
|
|
|||
|
|
1. **bacthDML**
|
|||
|
|
|
|||
|
|
通过使用数据库提供批量操作，减少对数据库的查询次数，即减少对系统资源的请求，减少了多次发起的网络延时开销，同时也会降低数据库的CPU开销。
|
|||
|
|
|
|||
|
|
2. **操作符优化**
|
|||
|
|
|
|||
|
|
使用EXISTS、NOTIN、IN等操作符优化SQL语句，减少数据交互次数，减少网络延时开销。
|
|||
|
|
|