Thank you! I'm going to publish some docker-based demo to run it on any machine. Actually, I haven't thought about publishing source code, but I'll think about it
@maxim
thx for the quick reply. May I ask why you sent use pure Lua with Tarantool stored procedures for the whole application? As you might know Tarantool is NoSQL database but supports SQL syntaxes as well thus making other people easier to understand the relations between the "tables".
I also wonder how you are thinking about solving the order details for an order.
I think that you mentioned something about order details in part 2, but not sure if the database was related to it or if it was a model only?
A question, the order book needs to be fast so have do you handle that? Do you remove matched orders, because with time the order table will grow in size very quickly. If you remove the matched orders then it leading to another question who h is related to my first question: how do you solve the order details when the order is removed from the order book? Do you create another table for storing those matched orders so a user can click on any filled or partially filled order to get the order details?
Sorry for my long comment, just want to know how you are thinking about solving it ?
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.
@maxim great article!
But is there any git repo for the source code ? Would be great if you can share.
Best regards Zilveer
Thank you! I'm going to publish some docker-based demo to run it on any machine. Actually, I haven't thought about publishing source code, but I'll think about it
@maxim thx for the quick reply. May I ask why you sent use pure Lua with Tarantool stored procedures for the whole application? As you might know Tarantool is NoSQL database but supports SQL syntaxes as well thus making other people easier to understand the relations between the "tables".
I also wonder how you are thinking about solving the order details for an order.
I think that you mentioned something about order details in part 2, but not sure if the database was related to it or if it was a model only?
A question, the order book needs to be fast so have do you handle that? Do you remove matched orders, because with time the order table will grow in size very quickly. If you remove the matched orders then it leading to another question who h is related to my first question: how do you solve the order details when the order is removed from the order book? Do you create another table for storing those matched orders so a user can click on any filled or partially filled order to get the order details?
Sorry for my long comment, just want to know how you are thinking about solving it ?
Regards Zilveer
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.