The data size is growing, it becomes really hard to handle the load we tend to handle. It leads to different issues like:
150
193
Maybe even #236
After a lot of conversations and brain storming we believe the mentioned issues can be solved using more traditional relational database management system, PostgreSQL in particular.
The main plan is:
Leverage the approach of designing the schemas for the queries (from NoSQL)
Respect the shard layout of nearcore by having multilple database instances
Utilize the partitioning to make the tables smaller, thus more effective
Build up read-replicas
Making this happen we expect to be able to:
serve even more requests per second due to relational db ability to get data in batches effectively
finally implement the long-standing query.access_key_list method (re: #187)
We realize all the disadvantages and complexity that's coming with relational DBMS. No faith in unicorns, we fully understand what we are doing.
Tracking issue
This issue serves the purpose of the container to track the work related to the bigger milestone.
Motivation
The data size is growing, it becomes really hard to handle the load we tend to handle. It leads to different issues like:
150
193
After a lot of conversations and brain storming we believe the mentioned issues can be solved using more traditional relational database management system, PostgreSQL in particular.
The main plan is:
nearcoreby having multilple database instancesMaking this happen we expect to be able to:
query.access_key_listmethod (re: #187)We realize all the disadvantages and complexity that's coming with relational DBMS. No faith in unicorns, we fully understand what we are doing.
Tracking issue
This issue serves the purpose of the container to track the work related to the bigger milestone.