ip分片重组会用到哪几个字段 es 索引规范？
es 索引规范？
您必须手动指定切片数量。
碎片的数量会影响查询效率。
有两种情况:
数据量大，碎片数少。会影响单个片段的查询效率。导致最终查询时间缓慢。
数据量不大，但切片太多。碎片太多会影响聚合效率，也会导致最终查询变慢。
不建议使用
redis集群如何解决key不均匀？
对于分布式存储系统的架构和运行管理来说，保证每个节点的数据存储容量和请求数量尽可能均衡是非常重要的。本文介绍了导致 "倾斜 "Redis大型集群运行维护中的数据请求及规避措施。严重的影响 "倾斜 "Redis的数据容量或请求量是从运维的角度来解释的。当数据容量和请求量倾斜时，Redis中几十个节点的集群存在一些痛点:
来自几个或单个节点的请求数量是 "过热 "，导致Redis分布式系统失去了可扩展性和集群的意义，类似于MongoDB_id字段作为切片键；导致运维能力规划，扩容困难；增加了自动配置管理的难度；单个集群节点应尽可能统一参数配置；监控报警很复杂(容量、QPS、连接数阈值等。).那么让我们 让我们看看那些经常导致严重后果的场景倾斜 "生产环境中的Redis集群。
普通的 "倾斜 "Redis集群场景一般是由于DBA规划不当和业务密钥空间设计不合理造成的。
DBA规划集群时或者扩展后，数据槽(hash bucket)的位分布不均匀，造成内存容量、键数和请求QPS倾斜；服务的关键空间设计不合理，所谓 "热键 "导致少量键的大QPS操作；这种节点的QPS过载；程序中使用了大量的Keys hash标签，可能导致一些数据槽中有大量的key；程序有一个很大的簇键(hash，set，l。Ist等。)，导致大密钥所在节点的容量和QPS很高；工人和教师执行Monitor等命令，导致当前节点客户端的输出缓冲区增加，used_memory_rss扩大，导致节点内存容量增加。接下来，当集群内存容量、键数或QPS请求数严重倾斜时，就要调查定位问题了。
Redis集群的故障排除倾斜 "检查集群每个段的数据槽是否均匀分布。
让 s以Redis Cluster集群为例，确定集群中每个节点负责的数据槽和键的数量。以下演示的一些例子并不轻微倾斜 "，但不严重，可以考虑再平衡。
检查节点热点键并确定顶部命令。
使用redis-faina，最好有一个实时分析平台。从下面的例子可以看出，两个前缀键的QPS比基本都是各50%，明显是热点键；您还可以看到auth命令的顶部命令。
程序是否大量使用了密钥散列标签？
这可能导致数据存储量和QPS不一致的问题。scan可以用来扫描keyspace中是否有hash标签，或者monitor，可以用vc-redis-sniffer。
该程序是否使用大型设置密钥？
例如，一个1kw字段的哈希键占用几GB的内存。这种set key一次操作几个字段，所以很难从proxy或者sdk找到key的大小。可通过redis-cli -bigk:和业务确认音)。在实际生产业务场景中，大规模集群很难做到集群的完全平衡，只要尽量保证不出现严重的倾斜问题即可。
那个 这是我的看法。你怎么看待这个问题？欢迎在下方评论区交流~我是科技领域的创作者，有十年互联网行业经验。欢迎关注我了解更多科技知识！
版权声明：本文内容由互联网用户自发贡献，本站不承担相关法律责任.如有侵权/违法内容,本站将立刻删除。
