解读SQL 内存数据库的细节

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 解读SQL 内存数据库的细节 相信大家对内存数据库的 概念并不陌生,之前园子里也有多位大牛介绍过...

解读SQL 内存数据库的细节

相信大家对内存数据库的 概念并不陌生,之前园子里也有多位大牛介绍过SQL内存数据库的创建方法,我曾仔细 拜读过,有了大致了解,不过仍有很多细节不清晰,比如:

(1)内存数据库是把整个数据库放到内存中的吗?

(2)数据都在内存里面,那宕机或者断电了,数据不是没有了吗?

(3)据在内存是怎么存放的,还是按照页的方式吗,一行的大小有限制吗?

(4)内存数据库号称无锁式设计,SQL是如何处理并发冲突的呢?

相信这些疑问也是大家在思考内存数据库时经常遇到的难题,下文将为大家一一揭开这些问题的面纱,如有不对之处,还请各位看官帮我指出。

一、内存数据库是如何存储的,只放在内存吗?是把整个数据库放在内存吗?

答案:不是。

如果你还没有看过宋大侠的博客,建议现在就看看。

http://www.cnblogs.com/CareySon/p/3155753.html

在这篇文章中,我想着重引用如下两个信息:

(1)内存数据库其实就是将指定的表放到内存中,而不是整个数据库;

(2)内存数据库用文件流的方式组织磁盘中的数据文件;

我再补充一个信息

(3)内存数据库的数据文件分data file和delta file,而且是成对出现;

1、内存数据库其实就是将指定的表放到内存中,而不是整个数据库;

从宋大侠的博客中可以知道,内存数据库的创建过程其实就是将表存放到内存中,而不是整个数据库。下图展示 了创建内存优化表的语法,红色框标注了内存与传统表创建时语法不相同的地方。

内存优化表不仅仅是把数据存放到内存中,要不然跟传统数据的缓存没有区别。在内存数据库中,内存优化表也叫为" natively compile memory-optimized tables",翻译过来就是本地编译内存优化表,内存优化表在创建的同时被编译成本地机器代码装载到内存中,本地机器代码包含了能被CPU直接执行的机器指令,所以对内存优化表的访问和操作将非常快。

内存优化表分两类,持久性表和非持久性表,对持久性表的改动会记录日志,即使数据库重启,数据也不会丢失;对非持久性表的操作不会记录日志,这些操作结果只保留在内存中,数据库重启后数据会丢失。

上文只是介绍了新建一张表的情况,在正常的业务环境中我们不可能对一个业务系统数据库的每张表都去create,那对于已经存在的表,有没有配置方法呢?答案恐怕不太令人满意,目前SQL暂不支持迁移现有表到内存中,因此要想使用内存数据库,现有的业务数据表必须重新创建。

2、内存数据库用文件流的方式组织磁盘中的数据文件

在内存数据库中,磁盘上存储的数据文件不在是区、页的存储方式,而是基于文件流存储。文件流存储的一个特点之一就是支持快速的读操作,这在数据库重启时将文件流中的数据load到内存中时很能提高效率。

3、内存数据库的数据文件分data file和delta file,而且是成对出现;

内存数据库中插入、更新的数据和删除的数据物理分开存储的,分别用data file和delta file保存。

(1)Data file

Data file用来保存"插入"或者"更新"的数据行,data file中数据行的存储顺序严格按照事务执行的顺序组织,比如data file中第一行的数据来自于事务1,第二行数据来自于事务2,这两行可以是同一个表的数据,也可以是不同表的数据,取决于这两个连续的事务操作的内存优化表是否相同。 这种方式的好处是保证了磁盘IO的连续性,避免随机IO。

Data file的大小是固定的,为128MB,当一个data file被写满了后,SQL会自动新建一个data file。因为数据在data file中保存的顺序是按照事务的执行顺序进行的,所以一张表的数据行(来自多个事务)可能跨越了多个data file,当对多行进行更新操作时,写操作可以分配到多个文件上,并且同时进行,这样就可以加快更新的效率。(下文介绍delta file时会介绍)

如下图,一共有4个data files(浅蓝色),第一个data file的事务范围为100-200,第二个data file的事务范围为200-300……(100、200表示时间戳)

在Data file中,如果一行被删除或者更新了,这行不会从data file中移除,而是通过delta file(上图黄色框)来标记删除的行,(update的本质是delete和insert的集合,所以执行update时也会有删除的动作),这样可以消除不必要的磁盘IO。

