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

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

交个朋友，一起成长！

1.数据量太大，比如上亿，就用oracle，优点上亿数据对Oracle来说轻飘飘的，也不用太多优化配置，缺点安装比较麻烦，上手比较慢。

2.数据量较大，比如千万级，用postgresql，它号称对标Oracle，处理千万级数据还是可以的，也是易学易用。

3.数据量一般，比如百万级，用mysql，这个级别的数据量mysql处理还是比较快的。

4.数据量较小，比如十万以下，sqlite、access都可以。

上面是基于单表 *** 作的数据量，你看着选。

简单易用的数据库哪个比较好？这个要具体看你的用途，如果数据量比较少（10万左右），追求简约简单，免费开源的sqlite就行，如果数据量比较多，考虑到高并发、分布式，可以使用专业的mysql、postgresql，下面我分别简单介绍一下，感兴趣的朋友可以尝试一下：

小巧灵活sqlite

这是基于c语言开发的一个轻量级关系型数据库，短小精悍、免费开源，个人使用无需繁琐的配置，只需一个简单的运行库便可直接使用，针对各种编程语言都提供了丰富的API接口， java、 python、c#等都可轻松 *** 作，如果你存储数据量不多，只是本地简单的 *** 作（读多写少），可以使用一下这个数据库，占用内存非常少，轻便灵活，当然，在高并发、数据量大的情况下就不合适了：

专业强大mysql

这是目前应该广泛使用的一个关系型数据库，免费开源跨平台，在信息系统开发方面一直占据着主力位置，如果你从事于web开发或者网站后台建设，那么这个数据库一定非常熟悉，支持高并发、分布式，存储数据量相对于sqlite来说，更多也更安全，索引、触发器、存储过程等功能非常不错，支持数据导入导出、恢复备份，只要你熟悉一下基本使用过程，很快就能掌握和运用：

免费开源postgresql

这是加州大学计算机系开发的一个对象-关系型数据库（自由软件），免费、开源、跨平台，支持流计算、全文检索、图式搜索、并行计算、存储过程、空间数据、K-V类型，相比较mysql来说，在复杂查询、高并发下更稳定、性能更优越，可扩展性、可维护性非常不错，但也有劣势，例如新旧版本不分离存储，没有Coverage index scan等，总体使用效果来说还不错：

当然，除了以上3个数据库，还有许多其他数据库，像mssql、oracle等也都非常不错，对于存储和处理数据来说绰绰有余，只要你熟悉一下基本使用过程，很快就能入门的，网上也有相关教程和资料，介绍的非常详细，感兴趣的话，可以搜一下，希望以上分享的内容能对你有所帮助吧，也欢迎大家评论、留言进行补充。

最符合初学者理解和入门的是Access，因为它和Excel本来就是一个套件，相互转化容易，复制粘贴即可，非常好理解库、表、字段、键的概念。

如果数据量不大，强烈推荐试试Filemaker，脚本化编程，自由定制输入界面、工作流程，非常便捷高效。

最近杀出来的airtable，更是简单高效，界面美观， *** 作与电子表格相当，发展势头也非常迅猛。

二者侧重点有所不同，用户可根据需要选择

作为一个软件开发人员，长期需要和数据库打交道，个人更加青睐于MySQL。虽然可能基于你的Excel原因，有些人会建议你使用Access数据库，但是基于我个人的 意见，我并不建议你那样做。采用MySql的具体理由如下：

1.MySQL具有普遍性，在国内的环境中，绝大多数的互联网企业采用的是MySQL。有了广大的用户基础后，针对于各种问题网上也能更好地找到解决方案。

2.MySQL相对于Oracle而言，更加轻量化，针对于从Excel量级的数据，没必要使用Oracle。同时MySQL是完全免费的，不用担心版权及费用问题，无论对个人还是对预算有限的企业而言都是很好的选择。

3.MySQL高度兼容标准SQL，这对于以后迁移到其他数据库而言，也能很大程度地降低学习成本。

希望我的回答能够对你有所帮助！！！[耶][耶][耶]

Excel办公确实便利，可以做一些简单的数据分析，但涉及大量复杂的数据运算，就会遇到和题主一样的问题，运算速度慢，如果主机性能不是很好，还有可能面临电脑死机，数据丢失等问题。

遇到这种情况，我们该如何解决呢？数据库的重要性显而易见！

现在， 我将用3分钟的时间，与您探讨该选择何种数据库，以及选择它的理由，是否有更优的解决方案呢？

MySQL数据库，90%的企业都会选择它

数据库选得好，企业的数据安全，资产安全，也就得到了保障。那么该如何选择数据库呢？这个跟你的业务量和业务服务行业，密不可分。

如果你只是上班打卡，用SQL server就可以了；

