哈希

哈希表的处理冲突 1. 开放定址法 2. 链地址法 将所有哈希地址相同的记录都链接在同一链表中。 来源： CSDN 作者： zhupengqq1 链接： https://blog.csdn.net/zhupengqq1/article/details/104141667

哈希算法 这个算法可以在一个字符串中 迅速判断两个字串是否相同 。 根据朴素算法，我们直接将两个字串相比较，遇到不同的字符就break，这样的时间复杂度是o（n），而改进后的哈希算法的时间复杂度为o（1）。 下面我们来具体看看哈希算法（先假设字符串中皆为小写字母）： 将字符串中的26个小写字母转换为数字，然后将每一个前缀的p进制的哈希值算出，通过 比较对应的哈希值来确定两个字串是否相同 。当然，p一般取131或13331，因为这样可以最大可能降低相同率，避免两个不同的字符串有相同的哈希值。由于字符串长度未知，哈希值可能会超过long long int的长度，但即使溢出也没有关系，溢出的值以long long int为例，会对2^64取模，对结果无太大关系。 以字符串str[]={a,b,c}为例： 先转化为数字：1 2 3； 为了方便运算，hash[0]=0; 计算每一个前缀的hash值（转化为131进制数）： hash[a]=h[0]^131+str[1]-‘a’+1=1; hash[ab]=hash[a]^131+str[2]-‘a’+1=133; hash[abc]=hash[ab]^131+str[3]-‘a’+1=17426; 此时，若是要知道字符串里两个字串是否相等则只要计算两个字串的哈希值是否相等即可。 如字符串s={a,b,c,a,b,c,g}; 计算s[r]到s

