BTree

Log-Structured Merge-Tree，简称 LSM。 以 Mysql、postgresql 为代表的传统 RDBMS 都是基于 b-tree 的 page-orented 存储引擎。现代计算机的最大处理瓶颈在磁盘的读写上，数据存储无法绕开磁盘的读写，纯内存型数据库除外，但由于内存存储的不稳定性，我们一般只将内存型的存储作为缓存系统。 为提升数据库系统的写性能，我们发现磁盘的 顺序写性能远远大于随机写性能 ，甚至性能高于内存的随机写。所以在很多偏向写性能的数据库系统中，以牺牲一部分读性能和增大写放大的情况下引入了 LSM 数据结构。 设计一个数据库引擎 我们从头开始设计一个数据库引擎。数据模型很简单，我们选最简单的 Key-Value 结构，一条数据只有一个 Key 和一个 Value。操作只有 get 和 put，如下： get(key); put(key, value); 从最简单的开始，每个数据库一个 data.db 文件，我们像写日志一样，将每条记录 append 到文件结尾。 key1,value1 key2,value2 key3,value3 key10,value10 key8,value8 这样我们已经完成了 80%了，然后需要完成读功能。如上数据文件，若需要查询 key2 数据，我们只能从文件开头开始遍历，当直到读取到 key2 数据： for

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 深度分页引发的机器性能问题 最近碰到一个ElasticSearch深度分页搜索，导致cpu占用过高问题，通过查阅ElasticSearch: 权威指南，了解到了深度分页为何会引起机器资源占用： 在集群系统中深度分页 为了理解为什么深度分页是有问题的，让我们假设在一个有5个主分片的索引中搜索。当我们请求结果的第一页（结果1到10）时，每个分片产生自己最顶端10个结果然后返回它们给请求节(requesting node)，它再排序这所有的50个结果以选出顶端的10个结果。 现在假设我们请求第1000页——结果10001到10010。工作方式都相同，不同的是每个分片都必须产生顶端的10010个结果。然后请求节点排序这50050个结果并丢弃50040个！ 你可以看到在分布式系统中，排序结果的资源和时间花费随着分页的深入而成倍增长。这也是为什么网络搜索引擎中任何语句不能返回多于1000个结果的原因。 理解以上那段文字，有必要了解ElasticSearch集群以及在集群中是查询的底层原理，本文试图通过总结ElasticSearch基本概念和底层原理，加深自身理解，同时希望对使用者有所帮助，避免不必要的踩坑。 基本概念 索引（index） “索引” 这个词在 ElasticSearch

新建表和字段建议 **1、**所有数据表和字段要有清晰的注释，字段说明 说明：不管是创建者还是其他开发或者后续维护者都能清楚知道数据表和字段定义的含义 **2、**表名、字段名使用小写字母或数字，禁止出现数字开头 说明：MySQL在Windows下不区分大小写，但在Linux下默认是区分大小写，为了避免出现不必要的麻烦，统一使用小写 **3、**每个列都设置为not null（如果列为BLOB/TEXT类型的，则这个列不能设置为NOT NULL)，且定义默认值 说明：3.1：NOT IN、!= 等负向条件查询在有 NULL 值的情况下返回非空行的结果集 3.2：使用 concat 函数拼接时，首先要对各个字段进行非 NULL 判断，否则只要任何一个字段为空都会造成拼接的结果为 NULL 3.3：当用count函数进行统计时，NULL 列不会计入统计 3.4：因为NULL的列使得索引，索引统计和值比较都更复杂，可为NULL的列会使用更多的存储空间，在mysql里也需要特殊处理，当可为NULL的列被索引时，每个索引记录需要一个额外的字节，如果计划在列上建索引，应该避免将列设计为NULL。 **4、**每个表有自增列id且为主键，使用无符号类型unsigned，不作业务逻辑使用 说明： 4.1：避免存储负值，且扩大了表示范围 4.2：如果使用非自增主键（如果身份证号或学号等）