如果你要储存会话信息，用户配置信息，购物车数据，建议使用NoSQL数据库；

不过90%的企业或个人，首选数据库都是MySQL数据库。

为什么这么说？

因为，它集 低成本、高可用、可靠性强、易用性强、体积小、速度快开放源码 等特性于一身，所以在金融、财务、网站、 数据处理 等应用领域，它占据着独一无二的优势。

这也是几乎所有企业都选择它，来存储数据的原因。

加之MySQL数据库，支持多种存储引擎，支持大型数据库，可以处理成千上万条记录，还提供用于管理、检查、优化数据库 *** 作的工具。

因而，MySQL尤其受个人，以及中小企业的推崇。

虽然MySQL数据库简单易用，但我还是不会部署该怎么办？

别担心，现在市面上已经出现了，一种自带数据库的新型办公软件。

比如说，云表企业应用平台，一款兼容excel功能，但功能更为强大的办公软件，它就内嵌了MySQL数据库。 （文末有免费获取方式）

云表内嵌的MySQL数据库，有何优点？

1. 性能更加优化，更加兼容系统。因为云表的研发人员，时刻更新维护MySQL数据库。

2. 省去自己手动部署的麻烦。但如果你熟悉部署数据库，想把数据库改成Oracle或SQL server等数据库，也可以设置。（不过，我建议IT小白还是 “拿来即用” 就好）

3. 快速实时计算。数据分析实时交互，完全满足管理决策中的临时性分析，多变的业务需求，以及频繁的结果刷新。

4. 通过自带的内存计算引擎，无需事先建立CUBE，IT部门将告别报表延时报表分析，亿级数据秒级响应。

内嵌的MySQL数据库是否可靠

云表不仅是一款办公软件，同时还是一款开发工具。

通过它，你将解决以下问题：

复杂的数据运算，精确到行列的权限管控，以及工作流，海量用户同时在线办公，数据透视，制作像销售单，洽谈合同等表单报表，一份制作，即可重复录用......

你还可以通过它，与电子称、地磅等进行对接，与用友金蝶等三方系统集成，生成条形码，扫码出入库，生成移动端APP...... 基本上业务所需的功能，你都可以放心交给它做。

它最大的亮点就是，你可以 用使用excel的手法，用它来开发业务应用。

而且，可视化的 拖拉拽 之后，开发出来的ERP、WMS、OA、进销存等业务应用，还秉承了MySQL数据库增删改查的功能特性。

没错，用云表开发出来的业务应用，是允许二次开发的，而且功能可以随时增删改查，轻松满足大集团精细化的数据控制需求。

不过，大家最关心的应该是数据安全问题吧。

数据存放在云表内嵌的MySQL数据库，是安全不丢失的，它提供了多种数据存储的方式，本地部署，云端部署，混合部署，任君挑选！

正因如此，像 恒逸石化、许继电气、航天科工委、中铁、中冶、云南小松 等大型集团，才鼓励内部员工去学习云表。

篇幅所限，只说到这里，说太多你也不会看。

免费 的软获取方式在下方：

数据库的用处可大着呢，不仅可以实现数据共享，减少数据冗余度，还能实现对数据的集中控制，保持数据的一致性和可维护性。选取简单易用的数据库，你有什么好的建议呢，留言让我们看到噢！

题主强调了简单易用。所以推荐最简单三个。

1.Access。

2.Excel。

3.飞书文档、腾讯文档、石墨文档等的表格。

如果要做分析，数据量才比较大，建议Access，还是专业的更好一些。网上教程也很多，比较容易学。而且建议用早一点的版本，比如2003或者2007，Access这些年微软一直想从office里去掉，奈何用的人还是很多，所以不敢去掉，但是采取了一种比较恶心的方法让用户放弃，就是每发布一个新版本，就去掉一些好用的功能，所以说Access是越早的功能越强。

还一个推荐就是Sql Server Express版本，是SQL Server的免费版本，不要钱，基本功能都有，要比sqllite等强大的多

这要结合你个人实际情况来定，有计算机基础，懂一点数据库的话那么市场上的那些软件都可以用，常用有oracle，sqlserver，mysql等，要上手快还是sqlserver比较快，界面 *** 作也比较直观；如果一点基础都没有，但是又要分析数据的话可以用微软自带的一个access，这个上手比较快。决定用哪一种之后还是要买点教材看，简单的sql查询要会，熟练之后也能提高工作效率。

个人使用数据库的话，只存数据不做分析，SQLite就足够了。

数据库类型还是数据类型？

数据库类型直接innodb

数据类型则遵从以下规则：

整数：int

金额：decimal

日期：date

日期时间：datetime

可变长度字符：varchar；即不确定有多长

固定长度字符：char；即知道字符长度，比如md5（）32位

文章详情等：longtext

---