redis高级应用

一、事务

Redis的事务相对不是很完善,下面通过实例来看一下redis事务的问题在哪?

事务正常执行:


Cassandra3.x官方文档_数据库内部 数据库 数据库学习 数据库知识 数据库内部

事务执行出现问题:


Cassandra3.x官方文档_数据库内部 数据库 数据库学习 数据库知识 数据库内部

以上实践可以看出redis虽然有事务,但是事务的机制并不完善,这是需要改进的地方。

一旦是数据库就会涉及到并发的问题,一般是使用锁类解决并发问题,锁分为悲观锁和乐观锁。在redis使用事务和watch监听一起达到乐观锁的效果,实例的完成需要开启两个会话。

实例:左侧为session2,右侧为session1


Cassandra3.x官方文档_数据库内部 数据库 数据库学习 数据库知识 数据库内部

1、Session1添加监听,开启事务

2、session2中对age进行修改

3、session1中添加事务队列,修改age

4、执行事务,获取age的值

在session1中对age添加了监听,在监听后如果age的值被改变session1中对age再次做修改则无法提交。

二、发布订阅消息

存储引擎

Cassandra使用了一种类似于日志结构合并树的存储结构,而不是像传统关系型数据库那样使用B-Tree。Cassandra避免写之前读。写前读,尤其是大型的分布式系统中,可能导致读取性能的延迟和其他问题。例如,两个客户端同时读。一个以覆盖的方式更新A,另一个以覆盖的方式更新B,同时删除A的更新。这种竞争条件会导致模棱两可的查询结果—虽然更新都是对的。

在Cassandra中为了避免写前读,存储引擎组在内存中进行插入和更新操作,然后在间隔的时候,依次将数据以追加的模式写入磁盘。一旦写入磁盘,数据就是不可变的,而且永远不会覆盖。读取数据需要结合这些不可变的、顺序写入的数据,以此发现正确的查询结果。你可以在写之前使用轻量级事务(LWT)来检查数据的状态。然而,此功能只被推荐用于有限的场合。

日志结构引擎避免了覆盖,使用了顺序IO来更新数据,对于写数据到固态硬盘和普通硬盘来说,是至关重要的。在HDD上,随机写比顺序写涉及到更多的查找操作。所导致的害处是实在的。由于Cassandra顺序写不可改变的文件,因此避免了写放大和磁盘故障,数据库容纳便宜的,消费者固态硬盘尤其好。在很多其他数据库上,写入放大是在SSD上是一个问题。

Cassandra如何读和写数据

Understanding howCassandra stores data.

要想管理和访问Cassandra的数据,理解Cassandra如何存储数据是非常重要的。hinted handoff的特性增加了Cassandra的性能,而且ACID(原子性,一致性,隔离性,持久性)的非一致性的数据库属性是理解读和写的关键概念。在Cassandra里,一致性的意思是如何保持最新,和在所有副本上的行的数据保持同步。

用于开发数据存储和索引的应用程序的客户端工具和应用编程接口(API)都是可用的。

数据如何写?

Understand how Cassandrawrites and stores data.

Cassandra在写路径上处理数据分为好几个阶段,以立即写日志开始,以写数据到磁盘结束。

? 写数据日志至commit log

? 写数据至memtable

? 从memtable刷新数据

? 存储数据值磁盘的SSTables

日志写入和memtable存储

当一个写发生时,Cassandra把数据存储到内存中的一个叫做memtable的结构里,而且为了提供可配置的持久化,它也将写入到磁盘的commit log里。Commit log接收Cassandra节点的每一个写操作,这些持久化的写操作永久存在,即使节点出现故障。Memtable是一个数据分区的写回缓存,Cassandra通过key查找。Memtable存储已排好序的写操作,直到达到配置的限制,然后再刷新。

从memtable刷新数据

刷新数据,Cassandra会按照memtable排序的顺序把数据写入磁盘。同时一个分区索引也会在磁盘上被创建,可以把token值映射到磁盘的某个位置上。当memtable的内容超过了配置好的阈值或者commit log的空间超过了commitlog_total_space_in_mb,这时memtable会进入一个会刷新到磁盘的队列中。该队列可以使用cassandra.yaml文件里的memtable_heap_space_in_mb或者memtable_offheap_space_in_mb来配置。如果将要刷新的数据超过了memtable_cleanup_threshold的值,Cassandra会阻塞写操作,直到下一个刷新成功。你可以使用

nodetool flush或者nodetooldrain(不需要监听其他节点,刷新memtables)直手动刷新一个表。为了减少commit log的重播时间,推荐最佳实践是在你启动节点之前刷新memtables。如果一个节点停止工作,在它停止之前重新提交commit log恢复memtable写。

commit log里的数据在相应的memtable里的数据刷新到磁盘的SSTable里以后,会进行合并。

Storingdata on disk in SSTables

每一个表都维护着一个Memtables和SSTables。commit log是所有的表共享的。SSTables是不可变的,在memtable刷新过后不会再重新写入。因此,一个分区通常保存在多个SSTable文件里。大量其他的SSTable结构存在着,以协助读操作。


Cassandra3.x官方文档_数据库内部 数据库 数据库学习 数据库知识 数据库内部

对于每一个SSTable,Cassandra会创建这些结构:

数据 (Data.db)

SSTable的数据。

主要索引 (Index.db)

行键的索引,有指针指向他们在数据文件中的位置

Bloom过滤器(Filter.db)

内存中存储的一个结构,在数据进入磁盘的SSTables之前检查数据是否存在于memtable里。

Compression信息(CompressionInfo.db)