字符串Hash 字符串hash就是 把一个字符串变成一个整数 当两个字符串相同时，它们通过hash计算后得到的整数相同，当两个字符串不同时，它们的数字就不同。 Hash公式 首先设一个进制数base，和一个取模数mod 给定一个字符串 S id（x）=x - ‘a’ + 1 * hash[ i ] =hash[ i -1 ] base + id(s[ i ]） hash冲突 比如orzc的哈希值为233，orzhjw的哈希值也为233 而这两个字符串显然不相同，这就叫hash冲突。 单hash方法 就是一个取模运算，只进行一次hash运算。公式如下： * hash[i]=(hash[i-1] base+id(s[i]))%mod 单哈希的hash冲突概率很低 例：取base=13，mod=101， 对字符串abc进行hash hash[0] = 1 hash[1] = (hash[0] * base +id(s[1]) % mod =15 hash[2] = (hash[1] * base + id[s[2]) % mod = 97 所以当base=13，mod=101时，可以把abc当作97，**即abc的hash值为97 ** 代码如下： int n=strlen(s+1),base=13,mod=101; int hash[1001],id[1001]; hash[0]=1;

提交了整整一页，我恨！TAT POJ 3261 Milk Patterns 题意：找到长度为n的串中出现次数为k的最长子串，子串可以有重叠部分。 思路：就很显然的二分+哈希。 但是我为什么交了一页！！！！ 开始直接while里面直接用了快读，死循环了，跑不出来，T了几发，还以为是算法有问题……www <= 被我写成了 < !!!!!!!! 我???? mod = 20007 ?????? 不是质数啊!!!!!!! qaq，我哭 就这两个我跟你讲，愣死没找出来bug. ……wwww，最后的最后www随便输了一组样例 10 2 1 1 1 1 1 1 1 1 1 1 发现答案不对，于是发现了第二个臭不要脸的bug 改了还是WA，心态崩了啊。对照网上的代码，有一篇跟我写的差不多，发现没什么问题啊？？？什么鬼啊。然后就一句一句的对，发现好像mod不一样，于是就改了和他一样的。shit，就过了！然后想了想20007不是质数啊qaq!!!!!!!!我恨 但是后来我又改了mod为小一点的100007，或者1000007，都过不了。就有点诡异。www. 应该是哈希冲突了。 中间还写了双哈希的代码，代码附在了最后， 双哈希 的话用100007就可，没什么限制。 这是第一道用了没用ull溢出自动取模的写法！！就给我整成了这个样子，我恨…… AC CODE #include <iostream>

BF 算法，暴力匹配算法，每次往后移一位 RK 算法，通过哈希算法对主串中的 n-m+1 个子串分别求哈希值，然后逐个与模式串的哈希值比较大小。如果某个子串的哈希值与模式串相等，那就说明对应的子串和模式串匹配了（这里先不考虑哈希冲突的问题）。因为哈希值是一个数字，数字之间比较是否相等是非常快速的。 但是需要遍历子串中的每个字符，算法整体的效率并没有提高 提高哈希算法 二十六进制来表示一个字符串：把 a～z 这 26 个字符映射到 0～25 这 26 个数字，a 就表示 0，b 就表示 1； 相邻两个子串的哈希值的计算公式有一定关系 ，可以使用 s[i-1]的哈希值很快的计算出 s[i]的哈希值 26^(m-1) 这部分的计算，我们可以通过查表的方法来提高效率。我们事先计算好 26 0、26 1、26 2……26 (m-1)，并且存储在一个长度为 m 的数组中，公式中的“次方”就对应数组的下标。当我们需要计算 26 的 x 次方的时候，就可以从数组的下标为 x 的位置取值，直接使用，省去了计算的时间。 只需要扫描一遍主串O(n)，模式串哈希值与每个子串哈希值之间的比较的时间复杂度是 O(1)，总共需要比较 n-m+1 个子串的哈希值，整体的 时间复杂度就是 O(n)。 来源： CSDN 作者： lwj~ 链接： https://blog.csdn.net/qq_41754573

什么是数据库调优？说得高大上，实际上就是减少磁盘IO次数。 众所周知，为数据表增加索引会使查询速度大大提升，MySQL索引其实是一种数据结构，有“哈希”和“B+树”可供用户选择。为什么只能用这两种呢？为什么不能用二叉树、平衡二叉树、红黑树等等呢？ 首先，来说一下MySQL增加数据的方式：一般都是主键自增的。根据二叉 树的特性：“左子树小于根节点，右子树大于根节点”，如果索引采用这种数据 结构，会生成一个向右倾斜的树，而且不会生成平衡二叉树。存放的数据越多， 树就越深，不能达到快速查询的目的。 如果采用红黑树，也一样只是生成一个比二叉树稍微改善一点的向右倾斜 的树而已。 上述两种数据结构并没有使磁盘IO次数减少。 我们知道“哈希”是一种散列算法，给定一个数据经过哈希运算后，能得到 一个固定长度的数列(哈希值)。MySQL索引存放哈希值，而哈希值所对应的是数 据的指针，因此哈希索引时间复杂度为O(1),查询速度极为迅速。 哈希索引有两个特点： 1.数据并不是按照索引值顺序存储，所以也就无法用于排序。 2.不支持任何范围查询 因为这两个缺陷，哈希索引只适用于某些特定的场合。 那B+树是怎么来解决上述的各种问题呢？ 不了解B+树是什么的同学可以点击链接 数据结构可视化 ，手动生成B+树并观察。 B+树允许每个结点拥有多个内部结点，“Max. Degree”代表每个结点的最大内部结点数量，B

作者：林冠宏 / 指尖下的幽灵 掘金： https://juejin.im/user/587f0dfe128fe100570ce2d8 博客： http://www.cnblogs.com/linguanh/ GitHub ： https://github.com/af913337456/ 腾讯云专栏： https://cloud.tencent.com/developer/user/1148436/activities 本文不做一般入门的区块链描述讲解。着重简述讲解： 区块链的分叉 共识算法 目录 前言 简单过一下区块链 通俗讲解共识 共识算法 PoW 区块链分叉 硬分叉的出现 软分叉的出现 参考 前言 由于最近的开发工作是与以太坊公链相关的去中心化交易所，项目两个多月之久，对区块链相关的知识内容了解了一些，故择文以记录之，但求文字通俗易懂，无纰漏。因自身求学过程中所遇坑无数，业内良文亦少之又少，深感朦胧之懂之不爽。此外，亦坚信区块链技术未来必能大放光芒，因现在多应用于虚拟货币，故人谈区块链，内心首想皆炒币相关之内容。 简单过一下区块链 我们一般意识形态中的 链 是 铁链 ，由铁铸成，一环扣一环。形象地，区块链的也可以这么理解，只不过它不是由铁铸成，而是由拥有一定 数据结构的块 连接而成，这是一个最 简单的雏形 见下图 通俗讲解共识 所谓 共识 ，通俗来说

RedisCommandExecutionException: MOVED 9656 192.168.1.101:7002 最近一个同事，在使用Redis集群进行操作的过程中，遇到如下错误 看这个错误信息，感觉挺奇怪。操作代码，使用Spring封装的RedisTemplate，而且操作内容并不复杂。将相关操作通过redis命令，在客服端执行 其实，看到这里，想必各位，已经知道异常出现的原因了。由于name和age两个key的槽位不同，在存储时，这两个key被映射到不同的节点，从而出现了上述异常。 下面介绍下Redis槽位信息 Redis集群内置16384个哈希槽，数据存储时，Redis首先对key使用crc16算法进行计算，将计算结果对16384取模，从而确定当前key对应于那个哈希槽。Redis正式通过哈希槽，来将数据大致均匀的映射到不同的节点。 在Redis中，可以通过cluster keyslot命令，查看key对应的槽位。 好了，到现在为止，知道了这个异常在Redis层面出现的原因。那么，这个原因出现的具体原因是什么呢？首先，让我们看一下其Redis配置 正式由于在这里使用单节点的配置方式，才导致上述异常信息。基于Redis集群，应当通过 spring . redis . cluster . nodes = 192.168 .1 .101 : 7001 , 192.168

数据库分片 解决数据库的 可扩展性 。 纵向扩展 增强单一服务器的性能，增强CPU、增加内存… 简单的架构和运维模型 考验单一服务器的性能上线 横向扩展 增加提供服务的服务器数量 更高的可扩展性 会增加架构和运维的复杂度 分片集群 主分片 集群中的每个数据库都会选择一个分片作为主分片 主分片 存储所有不需要分片的集合 创建数据库时，数据最少的分片被选为主分片 分片片键 那我们如何确定每篇文档应该被分配到哪个分片上呢，这个时候就需要用到 分片片键 。 片键值被用来 将集合中的文档划分 为数据段 片键必须对应一个 索引或索引前缀 （单键或复合键均可） 可以使用片键值的哈希值来生成哈希片键 如何合理的选择片键 片键值的 范围广 （可使用复合片键扩大范围） 片键值的 分布更均衡 （可使用复合片键平衡分布） 片键 不要单向增大/减小 （可使用哈希片键） 数据段的分裂 随着用户的插入请求，单个分片的数据段也会变多扩大，如果数据段达到一定数值，则会 自动触发数据段的分裂 。 数据段尺寸过大或包含过多文档时触发数据段分裂 只有 新增/更新文档 时才可能自动触发数据段分裂 数据段分裂通过更新 元数据 来实现 集群的平衡 一个分片可能有多个数据段，上面提到数据段尺寸变大会触发数据段的分裂，假如说一个分片中分裂出的数据段过多，也会触发平衡机移动数据段到数据段少的分片，使各个分片中的数据均衡分配。

uiautomator2+opencv-python基于图片识别算法实现自动化统计页面加载时间DEMO： 一、实践要点记录 1.uiautomator2实现UI操作 2.opencv-python基于图片识别算法，机器判断图片加载完成 3.过程： #点击页面入口时开始记录时间start_time # 边加载页面边截图 # 定义一个标准，哈希值范围是0-64，哈希值越小，图片越相似 # 当加载完成的页面和预期页面相似度高（python opencv 图片相似度 的算法），如哈希算法，当哈希值小于某个值，判断为加载完成 # 记录此时的时间点end_time # 终止截图、图片对比循环过程 # 计算时间差，即页面加载时间=end_time-start_time 4.代码实现： #encoding utf-8 import uiautomator2 as u2 from time import sleep from uiautomator2.ext.htmlreport import HTMLReport import pytest import allure import os from Tools import logger#自己封装的logger from Tools import compimgs_similar#封装了python opencv 图片相似度 的算法 import