我们已经讨论了PostgreSQL的索引引擎和访问方法的接口，以及哈希索引。现在我们将考虑b树，最传统和最广泛使用的索引。本文篇幅很大，请耐心等待。 Btree的结构 B-tree索引类型，以«btree»访问方法实现的，适合于可排序的数据。换句话说，必须为数据类型定义«greater»、«greater or equal»、«less»、«less or equal»和«equal»操作符。注意，相同的数据有时可能排序不同，这又回到了操作符家族的概念。 b-树的索引行被打包到页中。在叶子页中，这些行包含要索引的数据(键)和对表行的引用(tid)。在内部页中，每一行引用索引的一个子页，并包含该页中的最小值。 B树有一些重要的特征: ·B-树是平衡的，即每个叶子页与根页之间由相同数量的内部页分隔。因此，搜索任何值都需要相同的时间。 ·B-树是多分支的，也就是说，每个页(通常为8KB)包含很多(数百个)tid。因此，b-树的深度非常小，对于非常大的表，实际上可以达到4-5。 ·索引中的数据按非降序排序(页之间和每个页内部都是如此)，同级别页通过双向列表彼此连接。因此，我们可以通过向一个或另一个方向遍历列表来获得有序数据集，而不必每次都返回到根。 下面是一个简化的示例，说明在一个具有整型键的字段上建立索引。 索引的第一页是元数据页，它引用索引根。内部节点位于根的下面，叶子页位于最下面一行

一.数据库索引 索引的概念： 索引是对数据库表中一列或多列的值进行排序的一种结构，使用索引可快速访问数据库表中的特定信息。（如果按特定职员的姓来找他，则与在表中搜索的行相比，索引有助于更快的获取信息。 DB在执行一条Sql语句的时候，默认方式是根据搜索条件进行全表扫描，遇到匹配条件的就加入搜索结果集合。如果我们对某一字段增加索引，查询时就会先去索引表中一次定位骚特定值的行数，大大减少遍历的行数，能明显增加查询的速度。 索引的目的 索引的目的就是加快检索表中数据的方法。 索引的分类 主键索引（加速主键作为查询条件，where和on后面的条件）， 唯一索引 普通索引 索引的实现方法 一般分为B+树和哈希索引 B+树索引：在B-tree上改进得到，其非叶子节点均为key值，叶子节点是key-data键值对。叶子节点前后相连且有序。 哈希索引：通过key进行hash而将记录存储在不同的哈系桶中，默认无序。 为什么有了B+树索引还要hash索引？ 1）B+树默认有序，hash默认无序，所以哈希索引无法用于排序； 2）哈希索引O（1）在速度上毋庸置疑快于B+树近似O(logn); 3) 哈希索引只能进行等值查询（因为它要计算hash(key)再去匹配，而B+树索引可以进行等值，部分前缀，范围查询； 4）底层实现结构不同：B+树是非线性结构，hash桶是线性结构。 5）对于某些场景如热点页

在之前的文章中，我们讨论了PostgreSQL索引引擎、访问方法的接口以及以下方法:hash索引、b-tree、GiST、SP-GiST、GIN和RUM。本文的主题是BRIN(Block Range Index)。 与我们已经熟悉的索引不同，BRIN的想法是避免查找绝对不合适的行，而不是快速找到匹配的行。BRIN始终是一个不准确的索引:它根本不包含表行的tid。 简单地说，BRIN可以很好地处理值与其在表中的物理位置相关的列。 换句话说，如果没有ORDER BY子句的查询实际上以递增或递减的顺序返回列值(并且该列上没有索引)。 这种访问方法是在欧洲大型分析数据库项目轴心范围内创建的，关注的是几个tb或几十tb大的表。BRIN的一个重要特性使我们能够在这样的表上创建索引，索引比较小而且维护成本很低。 其工作原理如下。表被分割成ranges(好多个pages的大小)：因此被称作block range index(BRIN)。在每个range中存储数据的摘要信息。作为规则，这里是最小值和最大值，但有时也并非如此。假设执行了一个查询，该查询包含某列的条件;如果所查找的值没有进入区间，则可以跳过整个range;但如果它们确实在，所有块中的所有行都必须被查看以从中选择匹配的行。 在BRIN索引中，PostgreSQL会为每个8k大小的存储数据页面读取所选列的最大值和最小值，然后将该信息

本文源码： GitHub·点这里 || GitEE·点这里 一、索引简介 1、基本概念 首先要明确索引是什么：索引是一种数据结构，数据结构是计算机存储、组织数据的方式，是指相互之间存在一种或多种特定关系的数据元素的集合，例如：链表，堆栈，队列，二叉树等等。 其次要清楚索引的作用：索引可以使存储引擎快速找到数据记录，这是最基本的作用，索引是对查询速度最关键的影响，良好的索引设计可以使查询的效率有质的飞越。 索引的使用：如果查询语句使用所有，MySQL会在索引的数据结构上查询，如果查询到，就返回包含该索引的数据行。 2、索引的优点 唯一或者主键索引,保证列数据的唯一性 减少数据扫描量，快速查询数据； 数据有序的索引，可以将随机IO变成顺序IO； 有效的索引查询，可以避免排序和临时表； 3、索引分类 索引的种类非常多，如何分类取决多个场景和不同的角度，常见的划分如下： 产生作用：主键索引，普通索引，非空索引，全文索引； 覆盖字段：单列索引，组合索引； 数据结构：B-Tree索引，哈希索引，R-Tree索引； 注意 ：索引的实现是在存储引擎层面，相同的索引在不同的存储引擎中，其实现方式可能都是不一样的。 二、索引用法详解 1、不同索引特点 普通索引 基本的索引，没有任何使用限制，主要用来加速数据查询。适合经常出现在查询条件或排序条件中的数据列。 主键索引 特殊的唯一索引，不允许有空值

