Mysql-Innodb单表超过2kw逻辑验证
Mysql单表存储不要超过2kw？ 有不少文章在解释，Mysql单表最好不要超过2kw，了解时感觉头头是道实际上漏洞百出经不起推敲。有的人甚至会说Mysql指针大小是6，有的又说是12，搞的一塌糊涂根本不知道什么是什么，怪的很。但最终他们的结论是对的，实在有点难绷，为了避免以后又被这群人搞懵导致记错，写一个简单的笔记记录以下正确的推导过程。 他们的实际依据其实就是当B+树的层数增加，会导致Mysq
JVM及扩展内容介绍
JVM 总的来说，其实JVM包含有JVM内存模型-运行时数据区(Runtime Data Area)、类加载器(ClassLoader)、执行引擎(Execution Enginee)、本地接口(Native Interface)、本地库(Native Libararies) 介绍JVM的时候，其实可以展开为：内存模型、GC回收器、性能调优、双亲委派模型、内部机制 [ 公共表达式处理、JMM AO
GC回收器深入深出
垃圾回收的困境 在早期的JVM回收之中，为了避免出现应该回收的对象没有被回收，不应该被回收的对象(重新被引用)被回收了的情况，往往整个垃圾回收都需要跑在安全点下，也就是所谓的SafePiont。而想要出现所谓的SafePoint出现，那么整个程序本身不能做任何操作，那么这个时间点对于程序来说就好像时停了一样，这个时间段就被称为STW。 稍微一想就知道，STW对于程序的响应速度来说，明显是坏的，越长
ElasticSearch的调优
跟Mysql类似的，ES的调优也可以主要分为几个方面的优化，首先是数据结构的声明方面，其次是ES操作方面的优化，最后是操作系统方面的调优。 在结构方面 在声明mapping的时候，我们可以尽量避免以下的操作来尽量避免影响性能问题出现。 <font color='violet'>少声明字段</font>：如果我们声明字段过多，在写入存储的时候Index Buffer就只能存入更少的文档进行插入；而在
ELK日志架构
首先要明确一点的是，ELK需要以下多个工具组件来结合才能使用： Filebat 轻量级的日志收集工具 Logstash，主要是用来日志的搜集、分析、过滤日志的工具，支持大量的数据获取方式 一般分为两个版本， client 端我们会通过 Filebat 代替；而 server 端则还是使用 Logstash 方实现，并存放到ES之中进行记录。 Elasticsearch，本身是一个开源的分布式搜索引
ElasticSearch部署
ElasticSearch ElasticSearch本体 一般来说，如果我们的服务器能够正常通过wget下载东西的话，我们可以通过以下命令直接进行下载工作： wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-Version-linux-x86_64.tar.gz 下载完毕之后，通过tar -xvf命令进
ElasticSearch基础&查询
ElasticSearch 基本概念 集群 Es集群的特点：多个ES服务器可以组成集群存储大量的数据，并提供相关的服务 高可用性 (服务可用性、数据可用性) 可扩展性 并发量提高、数据量增多的时候，可以增加节点来直接解决。 集群状态 ES将索引和集群的健康情况都做了以下三种状态的区别，每个索引或者集群都会有以下三个状态 健康情况： GREEN 处于健康情况，目前副本分片都在正常运行的状态 Yell
ElasticSearch进阶查询
组合查询 在上面之中我们学习到了 match 和 term 进行查询的时候，只介绍了单个 api 做一个简单的查询效果，没有提供组合查询的效果的效果。 Bool Query，布尔查询效果，可以组合多过滤语句来帮助我们过滤文档。 Boosting Query，通过 positive 块指定匹配文档的评分，同时降低在 negative 块中匹配的文档的得分，提供调整相关性算分的能力 constant_
ElasticSearch集群问题&原理
ElasticSearch搭建集群 构建集群的节点 部署的时候集群节点无非就两种，一种是计算机 / 服务的数量不够，通过单个节点承担多个角色的方式来搭建索引；另外一种就是让单个节点承担单个角色。 对于第一种的情况其实没啥好介绍的，看着来就行了，毕竟资源受限最多也就只能那样了；而针对第二个情况，在资源的分配上可以大概参考以下的图表，配置不同服务节点所在的计算机等。 image-20241010155
ES存储 & 搜索原理
ES索引 倒排索引的实现 问题 倒排索引的实现问题，涉及到存储、快速定位词项本身、词项匹配文档数 分词形成的词项（term）可能是海量的，需要可以在内存和磁盘上高效存储； 既然词项是海量的，那么如何快速找到对应的词项也是个问题； 每个词项对应的文档数可能非常多，也就是上图中文档列表的链表很长； 在词项对应的文档多的情况下，多个文档列表间做交集的效率将是个挑战。 分词的存储结果和针对词项做快速定位其
