PgSQL · 应用案例 · PostgreSQL 图像搜索实践

背景 imgsmlr是PostgreSQL的一款支持以图搜图的插件, 支持 1、几种图像特征值数据类型, 2、图像特征值相似算子, 3、图像特征值相似排序索引支持, 4、图像相似排序的索引(通过扩展GiST索引接口实现)支持, 5、png,gif等图像格式特征值提取函数。 图像特征值为64*64的16个区域经过小波转换后的16个浮点数。 在数据量(图片数)非常庞大时,输入一个图片特征值,搜索相似度排行前N的图片,性能如何呢?如何优化呢? 接下来的3篇文档将分别

MySQL · myrocks · collation 限制

背景 MyRocks中的数据是按索引列以memcmp方式进行排序的。对于一些数字类型,需要进行转化才能直接通过memcmp进行比较, 例如有符号数在计算机中是用补码表示的,那么如果负数和正数直接按字节比较,结果负数会比正数大,实际存储时会将符号会反转存储,读取时再转化回来。对于字符类型,处理更加复杂,涉及到字符集的转换。 记录格式可以参考[1], [2] MyRocks索引字段如果包含字符类型,默认只支持binary collation,binary、latin1_bin、

Redis · 引擎特性 · 基于 LFU 的热点 key 发现机制

前言 业务中存在访问热点是在所难免的,redis也会遇到这个问题,然而如何发现热点key一直困扰着许多用户,redis4.0为我们带来了许多新特性,其中便包括基于LFU的热点key发现机制。 Least Frequently Used Least Frequently Used——简称LFU,意为最不经常使用,是redis4.0新增的一类内存逐出策略,关于内存逐出可以参考文章《Redis数据过期和淘汰策略详解》。 从LFU的字面意思我们很容易联想到key的访问频率,但

MySQL · 案例分析 · RDS MySQL线上实例insert慢常见原因分析

概述 insert慢是经常被问到的问题,笔者尝试在本文中对这个问题做一个分类梳理,列举的线上例子会做简化,希望对读者有所启发。 注意:因为阿里云MySQL线上实例还是以RDS 5.6为主体,本文的分析也是以5.6 innodb 引擎为主,其他版本的rds的实例可能略有差别。 insert几个可能的性能瓶颈点 有关MySQL insert源码分析的文章,可以参看阿里云云栖社区的文章,例如: 一条简单insert语句的调用栈 一条insert语句的执行过程 基

MongoDB · 引擎特性 · MongoDB索引原理

为什么需要索引? 当你抱怨MongoDB集合查询效率低的时候,可能你就需要考虑使用索引了,为了方便后续介绍,先科普下MongoDB里的索引机制(同样适用于其他的数据库比如mysql)。 mongo-9552:PRIMARY> db.person.find() { "_id" : ObjectId("571b5da31b0d530a03b3ce82"), "name" : "jack&quo

MSSQL · 最佳实践 · 使用非对称秘钥实现列加密

摘要 上一篇月报,我们分享了SQL Server使用对称秘钥实现列加密的方法。为了解决对称加密安全性低的问题,本期月报我们分享使用非对称秘钥加密方式实现SQL Server列加密方法,保护用户的关键、核心隐私数据列信息。 场景引入 对称加密是指加密和解密过程使用同一个密钥的加密算法,而非对称加密方法加密和解密过程使用不同的秘钥进行。因此,通常来说对称加密安全性较弱,非对象加密安全性相对较高。以下是关于对称加密和非对称加密的过程介绍。 对称加密过程 对称加密算法使用相

MySQL · RocksDB · Memtable flush分析

概述 首先我们知道在RocksDB中,最终数据的持久化都是保存在SST中,而SST则是由Memtable刷新到磁盘生成的,因此这次我们就主要来分析在RocksDB中何时以及如何来Flush内存数据(memtable)到SST. 简单来说在RocksDB中,每一个ColumnFamily都有自己的Memtable,当Memtable超过固定大小之后(或者WAL文件超过限制),它将会被设置为immutable,然后会有后台的线程启动来刷新这个immutable memtabl

MySQL · 引擎特性 · IO_CACHE 源码解析

概述 在数据库中 IO 的重要性不言而喻,为了更好的管理 IO 操作,大多数数据库都自己管理页数据和刷脏机制(例如 InnoDB 中的 Buffer pool),而不是交给文件系统甚至是操作系统调度。但是对于顺序写入的日志数据,使用文件系统接口方便的多,文件系统 也是以页的形式管理,呈现给应用层的是一片连续可写的空间,管理的单位称为 Sector 大小是 4KB,所以对于 4KB 对齐的地址读写可以避免跨多个 Sector,对文件系统的性能有很大的提高。MySQL 中的 IO

MySQL · 源码分析 · Innodb缓冲池刷脏的多线程实现

简介 为了提高性能,大多数的数据库在操作数据时都不会直接读写磁盘,而是中间经过缓冲池,将要写入磁盘的数据先写入到缓冲池里,然后在某个时刻后台线程把修改的数据刷写到磁盘上。MySQL的InnoDB引擎也使用缓冲池来缓存从磁盘读取或修改的数据页,如果当前数据库需要操作的数据集比缓冲池中的空闲页面大的话,当前缓冲池中的数据页就必须进行脏页淘汰,以便腾出足够的空闲页面供当前的查询使用。如果数据库负载太高,对于空闲页面的需求超出了page cleaner的淘汰能力,这时候是否能够快速获

MySQL · 引擎特性 · B+树并发控制机制的前世今生

前言 B+树是1970年Rudolf Bayer教授在《Organization and Maintenance of Large Ordered Indices》一文中提出的[1]。它采用多叉树结构,降低了索引结构的深度,避免传统二叉树结构中绝大部分的随机访问操作,从而有效减少了磁盘磁头的寻道次数,降低了外存访问延迟对性能的影响。它保证树节点中键值对的有序性,从而控制search/insert/delete/update操作的时间复杂度在O(log(n))的范围内。鉴于上