数据库选型，物联网时代的数据库如何选型
大家好，数据库选型相信很多的网友都不是很明白，包括物联网时代的数据库如何选型也是一样，不过没有关系，接下来就来为大家分享关于数据库选型和物联网时代的数据库如何选型的一些知识点，大家可以关注收藏，免得下次来找不到哦，下面我们开始吧！
数据库的种类有哪些
很长时间以来，关系型数据库一直是大公司的专利，市场被Oracle/DB2等企业数据库牢牢把持。但是随着互联网的崛起、开源社区的发展，上世纪九十年代MySQL1.0的发布，标志着关系型数据库的领域社区终于有可选择的方案。
MySQL
第一个介绍的单机RDBMS就是MySQL。相信大多数朋友都已经对MySQL非常熟悉，基本上MySQL的成长史就是互联网的成长史。我接触的第一个MySQL版本是MySQL4.0，到后来的MySQL5.5更是经典——基本所有的互联网公司都在使用。MySQL也普及了「可插拔」引擎这一概念，针对不同的业务场景选用不同的存储引擎是MySQLtuning的一个重要的方式。比如对于有事务需求的场景使用InnoDB;对于并发读取的场景MyISAM可能比较合适;但是现在我推荐绝大多数情况还是使用InnoDB，毕竟5.6后已经成为了官方的默认引擎。大多数朋友都基本知道什么场景适用MySQL(几乎所有需要持久化结构化数据的场景)，我就不赘述了。
另外值得一提的是MySQL5.6中引入了多线程复制和GTID，使得故障恢复和主从的运维变得比较方便。另外，5.7(目前处于GA版本)是MySQL的一个重大更新，主要是读写性能和复制性能上有了长足的进步(在5.6版本中实现了SCHEMA级别的并行复制，不过意义不大，倒是MariaDB的多线程并行复制大放异彩，有不少人因为这个特性选择MariaDB。MySQL5.7MTS支持两种模式，一种是和5.6一样，另一种则是基于binloggroupcommit实现的多线程复制，也就是MASTER上同时提交的binlog在SLE端也可以同时被apply，实现并行复制)。如果有单机数据库技术选型的朋友，基本上只需要考虑5.7或者MariaDB就好了，而且5.6、5.7由Oracle接手后，性能和稳定性上都有了明显的提升。
PostgreSQL
PostgreSQL的历史也非常悠久，其前身是UCB的Ingres，主持这个项目的MichaelStronebraker于2023年获得图灵奖。后来项目更名为Post-Ingres，项目基于BSDlicense下开源。1995年几个UCB的学生为Post-Ingres开发了SQL的接口，正式发布了PostgreSQL95，随后一步步在开源社区中成长起来。和MySQL一样，PostgreSQL也是一个单机的关系型数据库，但是与MySQL方便用户过度扩展的SQL文法不一样的是，PostgreSQL的SQL支持非常强大，不管是内置类型、JSON支持、GIS类型以及对于复杂查询的支持，PL/SQL等都比MySQL强大得多，而且从代码质量上来看，PostgreSQL的代码质量是优于MySQL的，另外相对于MySQL5.7以前的版本，PostgreSQL的SQL优化器比MySQL强大很多，几乎所有稍微复杂的查询PostgreSQL的表现都优于MySQL。
从近几年的趋势上来看，PostgreSQL的势头也很强劲，我认为PostgreSQL的不足之处在于没有MySQL那样强大的社区和群众基础。MySQL经过那么多年的发展，积累了很多的运维工具和最佳实践，但是PostgreSQL作为后起之秀，拥有更优秀的设计和更丰富的功能。电脑培训发现PostgreSQL9以后的版本也足够稳定，在做新项目技术选型的时候，是一个很好的选择。另外也有很多新的数据库项目是基于PostgreSQL源码的基础上进行二次开发，比如Greenplum等。
物联网时代的数据库如何选型
物联网时代，大量的数据从不同的设备传感器产生，单机数据库系统肯定无法存储这么大量的数据，在选择数据库方面，肯定要选择具有分布式能力存储的数据库。
在物联网时代，数据之间还有一个非常重要的特性，那就是数据之间的关联性。不同的数据从相互连接的互联网设备传感器中产生，由于不同的传感器相互连接，协同工作和采集数据，如何将大量具有相互关联的数据保存在数据库，这里我推荐使用图数据库来进行存储。
图数据库相对于其他数据库来说，最大的优势就是查询数据之间的关联性会更加快速，消耗的时间会更短。打个比方，在社交网络中，我们想要查询在用户A的粉丝中，粉丝关注了B的用户。如果使用传统关系型数据库来存储用户的关注关系，在上面的数据统计中，要使用两层Join才能算出结果，而关系型数据库Join操作会很慢。使用图型数据库存储数据的话，图中的点为用户，边为用户的关注关系，在查询A的粉丝，同时粉丝也关注B的用户，只需要遍历两层关注关系就能很快查询到结果。
图数据库也属于NoSql数据库的一种，常用的图形数据库有，JanusGraph、Neo4j、Cayley、dgraph。不同的图数据库，底层实现也不尽相同。
JanusGraph是一种分布式图数据库，由Java语言开发，可以使用Hadoop生态存储系统作为数据源，构建出数据大图。是TiTan图数据库的开源版本，支持事务的ACID。
Neo4j是一种单机的图数据库，其优势就是能够快速安装并且使用，便于新同学上手。你的数据量一般不大的话，我推荐使用Neo4j，直接使用Neo4j相关的API就可以将数据模型图构建而出，然后使用Neo4jCypher查询语言，就可以分析数据，Cypher是一种类SQL的语言。
Cayley和Dgraph都是使用Go语言实现的图数据库，Go语言的最大特性就是其编译速度和开发便捷性，Cayley和Dgraph都支持分布式存储，不过都不支持SQL语言查询数据，Dgraph不支持事务，而Cayley支持事务，不过在开源社区，Dgraph比Cayley更加活跃，这里优先建议使用Dgraph作为物联网的存储数据库。
总体来说，在物联网时代，一定要学会使用图数据库，在分析大量数据之间的关联性时，图数据库就能够派上用场，图数据库最大的优势就是分析不同数据之间的关联性。
数据库架构选型与落地,看这篇就够了
随着时间和业务的发展，数据库中的数据量增长是不可控的，库和表中的数据会越来越大，随之带来的是更高的磁盘、 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：架构师。
交个朋友，一起成长！
关于数据库选型到此分享完毕，希望能帮助到您。