这种打标签的 *** 作可以通过滚动,重启集群实例,因为涉及到重启后的数据恢复问题,可能滚动重启的时间会比较长(根据数据量大小和分片数量决定),可以通过如下的方式,增加数据恢复的最大并行度和数据恢复的最大带宽进行调整,逐步调大到不影响集群业务性能为止。
1、ES 集群异构,机器硬件资源配置不一,有高性能 CPU 和 SSD 存储集群,也有大容量的机械磁盘集群,比如我们的场景就是存放冷数据的集群,服务器都是多年前买的一批满配的 4T Dell R70,但是新扩容的热节点机器均为 DELL 高性能 SSD 磁盘和 CPU 的 R740 机器。
2、对于时间型数据来说,一般是当前的数据,写入和查询较为集中,所以高性能的资源应该优先提供给这些数据使用。
3、集群的搜索和写入性能,取决于最慢节点的性能。
1、ES 的索引已经按照天或者月的时间维度生成索引。
2、 历史 数据相对于近期数据来说没有高频度的查询需求。
本文实现策略:最新的天和月索引均为热数据,其他索引根据查询周期不同,调整为冷数据。当然业务不同策略不同,具体实现策略还是需要根据实际的业务场景来决定。
前置条件
需要修改 ES 集群配置文件,对节点进行打标签 *** 作,配置如下:
热数据实例:
冷数据实例:
修改集群配置需要进行重启实例生效
这种打标签的 *** 作可以通过滚动,重启集群实例,因为涉及到重启后的数据恢复问题,可能滚动重启的时间会比较长(根据数据量大小和分片数量决定),可以通过如下的方式,增加数据恢复的最大并行度和数据恢复的最大带宽进行调整,逐步调大到不影响集群业务性能为止。
设置数据恢复的最大并行度
设置数据恢复的最大带宽
新增索引实现冷热数据分离
集群滚动重启完成之后,已经具备了冷热数据分离的条件,那么如何让新增索引自动成为热数据呢?
答案就是修改 ES 索引的模板,为 ES 索引打 tag,配置实例如下:
只要在索引模板中打了热标签的索引,就会在创建的时候自动分布在集群中实例打了热标签的节点上。
历史 索引实现冷热数据迁移
那么 历史 的 ES 数据如何让其从热节点迁移到冷节点呢?
答案就是,通过 api 修改 ES 索引的标签,将其变更为冷标签,这样 ES 索引就会自动迁移到集群中打了冷标签的实例上,配置如下:
实际生产中会将制定好的冷热数据规则编写成脚本,放到计划任务中,来定时定点的运行,达到热数据自动迁移为冷数据的目的。
熟悉 ES 的同学知道,JVM heap 分配不能超过 32GB,对于使用物理机部署 ES 的环境来说,一台机器的内存往往就动辄 192G 或者 256G,如果只跑一个 ES 实例,只能利用到 32G 的 heap,而且还无法充分发挥 CPU 和 IO 资源,这样显然是不经济的。
因为我们常常会部署单机多实例的 ES 节点,在多实例配置中除了要隔离日志和数据目录之外,还需要增加以下两个配置,不然一台物理机宕机,可能会因为多个副本存在一个 ES 物理机上面导致业务受到影响。
# 执行检查以防止基于主机名和主机地址在单个主机上分配同一分片的多个实例。 默认为 false,表示默认情况下不执行检查。 此设置仅适用于在同一台计算机上启动多个节点的情况。这个我的理解是如果设置为 false,则同一个节点上多个实例可以存储同一个 shard 的多个副本没有容灾作用了。
故名思议,冷数据就是没人访问货很少访问的数据,热数据就是大家都喜欢看的数据。数据存放的介质有SSD、SAS、NLSAS、磁带等,价格和性能成正比,如果把冷数据和热数据都放在性能好的介质中,客户的投入就很高,性价比不好。所以见热数据存放在高速介质中,冷数据存放在廉价介质中做分离。
集中存储中的分层就是根据热度表,对数据进行迁移实现分层存储。
前段时间面试被问到这个问题了? 我的回答也是很简单,总结大概就有两点 :事后我我下去又翻了许多资料,主要总结出一下内容 :
因为Redis是基于内存的 *** 作,CPU不是Redis的瓶颈,Redis的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现,而且CPU不会成为瓶颈,所以 Redis 是单线程的。
IO多路复用是一种同步IO模型,实现一个线程可以监视多个文件句柄;一旦某个文件句柄就绪,就能够通知应用程序进行相应的读写 *** 作;没有文件句柄就绪时会阻塞应用程序,交出cpu。多路是指网络连接,复用指的是同一个线程。
这里可能有不理解的地方,我尝试说一下我的理解 :
进程执行都是顺序执行的,当我们在执行一个 *** 作的时候,进程可能阻塞,此时进程就阻塞在这个调用上,不能执行其他 *** 作。有没有什么解决办法呢 ? 有! 就是上面说的 IO多路复用 。IO多路复用本质上是在同一个线程或进程中,通过拨动开关的方式来执行多个IO *** 作。注意实际上每个IO *** 作都是独立进行的。只是由原来的一对一变成了多对多。
在 Linux 主要有 3 种实现 : select、poll、epoll
select 、poll : 开启一个线程,隔一段时间去询问你是否有完成 *** 作 ,如果完成了,你就去执行。
epoll : 当你可以使用的时候,你发消息去通知,然后执行 。
Redis的VM(虚拟内存)机制就是暂时把不经常访问的数据(冷数据)从内存交换到磁盘中,从而腾出宝贵的内存空间用于其它需要访问的数据(热数据)。通过VM功能可以实现冷热数据分离,使热数据仍在内存中、冷数据保存到磁盘。这样就可以避免因为内存不足而造成访问速度下降的问题。Redis提高数据库容量的办法有两种:一种是可以将数据分割到多个Redis Server上;另一种是使用虚拟内存把那些不经常访问的数据交换到磁盘上。需要特别注意的是Redis并没有使用OS提供的Swap,而是自己实现。
Redis为了保证查找的速度,只会将value交换出去,而在内存中保留所有的Key。所以它非常适合Key很小,Value很大的存储结构。如果Key很大,value很小,那么vm可能还是无法满足需求。
相关配置 :
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)