数据库学习

数据库

数据库选择

• 用于具有结构化数据的事务用例的RDBMS

关系型数据库

列式存储是一个内部概念，用于提高RDBMS的OLAP工作负载的性能，并且不是一个记录接着一个记录地存储表的数据，而是一个列接着一个列。

因为它们可以一次性地被读取出来，而不是先对整行进行读取后再丢弃掉不需要的列。面向列的存储非常适合计算聚合的分析型工作负载。

在一次读取中，从同一列中读取多个值可以显著提高缓存利用率和计算效率。在现代CPU上，向量化指令可以使单条CPU指令一次处理多个数据点。

将具有相同数据类型的值存储在一起（例如，数字与数字在一起，字符串与字符串在一起）可以提高压缩率。我们可以根据不同的数据类型使用不同的压缩算法，并为每种情况选择最有效的压缩方法。

如果所读取的记录中的大多数或所有列都是需要的，并且工作负载主要由单条记录查询和范围扫描组成，则面向行的存储布局可能产生更好的结果。如果扫描跨越多行，或者在列的子集上进行计算聚合，则值得考虑使用面向列的存储布局。

• 用于低延迟分布式数据库的宽列数据库

面向列的数据库不应与宽列式存储（如BigTable或HBase）相混淆。在这些数据库中，数据表示为多维映射，列被分组为列族（通常存储相同类型的数据），并且在每个列族中，数据被逐行存储。此布局最适合存储由一个键或一组键来检索的数据。

宽列存储数据库 (Wide-Column Database)，也称作可扩展记录存储 (Extensible record Stores) 是一种兼具了广泛的可使用性、可拓展性、高性能和高可用性的分布式 NoSQL 数据库。

最容易出现混淆的地方是，数据在表面上最初是由行进行排列的，表的主要键是行键。但是与关系型数据库不同，在列式数据库中，没两个行需要相同的列。正如上面所说的那样，在表被创建后，用户能够快速在行中加入列。实际上，你能够向一行中增加许多列。虽然最高上限值难以被准确地计算出来，但是用户几乎不可能达到这样的上限，即便他们加入大量列的情况下也是如此。

https://www.jianshu.com/p/1b692482e25c

• 分布式缓存的键值存储

  键值存储，即Key-Value存储，简称KV存储。它是NoSQL存储的一种方式。它的数据按照键值对的形式进行组织，索引和存储。KV存储非常适合不涉及过多数据关系业务关系的业务数据，同时能有效减少读写磁盘的次数，比SQL数据库存储拥有更好的读写性能。

  对数据库高并发读写的需求；

  对海量数据的高效率存储和访问的需求；

  对数据库的高可扩展性和高可用性的需求

• 极端关系数据的图形数据库

  一种专用于创建和处理图形的专业化单一用途平台。其中，图形包括节点、边和属性，它们能够以关系数据库无法实现的方式来表示和存储数据。

  属性图用于对数据之间的关系进行建模，能够基于这些关系进行查询和数据分析。属性图具有顶点（包含有关主题的详细信息）和边（表示顶点之间的关系）。顶点和边可以具有相关联的属性。

• 用于全文和高级搜索的搜索引擎（例如，基于位置的搜索）

  搜索引擎这个词，大家一定不陌生。百度，必应，或是谷歌.

  搜索引擎将结果递交给我们。那么，结果从哪里来？

  当然，它可以根据我们输入的搜索词，借助爬虫技术从互联网获取数据，然后将结果交给我们。但如果真是这样，当我们输入完搜索内容并按下回车，可能要去泡一碗葛粉细细品味后，才能得到搜索结果。

  因此，搜索引擎需要将互联网上的大量数据存储在本地，并根据我们的输入内容从中寻找内容，并呈现过我们。

  这些数据从哪里来？还是需要爬虫。只不过，爬虫本身和搜索过程是分离的。爬虫爬取到互联网上的大量数据，通过一些流程处理成可以供搜索引擎读取的数据。之后，每当我们按下回车，搜索引擎从处理过的数据里寻找我们需要的内容，并呈现。

  比如：Elasticsearch 是一个功能强大的搜索引擎，支持地理查询，但并不是每个人都习惯于处理空间数据。

