Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Commit e372fd0

Browse files
author
guangxin.yuan
committed
update
1 parent a4ebe6c commit e372fd0

File tree

1 file changed

+5
-1
lines changed

1 file changed

+5
-1
lines changed

‎Rocket.md

Lines changed: 5 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -89,7 +89,10 @@ quicklist 的设计,其实是结合了链表和 ziplist 各自的优势。简
8989

9090
listpack 也叫紧凑列表,它的特点就是用一块连续的内存空间来紧凑地保存数据,同时为了节省内存空间,listpack 列表项使用了多种编码方式,来表示不同长度的数据,这些数据包括整数和字符串。在 listpack 中,因为每个列表项只记录自己的长度,而不会像 ziplist 中的列表项那样,会记录前一项的长度。所以,当我们在 listpack 中新增或修改元素时,实际上只会涉及每个列表项自己的操作,而不会影响后续列表项的长度变化,这就避免了连锁更新。
9191

92-
###
92+
### Redis的跳表和Mysql的B+树结构
93+
1. B+树是多叉平衡搜索树,只需要3层左右就能存放2kw左右的数据,同样情况下跳表则需要24层左右,假设层高对应磁盘IO,那么B+树的读性能会比跳表要好,因此mysql选了B+树做索引。
94+
2. redis的读写全在内存里进行操作,不涉及磁盘IO,同时跳表实现简单,相比B+树、AVL树、少了旋转树结构的开销,因此redis使用跳表来实现ZSET,而不是树结构。
95+
3. 存储引擎RocksDB内部使用了跳表,对比使用B+树的innodb,虽然写性能更好,但读性能属实差了些。在读多写少的场景下,B+树依旧是最佳选择。
9396

9497
### Redis 的数据过期策略
9598

@@ -324,6 +327,7 @@ MySQL为了保证ACID中的一致性和持久性,使用了WAL(Write-Ahead Logg
324327
* 平衡二叉树:通过旋转解决了平衡的问题,但是旋转操作效率太低。
325328
* 红黑树:通过舍弃严格的平衡和引入红黑节点,解决了 AVL旋转效率过低的问题,但是在磁盘等场景下,树仍然太高,IO次数太多。
326329
* B+树:在B树的基础上,将非叶节点改造为不存储数据纯索引节点,进一步降低了树的高度;此外将叶节点使用指针连接成链表,范围查询更加高效。
330+
* B+树是由多个页组成的多层级结构,每个页16Kb,对于主键索引来说,最末级的叶子结点放行数据,非叶子结点放的则是索引信息(主键id和页号),用于加速查询。
327331

328332
### B+树的叶子节点都可以存哪些东西
329333

0 commit comments

Comments
(0)

AltStyle によって変換されたページ (->オリジナル) /