如果data file的数据永不删除,那文件岂不是无限制的增大,以后备份不是得用很大的磁盘才行?当然不是,SQL在处理这个问题用到方法其实很简单——"合并",根据合并策略,将多个data file和delta file合并起来,依据delta file的内容删除data file中的多余记录,然后将多个data file合并成一个文件,从而减小数据文件占用的磁盘空间大小。

(2) Delta file

每个data file都有一个与之匹配的Delta File,这个匹配是指事务范围上的匹配,两者记录的是同一段事务(包括一个或者多个事务)上的数据,Delta File中记录了data file中被删除行的标记,这个标记其实就是一个关联信息{inserting_tx_id, row_id, deleting_tx_id }。它跟data file一样,也是严格按照事务操作的顺序来保存删除的行的信息。

如上图,该内存数据库有5个data file,分别存放了事务范围在100-200、200-300、300-400、400-500及500的数据。如果有一个时间戳为501的事务需要删除时间戳为150、250、450的事务所产生的数据和增加一些新数据时,相应的IO请求就会被分配到第1、2、4的 delta file上和第5的data file上。删除操作可以分配到多个文件上,并且同时进行,这样就可以加快删除的效率。

二、数据都在内存里面,那宕机或者断电了,数据不是没有了吗?

答案:不是。

内存数据库通过两种方式保证数据的持久性:事务日志和chcekpoint。

(1)事务日志

内存数据库的"写日志"和"写数据"在一个事务中进行,在事务执行期间,SQL会先"写数据"然后在才"写日志",这点与传统数据库不同,在传统数据库中,不管是在内存中还是磁盘中,"写数据"总是在"写日志"之后,也就是通常所说的WAL(Write-Ahead Transaction Log)。但是,在事务提交时,内存数据库和传统数据库在"写日志"上没有什么区别:日志会先于数据写入到磁盘中。

因此,即使服务器发生了宕机或者断电,下次数据库重启时会按照已经保存在磁盘中事务日志将业务redo(重做),所以不要担心数据会丢失。

另外,需要补充的是,内存数据库只会对持久性表将已提交的事物日志保存到磁盘中。这样做的好处可以减少写磁盘的次数。内存数据库支持频繁、快速的增、删、改等操作,这个强度远远高于传统数据库,数据库需要为每笔操作写日志,这样就会产生大量磁盘IO,写日志操作将有可能成为性能瓶颈,不记录未提交的事务日志就减少写日志的数量,从而可以提高数据库的性能。

有同学会想,不记录未提交事务的日志会不会导致数据不一致呢?

肯定不会,因为日志在写入磁盘前不可能发生先把"脏数据"写入到磁盘的现象(下面介绍checkpoint的时候会介绍原因)。

(2)CheckPoint

在内存数据库中,CheckPoint的主要目的就是将内存中的"数据"写入到磁盘中,从而在数据库崩溃或者重启时减少数据恢复的时间。不需要数据库逐条读取所有的日志来恢复数据。默认情况下Checkpoint是周期性进行的,当日志至上次checkpoint后增加了512M时会触发新一轮CheckPoint。

在传统数据库这种,Checkpoint可以将未提交的数据flush到磁盘的mdf文件中,这个现象在内存数据库中不会发生,因为内存数据库只将已提交事务的日志,而在写日志(到磁盘)之前不可能将数据先写到磁盘中,因此可以保证写到磁盘中的数据一定是已提交事务的数据。

三、数据在内存是怎么存放的,还是按照页的方式吗,一行的大小有限制吗?

答案:不是按照页的方式,一行的限制大小为8060Bytes。

内存优化表是基于行版本存储的,同一行在内存中会有多个版本,可以将内存优化表的存储结构看作是该表中 所有行的多个行版本的集合。

内存优化表中的行跟传统数据库的行结构是不一样的,下图描述了内存优化表中一行的数据结构:

在内存优化表中,一行有两个大部分组成:Row header和Row body,

Row header记录这个行的有效期(开始时间戳和结束时间戳)和索引指针

Row body记录了一行的实际数据。

在内存优化表中,行版本的数量是由针对该行的操作次数决定的,比如:每更新一次,就会新产生一行,增加一个行版本,新行有新的开始时间戳,新行产生后,原来的数据行会自动填充结束时间戳,意味这行已经过期。

