note
note copied to clipboard
Yhzhtk
知识代码笔记
### 问题引出 我之前的一篇博客 [数据库并发不一致分析](http://yhzhtk.info/2014/06/16/database-consistency-lock.html) 有提到过事务隔离级别以及相应加锁方式、能够解决的并发问题。 > 标准情况下，在 RR(Repeatable Read) 隔离级别下能解决不可重复读（当行修改）的问题，但是**不能解决幻读**的问题。 而之前有看过一篇 mysql 加锁的文章 [MySQL 加锁处理分析](http://hedengcheng.com/?p=771)，里面有提到一点： > 对于Innodb，Repeatable Read (RR) 针对当前读，RR隔离级别保证对读取到的记录加锁 (记录锁)，同时保证对读取的范围加锁，新的满足查询条件的记录不能够插入 (间隙锁)，**不存在幻读现象**。 那么问题来了，到底 Innodb 中 RR 隔离级别是否能解决幻读呢？ 在 MySQL 加锁处理分析这篇文章下面的评论中，有这样的一个交流：...
OOM killer 是什么意思，可以在网上查一下，很多资料，这里不再解释。 其中有三个相关文件： - /proc/$PID/oom_adj - /proc/$PID/oom_score - /proc/$PID/oom_score_adj 其中 oom_score 表示最终的分数，**该分数越大，越可能被 Killer 杀掉。** 而 oom_adj 是调整分数的，可以设置为负值，会对 oom_score减分。 从Linux 2.6.36开始都安装了/proc/$PID/oom_score_adj，此后将替换为/proc/$PID/oom_adj。详细内容请参考Documentation/feature-removal-schedules.txt。即使当前是对/proc/$PID/oom_adj进行的设置，在内核内部进行变换后的值也是针对/proc/$PID/oom_score_adj设置的。 通过 cat /proc/$PID/oom_score 可以查看进程的得分，下面的脚步是可以查询系统**所有进程**的 oom_score。 ``` ps -eo pid,comm,pmem...
业务处理高并发时经常会遇到死锁问题，要想了解并解决死锁问题，首先得明白 Mysql 不同隔离级别的加锁原理。 在阅读 [MySQL 加锁处理分析] http://hedengcheng.com/?p=771 后有很大收获，摘取主要内容，总结记录一下。 ### 快照读 简单的select操作，属于快照读，不加锁。(当然，也有例外，下面会分析) ``` select * from table where ?; ``` ### 当前读 特殊的读操作，插入/更新/删除操作，属于当前读，需要加锁。 ``` select * from table where ? lock...
之前提过一个Android截屏的方法 #2 就是通过执行系统自带 screencap 保存到SD卡，再从SD卡读取图片并转成Bitmap，这样会启动一个进程，耗费两次IO，速度很慢。 下面给出一个更高效的方法，**将原来需要1500ms的截屏时间缩减到100ms**。 这个方法是读取 读取 /dev/graphics/fb0 文件， 并将字节流转成rgb信息，并转成Bitmap，所有操作都是Java并在内容中，只有一个读取IO，没有启动进程，**速度提升10倍**以上。 ``` FileInputStream graphics = null; try { graphics = new FileInputStream(“/dev/graphics/fb0”); } catch (FileNotFoundException e) { e.printStackTrace(); return null;...
## Introduction Apache Flink提供容错机制来持续恢复数据流应用程序的状态(State)。 该机制确保即使在出现故障时，程序的状态最终可以恢复；在数据流里有两种级别的恢复保障，一是 exactly once，另一种是 at least once（下面会讲），他们可以通过开关调整。 容错机制不断绘制分布式流式数据流的快照。 对于状态较小的流式传输应用程序，这些快照非常轻，可以频繁绘制，而不会对性能产生太大影响。 流应用程序的状态存储位置可以配置（例如主节点或HDFS）。 如果程序失败（由于机器，网络或软件故障），Flink会停止分布式流式数据流。 然后系统重新启动运行节点(Operator)并将其重置为最新的成功检查点。 输入流被重置到状态快照记录的位置。 重新启动的并行数据流，只处理该快照检查点以后的记录，先前检查点状态之前的记录，不再处理(原文贴上，这句话不太好理解 Any records that are processed as part of the restarted parallel dataflow are...
## 个人理解的特点 * 是一个 MySQL 的存储引擎，使用协议语法同 MySQL，接入非常简单； * 列式存储+压缩(最高压缩比30:1)，相同数据量使用机器数少，有效降低机器成本； * 根据数据特性选择压缩算法，如 GZIP， LZ4； * 通过 build on insert, build on select 构建多个额外的 meta 数据，提高查询效率； * 同类产品：Infobright(起源)，Sybase，HANA，Vertica，Greenplum ## 存储结构剖析 HiStore 是按...
## 原始方案 1. 通过补位的方式，如 3, 13, 133 补位为 003， 013， 133，然后通过顺序索引查找 2. 通过boolean or 的方式查找，比如查询 [13, 133]，则组装多个 13 or 14 or 15....or 133的方式 显然，上述两种方式都存在较大问题，补位补多少个0并不确定，or 条件太多性能会极差，超过限制会抛出异常。 ## 新方案 1. 将所有数值编码，满足编码前单调递增，编码后也是单调递增，比如 float...
## 索引构建总结 ### 1. 基于排序的索引构建算法 * 它是一种最原始的在内存中进行倒排的方法 * 基于块的排序索引算法 * 合并排序操作对于基于磁盘的排序来说很高效(避免寻道) ### 2. 内存式单遍扫描索引构建算法 * 没有全局的词典 * 对每个块都生成单独的词典 * 不对倒排记录进行排序 * 有新的倒排记录出现时，直接在倒排记录表中增加一项 ### 3. 采用MapReduce的分布式索引构建算法 ### 4. 动态索引构建算法：多个索引，对数合并 ## 索引压缩...
分词就是对一段文本，通过规则或者算法分出多个词，每个词作为搜索的最细粒度一个个单字或者单词。只有分词后有这个词，搜索才能搜到，分词的正确性非常重要。分词粒度太大，搜索召回率就会偏低，分词粒度太小，准确率就会降低。如何恰到好处的分词，是搜索引擎需要做的第一步。 ### 正确性&粒度 * 分词正确性 * “他说的确实在理”，这句话如何分词？ * “他-说-的确-实在-理” [错误语义] * “他-说-的-确实-在理” [正确语义] * 分词的粒度 * “中华人民共和国宪法”，这句话如何分词？ * “中华人民共和国-宪法”，[搜索 中华、共和国 无结果] * “中华-人民-共和国-宪法”，[搜索 共和 无结果] * “中-华-人-民-共-和-国-宪-法”，[搜索其中任意字都有结果] 分词的粒度并不是越小越好，他会降低准确率，比如搜索 “中秋” 也会出现上条结果，而且粒度越小，索引词典越大，搜索效率也会下降，后面会细说。...