一个文件,包含未压缩的数据长度,块偏移量和其他的压缩信息。

统计 (Statistics.db)

统计SSTable的内容元数据。

文摘 (Digest.crc32, Digest.adler32, Digest.sha1)

包含数据文件的adler32校验和的文件

CRC(CRC.db)

包含在一个未压缩文件里的块的CRC32的文件。

SSTable索引摘要(SUMMARY.db)

保存在内存中的分区索引的示例。

SSTable表的内容 (TOC.txt)

存储sstable表的内容所有组件列表的文件。

第二索引 (SI_.*.db)

内置第二索引,一个SSTable里可存在多个第二索引。

SSTables是存储在磁盘上的文件。SSTable文件的命名规则在Cassandra2.2和后来的版本中发生了改变,为了缩短文件路径。数据文件存储的位置随着安装方式的不同而不同。对于每一个键空间,数据目录内的目录存储每一个表。例如,/data/data/ks1/cf1-5be396077b811e3a3ab9dc4b9ac088d/la-1-big-Data.db代表一个数据文件。开始表示键空间的名称,以区分流空间或者批量加载数据。这个例子中的十六进制字符串5be396077b811e3a3ab9dc4b9ac088d,追加到表名称后面,来表示唯一的表ID。

Cassandra为每一个表创建一个子目录,这样你可以使用一个表来选择物理驱动器或数据量。这样就提供了把表转移到更快的媒介上的能力来获得更好的性能,比如SSD,而且在存储层上在所有附加的存储设备上划分表以获得更好的I/O平衡。

数据是如何保持的?

Cassandra processes dataat several stages on the write path. Compaction to maintain healthy SSTables isthe last step in the write path process.

Cassandra写过程把数据存储到一个叫做SSTables的结构里。SSTables是不可变的。Cassandra为新插入的或者更新的数据写入一个新时间戳的版本到新的SSTables里,而不是使用插入或者更新的数据去覆盖已存在的行。同样,Cassandra也不删除空间:代替的是,Cassandra把需要删除的数据标记为tombstone(墓碑)。

随着时间的推移,Cassandra可能为每一行写了很多的版本,每一个都在不同的SSTable里。每一个版本都有一个不同的时间戳作为唯一的标志存储。这意味着Cassandra必须有越来越多的SSTables来检索数据的一整排。

为了保持数据库的健壮性,Cassandra周期性的合并SSTables和丢弃旧的数据。这个过程叫做compaction。

Compaction

Compaction通过分区键来合并每一个SSTable里的数据,使用最近的时间戳来选择数据的版本。合并的过程是永久的。因为每一个SSTable里的行是通过分区键排序的,因此合并过程并不使用随机I/O。在移除已删除的列和行以后,compaction过程把SSTables合并到一个单一的SSTables里。旧的SSTables文件只要等待使用文件完成读取以后就会被删除。


Cassandra3.x官方文档_数据库内部 数据库 数据库学习 数据库知识 数据库内部

Compaction会导致一个临时的磁盘占用和磁盘I/O,这是旧的和新的SSTables同时存在。当它完成以后,compaction释放旧的SSTables占用的磁盘空间。它通过压缩过的SSTables替换旧SSTables来提高了读性能。Cassandra甚至可以在完成写之前直接从新的SSTable里读取数据,而不是等待整个compaction过程完成以后。

当Cassandra处理读和写的时候,它在页缓存里使用新SSTables替换掉旧的SSTables。缓存新的SSTables,把读操作导向新的SSTables是一个渐进的过程-它不会导致戏剧性的缓存丢失。Cassandra提供了可预见的高性能,即使在高负载下。

Compaction策略

Cassandra支持不同的compaction策略。每一个都有自己的优势。理解每一种策略是如果工作的,对于选择适合你自己应用程序工作负载的策略是至关重要的。虽然下面的每一种选择都是以广义的建议开始的,但是有很多复杂的因素影响了compaction策略的选择。有关更多关于每一种策略相对的优势,和指定使用用例的讨论的更多信息,参考:哪一种compaction策略是最好的?

SizeTieredCompactionStrategy(STCS)

推荐用于写密集工作负载

当一组(默认4)相似大小的SSTables累积起来的时候,SizeTieredCompactionStrategy(STCS)初始化compaction。该compaction策略合并这些SSTables成一个更大的SSTable。然后这个更大的SSTables依次合并成一个更大的SSTables。在任何给定的时间里,几个大小不等的SSTables同时存在。


Cassandra3.x官方文档_数据库内部 数据库 数据库学习 数据库知识 数据库内部

当这个策略在一个写密集的工作负载下运行的很好的时候,它使读变得更慢,因为按大小合并的过程并不倾向于按行分组数据。因为这个原因,它更可能是一个特殊行的数据可能分布在很多的SSTables里。同样,移除已被删除的数据的发生是不可预知的,因为SSTable的大小是compaction过程的触发器,而且SSTables增长的速度可能还不能达到合并和移除旧数据的条件。由于最大的SSTables大小会增长,磁盘compaction空间数量需要同时既容纳新的,也要容纳旧的SSTables,可能超过一个典型的节点的磁盘空间大小。

? Pros:压缩写密集工作负载很不错

? Cons:可以保持过时的数据太长。需要的内存量随着时间的推移而增加。

本文数据库(综合)相关术语:系统安全软件

分页:12
转载请注明
本文标题:Cassandra3.x官方文档_数据库内部 数据库 数据库学习 数据库知识 数据库内部
本站链接:http://www.codesec.net/view/524255.html
分享请点击:


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 数据库(综合) | 评论(0) | 阅读(82)