专栏首页IT技术精选文摘什么是内存数据库以及它如何有效保存数据

什么是内存数据库以及它如何有效保存数据

你可能听说过内存数据库。如果没有,您可以从这里(https://en.wikipedia.org/wiki/In-memory_database)快速查看他们的概述!

长话短说,内存数据库就是将整个数据集保存在RAM中的数据库。这意味着什么?这意味着每次查询数据库或更新数据库中的数据时,只能访问主存。这些操作没有涉及磁盘 - 这是很好的,因为主存的速度比任何磁盘都快。这种数据库的一个好例子就是Memcached。

但是,如果内存数据库重启或崩溃后,如何恢复数据?如果只要一个内存中的数据库,那就没有办法了。一台机器停机 - 数据全部丢失。

可以将内存数据存储的功能与MySQL或Postgres之类的旧数据库的持久性相结合?当然!会影响性能吗?令人惊讶的是,没有!

这里有些持久性的内存数据库,如Redis,Aerospike和Tarantool。

您可能想知道内存中的存储是否可以持久存在。这里的秘诀是,您仍然将内容保留在内存中,但另外,您可以在事务日志中对磁盘上的每个操作进行持久化。如下图:

您可能会注意到的第一件事是,即使您这个很好的快速的内存数据库具有持久性,但它的查询不会慢,因为它仍然只能像内存数据库那样仅仅占用主内存。 这是好消息! 但是更新呢? 每个更新(我们称之为事务)应该不仅应用于内存,而且还要持久到一个缓慢的磁盘上 。这会是问题吗? 我们来看下图:

事务仅以追加的方式应用事务日志。 这有什么好处? 当以这种追加的方式处理时,磁盘相当快。 如果我们使用旋转磁性硬盘驱动器(HDD),它可以以每秒100 MB的速度写入文件的末尾。 如果你不相信我,请尝试在Unix / Linux / MacOS shell中运行这个测试:

cat /dev/zero >some_file

查看some_file的增长速度。当您按顺序使用磁盘时,磁盘速度非常快。另一方面,当您随机使用它们时,它们是非常缓慢的。它们通常可以每秒完成大约100次随机操作。

如果您将每个字节逐字节的写入HDD的随机位置,则可以在这种情况下看到磁盘的吞吐量的峰值大概在一秒钟100字节。再者,每秒钟只有100个字节!最糟糕的情况(每秒100字节)和最佳情况(100,000,000字节/秒)磁盘访问速度之间这六个数量级的巨大差异是基于以下事实:为了寻找随机扇区磁盘,已经发生磁盘头的物理移动(而您不需要它来进行顺序访问,因为您只是从磁盘读取数据,因为磁盘头是稳定的)。

如果考虑固态硬盘(SSD),那么由于没有移动部件,情况会更好。但是,最好/最差的比例是相似的。连续访问每秒提供200-300兆字节,随机访问每秒提供1,000-10,000次查询,即四到五个数量级。

因此,我们的内存数据库会以每秒100 MB的事务刷到磁盘。这够快吗?真的很快。如果一个事务大小是100字节,那么这将是每秒一百万个事务!这个数字非常高,您可以肯定地确保磁盘永远不会成为内存数据库的瓶颈。这是一个内存数据库的详细基准测试(https://gist.github.com/danikin/a5ddc6fe0cedc6257853),每秒显示一百万次事务,其中瓶颈是CPU,而不是磁盘。

总结上面关于磁盘和内存数据库的所有信息:

1.内存数据库不使用磁盘进行非更改的操作。

2.内存数据库确实使用磁盘进行数据更改操作 - 但是它们以最快的方式使用它。

为什么常规的基于磁盘的数据库不采用相同的技术?首先,它不像内存数据库,他们需要从每个查询的磁盘上读取数据(让我们忘记缓存一分钟,这将是另一篇文章的主题)。

你永远不知道下一个查询是什么,所以你可以想象的到这个查询在磁盘上产生了随机访问的工作负载,这也是最糟糕的磁盘使用情况。第二,基于磁盘的数据库需要持久化更改,以便可以立即读取已更改的数据。

不像内存数据库(通常不会从磁盘读取,除非启动时出于恢复原因)。基于磁盘的数据库需要特定的数据结构,以避免对事务日志进行全面扫描,以便快速读取数据集。一种类型的数据结构是B / B +树。这种数据结构的另一面是,您应该在每个更改操作上更改B / B +树,这可能会导致磁盘上的随机工作负载。在提高读取操作性能的同时,B / B +树正在降级以进行写入操作。有一些基于B / B +树的数据库引擎,包括MySQL或Postgres存储引擎的InnoDB。

还有另一种数据结构在写入工作负载方面要好一些:LSM树。这种现代数据结构并不能解决随机读取问题,而是部分解决了随机写入问题。这些引擎的例子是RocksDB,LevelDB或Vinyl。您可以在此图中看到概要:

因此,具有持久性的内存数据库在读/写操作上可以真正快速,与纯内存数据库一样快,使用磁盘非常有效,并且不会成为瓶颈。

结论

在这我想提到的最后一个(但并非最不重要的)话题是快照。快照是压缩的事务日志。数据库状态的快照是整个数据集的副本。快照和最新的事务日志足以恢复数据库状态。使用快照,您可以删除在快照之上没有任何新信息的所有过时的事务日志。

为什么我们需要压缩日志?因为事务日志越多,数据库的恢复时间就越长。另一个原因是你不想用过时和无用的信息来填充你的磁盘。

快照本质上是将整个数据库从主存储器暂时转储到磁盘。一旦我们将数据库转储到磁盘,我们可以删除不包含快照中最后一个事务检查点的事务的所有事务日志。轻松吧?这只是因为在一个快照中已经包含了从一开始就有的所有其他事务。

本文分享自微信公众号 - IT技术精选文摘(ITHK01),作者:Bill译

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2017-09-15

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • Java I/O底层是如何工作的?

    本博文主要讨论I/O在底层是如何工作的。本文服务的读者,迫切希望了解Java I/O操作是在机器层面如何进行映射,以及应用运行时硬件都做了什么。 假定你熟悉基...

    用户1263954
  • 58同城数据库架构设计思路

    (1)可用性设计 解决思路:复制+冗余 副作用:复制+冗余一定会引发一致性问题 保证“读”高可用的方法:复制从库,冗余数据,如下图 ? 带来的问题:主从不一致 ...

    用户1263954
  • 本地IDC机房数据库容灾解决方案

    风险无处不在,包括自然灾害以及突发事件等,有时候我们无法预测到一些风险,比如天津港爆炸事件。IT领域也一样,总是有意想不到的事情,风险具有不可预测性,万全之策就...

    用户1263954
  • 附加文件时候的提示“无法重新生成日志,原因是数据库关闭时存在打开的事务/用户,该数据库没有检查点或者该数据库是只读的 ”

    【SQLServer】【恢复挂起的解决方案】附加文件时候的提示“无法重新生成日志,原因是数据库关闭时存在打开的事务/用户,该数据库没有检查点或者该数据库是只读的...

    逸鹏
  • double write buffer,你居然没听过?

    MySQL的buffer一页的大小是16K,文件系统一页的大小是4K,也就是说,MySQL将buffer中一页数据刷入磁盘,要写4个文件系统里的页。

    架构师之路
  • 行业观察:抛弃传统数据库,拐点将至,乘云而上!

    近几年来,大规模代替传统商业数据库(以Oracle为代表),已成为行业内的共识。其实早在十余年前,以阿里为代表的国内企业就在企业内部实践了这一过程,并且取得了非...

    用户5548425
  • 【学习】NoSQL数据库的35个应用场景

    现在我们站在各个用例的角度上来考虑那种系统适合于这些用例。 你的意见是首先,我们要纵览各种数据模型。这些模型的分类方法来自于Emil Eifrem 和 NoSQ...

    小莹莹
  • mybatis 详解(一)------JDBC

    1、什么是MyBatis?   MyBatis 本是apache的一个开源项目iBatis, 2010年这个项目由apache software foundat...

    IT可乐
  • 奇怪的编码问题

    今天使用R爬取数据的时候发现一个奇怪的问题,我将每个属性的数据先保存在vector中,然后再合并到data.frame中时,发现打印names时数据正常显示中文...

    用户2936342
  • 云天励飞王孝宇:持续不断的产品和商业创新是AI公司的核心竞争力 | 镁客请讲

    在王孝宇看来,基于对场景的精准把握和计算机视觉技术的娴熟应用,最大化做好产品是一家公司的重点所在。

    镁客网

扫码关注云+社区

领取腾讯云代金券