zoukankan      html  css  js  c++  java
  • 4.数据库mysql相关

    unity 协作fmod 设计游戏音乐音效。

    DFS一般指深度优先搜索

    SQL

    1. 非关系型数据库(NoSQL)去掉了关系型数据库中的关系特性,从而获得更好的扩展性。NoSQL并没有严格的存储方式,采用不同的存储结构是为了获得更高的性能和更高的并发。

    2. NoSQL根据存储方式可分为四大类,键值存储数据库/列存储数据库/文档型数据库和图形数据库。

    3. 一般常用的有作为数据缓存的 redis 和分布式系统的HBase。

    4. NoSQL分类

      • 键值存储数据库
        • 原理:通过哈希表实现键值 Key-Value 对应。
        • 应用场景:作为大量数据高访问的缓存;日志系统。
        • 产品:Memcahced/Redis/MemcacheDB
      • 列存储数据库
        • 原理:根据数据的属性按照列进行存储
        • 应用场景:分布式文件系统
        • 产品:Cassandra/HBase
      • 文档型数据库
        • 原理:Key-Value对应的键值对,Value作为结构化文档数据
        • 应用场景:Web应用
        • 产品:CouchDB,MongoDB
      • 图形数据库
        • 原理:利用图结构进行存储
        • 应用场景:知识图谱/社交关系
        • 产品:Neo4J/InfoGrid/Infinite Graph
    5. 关系型数据库 VS NoSQL

      • 关系型数据库
        • 优点
          • 二维表格,关系模式容易理解
          • 可维护性高,统一使用表结构存储
          • 采用通用的查询语言SQL,学习成本低
          • 通过SQL可实现多个表之间的非常复杂的查询
        • 缺点
          • 读写性能比较差,尤其是海量数据的高效率读写
          • 以固定的表结构存储,灵活性较差
          • 难以满足高并发的读写需求,硬盘IO是问题
      • NoSQL
        • 优点
          • 格式灵活,没有固定的存储格式
          • 可扩展性高,容易进行水平扩展
          • 无需sql层解析,读写性能高
          • 部署简单,基本都是开源软件,价格便宜
        • 缺点
          • 不提供sql支持,学习和使用成本较高
          • 无事务处理,不支持ACID特性
          • 数据结构相对复杂,复杂查询方面稍欠
    6. MySQL

      • 逻辑架构分为四层,包括连接层/服务层/引擎层和存储层
        • 连接层:负责处理客户端的连接以及权限的认证。
        • 服务层:定义有许多不同的模块,包括权限判断,SQL接口,SQL解析,SQL分析优化,缓存查询的处理以及部分内置函数执行等。MySQL的查询语句在服务层内进行解析/优化/缓存以及内置函数的实现和存储。
        • 引擎层:负责MySQL中数据的存储和提取。MySQL中的服务器层不管理事务,事务由存储引擎实现的。其中支持事务的存储引擎为InnoDB。
        • 存储层:负责将数据存储与设备的文件系统中。
      • 流程
        连接流程
        客户端
        连接层(连接器)处理客户端连接,授权认证
        服务层(查询缓存,分析器->优化器->执行器)查询语句的解析,优化,缓存以及内置函数的实现和存储
        引擎层(存储引擎)负责数据的存储和提取
        存储层负责硬件设备的数据存储
      • MySQL的事务
        • 事务是MySQL区别于NoSQL的重要特征,是保证关系型数据库数据一致性的关键技术。事务可看作是对数据库操作的基本执行单元,可能包含一个或多个SQL语句,这些语句在执行时,要么都执行,要么都不执行。

          • 事务的执行包括两个操作,提交和回滚
          • 提交:commit,将事务执行结果写入数据库。
          • 回滚:rollback,回滚所有已经执行的语句,返回修改之前的数据。
        • MySQL事务包含四个特性 ACID

          • 原子性(Atomicity) 语句要么全执行,要么全不执行,是事务最核心的特性,事务本身就是以原子性来定义的;实现主要基于 undo log 日志实现。
          • 持久性(Durability) 保证事务提交后不会因为宕机等原因导致数据丢失;实现主要基于 redo log 日志。
          • 隔离性(Isolation) 保证事务执行尽可能不受其他事务影响;InnoDB 默认的隔离级别是 RR, RR的实现主要基于锁机制/数据的隐藏列/undo log和类 next-key lock机制。
          • 一致性(Consistency) 事务追求的最终目标,一致性的实现既需要数据库层面的保障,也需要应用层面的保障。
        • 特性详解

          特性 详解
          原子性 表示事务不可再分;当事务需要回滚,InnoDB引擎会调用 undo log日志进行SQL语句的撤销,实现回滚
          持久性 指事务提交之后,数据库的改变就应该是永久性的,而不是暂时的,甚至是系统宕机故障也不会对结果产生影响;
          事务的持久性是通过InnoDB存储引擎中的redo log日志来实现的
          隔离性 1。原子性和持久性只是单个事务本身层面的性质;
          2。隔离性指的是事务之间应该保持的关系。隔离性要求不同事务之间的影响是互不干扰的,一个事务的操作和其他事务是相互隔离的。
          3。在事务的执行期间很有可能其他事务也开始执行,因此多事务的并发性就要求事物之间的操作是相互隔离的,这一点跟多线程之间数据同步的概念有些类似。
          一致性 一致性是指事务执行结束后,数据库的完整性约束没有被破坏,事务执行的前后都是合法的数据状态。
          一致性是事务追求的最终目标,原子性、持久性和隔离性,实际上都是为了保证数据库状态的一致性而存在的。
          • 锁机制
            划分标准 不同种类
            按照粒度划分 行锁/表锁/页锁
            按照使用方式划分 共享锁/排他锁
            按照思想划分 悲观锁/乐观锁
            # 锁机制
            # 事务之间的隔离,是通过锁机制实现的。当一个事务需要对数据库中的某行数据进行修改,需要先给数据加锁;加了锁的数据,其他事务是不能运行操作的,只能等待当前事务提交或回滚将锁释放。
            #
            #    粒度:指数据仓库的数据单位中保存数据的细化或综合程度的级别。细化程度越高,粒度就越小;相反,细化程度越低,粒度级就越大。
            #    MySQL中的锁的粒度有三种:
            #    1) 行锁:粒度最小的锁,对当前操作的行进行加锁。
            #    2) 表锁:粒度最大的锁,当前操作对整张表加锁。
            #    3) 页锁:介于行级锁和表级锁之间的一种锁,表示对页进行加锁。
            #    表锁的并发性能较差,
            #    行锁只需要锁定操作的数据,并发性能好。但是由于加锁本身需要消耗资源(获得锁/检查锁/释放锁等都需要消耗资源),因此在锁定数据较多情况下使用表锁可以节省大量资源。
            #
            
          • 并发读取问题
            在并发情况下,MySQL的同时读写可能会导致三类问题
            脏读
            时间 事务A 事务B
            T1 开始事务 开始事务
            T2 修改文章A的阅读量从100改到2000
            T3 查询文章A的阅读量结果为2000
            T4 事务回滚
            事务A这样就是脏读,即读取了其他事务回滚了的错误数据
            不可重复读
            时间 事务A 事务B
            T1 开始事务 开始事务
            T2 查询文章A的阅读量,结果为100
            T3 修改文章A的阅读数量从100改到200
            T4 提交事务
            T5 查询文章的阅读量,结果为200
            事务A在先后读取同一条件得到的结果却不一样;
            说明事务A在执行过程中,数据被其他事务给修改了,这样使得数据的查询结果不再可靠
            幻读
            时间 事务A 事务B
            T1 开始事务 开始事务
            T2 查询到 0<阅读量<100的文章,查到了15条结果
            T3 插入一篇阅读量为50的文章
            T4 提交事务
            T5 再次查询结果为16条
            不可重复读与幻读的区别是前者是数据变了,后者是行数变了。
          • 隔离级别
            隔离级别 脏读 不可重复读 幻读
            读未提交 Read Uncommitted 可能 可能 可能
            读已提交 Read Committed 不可能 可能 可能
            可重复读 Repeatable Read 不可能 不可能 可能
            可串行化 Serializable 不可能 不可能 不可能
          • MVCC:Multi-Version Concurrency Control,即多版本的并发控制协议
                # MVCC的特点就是在同一时刻不同事务可以读取到不同版本的数据,从而解决脏读和不可重复读的问题。
                # MVCC实际上就是通过数据的隐藏列和回滚日志(undo log),实现多个版本数据的共存。这样的好处是使用MVCC进行读数据的时候,不用加锁,从而避免了同时读写的冲突。
                # 在实现MVCC时,每一行的数据中会额外保存几个隐藏的列,比如当前行创建时的版本号和删除时间和指向undo log的回滚指针。这里的版本号并不是实际的时间值,而是系统版本号。每开始新的事务,系统版本号都会自动递增。事务开始时的系统版本号会作为事务的版本号,用来和查询每行记录的版本号进行比较。
                # 每个事务又有自己的版本号,这样事务内执行数据操作时,就通过版本号的比较来达到数据版本控制的目的。
                # 另外 InnoDB 是通过 "next-key lock"机制来实现 RR 隔离级别的, ??????
                #
                # next-key lock 实际上就是行锁的一种,只不过它不只是会所著当前行记录的本身,还会锁定一个范围,比如上面幻读的例子,开始查询0<阅读量<100的文章时,只查到15个结果。next-key lock会查询出这15行进行锁定,同时还会对0<阅读量<100这个范围进行加锁,这实际上就是一种间隙锁。间隙锁能够防止其他事务在这个间隙修改或插入记录。这样一来,就保证了在0<阅读量<100这个间隙中,只存在原来的15行数据,从而避免幻读。
                # 间隙锁:封锁索引记录中的间隔。
            
          • 串行化隔离
            时间 事务A 事务B
            T1 开始事务 开始事务
            T2 查询 0<阅读量<100的文章,结果:文章A,阅读量为99。
            T3 插入一篇文章B,阅读量为50。
            T4 提交事务
            T5 修改 0<阅读量<100 的所有文章的阅读量为10000
            T6 提交事务
            问:在T6时间,事务A提交事务之后,猜一猜文章A和文章B的阅读量为多少?
            答:文章AB的阅读量都被修改成了10000。这代表着事务B的提交实际上对事务A的执行产生了影响,表明两个事务之间并不是完全隔离的。虽然能够避免幻读现象,但是却没有达到串行化的级别。
            这还说明,避免脏读、不可重复读和幻读,是达到可串行化的隔离级别的必要不充分条件。可串行化是都能够避免脏读、不可重复读和幻读,但是避免脏读、不可重复读和幻读却不一定达到了可串行化。
  • 相关阅读:
    吴裕雄--天生自然 python语言数据分析:开普勒系外行星搜索结果分析
    吴裕雄--天生自然 R语言数据分析:火箭发射的地点、日期/时间和结果分析
    吴裕雄--天生自然 PYTHON数据分析:基于Keras的CNN分析太空深处寻找系外行星数据
    吴裕雄--天生自然 python数据分析:基于Keras使用CNN神经网络处理手写数据集
    吴裕雄--天生自然 PYTHON数据分析:钦奈水资源管理分析
    吴裕雄--天生自然 PYTHON数据分析:医疗数据分析
    独家解密:阿里大规模数据中心性能分析
    日志服务Python消费组实战(三):实时跨域监测多日志库数据
    日志服务Python消费组实战(二):实时分发数据
    日志服务与SIEM(如Splunk)集成方案实战
  • 原文地址:https://www.cnblogs.com/sweetXiaoma/p/13936584.html
Copyright © 2011-2022 走看看