• 用于具有事务保证的低延迟分布式数据库的分布式 SQL

  分布式SQL数据库的定义特征是整个数据库集群（无论其中的节点数如何）对于应用程序都将其视为单个逻辑SQL数据库。

  

  https://zhuanlan.zhihu.com/p/97940104

• 用于数据仓库和分析的OLAP 数据库

OLAP(On-Line Analytical Processing) :联机分析系统

主要目标是做数据分析。数据仓库是OLAP系统的一个典型示例，主要用于数据分析

https://blog.csdn.net/qq_41769397/article/details/131680900

对比HBase、Cassandra和MongoDB

(189条消息) 三大NoSQL数据库HBase、Cassandra和MongoDB大比拼_cassandra hbase mongodb_DemonHunter211的博客-CSDN博客

对比mongodb和MySQL

mongodb三高：

• 高并发读写
• 对海量数据高效存储和访问
• 高可扩展性和高可用性

具体应用场景：

• 社交场景，存储用户信息，朋友圈地理位置等（海量数据）
• 游戏场景，需要响应速度快，方便查询，高效存储和访问
• 物流场景，订单状态不断更新。已mongodb内嵌数组形式存储，一次查询就能将订单所有变更读取出来（高并发读写）
• 物联网场景，使用mongodb接入智能设备，存信息及设备日常日志信息，并对信息进行多维度分析
• 视频直播，存用户信息，点赞互动等信息（高并发读写，海量数据高效存储访问）

应用场景共同点：

1. 数据量大
2. 读写频繁
3. 价值较低，对事务要求性不高和不需要复杂的join查询

这样的数据适合用mongodb存储

相对于MySQL可以更低成本（学习，开发，运维），MySQL也可以实现，但是需要非常好的优化，mongodb操作简单

事务

1. @Transaction用在非public上时不生效
2. @Transaction用同一个类上调用不生效

比如一个service类中包含methodA方法和methodB方法，methodA调用了methodB方法，这个时候methodB方法上就算添加了事务注解也没用，因为Spring AOP代理造成的，因为只有当事务方法被当前类以外的代码调用时，才会由Spring生成的代理对象来管理，而调用同一个类中的方法是使用的this指针调用，this是原有对象，所以事务会失效。通用的解决方案是分裂编写，将methodB抽离至其他类，然后注入调用。

因为@Transaction事务的传播性，在A上加注解是有效的，不过要这样用

@Transactional(rollbackFor = Exception.class)

在@Transactional注解中如果不配置rollbackFor属性,那么事物只会在遇到RuntimeException的时候才会回滚,加上rollbackFor=Exception.class,可以让事物在遇到非运行时异常时也回滚

collate

项目遇到的问题
不同表同一字段，创建的数据库表指定字符串排序规则为
utf8mb4_general_ci和utf8mb4_unicode_ci两种，导致关联无法比较

【charset不同实际问题：慢SQL，查询速度巨慢！！】

【collate不同实际问题：无法关联，报错！！】

– 错误 SELECT a.mobile from play a INNER JOIN user_t b ON a.mobile = b.mobile

–正确 SELECT a.mobile from play a INNER JOIN user_t b ON a.mobile = b.mobile COLLATE utf8mb4_general_ci [显示转为与a的collate规则一致！]

注意：一般情况下同数据库中表的字段排序类型都是相同的！，除非开发者不小心导致

数据库锁等待

show processlist;
select * from information_schema.innodb_trx;
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;

SQL 多条件批量查询

想批量按照条件查询，首先想到的都是用in，上面也说了，in只能按照一个条件批量查询。想要使用两个条件批量查询。可以拼接条件和字段，SQL如下：

select * from tableA where CONCAT(code,number) in  ('3249sdf0232340dfssdf34','3249sdf0242340dfssdf35',……);

在代码中遍历条件，将code和number拼接起来，然后在传给SQL的in条件里面，就完美解决了。不知道这样处理会不会有什么隐患，或者对性能有什么影响，这样应该索引没法使用了。不过相较于循环查询，即便这样索引失效，效率也更高
ber拼接起来，然后在传给SQL的in条件里面，就完美解决了。不知道这样处理会不会有什么隐患，或者对性能有什么影响，这样应该索引没法使用了。不过相较于循环查询，即便这样索引失效，效率也更高