It is pretty hard to suggest anything with just the information you shared, you need to provide more context.
Like, what will the data looks like? It will be the same for each customer? Is it time-series based? What is the average document size? What is the retention needed? What is the event rate per second?
The best way to size an Elasticsearch cluster is doing a Proof of Concept of your use case with a small cluster to see how it will behave and what resources you need, then you can extrapolate with this information.
But assuming 2000 customers and 200 index per customer, you will have something near 400k indices, you will probably need hundreds of nodes for this.
Could you please let me know your thoughts on the below examples?
E.g. Approach 1: 4TB of data with 1000 tenants to implement using single index index per tenant Approach 2: 4TB of data with 1000 tenants to implement using 100 index per tenant
which could be a better approach for scalability and cost-effectiveness.
Could you please let me know your thoughts on the below examples?
E.g. Approach 1: 4TB of data with 1000 tenants to implement using a single index per tenant Approach 2: 4TB of data with 1000 tenants to implement using 100 index per tenant
which could be a better approach for scalability and cost-effectiveness.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.