先自我介绍一下,小编浙江大学毕业,去过华为、字节跳动等大厂,目前阿里P7
深知大多数程序员,想要提升技能,往往是自己摸索成长,但自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年最新软件测试全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上软件测试知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新
如果你需要这些资料,可以添加V获取:vip1024b (备注软件测试)
正文
深入原理推荐:
- Elasticsearch之如何合理分配索引分片? https://www.elastic.co/cn/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster
- Elasticsearch究竟要设置多少分片数? https://qbox.io/blog/optimizing-elasticsearch-how-many-shards-per-index
1.2、数据动态持续写入场景
如果存在连续写入到Elasticsearch集群的数据流,如:实时爬虫互联网数据写入ES集群。则应使用基于时间的索引以便更轻松地维护索引。
如果写入数据流的吞吐量随时间而变化,则需要适当地改变下一个索引的配置才能实现数据的动态扩展。
那么,如何查询分散到不同的基于时间索引的所有文档?答案是别名。可以将多个索引放入别名中,并且对该别名进行搜索会使查询就像在单个索引上一样。
当然,需要保持好平衡。注意思考:将多少数据写入别名?别名上写入太多小索引会对性能产生负面影响。
例如,是以周还是以月为单位为单位建立索引是需要结合业务场景平衡考虑的问题?
如果以月为单位建议索引性能最优,那么相同数据以周为单位建立索引势必会因为索引太多导致负面的性能问题。
深入原理推荐:Elasticsearch索引管理利器——Curator深入详解
1.3、Index Sorting
注意:索引排序机制是6.X版本才有的特性。
在Elasticsearch中创建新索引时,可以配置每个分片中的分段的排序方式。 默认情况下,Lucene不会应用任何排序。 index.sort.* 定义应使用哪些字段对每个Segment内的文档进行排序。
使用举例:
curl -X PUT “localhost:9200/twitter” -H ‘Content-Type: application/json’ -d’
{
“settings” : {
“index” : {
“sort.field” : “date”,
“sort.order” : “desc”
}
},
“mappings”: {
“properties”: {
“date”: {
“type”: “date”
}
}
}
}
目的:index sorting是优化Elasticsearch检索性能的非常重要的方式之一。
**大白话:**index sorting机制通过写入的时候指定了某一个或者多个字段的排序方式,会极大提升检索的性能。
更深原理:推荐阅读:https://www.elastic.co/cn/blog/index-sorting-elasticsearch-6-0
2、分片层面优化配置
分片是底层基本的读写单元,分片的目的是分割巨大索引,让读写并行执行。写入过程先写入主分片,主分片写入成功后再写入副本分片。
副本分片的出现,提升了集群的高可用性和读取吞吐率。
在优化分片时,分片的大小、节点中有多少分片是主要考虑因素。副本分片对于扩展搜索吞吐量很重要,如果硬件条件允许,则可以小心增加副本分片的数量。
容量规划的一个很好的启动点是分配分片,“《深入理解Elasticsearch》强调:最理想的分片数量应该依赖于节点的数量。”其数量是节点数量的1.5到3倍。
分配副本分片数的公式:max(max_failures,ceil(num_nodes /) num_primaries) - 1)。
原理:如果您的群集具有num_nodes节点,总共有num_primaries主分片,如果您希望最多能够同时处理max_failures节点故障,那么适合您的副本数量为如上公式值。
公式来源:https://www.elastic.co/guide/en/elasticsearch/reference/master/tune-for-search-speed.html
总的来说:节点数和分片数、副本数的简单计算公式如下:
所需做大节点数=分片数*(副本数+1)。
3、Elasticsearch整体层面配置
配置Elasticsearch集群时,最主要的考虑因素之一是确保至少有一半的可用内存进入文件系统缓存,以便Elasticsearch可以将索引的hot regions保留在物理内存中。
在设计集群时还应考虑物理可用堆空间。 Elasticsearch建议基于可用堆空间的分片分配最多应为20个分片/ GB,这是一个很好的经验法则。
例如,具有30 GB堆的节点最多应有600个分片,以保持集群的良好状态。
一个节点上的存储可以表述如下:节点可以支持的磁盘空间= 20 (堆大小单位:GB)(以GB为单位的分片大小)
由于在高效集群中通常会看到大小在20到40 GB之间的分片,
因此最大存储空间可以支持16 GB可用堆空间的节点,最多可达12 TB的磁盘空间(201640=12.8TB)。
边界意识有助于为更好的设计和未来的扩展操作做好准备。
可以在运行时以及初始阶段进行许多配置设置。
在构建Elasticsearch索引和集群本身以获得更好的搜索性能时,了解在运行时哪些配置可以修改以及哪些配不可以修改是至关重要的。
3.1 动态设置
1、设置历史数据索引为只读状态。
基于时间的动态索引的执行阶段,如果存放历史数据的索引没有写操作,可以将月度索引设置为只读模式,以提高对这些索引的搜索性能。
6.X之后的只读索引实战设置方式:
PUT /twitter/_settings
{
“index.blocks.read_only_allow_delete”: null
}
2、对只读状态索引,进行段合并。
当索引设置为只读时,可以通过强制段合并操作以减少段的数量。
优化段合并将导致更好的搜索性能,因为每个分片的开销取决于段的计数和大小。
- 注意1:不要将段合并用于读写索引,因为它将导致产生非常大的段(每段> 5Gb)。
- 注意2:此操作应在非高峰时间进行,因为这是一项非常耗资源的操作。
段合并操作实战方式:
curl -X POST “localhost:9200/kimchy/_forcemerge?only_expunge_deletes=false&max_num_segments=100&flush=true”
3、使用preference优化缓存利用率
有多个缓存可以帮助提高搜索性能,例如文件系统缓存,请求缓存或查询缓存。
然而,所有这些缓存都维护在节点级别,这意味着如果您在拥有1个或更多副本且基于默认路由算法集群上连续两次运行相同的请求,这两个请求将转到不同的分片副本上 ,阻止节点级缓存帮助。
由于搜索应用程序的用户一个接一个地运行类似的请求是常见的,例如为了检索分析索引的部分较窄子集,使用preference标识当前用户或会话的偏好值可以帮助优化高速缓存的使用。
preference实战举例:
GET /_search?preference=xyzabc123
{
“query”: {
“match”: {
“title”: “elasticsearch”
}
}
4、禁止交换
可以在每个节点上禁用交换以确保稳定性,并且应该不惜一切代价避免交换。它可能导致垃圾收集持续数分钟而不是毫秒,并且可能导致节点响应缓慢甚至断开与集群的连接。
在Elasticsearch分布式系统中,让操作系统终止节点更有效。可以通过将bootstrap.memory_lock设置为True来禁用它。
Linux系统级配置:
sudo swapoff -a
Elasticsearch配置文件elasticsearch.yml配置:
bootstrap.memory_lock: true
5、增加刷新间隔 refresh_interval
默认刷新间隔为1秒。这迫使Elasticsearch每秒创建一个分段。实际业务中,应该根据使用情况增加刷新间隔,举例:增加到30秒。
这样之后,30s产生一个大的段,较每秒刷新大大减少未来的段合并压力。最终会提升写入性能并使搜索查询更加稳定。
更新刷新间隔实战:
PUT /twitter/_settings
{
“index” : {
“refresh_interval” : “1s”
}
}
6、设置index.merge.scheduler.max_thread_count
index.merge.scheduler.max_thread_count默认设置为Math.max(1, Math.min(4, Runtime.getRuntime().availableProcessors() / 2))。
但这适用于SSD配置。对于HDD,应将其设置为1。
实战:
curl -XPUT ‘localhost:9200/_settings’ -d '{
“index.merge.scheduler.max_thread_count” : 1
}
7、禁止动态分配分片
有时,Elasticsearch将重新平衡集群中的分片。此操作可能会降低检索的性能。
在生产模式下,需要时,可以通过cluster.routing.rebalance.enable设置将重新平衡设置为none。
PUT /_cluster/settings
{
“transient” : {
“cluster.routing.allocation.enable” : “none”
}
}
其中典型的应用场景之包括:
- 集群中临时重启、剔除一个节点;
- 集群逐个升级节点;当您关闭节点时,分配过程将立即尝试将该节点上的分片复制到集群中的其他节点,从而导致大量浪费的IO. 在关闭节点之前禁用分配可以避免这种情况。
更多实践,推荐阅读:https://www.elastic.co/guide/en/elasticsearch/reference/5.5/restart-upgrade.html
8、充分利用近似日期缓存效果
现在使用的日期字段上的查询通常不可缓存,因为匹配的范围一直在变化。
然而,就用户体验而言,切换到近似日期通常是可接受的,并且能更好地使用查询高速缓存带来的益处。
实战如下:
GET index/_search
{
“query”: {
“constant_score”: {
“filter”: {
“range”: {
“my_date”: {
“gte”: “now-1h/m”,
“lte”: “now/m”
}
}
}
}
}
}
这里可能不大好理解,推荐深入阅读:https://www.elastic.co/guide/en/elasticsearch/reference/current/tune-for-search-speed.html
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
需要这份系统化的资料的朋友,可以添加V获取:vip1024b (备注软件测试)
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
//www.elastic.co/guide/en/elasticsearch/reference/current/tune-for-search-speed.html>
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
需要这份系统化的资料的朋友,可以添加V获取:vip1024b (备注软件测试)
[外链图片转存中…(img-FkwfShcF-1713300079620)]
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!