ES 作为一个分布式搜索引擎,从扩展能力和搜索特性上而言无出其右,然而它有自身的弱势存在,其作为近实时存储系统,由于其分片和复制的设计原理,也使其在数据延迟和一致性方面都是无法和 OLTP(Online Transaction Processing)系统相媲美的。也正因如此,通常它的数据都来源于其他存储系统同步而来,做二次过滤和分析的。这就引入了一个关键节点,即 ES 数据的同步写入方式,本文介绍
在持续建设基于 ES 的跨域数据聚合服务中发现 ES 的很多特性跟 MySQL 等常用数据库差别较大,本文会分享 ES 的实现原理、在直播平台中的业务选型建议及实践中遇到的问题和思考。Elasticsearch 是一种分布式的、近实时的海量数据存储、检索与分析引擎。我们常说的“ELK”就是指 Elasticsearch、Logstash / Beats、Kibana 组成的具备收集、存储、检索和可
继上文在完成了从千万级到亿级商品量级搜索系统的搭建后,本文将继续介绍一些扩容无法解决的 ES 性能问题,即对相关 ES 搜索引擎的稳定性治理实践。希望通过本文大家可以对 ES 的使用场景有更多数据和使用上的参考。回顾:
从 0 到 1 搭建亿级商品 ES 搜索引擎完成了第一阶段 ES 搜索引擎的搭建后,
随着业务的发展问题也逐渐开始暴露,起源是在某次大促活动下线的时候,ES 集群某个机房 CPU
11在 KubeCon CN 2023 的「 Open AI + 数据 | Open AI + Data」专题中,火山引擎软件工程师胡元哲分享了《 使用 KubeRay 和 Kueue 在 Kubernetes 中托管 Ray 工作负载|Sailing Ray workloads with KubeRay and Kueue in Kubernetes 议题。以下是本次演讲的文字稿。本文将从