You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We've already discussed this topic several times, it's better to collect all thoughts/requirements/ideas in one place so that we can make the decision faster when we decide to move on with the migration.
### Why do we think about the migration? 1. The speed of SELECT queries degraded dramatically, and we have the feeling that it couldn't be improved in the current setup 2. I'm afraid that in one day we will have issues with the speed of INSERTs (it's not the bottleneck still; if we will meet this problem, the hotfix is to add the partitions)
### The results of the discussions
We anyway need to use relational DB: it suits the nature of the data perfectly
Partitioning does not solve the main problem, we still have the same CPU limit
We are thinking about the sharded solution (read: partitioning on several machines), the main candidate for now is https://www.singlestore.com
It would be great to have the ability to share the dump of the DB to help the users run their own Indexer without the requirement to wait several weeks for collecting all historical data (see Postgres dump #187)
We've already discussed this topic several times, it's better to collect all thoughts/requirements/ideas in one place so that we can make the decision faster when we decide to move on with the migration.
### Why do we think about the migration? 1. The speed of
SELECT
queries degraded dramatically, and we have the feeling that it couldn't be improved in the current setup 2. I'm afraid that in one day we will have issues with the speed ofINSERT
s (it's not the bottleneck still; if we will meet this problem, the hotfix is to add the partitions)### The results of the discussions
The text was updated successfully, but these errors were encountered: