- Più recenti
- Maggior numero di voti
- Maggior numero di commenti
Hello, please see my thoughts below:
-
Elasticsearch is designed to scale horizontally. They'd need to keep on eye on the monitoring but they can simply add additional nodes to the cluster should resources start becoming strained. Overtime they'll learn how big their indexes and shards are and be able to calculate if they need additional nodes when adding a new tenant. See this blog re petabyte scale https://aws.amazon.com/blogs/database/run-a-petabyte-scale-cluster-in-amazon-elasticsearch-service/ it recommends no more than 30,000 shards in a cluster.
-
ES isn't really designed for modifications. There are two things to consider: a. The total number of documents being indexed per second - the modification will count as a reindex. If the cluster is struggling with indexing again Elasticsearch can scale horizontally so this isn't an issue. b. Performance. Elasticsearch doesn't delete from the index when a document is deleted. I've previously had indexes of 10s of millions of records with 10s of millions of deleting and haven't noticed much of a performance issue. We rearchitected the solution to time based indexes so we had less deleted docs per index. This also allowed us to run force merge on the older indicies once they weren't being written to any longer. DO NOT RUN FORCE MERGE ON AN INDEX THAT IS STILL BEING WRITTEN TO. So it is probably worth a conversation about the data and whether it fits nicely in time or size based indexes e.g. emailMessage-TenantId20190527 and rolls weekly, or emailMessageTenantId0001 and it rolls when it reaches a certain size.
-
Unfortunately not on this. However whilst talking of tools this tool is quite useful for managing indexes https://www.elastic.co/guide/en/elasticsearch/client/curator/current/index.html
Hope that helps.
Contenuto pertinente
- AWS UFFICIALEAggiornata un anno fa
- AWS UFFICIALEAggiornata 2 anni fa
- AWS UFFICIALEAggiornata 2 anni fa