备注:上图实际上只有3行,第1行有3个行版本,第2行有2个行版本,第3行有4个行版本。

既然同一行在内存中存在这么多的行版本,那数据库在访问时是怎么控制的呢?

在传统数据库中,表中每一行都是唯一的,一个事务如想找到一行,通过文件号、页号、槽位就可以了。

在内存数据库中,每一行有多个行版本,一个事务不可能对将每个行版本都操作一遍,实际上,一个事物只能操作同一行的一个行版本,至于它能对哪个行版本进行操作,取决于事务执行时间是否在这行的两个时间戳之间。除此之外的其他行版本对该事务而言是不可见的。

由于一行可能存在多个行版本,大家可能会提出这样一个疑问:每行都有这么多行版本,一张上百万行的表,内存哪够呀。不用担心,前文介绍过了,每个行实际上是有时间戳的,对于已经打上结束时间戳且没有活动事务访问的行,SQL Server会通过garbage collection机制回收它占用的内存,从而节省内存。所以不要担心内存不够。

四、内存数据库号称无锁式设计,那如果发生了并发冲突怎么办,SQL是如何处理冲突的呢?

答案:内存数据库用行版本来处理冲突。

锁的一个重要作用就是避免多个进程同时修改数据,从而造成数据不一致。常见的冲突现象包括读写互锁和写写互锁。那内存数据库是如何通过行版本来解决这两种锁定现象的呢?

(1)读写互锁

在内存数据库中,所有对内存优化表的事务隔离都是基于快照的,准确的说是基于行的快照。从上文行的 结构可以知道,每行的行头包括开始时间戳和结束时间戳的,一个事务能不能访问到这行关键在于事务的启动时间是不是在这行的两个时间戳内。

如果某个事务正在修改一行(快照),但还未提交到内存优化表中,也就是说"新行"还没有结束时间戳,对"读事务"而言,它读还是是原来行(快照),因此不会存在脏读的现象。

(2)写写互锁

两个事务同时更新一行时,就会发生写写互锁。

内存数据库冲突发生的概率比传统数据库小很多,但如果实在遇到了冲突,只能调整应用程序,在应用程序中加入"重试逻辑"(等待一会,然后再重新发起事务)来解决。

或许有同学觉得这种方式好像也没有什么大的性能改变。其实不然,举个例子,在传统数据库中一个锁可能将整个表都管住了,在表锁期间只能等待这个事务做完才能执行其他事务,而实际上这个事务可能只是修改了小部分行,因为表锁的存在,其他行那些不需要被这个事务操作的行。但内存数据库中写写冲突总是发生在行级别的,这个粒度小多了,影响没这么大。






About Me

...............................................................................................................................

● 本文来自于转载文章

● 小麦苗云盘地址:http://blog.itpub.net/26736162/viewspace-1624453/
● 
原文地址:http://www.uml.org.cn/sjjm/201611242.asp

● QQ群:230161599     微信群:私聊

● 联系我请加QQ好友(642808185),注明添加缘由

● 版权所有,欢迎分享本文,转载请保留出处

...............................................................................................................................

手机长按下图识别二维码或微信客户端扫描下边的二维码来关注小麦苗的微信公众号:xiaomaimiaolhr,免费学习最实用的数据库技术。

wpsF8C8.tmp

 

