The webinar will start soon... Elasticsearch Performance Optimisation

Transcription

1 The webinar will start soon... Performance Optimisation 1

2 whoami Alan Hardy Sr. Solutions Architect NEMEA 2

3 Webinar Housekeeping & Logistics Slides and recording will be available following the webinar Please ask questions via Q&A 3

4 Our topics: Performance Optimization across: Nodes Indices and Shards Hot/Warm Data Tiers Queries Mappings Wrap up and Q&A 4

5 Application Search Metrics Site Search APM Enterprise Search Business Analytics Logging Security Analytics Future Solutions Kibana Visualize & Manage Elastic Stack Store, Search, & Analyze Beats Logstash Ingest SaaS Self Managed Elastic Cloud Elastic Cloud Enterprise Standalone Deployment

6 Quick Start Beats, and Kibana Beats FILEBEAT WINLOGBEAT HEARTBEAT METRICBEAT Uniform Nodes (3+) Kibana PACKETBEAT AUDITBEAT File Spool Queue 6 All product names, logos, and brands are property of their respective owners and are used only for identification purposes. This is not an endorsem ent.

7 Flexible ingestion and input sources Beats FILEBEAT WINGLOGBEAT Master (3) HEARTBEAT METRICBEAT Logstash Ingest (X) Coordinating (X) Kibana PACKETBEAT AUDITBEAT Data Hot (X) Kafka Data Warm (X) Data store Web APIs Redis Messaging Queue Workers (2+) Alerting (X) Social Sensors Machine Learning (2+) 7 All product names, logos, and brands are property of their respective owners and are used only for identification purposes. This is not an endorsem ent.

8 8 Nodes

9 Node Types Nodes can play one or more roles, for workload isolation and scaling Master (3) Ingest (2+) Coordinating (0+) Data Hot (2+) Data Warm (2+) Alerting (0+) Machine Learning (0+) Master Nodes Control the cluster, requires a minimum of 3, one is active at any given time Data Nodes Hold indexed data and perform data related operations Differentiated Hot and Warm Data nodes can be used Ingest Nodes Use ingest pipelines to transform and enrich before indexing Coordinating Nodes Route requests, handle search reduce phase, distribute bulk indexing All nodes function as coordinating nodes Alerting Nodes Run alerting jobs Machine Learning Nodes Run machine learning jobs 9 All product names, logos, and brands are property of their respective owners and are used only for identification purposes. This is not an endorsem ent.

10 Omni-nodes If you start small Query Input Master, Data, Ingest, Coordinating, Machine Learning, Alerting, Cross Cluster Search Node Master, Data, Ingest, Coordinating, Machine Learning, Alerting, Cross Cluster Search Node Master, Data, Ingest, Coordinating, Machine Learning, Alerting, Cross Cluster Search Node Response 10 All product names, logos, and brands are property of their respective owners and are used only for identification purposes. This is not an endorsem ent.

11 Dedicated Nodes & Vertical Scaling Introduce separation of duties, vertical scaling Master Nodes Query Input Response Coordinating Nodes Data Nodes Machine Learning Nodes 11 All product names, logos, and brands are property of their respective owners and are used only for identification purposes. This is not an endorsem ent.

12 Hardware Recommendations For On-Premise or IaaS Cloud Deployments SEARCH 1:16 HOT 1:32 WARM OR UNIFORM 1:64 COOL 1:96 Data volumes are guidelines 1 TB 2 TB 4 TB 6 TB Logstash Kibana Heavy Worker 16 CPU cores 32 GB RAM Any Storage Heavy Instance (Search) 8+ CPU cores 64 GB RAM SSD Heavy Instance (Hot) 8+ CPU cores 64 GB RAM SSD Heavy Instance (Warm) 8 CPU cores 64 GB RAM SSD, SAN, SATA Heavy Instance (Cool) 8 CPU cores 64 GB RAM SSD, SAN, SATA Heavy Reporting 2 CPU cores 8 GB RAM Any Storage Logstash Kibana Regular Worker Ingest Machine Learning Regular 8 CPU cores 16 GB RAM Any Storage 8 CPU cores 32 GB RAM Any Storage 8 CPU cores 64 GB RAM Any Storage 2 CPU cores 4 GB RAM Any Storage Logstash Light Worker 4 CPU cores 8 GB RAM Any Storage Tribe or Cross-Cluster 4 CPU cores 16 GB RAM Any Storage Coordinating 4 CPU cores 16 GB RAM Any Storage 12 All product names, logos, and brands are property of their respective owners and are used only for identification purposes. This is not an endorsem ent. Master 4 CPU cores 8 GB RAM Any Storage * Data volumes are guidelines

