Tagged: ElasticSearch

[转]全文搜索引擎选 ElasticSearch 还是 Solr? 0

[转]全文搜索引擎选 ElasticSearch 还是 Solr?

最近项目组安排了一个任务,项目中用到了全文搜索,基于全文搜索 Solr,但是该 Solr 搜索云项目不稳定,经常查询不出来数据,需要手动全量同步,而且是其他团队在维护,依赖性太强,导致 Solr 服务一出问题,我们的项目也基本瘫痪,因为所有的依赖查询都无结果数据了。所以考虑开发一个适配层,如果 Solr 搜索出问题,自动切换到新的搜索–ES。 其实可以通过 Solr 集群或者服务容错等设计来解决该问题。但是先不考虑本身设计的合理性,领导需要开发,所以我开始踏上了搭建 ES 服务的道路,从零开始,因为之前完全没接触过 ES,所以通过本系列来记录下自己的开发过程。 Please follow and like us:0

[转]超详细的Elasticsearch高性能优化实践 0

[转]超详细的Elasticsearch高性能优化实践

ES 性能调优 ES 的默认配置,是综合了数据可靠性、写入速度、搜索实时性等因素。实际使用时,我们需要根据公司要求,进行偏向性的优化。 写优化 假设我们的应用场景要求是,每秒 300 万的写入速度,每条 500 字节左右。 针对这种对于搜索性能要求不高,但是对写入要求较高的场景,我们需要尽可能的选择恰当写优化策略。 综合来说,可以考虑以下几个方面来提升写索引的性能: 加大 Translog Flush ,目的是降低 Iops、Writeblock。 增加 Index Refresh 间隔,目的是减少 Segment Merge 的次数。 调整 Bulk 线程池和队列。 优化节点间的任务分布。 优化 Lucene 层的索引建立,目的是降低 CPU 及 IO。...

[总结]从10秒到2秒!ElasticSearch性能调优实践 0

[总结]从10秒到2秒!ElasticSearch性能调优实践

做过数据收集、数据开发、数据存储的同学相信对这个简称并不陌生,而 ElasticSearch(以下简称 ES)则在 ELK 栈中占着举足轻重的地位。 前一段时间,我亲身参与了一个 ES 集群的调优,今天把我所了解与用到的调优方法与大家分享,如有错误,请大家包涵与指正。 Please follow and like us:0

[转]基于Elasticsearch分布式搜索引擎的架构原理 0

[转]基于Elasticsearch分布式搜索引擎的架构原理

(1)倒排索引到底是啥? 要了解分布式搜索引擎,先了解一下搜索这个事儿吧,搜索这个技术领域里最入门级别的一个概念就是倒排索引。 我们先简单说一下倒排索引是个什么东西。 Please follow and like us:0

[转]400+节点Elasticsearch集群的运维经验 0

[转]400+节点Elasticsearch集群的运维经验

Meltwater 的工程师通过官方技术博客分享了他们如何运行和维护 400+ 节点的 Elasticsearch 集群。主要介绍了业务中积累的时间序列数据的特点、数据量和每日滚动索引策略,以及他们对 Elasticsearch 版本的选择(没错,目前他们使用的是 1.X,而且做了源码级的修改)、为何不选择托管的云服务、索引结构和分片规划等,最后重点介绍了他们在性能方面的努力和经验,给出了一个性能参考列表。 Please follow and like us:0

[转]日均5亿查询量,京东到家订单中心ES架构演进 0

[转]日均5亿查询量,京东到家订单中心ES架构演进

京东到家订单中心系统业务中,无论是外部商家的订单生产,或是内部上下游系统的依赖,订单查询的调用量都非常大,造成了订单数据读多写少的情况。 我们把订单数据存储在 MySQL 中,但显然只通过 DB 来支撑大量的查询是不可取的。 同时对于一些复杂的查询,MySQL 支持得不够友好,所以订单中心系统使用了 Elasticsearch 来承载订单查询的主要压力。 Please follow and like us:0

[转]携程新一代监控告警平台Hickwall架构演进 0

[转]携程新一代监控告警平台Hickwall架构演进

监控告警是网站可用性的第一道防线,为网站提供更加实时可靠高效的监控告警,对互联网企业具有非凡的意义。致力于这个目标,经过不断地改进,携程新一代监控告警平台 Hickwall 在存储效率、查询速度和告警可靠性方面都有了极大的改善。 本文将从存储、聚合、告警三个方面介绍 Hickwall 在核心架构方面的演进。 Please follow and like us:0

[转]分布式之elk日志架构的演进 0

[转]分布式之elk日志架构的演进

日志系统的必要性? 最早定位生产问题,就是连上一台机器,然后用使用 grep / sed / awk 等 Linux 脚本工具去日志里查找故障原因。如果发现不在这台机器上,就去另一台机器上查日志。有经历过上述步骤的童鞋们,请握个抓! 然而,当你的生产上是一个有几千台机器的集群呢?你要如何定位生产问题呢?又或者,你哪天有这么一个需求,你需要收集某个时间段内的应用日志,你应该如何做? 为了解决上述问题,我们就需要将日志集中化管理。这样做,可以提高我们的诊断效率。同时也有利于我们全面理解系统。 Please follow and like us:0

[转]滴滴Elasticsearch多集群架构实践 0

[转]滴滴Elasticsearch多集群架构实践

Elasticsearch 是基于 Lucene 实现的分布式搜索引擎,提供了海量数据实时检索和分析能力。Elastic 公司开源的一系列产品组成的 Elastic Stack,可以为日志服务、搜索引擎、系统监控等提供简单、易用的解决方案。 Please follow and like us:0

0

[转]手把手教你搭建一个 Elasticsearch 集群

为何要搭建 Elasticsearch 集群 凡事都要讲究个为什么。在搭建集群之前,我们首先先问一句,为什么我们需要搭建集群?它有什么优势呢? 高可用性 Elasticsearch 作为一个搜索引擎,我们对它的基本要求就是存储海量数据并且可以在非常短的时间内查询到我们想要的信息。所以第一步我们需要保证的就是 Elasticsearch 的高可用性,什么是高可用性呢?它通常是指,通过设计减少系统不能提供服务的时间。假设系统一直能够提供服务,我们说系统的可用性是 100%。如果系统在某个时刻宕掉了,比如某个网站在某个时间挂掉了,那么就可以它临时是不可用的。所以,为了保证 Elasticsearch 的高可用性,我们就应该尽量减少 Elasticsearch 的不可用时间。 Please follow and like us:0