我们晓得加密后的数据对模糊查询不是很友好，本篇就针对加密数据模糊查询那个问题来展开讲一讲实现的构想，希望对各人有所启发。
为了数据平安我们在开发过程中经常会对重要的数据停止加密存储，常见的有：密码、手机号、德律风号码、详细地址、银行卡号、信誉卡验证码等信息，那些信息对加解密的要求也纷歧样，好比说密码我们需要加密存储，一般利用的都是不成逆的慢hash算法，慢hash算法能够制止暴力破解（典型的用时间换平安性），在检索时我们既不需要解密也不需要模糊查找，间接利用密文完全婚配，但是手机号就不克不及如许做，因为手机号我们要查看原信息，而且敌手机号还需要撑持模糊查找，因而我们今天就针对可逆加解密的数据撑持模糊查询来看看有哪些实现体例。
在网上随意搜刮了一下，关于《加密后的模糊查询》 的帖子良多，趁便整理了一下实现的办法，不能不说良多都是不靠谱的做法，以至有一些沙雕做法，接下来我们就对那些做法来讲讲实现构想和好坏性。
若何对加密后的数据停止模糊查询
我整理了一下对加密的数据模糊查询大致分为三类做法，如下所示：
沙雕做法（不动脑思虑曲男的构想，尽管实现功用从不深切思虑问题）
常规做法（思虑了查询性能问题，也会利用一些存储空间换性能等做法）
超神做法（比力高端的做法从算法层面上思虑）
我们就对那三种实现办法逐个来讲讲实现构想和好坏性，起首我们先看沙雕做法。
沙雕做法
将所有数据加载到内存中停止解密，解密后通过法式算法来模糊婚配
将密文数据映射一份明文映射表，俗称tag表，然后模糊查询tag来联系关系密文数据
沙雕一
我们先来看看第一个做法，将所有数据加载到内存中停止解密，那个若是数据量小的话能够利用那个体例来做，如许做既简单又实惠，若是数据量大的话那就是灾难，我们来大致算一下。
一个英文字母(不分大小写)占一个字节的空间，一个中文汉字占两个字节的空间，用DES来举例，13800138000加密后的串HE9T75xNx6c5yLmS5l4r6Q==占24个字节。
条数BytesMB100w2400万22.891000w2.4亿228.891亿24亿2288.89
轻则上百兆，重则上千兆，如许分分钟给应用法式整成Out of memory，如许做若是数据少只要几百、几千、几万条时是完全能够如许做的，但是数据量大就强烈不料见了。
沙雕二
我们再来看第二个做法，将密文数据映射一份明文映射表，然后模糊查询映射表来联系关系密文数据，what？？？！！！那我们为什么要对数据加密呢，间接不加密不是更好么！
我们既然对数据加密必定是有平安诉求才会如许做，增加一个明文的映射表就违犯了平安诉求，如许做既不平安也不便利完满是脱裤子放x，多此一举，强且不保举。
常规做法
我们接下来看看常规的做法，也是最普遍利用的办法，此类办法及称心的数据平安性，又对查询友好。
展开全文
在数据库实现加密算法函数，在模糊查询的时候利用decode(key) like '%partial%
对密文数据停止分词组合，将分词组合的成果集别离停止加密，然后存储到扩展列，查询时通过key like '%partial%'
常规一
在数据库中实现与法式一致的加解密算法，修改模糊查询前提，利用数据库加解密函数先解密再模糊查找，如许做的长处是实现成本低，开发利用成本低，只需要将以往的模糊查找略微修改一下就能够实现，但是缺点也很明显，如许做无法操纵数据库的索引来优化查询，以至有一些数据库可能无法包管与法式实现一致的加解密算法，但是关于常规的加解密算法都能够包管与应用法式一致。
若是对查询性能要求不是出格高、对数据平安性要求一般，能够利用常见的加解密算法好比说AES、DES之类的也是一个不错的选择。
若是公司有本身的算法实现，而且没有供给多端的算法实现，要么找个算法好的人去研究吃透补全多端实现，要么放弃利用那个办法。
我们创建了一个高量量的手艺交换群，与优良的人在一路，本身也会优良起来，赶紧点击加群，享受一路生长的快乐。
常规二
对密文数据停止分词组合，将分词组合的成果集别离停止加密，然后存储到扩展列，查询时通过key like '%partial%'，那是一个比力划算的实现办法，我们先来阐发一下它的实现构想。
先对字符停止固定长度的分组，将一个字段拆分为多个，好比说根据4位英文字符（半角），2个中文字符（全角）为一个检索前提，举个例子：
ningyu1利用4个字符为一组的加密体例，第一组ning ，第二组ingy ，第三组ngyu ，第四组gyu1 … 依次类推。
若是需要检索所有包罗检索前提4个字符的数据好比：ingy ，加密字符后通过 key like “%partial%” 查库。
我们都晓得加密后长度会增长，增长的那部门长度存储就是我们要破费的额外成本，典型的利用成原来换取速度，密文增长的幅度跟着算法差别而差别以DES举例，13800138000加密前占11个字节，加密后的串HE9T75xNx6c5yLmS5l4r6Q==占24个字节，增长是2.18倍，所以一个优良的算法是多么的重要，能为公司节省很多成本，但是话又说回来算法工程师的工资也不低，所以我也不晓得是节省成本仍是增加成本，哈哈哈…你们本身算吧。
回到主题，那个办法固然能够实现加密数据的模糊查询，但是对模糊查询的字符长度是有要求的，以我上面举的例子模糊查询字符原文长度必需大于等于4个英文/数字，或者2个汉字，再短的长度不料见撑持，因为分词组合会增加从而招致存储的成本增加，反而平安性降低。
各人能否都对接过 淘宝、拼多多、JD他们的api，他们对平台订单数据中的用户敏感数据就是加密的同时撑持模糊查询，利用就是那个办法，下面我整理了几家电商平台的密文字段检索计划的阐明，感兴趣的能够查看下面链接。
淘宝密文字段检索计划阿里巴巴文字段检索计划拼多多密文字段检索计划京东密文字段检索计划
ps. 根本上都是一样的，公然都是互相剽窃，连加密后的数据格局都一致。
那个办法长处就是实现起来不算复杂，利用起来也较为简单，算是一个折中的做法，因为会有扩展字段存储成本会有升高，但是可操纵数据库索引优化查询速度，保举利用那个办法。
超神做法
我们接下来看看优良的做法，此类做法难度较高，都是从算法层面来考虑，有些以至会设想一个新算法，固然已有一些现成的算法参考，但是大多都是半废品无法拿来间接利用，所以仍是要有人去深切研究和整合到本身的应用中去。
从算法层面思虑，以至会设想一个新算法来撑持模糊查找
那个层面大多是专业算法工程师的研究范畴，想要设想一个有序的、非不成逆的、密文长度不克不及增长过快的算法不是一件简单的工作，大致的构想是如许的，利用译码的体例停止加解密，保留密文和原文一样的挨次，从而撑持密文模糊婚配，说的比力笼统因为我也不是那方面的专家没有更深一步的研究过，所以我从网上找了一些材料能够参考一下。
数据库中字符数据的模糊婚配加密办法
那里提到的Hill密码处置和模糊婚配加密办法FMES能够重点看看.
一种基于BloomFilter的改良型加密文本模糊搜刮机造研究
撑持快速查询的数据库若何加密
基于Lucene的云端搜刮与密文根底上的模糊查询
基于Lucene的构想就跟我们上面介绍的常规做法二类似，对字符停止等长度分词，将分词后的成果集加密后存储，只不外存储的db纷歧样，一个是关系型数据库，一个是es搜刮引擎。
云存储中一种撑持可验证的模糊查询加密计划
总结
我们到那里对加密数据的检索计划全数介绍完了，我们起首提到的是网上搜刮到处可见的沙雕做法，在那里也讲了不保举利用那些沙雕做法，尽量利用常规做法，若是公司有专业算法标的目的人才的话无妨能够考虑基于算法层面的超神做法。
总的来说从投入、产出比、及实现、利用成原来算的话常规做法二长短常保举的。