邓亚萍20亿做网站,wordpress实名插件,asp.net开发网站好不好,物流企业网站建设特色索引创建后#xff0c;要非常谨慎#xff0c;创建不好后面会出现各种问题。
索引设计的重要性 索引创建后#xff0c;索引分片只能通过_split和_shrink 接口对其进行成倍的增加和缩减。 ES的数据是通过_routing分配到各个分片上的#xff0c;所以本质上不推荐区改变索引的…索引创建后要非常谨慎创建不好后面会出现各种问题。
索引设计的重要性 索引创建后索引分片只能通过_split和_shrink 接口对其进行成倍的增加和缩减。 ES的数据是通过_routing分配到各个分片上的所以本质上不推荐区改变索引的分片数量的因为这样都会对数据进行重新移动。还有就是索引只能新增字段不能对字段进行修改和删除缺乏灵活性所以每次都只能通过_reindex重建索引了还有就是一个分片的大小以及所以分片数量的多少严重影响到了索引的查询和写入性能所以可想而知设计一个好的索引能够减少后期的运维管理和提高不少性能所以前期对索引的设计是相当的重要的。
基于时间的索引设计
Index设计时要考虑的第一件事就是基于时间对Index进行分割即每隔一段时间产生一个新的Index。
因为现实世界的数据是随着时间的变化而不断产生的切分管理可以获得足够的灵活性和更好的性能。 如果数据都存储在一个Index中很难进行扩展和调整因为Elasticsearch中Index的某些设置在创建时就设定好了是不能更改的比如Primary Shard的个数。而根据时间来切分Index则可以实现一定的灵活性既可以在数据量过大时及时调整Shard个数也可以及时响应新的业务需求。 大多数业务场景下客户对数据的请求都会命中在最近一段时间上通过切分Index可以尽可能的避免扫描不必要的数据提高性能。
时间间隔 根据上面的分析自然是时间越短越能保持灵活性但是这样做就会导致产生大量的Index而每个Index都会消耗资源来维护其元信息的因此需要在灵活性、资源和性能上做权衡。 1常见的间隔有小时、天、周和月:先考虑总共要存储多久的数据然后选一个既不会产生大量Index又能够满足于定灵活性的间隔比如你需要存储6个月的数据那么一开始选择“周“这个间隔就会比较合适。 2考虑业务增长速度:假如业务增长的特别快比如上周产生了1亿数据这周就增长到了10亿那么就需要调低这个间隔来保证有足够的弹性能应对变化。
如何实现分割 切分行为是由客户端(数据的写不端)发起的根据时间间隔与数据产生时间将数据写入不同的Index中为了易于区分会在Index的名字中加上对应的时间标识。 创建新Index这件事可以是客户端主动发起一个创建的请求带上具体的Settings、Mappings等信息但是可能会有一个时间错位即有新数据写入时新的ndex还没有建好Elasticsearch提供了更优雅的方式来实现这个动作即Index Template 索引模板
使用索引模板 就是把已经创建好的某个索引的参数设置(settings)和索引映射(mapping)保存下来作为模板在创建新索引时指定要使用的模板名就可以直接重用已经定义好的模板中的设置和映射。 Elasticsearch基于与索引名称匹配的通配符模式将模板应用于新索引也就是说通过索引进行匹配看看新建的索引是否符合索引模板如果符合就将索引模板的相关设置应用到新的索引如果同时符合多个索引模板呢这里需要对参数priority进行比较这样会选择priority大的那个模板进行创建索引。 在创建索引模板时如果匹配有包含的关系或者相同则必须设置priority为不同的值否则会报错索引模板也是只有在新创建的时候起到作用修改索引模板对现有的索引没有影响同样如果在索引中设置了一些设置或者mapping都会覆盖索引模板中相同的设置或者mapping。
索引模板的用途 如果你需要每间隔一定的时间就建立一次索引你只需要配置好索引模板以后就可以直接使用这个模板中的设置不用每次都设置settings和mappings。
创建索引模板
PUT _index_template/logstash-village
{index_patterns: [logstash-village-* // 可以通过logstash-village-*来适配创建的索引],template: {settings: {number_of_shards: 3, //指定模板分片数量number_of_replicas: 2 //指定模板副本数量},aliases: {logstash-village: {} //指定模板索引别名},mappings: { //设置映射dynamic: strict, //禁用动态映射properties: {timestamp: {type: date,format: strict_date_optional_time||epoch_millis||yyyy-MM-dd HH:mm:ss},version: {doc_values: false,index: false,type: integer},name: {type: keyword},province: {type: keyword},city: {type: keyword},area: {type: keyword},addr: {type: text,analyzer: ik_smart},location: {type: geo_point},property_type: {type: keyword},property_company: {type: text,analyzer: ik_smart},property_cost: {type: float},floorage: {type: float},houses: {type: integer},built_year: {type: integer},parkings: {type: integer},volume: {type: float},greening: {type: float},producer: {type: keyword},school: {type: keyword},info: {type: text,analyzer: ik_smart}}}}
}
模板参数 分片设计 所谓分片设计就是如何设定主分片的个数。看上去只是一个数字而已也许在很多场景下即使不设定也不会有问题ES7默认是1个主分片一个副本分片但是如果不提前考虑一旦出问题就可能导致系统性能下降、不可访问、甚至无法恢复换句话说即使使用默认值也应该是通过足够的评估后作出的决定而非拍脑袋定的。
限制分片大小 单个Shard的存储大小不超过30GB。Elastic专家根据经验总结出来大家普遍认为30GB是个合适的上限值实践中发现单个Shard过大超过30GB会导致系统不稳定。 为什么不能超过30GB主要是考虑Shard Relocate过程的负载我们知道如果Shard不均衡或者部分节点故障Elasticsearch会做Shard Relocate在这个过程中会搬移Shard如果单个Shard过大会导致CPU、IO负载过高进而影响系统性能与稳定性。 评估分片数量
单个Index的Primary Shard个数 k * 数据节点个数
在保证第一点的前提下单个Index的Primary Shard个数不宜过多否则相关的元信息与缓存会消耗过多的系统资源这里的k为一个较小的整数值建议取值为1,2等整数倍的关系可以让Shard更好地均匀分布可以充分的将请求分散到不同节点上。 小索引设计
对于很小的Index可以只分配1~2个Primary Shard的
有些情况下Index很小也许只有几十、几百MB左右那么就不用按照第二点来分配了只分配1~2个Primary Shard是可以的。
