具体的数据库设计与实现过程

大致的讲主要是根据用户的需求，然后设计数据库的E-R模型，然后将E-R模型图转换为各种表，并对其进行数据库设计范式（范式因不同书籍有不同）的审核，然后进行数据库的实施，然后运行维护。

一句话来讲就是将用户的需求变成带有各种关系的表，以及其它的数据库结构，然后供编程使用

具体如下：

按照规范设计的方法，考虑数据库及其应用系统开发全过程，将数据库设计分为以下六个阶段

（1）需求分析。

（2）概念设计。

（3）逻辑设计。

（4）物理设计。

（5）数据库实施。

（6）数据库运行和维护。

5．1．1需求分析阶段

进行数据库设计首先必须准确了解与分析用户需求，包括数据与处理需求。需求分析是整个设计过程的基础，是最困难、最耗时的一步。作为“地基”的需求分析是否做得充分与准确，决定了在其上构建“数据库大厦”的速度与质量。需求分析做得不好，可能会导致整个数据库重新设计，因此，务必引起高度重视。

5．1．2概念模型设计阶段

在概念设计阶段，设计人员仅从用户角度看待数据及其处理要求和约束，产生一个反映用户观点的概念模式，也称为“组织模式”。概念模式能充分反映现实世界中实体间的联系，又是各种基本数据模型的共同基础，易于向关系模型转换。这样做有以下好处：

（1）数据库设计各阶段的任务相对单一化，设计复杂程度得到降低，便于组织管理。

（2）概念模式不受特定DBMS的限制，也独立于存储安排，因而比逻辑设计得到的模式更为稳定。

（3）概念模式不含具体的DBMS所附加的技术细节，更容易为用户所理解，因而能准确地反映用户的信息需求。

概念模型设计是整个数据库设计的关键，它通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型。如采用基于E-R模型的数据库设计方法，该阶段即将所设计的对象抽象出E-R模型；如采用用户视图法，则应设计出不同的用户视图。

5．1．3逻辑模型设计阶段

逻辑模型设计阶段的任务是将概念模型设计阶段得到的基本E-R图，转换为与选用的DBMS产品所支持的数据模型相符合的逻辑结构。如采用基于E-R模型的数据库设计方法，该阶段就是将所设计的E-R模型转换为某个DBMS所支持的数据模型；如采用用户视图法，则应进行表的规范化，列出所有的关键字以及用数据结构图描述表集合中的约束与联系，汇总各用户视图的设计结果，将所有的用户视图合成一个复杂的数据库系统。

5．1．4数据库物理设计阶段

数据库的物理结构主要指数据库的存储记录格式、存储记录安排和存取方法。显然，数据库的物理设计完全依赖于给定的硬件环境和数据库产品。在关系模型系统中，物理设计比较简单一些，因为文件形式是单记录类型文件，仅包含索引机制、空间大小、块的大小等内容。

物理设计可分五步完成，前三步涉及到物理结构设计，后两步涉及到约束和具体的程序设计：

（1）存储记录结构设计：包括记录的组成、数据项的类型、长度，以及逻辑记录到存储记录的映射。

（2）确定数据存放位置：可以把经常同时被访问的数据组合在一起，“记录聚簇（cluster）”技术能满足这个要求。

（3）存取方法的设计：存取路径分为主存取路径及辅存取路径，前者用于主键检索，后者用于辅助键检索。

（4）完整性和安全性考虑：设计者应在完整性、安全性、有效性和效率方面进行分析，作出权衡。

（5）程序设计：在逻辑数据库结构确定后，应用程序设计就应当随之开始。物理数据独立性的目的是消除由于物理结构的改变而引起对应用程序的修改。当物理独立性未得到保证时，可能会引发对程序的修改。

数据库物理设计是为逻辑数据模型选取一个最适合应用环境的物理结构，包括存储结构和存取方法。

5．1．5数据库实施阶段

根据逻辑设计和物理设计的结果，在计算机系统上建立起实际数据库结构、装入数据、测试和试运行的过程称为数据库的实施阶段。实施阶段主要有三项工作。

（1）建立实际数据库结构。对描述逻辑设计和物理设计结果的程序即“源模式”，经DBMS编译成目标模式并执行后，便建立了实际的数据库结构。

（2）装入试验数据对应用程序进行调试。试验数据可以是实际数据，也可由手工生成或用随机数发生器生成。应使测试数据尽可能覆盖现实世界的各种情况。

（3）装入实际数据，进入试运行状态。测量系统的性能指标，是否符合设计目标。如果不符，则返回到前面，修改数据库的物理模型设计甚至逻辑模型设计。

5．1．6数据库运行和维护阶段

数据库系统正式运行，标志着数据库设计与应用开发工作的结束和维护阶段的开始。运行维护阶段的主要任务有四项：

（1）维护数据库的安全性与完整性：检查系统安全性是否受到侵犯，及时调整授权和密码，实施系统转储与备份，发生故障后及时恢复。

（2）监测并改善数据库运行性能：对数据库的存储空间状况及响应时间进行分析评价，结合用户反应确定改进措施。

（3）根据用户要求对数据库现有功能进行扩充。

（4）及时改正运行中发现的系统错误。

数据库系统（database

system），是由数据库及其管理软件组成的系统。

一个完整的数据库系统包括

1

计算机硬件

计算机硬件是数据库系统的物质基础，是存储数据库及运行数据库管理系统的硬件资源，主要包括主机、存储设备、输入输出设备以及计算一个完整的数据库系统包括哪些部分？

随着时间和业务的发展，数据库中的数据量增长是不可控的，库和表中的数据会越来越大，随之带来的是更高的 磁盘 、 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、把不同类型的分成几个表，纵向切分

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点看你的需求，我个人是不建议的。打了半个多小时想是在写论文，希望对你有帮助。

负责设计大数据系统的底层架构。大数据底层设计师负责设计和优化大数据系统的底层架构，包括数据存储、数据管理、数据分析和处理等方面。他们需要对分布式计算、并行处理、数据库技术、数据挖掘等技术有深入的了解，并根据需求和性能要求，设计出适合的底层架构。大数据底层设计师还需要与大数据开发工程师、数据科学家等团队密切合作，确保整个大数据系统的可靠性、可扩展性和性能表现。

我虽然没参与过微博底层的开发，如果是我设计这个数据库的话我会用2张表解决这个问题

第一张表 用户信息表， 主要依靠ID主键识别用户

第二张表，关系表， 关键col3列 前两列 分别是 好友源 和 好友目标 ,第三列是 关系状态

然后加了好友 只要不断地 在第二张表加入 新行 比如

用户A，用户C ，好友

用户A，用户B ,黑名单

用户B,用户A, 好友

如果是QQ这类 检索关系时候 0， 1字段一起搜索ID 就是互为好友

微博这种 就是单向的 关注。

大概就是这样的模型

可能的问题是用户过多时候表2可能会非常巨大。检索速度可能会受影响

用资源换效率的方式

还可以每个用户一张表

以上就是关于具体的数据库设计与实现过程全部的内容，包括:具体的数据库设计与实现过程、如何设计一个完整的数据库系统、数据库架构选型与落地，看这篇就够了等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！