13 13 Indices and Shards

14 The Basics DATA NODE I SHARD 0 PRIMARY SHARD 1 REPLICA SHARD 0 REPLICA SHARD S E G M E N T SHARD 1 PRIMARY INDEX 14 DATA NODE II

15 Indices, Shards, and Segments Tips for clusters of any size Indices take up CPU, RAM How many indices shards should I have? Well, it depends. But no more than 25 per GB of Java heap space on the data node. How big should a shard be? Well, it depends. Shards take up CPU, RAM Segments take up CPU, RAM, File Handles But between 1-10 GB for a fulltext search use case, and GB for a time series use case. We are changing the default # of shards from 5 to 1 in

16 Index Operations SHARD SHARD S E G M E N T _forcemerge SEGMENT SHARD SHARD SHARD SHARD SHARD SHARD _shrink SHARD SHARD INDEX _reindex INDEX INDEX-ALT 16

17 Moar Index Operations INDEX M docs _rollover INDEX-001 INDEX-002 INDEX _alias INDEX INDEX-ALT 17

18 18 Hot/Warm Data Tiers

19 Data Node Hardware Varying disk:ram ratios result in control over fast ßà cheap Data volumes are guidelines SEARCH 1:16 HOT 1:32 WARM OR UNIFORM 1:64 COOL 1:96 1 TB 2 TB 4 TB 6 TB Data Node (Search) Data Node (Hot) Data Node (Warm) Data Node (Cool) 8+ CPU cores 64 GB RAM SSD 8+ CPU cores 64 GB RAM SSD 8 CPU cores 64 GB RAM SSD, SAN, SATA 8 CPU cores 64 GB RAM SSD, SAN, SATA 19 * Data volumes are guidelines

20 Inside a Large Logging Cluster Reduce infrastructure costs, isolate workloads, and manage data lifecycle Master Input Alerting Nodes Query Response Ingest/ Coordinating Nodes Hot Data Nodes Curator Warm Data Nodes Machine Learning Nodes Coordinating Nodes 20

21 Ingest performance tips with hot/warm (match # of written-to shards with # of hot nodes) Increase refresh rate setting 21

22 22 Query Performance

23 Query profiler Reduce # of network hops with dedicated coordinating nodes Reduce # of shards needed to answer query (add filters, reduce shard count) Reduce # of nodes needed to answer query (increase replicas) Index sorting 23

24 : Dedicated Coordinating Nodes QUERY WITHOUT: 1 Load Balancer 2 DATA NODE DATA NODE DATA NODE SCATTER/G ATHER PROCESS 4 3 QUERY WITH: 1 COORDINATING NODE 5 INDEX A SHARD 1 INDEX A SHARD 2 INDEX A SHARD 3 Advantages: Offloading scatter/gather process from data nodes Improvements for read side as well as bulk write side No load balancer needed: clients can round-robin or run their own Coordinating Node SCATTER/G ATHER PROCESS

25 : Custom Routing QUERY QUERY What it is: WITHOUT: WITH: Load Balancer In cases where we often filter by a common field, can use that field s value to split the data across shards such that all data of a particular value always ends up in a single shard. 1 1 COORDINATING NODE SCATTER/G ATHER PROCESS SCATTER/G ATHER PROCESS DATA NODE DATA NODE DATA NODE INDEX A SHARD 1 INDEX A SHARD 2 INDEX A SHARD 3 Advantages: Less hops Significantly reduced shard hit Combine with index sorting for crazy-fast searching 25

26 26 Mapping Carving

27 27 Reducing features such as index, doc_values improves ingest rate, disk usage, memory pressure, query performance

28 Questions?

29 Thank You Web : Products : Forums : Community : Twitter Contact us :