数据库技术交流
相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
相关文章
|
2月前
|
SQL 关系型数据库 MySQL
大数据新视界--大数据大厂之MySQL数据库课程设计:MySQL 数据库 SQL 语句调优方法详解(2-1)
本文深入介绍 MySQL 数据库 SQL 语句调优方法。涵盖分析查询执行计划,如使用 EXPLAIN 命令及理解关键指标;优化查询语句结构,包括避免子查询、减少函数使用、合理用索引列及避免 “OR”。还介绍了索引类型知识,如 B 树索引、哈希索引等。结合与 MySQL 数据库课程设计相关文章,强调 SQL 语句调优重要性。为提升数据库性能提供实用方法,适合数据库管理员和开发人员。
|
3月前
|
SQL 数据库连接 Linux
数据库编程:在PHP环境下使用SQL Server的方法。
看看你吧,就像一个调皮的小丑鱼在一片广阔的数据库海洋中游弋,一路上吞下大小数据如同海中的珍珠。不管有多少难关,只要记住这个流程,剩下的就只是探索未知的乐趣,沉浸在这个充满挑战的数据库海洋中。
92 16
|
3月前
|
SQL 关系型数据库 MySQL
如何优化SQL查询以提高数据库性能?
这篇文章以生动的比喻介绍了优化SQL查询的重要性及方法。它首先将未优化的SQL查询比作在自助餐厅贪多嚼不烂的行为,强调了只获取必要数据的必要性。接着,文章详细讲解了四种优化策略:**精简选择**(避免使用`SELECT *`)、**专业筛选**(利用`WHERE`缩小范围)、**高效联接**(索引和限制数据量)以及**使用索引**(加速搜索)。此外,还探讨了如何避免N+1查询问题、使用分页限制结果、理解执行计划以及定期维护数据库健康。通过这些技巧,可以显著提升数据库性能,让查询更高效流畅。
|
8月前
|
SQL 开发框架 .NET
ASP.NET连接SQL数据库:详细步骤与最佳实践指南ali01n.xinmi1009fan.com
随着Web开发技术的不断进步,ASP.NET已成为一种非常流行的Web应用程序开发框架。在ASP.NET项目中,我们经常需要与数据库进行交互,特别是SQL数据库。本文将详细介绍如何在ASP.NET项目中连接SQL数据库,并提供最佳实践指南以确保开发过程的稳定性和效率。一、准备工作在开始之前,请确保您
570 3
|
4月前
|
SQL 存储 关系型数据库
【SQL技术】不同数据库引擎 SQL 优化方案剖析
不同数据库系统(MySQL、PostgreSQL、Doris、Hive)的SQL优化策略。存储引擎特点、SQL执行流程及常见操作(如条件查询、排序、聚合函数)的优化方法。针对各数据库,索引使用、分区裁剪、谓词下推等技术,并提供了具体的SQL示例。通用的SQL调优技巧,如避免使用`COUNT(DISTINCT)`、减少小文件问题、慎重使用`SELECT *`等。通过合理选择和应用这些优化策略,可以显著提升数据库查询性能和系统稳定性。
146 9
|
3月前
|
SQL 监控 数据库
如何解决 SQL Server 占用内存过多问题
SQL Server 占用过多内存会导致响应缓慢和查询性能低下。解决流程包括:1) 查看内存使用情况,2) 分析各数据库内存占用,3) 优化 SQL Server 配置(如限制最大内存),4) 优化查询(如创建索引),5) 持续监控效果。通过这些步骤可有效控制内存占用,提升系统性能。
478 0
|
5月前
|
SQL Java 数据库连接
【潜意识Java】MyBatis中的动态SQL灵活、高效的数据库查询以及深度总结
本文详细介绍了MyBatis中的动态SQL功能,涵盖其背景、应用场景及实现方式。
564 6
|
6月前
|
SQL Oracle 数据库
使用访问指导(SQL Access Advisor)优化数据库业务负载
本文介绍了Oracle的SQL访问指导(SQL Access Advisor)的应用场景及其使用方法。访问指导通过分析给定的工作负载,提供索引、物化视图和分区等方面的优化建议,帮助DBA提升数据库性能。具体步骤包括创建访问指导任务、创建工作负载、连接工作负载至访问指导、设置任务参数、运行访问指导、查看和应用优化建议。访问指导不仅针对单条SQL语句,还能综合考虑多条SQL语句的优化效果,为DBA提供全面的决策支持。
155 11
|
6月前
|
SQL 关系型数据库 MySQL
MySQL导入.sql文件后数据库乱码问题
本文分析了导入.sql文件后数据库备注出现乱码的原因,包括字符集不匹配、备注内容编码问题及MySQL版本或配置问题,并提供了详细的解决步骤,如检查和统一字符集设置、修改客户端连接方式、检查MySQL配置等,确保导入过程顺利。
|
6月前
|
SQL 监控 安全
SQL Servers审核提高数据库安全性
SQL Server审核是一种追踪和审查SQL Server上所有活动的机制,旨在检测潜在威胁和漏洞,监控服务器设置的更改。审核日志记录安全问题和数据泄露的详细信息,帮助管理员追踪数据库中的特定活动,确保数据安全和合规性。SQL Server审核分为服务器级和数据库级,涵盖登录、配置变更和数据操作等事件。审核工具如EventLog Analyzer提供实时监控和即时告警,帮助快速响应安全事件。
130 1