Neo4j是一款高性能的图数据库，它采用了图形数据模型来存储和处理数据。与传统的关系型数据库相比，Neo4j具有更高的可扩展性和更高效的查询性能，特别适用于需要处理复杂关系数据的应用场景。 Neo4j Graph Database & Analytics – The Leader in Graph DatabasesConnect data as it’s stored with Neo4j. Perform powerful, complex queries at scale and speed with our graph data platform.Graph Database & Analytics Neo4j的收费模式分为两种：开源版和企业版。开源版是免费的，可以用于个人或小型项目。企业版则需要付费，提供更多高级功能和技术支持。 Neo4j的主要功能包括： 图形数据存储和查询：Neo4j使用图形数据模型来存储数据，可以轻松处理复杂的关系数据。 高效的查询性能：由于采用了图形数据模型，Neo4j可以轻松地处理深度查询和复杂的关系查询，

按照数据模型分类： * 关系型数据库（RDBMS）：以表格形式存储数据，使用 SQL 语言进行查询和操作。 * 非关系型数据库（NoSQL）：不使用传统的关系型数据模型，而是采用其他数据模型，如文档型、键值对、列式、图形等。 按照数据处理方式分类： * 事务型数据库：支持事务处理和 ACID 特性（原子性、一致性、隔离性、持久性）。 * 非事务型数据库：不支持事务处理和 ACID 特性，但具有更高的性能和可扩展性。 按照部署方式分类： * 单机数据库：数据存储在单台计算机上，适用于小型应用。 * 分布式数据库：数据存储在多台计算机上，通过网络进行通信和协作，适用于大型应用和高并发场景。 按照使用范围分类： * 个人数据库：适用于个人使用或小型团队。 * 企业数据库：适用于企业级应用，需要支持高并发、高可用、高安全等需求。 按照数据存储方式分类： * 内存数据库：数据存储在内存中，查询和操作速度非常快，但数据容量受限。

MySQL的DATETIME类型是精确到秒的，而Java的LocalDateTime类型是精确到纳秒的。因此，在将MySQL的DATETIME类型存入Java的LocalDateTime类型时，会发生四舍五入的情况。 例如，如果MySQL的DATETIME类型为2022-01-01 12:34:56.789，当它被存入Java的LocalDateTime类型时，会被四舍五入到2022-01-01 12:34:57。 为了避免这种情况，可以使用Java的java.sql.Timestamp类型来存储MySQL的DATETIME类型。这个类型也是精确到纳秒的，与LocalDateTime类型匹配，不会出现四舍五入的问题。

BufferPool官方文档： MySQL :: MySQL 8.0 Reference Manual :: 15.5.1 Buffer Pool 在InnoDB存储引擎中，为了提高MySQL服务性能，减少磁盘IO次数，故此所有的DML操作均是在内存中的 BufferPool 中完成。最后通过服务的异步刷盘策略把修改数据落盘到磁盘中。 为什么需要设计 BufferPool ？这里我想一般有计算机基础知识的人都知道，内存和硬盘的效率是天差地别的，对于CPU来说硬盘的传输以及响应时间性能太低下，故此 MySQL 设计出了 BufferPool 来映射磁盘中的真实数据，并在内存中进行数据的管理与操作，这样执行DML语句的效率不就起飞了吗？至于是如何保障内存中的 BufferPool 数据在宕机，掉电的场景不会出现丢失（物理打击除外😃，大力出奇迹，硬盘都给你扬了），之前我的文章中也有所讲解： MySQL 执行链路当客户端SQL语句提交给 MySQL 服务器时首先需要建立连接，连接器会与客户端进行连接，并校验用户身份信息，权限信息，如果权限通过，则通过SQL分析器对SQL语句进行语义分

当客户端SQL语句提交给 MySQL 服务器时首先需要建立连接，连接器会与客户端进行连接，并校验用户身份信息，权限信息，如果权限通过，则通过SQL分析器对SQL语句进行语义分析（检查SQL语句是否合法，能否解析通过），分析完成后将会对SQL的执行过程进行优化，例如剔除不必要的查询条件 1=1 ，以及选择最优的索引与Where条件的字段排序。 然后交给执行器执行此SQL语句，执行器将会根据数据库所使用的存储引擎执行SQL。MySQL在设计时是分为了两层，即Server层和存储引擎层。这样做的好处就是解藕，可以根据不同的数据库去选择合适的存储引擎。 常用的InnoDB存储引擎是以页（16KB）为单位来管理存储空间的，任何的增删改差操作最终都会操作完整的一个页，会将整个页加载到 BufferPool 中并且所有的数据操作都是在 BufferPool 中完成，BufferPool 通常设置为服务器60%-70%左右的内存占用，这样数据的操作直接在内存中执行，从而提高数据操作的效率（如果每一条DML语句都要进行 IO 操作那么数据库的磁盘很容易变成瓶颈，改一条数据需要先从磁盘中读取，然后刷盘

在企业应用程序开发中，我们生产环境会不止一台存储节点，特别是在微服务领域中，我们会设计每个业务Service模块都会对应一个自身业务模块的DB存储节点。然后再对这个DB存储节点做高可用部署，如主从同步，半同步，异步复制+主从切换这些方案，并且后续当数据库数据体积越来越庞大时，便要继续对存储节点做垂直或水平拆分。 那么我们在编写Service中的业务逻辑时，肯定会遇到一个业务操作会调用到其他不同的业务模块，那么对应的产生数据就会落盘到不同的存储节点中，为了保障多个数据库实例之间的事物ACID特性，故此我们肯定需要通过一些手段来保障两个不同的数据库存储节点对这个业务开启的事物作出相同的操作，达到以下效果： 1、如果整个业务调用链路均成功，那么所有对应的数据库做事物提交。 2、如果调用链路中抛出了异常，那么所有对应的数据库做回滚操作。 为了到达这个目的，故此出现了Seata： 在这些分布式事务解决方案中，一般有以下这些角色： RM (Resource Manager) 管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。 TC (Tr

HBase全称：Hadoop Database。 HBase是一种高可靠性，高性能，面向列的可扩展分布式存储系统，使用HBase技术在廉价的PC服务器上构建大规模结构化存储集群。 HBase的目标是存储和处理大量数据，特别是仅使用标准硬件配置即可处理包含数千行和列的大量数据，可处理PB级别数据存储，亿级QPS查询。 它适用于实时性要求不高的业务场景，HBase存储Byte数组，该数组不介意数据类型，从而允许动态，灵活的数据模型。 架构解析： HBase由HMaster和HRegionServer组成，并且遵循主从服务器体系结构。 HBase将逻辑表分为多个数据块HRegion，并将它们存储在HRegionServer中。 HMaster负责管理所有HRegionServer。 它本身不存储任何数据，而仅存储数据到HRegionServer的映射(元数据)。 群集中的所有节点均由Zookeeper协调，并处理HBase操作期间可能遇到的各种问题。 HBase的基本架构如下所示： 客户端：使用HBase的RPC机制与HMaster和HRegionServer通信，提交请求并获得