try if search works in big datasets
Before https://github.com/huggingface/datasets-server/pull/2641, I wanted to try changing the memory limit.
Maybe it is a dummy doubt, but I don't understand why we have many search replicas when there are a low number of requests (we have only 12 for rows, which is highly requested).
![image](https://github.com/huggingface/datasets-server/assets/5564745/46e8267b-8a5f-4ed4-a89a-40674526923b)
Isn't it better to have less replicas with a high memory limit so that we avoid OOM? (Not sure how it impacts in terms of infra costs) 
I might be wrong but I chose 7 replicas with a 30 GB memory based on:
- Our biggest index with FTS support is 30 GB size:
![image](https://github.com/huggingface/datasets-server/assets/5564745/30657045-216b-4b8c-b486-0785d423ef4b)

I am still investigating, but even with the JOIN with a small stage in the left table at https://github.com/huggingface/datasets-server/pull/2641, duckdb looks to be doing a SEQ_SCAN (full table scan) when retrieving all the columns. (I will ask the duckdb team and document here if possible). Doing a SEQ_SCAN implies almost loading the full table, so, if we have a 30 GB database, in the worst scenario, it will be needed a 30 GB of memory allocated.
 

I am not sure if it is ok to calculate this way, but I am assuming that before, we had 24 replicas with a memory limit of 9 GB, which gives  24*9 = 216 GB, and then 216/30 = 7.2 replicas
try if search works in big datasets: Before https://github.com/huggingface/datasets-server/pull/2641, I wanted to try changing the memory limit.
Maybe it is a dummy doubt, but I don't understand why we have many search replicas when there are a low number of requests (we have only 12 for rows, which is highly requested).
![image](https://github.com/huggingface/datasets-server/assets/5564745/46e8267b-8a5f-4ed4-a89a-40674526923b)
Isn't it better to have less replicas with a high memory limit so that we avoid OOM? (Not sure how it impacts in terms of infra costs) 
I might be wrong but I chose 7 replicas with a 30 GB memory based on:
- Our biggest index with FTS support is 30 GB size:
![image](https://github.com/huggingface/datasets-server/assets/5564745/30657045-216b-4b8c-b486-0785d423ef4b)

I am still investigating, but even with the JOIN with a small stage in the left table at https://github.com/huggingface/datasets-server/pull/2641, duckdb looks to be doing a SEQ_SCAN (full table scan) when retrieving all the columns. (I will ask the duckdb team and document here if possible). Doing a SEQ_SCAN implies almost loading the full table, so, if we have a 30 GB database, in the worst scenario, it will be needed a 30 GB of memory allocated.
 

I am not sure if it is ok to calculate this way, but I am assuming that before, we had 24 replicas with a memory limit of 9 GB, which gives  24*9 = 216 GB, and then 216/30 = 7.2 replicas