先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7
深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年最新软件测试全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
如果你需要这些资料，可以添加V获取：vip1024b （备注软件测试）
正文
归根结底，你要让es性能要好，最佳的情况下，就是你的机器的内存，至少可以容纳你的总数据量的一半
比如说，你一共要在es中存储1T的数据，那么你的多台机器留个filesystem cache的内存加起来综合，至少要到512G，至少半数的情况下，搜索是走内存的，性能一般可以到几秒钟。
如果最佳的情况下，我们自己的生产环境实践经验，最好是用es就存少量的数据，就是你要用来搜索的那些索引，内存留给filesystem cache的，就100G，那么你就控制在100gb以内，相当于是，你的数据几乎全部走内存来搜索，性能非常之高，一般可以在1秒以内
所以尽量在es里，就存储必须用来搜索的数据，比如说你现在有一份数据，有100个字段，其实用来搜索的只有10个字段，建议是将10个字段的数据，存入es，剩下90个字段的数据，可以放mysql，hadoop hbase，都可以。
这样的话，es数据量很少，10个字段的数据，都可以放内存，就用来搜索，搜索出来一些id，通过id去mysql，hbase里面去查询明细的数据
2、用更快的硬件资源
（1）给filesystem cache更多的内存资源
（2）用SSD固态硬盘
（3）使用本地存储系统，不要用NFS等网络存储系统
（4）给更多的CPU资源
3、document模型设计
document模型设计是非常重要的，不要在搜索的时候才想去执行各种复杂的乱七八糟的操作。es能支持的操作就是那么多，不要考虑用es做一些它不好操作的事情。如果真的有那种操作，尽量在document模型设计的时候，写入的时候就完成。另外对于一些太复杂的操作，比如join，nested，parent-child搜索都要尽量避免，性能都很差的。
在搜索/查询的时候，要执行一些业务强相关的特别复杂的操作：
（1）在写入数据的时候，就设计好模型，加几个字段，把处理好的数据写入加的字段里面
（2）自己用java程序封装，es能做的，用es来做，搜索出来的数据，在java程序里面去做，比如说我们，基于es，用java封装一些特别复杂的操作
4、预先index data
为了性能，提前优化data index时的数据模型，比如说document有一个price field，然后大多数查询都对一个固定的范围，对这个field使用range范围查询，那么可以提前将这个price的范围处理出来，写入一个字段中。比如下面这样：
PUT index/type/1
{
“designation”: “spoon”,
“price”: 13
}
GET index/_search
{
“aggs”: {
“price_ranges”: {
“range”: {
“field”: “price”,
“ranges”: [
{ “to”: 10 },
{ “from”: 10, “to”: 100 },
{ “from”: 100 }
]
}
}
}
}
我们完全可以增加一个price_range字段：
PUT index
{
“mappings”: {
“type”: {
“properties”: {
“price_range”: {
“type”: “keyword”
}
}
}
}
}
然后写入的时候，直接计算出来这个range：
PUT index/type/1
{
“designation”: “spoon”,
“price”: 13,
“price_range”: “10-100”
}
然后搜索的时候，就可以直接用term查询了，性能非常高：
GET index/_search
{
“aggs”: {
“price_ranges”: {
“terms”: {
“field”: “price_range”
}
}
}
}
5、预热filesystem cache
如果我们重启了es，那么filesystem cache是空壳的，就需要不断的查询才能重新让filesystem cache热起来，我们可以先说动对一些数据进行查询。比如说，你本来一个查询，要用户点击以后才执行，才能从磁盘加载到filesystem cache里，第一次执行要10s，以后每次就几百毫秒。你完全可以，自己早上的时候，就程序执行那个查询，预热，数据就加载到filesystem cahce，程序执行的时候是10s，以后用户真的来看的时候就才几百毫秒。
6、避免使用script脚本
说实话，一般是避免使用es script的，实际生产中更是少用，性能不高，尽量不要使用
7、使用固定范围的日期查询
尽量不要使用now这种内置函数来执行日期查询，因为默认now是到毫秒级的，是无法缓存结果，尽量使用一个阶段范围，比如now/m，就是到分钟级
那么如果一分钟内，都执行这个查询，是可以取用查询缓存的
PUT index/type/1
{
“my_date”: “2016-05-11T16:30:55.328Z”
}
GET index/_search
{
“query”: {
“constant_score”: {
“filter”: {
“range”: {
“my_date”: {
“gte”: “now-1h”,
“lte”: “now”
}
}
}
}
}
}
完全可以替换为：
GET index/_search
{
“query”: {
“constant_score”: {
“filter”: {
“range”: {
“my_date”: {
“gte”: “now-1h/m”,
“lte”: “now/m”
}
}
}
}
}
}
磁盘读写性能优化
优化磁盘空间的占用，减少磁盘空间的占用，更多的数据可以进入filesystem cache。比如说你原来，磁盘空间占用一共是1T，内存只有512G，现在优化了磁盘空间占用之后，减少了数据量，可能数据量就只有512G了，那么就可以全部进入内存
1、禁用不需要的功能
聚合，搜索，评分，近似匹配
聚合：doc values
搜索：倒排索引，index
评分：norms
近似匹配：index_options（freqs）
任何一个功能不需要，就把对应的存储的数据给干掉，这样可以节约磁盘空间的占用，也可以优化磁盘的读写性能
默认情况下，es在写入document到索引的时候，都会给大多数的field增加一份doc values，就是正排索引，用来进行聚合或者排序的。比如说，如果我们有一个叫做foo的数字类型field，我们要对这个字段运行histograms aggr聚合操作，但是可能我们并不需要对这个字段进行搜索，那么就可以禁止为这个字段生成倒排索引，只需要doc value正排索引即可。
禁用倒排索引：
PUT index
{
“mappings”: {
“type”: {
“properties”: {
“foo”: {
“type”:“integer”,
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注软件测试）
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
o的数字类型field，我们要对这个字段运行histograms aggr聚合操作，但是可能我们并不需要对这个字段进行搜索，那么就可以禁止为这个字段生成倒排索引，只需要doc value正排索引即可。
禁用倒排索引：
PUT index
{
“mappings”: {
“type”: {
“properties”: {
“foo”: {
“type”:“integer”,
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注软件测试）
[外链图片转存中…(img-jmuioSqa-1713125880076)]
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
扫一扫
1141
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
