#community-help

Discussing Multi-tenant Indexing and Typesense Clusters

TLDR Semyon enquired about search and indexing performance for multi-tenant indexing. Virginio suggested using Typesense cloud, but Semyon noted the cost difference against bare metal instances. Jason proposed vertical scaling before multi-cluster setup.

3mo

Join the chat

Jul 11, 2023 (3 months ago)

Photo of md5-4b1d6636a0bc33b8dc831071ebf091bd

Semyon

02:01 PM

Hi everyone! I am building an application with multi-tenant indexes with lots of users (and consequently lots of data). I am wondering how it will affect the search and indexing performance, is there a point where I should consider orchestrating multiple typesense instances for this purpose instead?

Photo of md5-71a4ca653165a513ae254236605feb2c

Virginio

02:14 PM

i think the best option is using typesense cloud, so with that you don't need manage the infraestructure.

Semyon

02:29 PM

• I don't think just using typesense cloud solves the question I've asked, since indexing performance and search performance are still relevant concerns. By the end of the day they sell something pretty close to raw compute (which is good I think, but doesn't abstract my issues away).
• It is quite pricey relative to the other options which are in my opinion quite accessible even though lots of cloud brainwashed people may argue with this statement. I am talking about renting bare metal instance. For example, 64 Gb of RAM on typesense cloud will amount to 1000$ for the simplest, no high availability setup. In contrast I can rent the same hardware for 40$ from Hetzner and get typesense up and running in 20 minutes. Just saying…

Virginio

02:45 PM

😮 $1000 vs $40 is huge saving, so if you can do that and manage typesense, i think you can follow this information to create your cluster based on typesense recommendations:
https://typesense.org/docs/guide/high-availability.html#configuring-a-typesense-cluster
🙂

Photo of md5-8813087cccc512313602b6d9f9ece19f

Jason

03:06 PM

In general, I would recommend first scaling up vertically (add RAM / CPU to each node in a single Typesense cluster), before going to multiple Typesense clusters, just to avoid the additional ops overhead.

Within a single cluster, a good way to shard is to split the data into multiple collections when it reaches say 10s of millions of records and you notice slowdowns for the types of search queries you’re doing (different search params consume different amount of CPU cycles)

Semyon

03:12 PM

Thank you very much for the response!

Typesense

Lightning-fast, open source search engine for everyone | Knowledge Base powered by Struct.AI

Indexed 2786 threads (79% resolved)

Join Our Community Manage subscription

Similar Threads

Switching from Elastic to Typesense on k8s Cluster

Nicolo needed to know capabilities and features of Typesense. Jason and William provided explanations and shared experiences using it along with documentation links. Nicolo appreciated the insights.

20mo

Optimizing Typesense Implementation for Large Collections

Oskar faced performance issues with his document collection in Typesense due to filter additions. Jason suggested trying a newer Typesense build and potentially partitioning the data into country-wise collections. They also discussed reducing network latency with CDN solutions.

9mo

Addressing Typesense Server Issues and Optimization Needs

Robert had an issue with a 'stuck' typesense server. Jason and Kishore Nallan gave advice on handling writes, configuration for high search volumes, and running multiple typesense instances. They also recommended monitoring CPU usage and updating the server version for bug fixes.

12mo