概述 权限是大部分的后台管理系统都需要实现的功能，用户控制不同的角色能够进行的不同的操作。Spring Security的可以进行用户的角色权限控制，也可以进行用户的操作权限控制。在之前的代码实现上，我们仅仅只是实现用户的登录，在用户信息验证的时候使用UserDetailsService，但是却一直忽略了用户的权限。 一. 启动类配置 /** * 开启方法的注解安全校验。 * securedEnabled @Secured("ROLE_abc") 该注解是Spring security提供的 * jsr250Enabled @RolesAllowed("admin") 该注解是 JSR250 支持的注解形式 * prePostEnabled @PreAuthorize("hasAuthority('user:add') */ @SpringBootApplication @EnableGlobalMethodSecurity ( securedEnabled = true , jsr250Enabled = true , prePostEnabled = true ) public class SecurityApplication { public static void main ( String [ ] args ) { SpringApplication . run (

一、前言 上两节，我们依次讲了树、二叉树、二叉搜索树。二叉搜索树是最常见的一种二叉树。它支持快随插入、删除、查找操作。各个操作的时间复杂度和树的高度成正比，平均时间复杂度是O（logN）。 不过二叉搜索树在频繁动态更新过程中可能会出现树的高度远大于 log2n 的情况，从而导致各个操作的效率下降。极端情况下，二叉树会退化为链表，时间复杂度会退化到 O(n)。要解决 复杂度退化这个问题 ，需要一种 平衡二叉搜索树 。比如红黑树、AVL树、树堆。 在工程中，很多用到平衡二叉搜索树的地方都会使用红黑树。为什么工程中都喜欢用红黑树而不是其他平衡二叉搜索树。 二、平衡二叉搜索树 平衡二叉树的严格定义是这样的： 二叉树中任意一个节点的左右子树的高度相差不能大于 1 。 平衡二叉查找树不仅满足上面平衡二叉树的定义，还满足二叉查找树的特点。 最先被发明的平衡二叉查找树是AVL 树 ，它严格符合我刚讲到的平衡二叉查找树的定义，即任何节点的左右子树高度相差不超过 1，是一种高度平衡的二叉查找树。 发明平衡二叉查找树这类数据结构的初衷是，解决普通二叉查找树在频繁的插入、删除等动态更新的情况下，出现时间复杂度退化的问题。所以， 平衡二叉查找树中“平衡”的意思，其实就是让整棵树左右看起来比较“对称”、比较“平衡”，不要出现左子树很高、右子树很矮的情况。这样就能让整棵树的高度相对来说低一些，相应的插入、删除

数据结构和基础算法作为计算机科学的必学课程，近几年却关注度越来越少。但 程序员真的不再需要这两门基础知识了吗 ？一位在 Uber 等科技公司工作过的开发者分享了他的一手经验，告诉你实际工作中会用到哪些数据结构和算法。 作者：Gergely Orosz，机器之心编译，参与：小舟、杜伟。 日常工作中，你经常使用算法和数据结构吗？曾就职于 Uber 等科技公司的工程师 Gergely Orosz 提出了这样一个问题。此外，他也注意到，越来越多的人觉得算法是无用的，并认为它们只是科技公司提出的一种强制性措施罢了。 本文作者 Gergely Orosz。 不仅如此，也有更多的人抱怨称算法只是纯粹的学术练习。在 Homebrew 作者 Max Howell 发表他的谷歌面试经历之后，这样的想法被进一步普及。 虽然 Gergely Orosz 自己也从来不需要使用二叉树翻转（binary tree inversion），但是他在 Skype、Microsoft、Skyscanner 以及 Uber 工作时，每天都会遇到使用数据结构和算法的情况。 此外，他有时也需要基于这些概念编写代码和做出决策。最后，Gergely Orosz 借助这些知识来理解有些事物如何和为何构建，以及如何使用或修改它们。 由此可见，数据结构和算法并不是如人们所言用处不大。在本文中，Gergely Orosz