As concerning using tarantool's SQL dialect I should say that's not so good idea as you could think. This way produces additional overhead and complicates the application code. You should plan your scheme like in traditional RDBMS. That's why I choose stored procedures on Lua.
Order's information should be encoded by using msgpack or json format and stored in spaces like KV.
Tarantool memory engine used only for orders which could be traded (active orders and pending orders). After filling order have to be stored in postgres. There are two tables for it: ticks - information about price changes after each deal and orders_history - completed, cancelled orders.
As you noticed there is issue with performance linked with size of that tables. But there is easy way to overcome this issue - using Timescale extension for Postgresql.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
As concerning using tarantool's SQL dialect I should say that's not so good idea as you could think. This way produces additional overhead and complicates the application code. You should plan your scheme like in traditional RDBMS. That's why I choose stored procedures on Lua.
Order's information should be encoded by using msgpack or json format and stored in spaces like KV.
Tarantool memory engine used only for orders which could be traded (active orders and pending orders). After filling order have to be stored in postgres. There are two tables for it:
ticks- information about price changes after each deal andorders_history- completed, cancelled orders.As you noticed there is issue with performance linked with size of that tables. But there is easy way to overcome this issue - using Timescale extension for Postgresql.