Hi All,
Re data read/write performance; here are my 2 cents.
I think this is a very relative topic, and only relative to this thread since Chris is making a true trading class library 'platform'. What really matters imo is 'where' you are going to host your database, and 'how often' you are going to read/write data to it. Based on these dynamics driven by trading style - you have a plethora of options open to you. From local databases/file structures to cloud blobs / tables or relational database. Each can be appropriate (if not optimal) based on these underlying dynamics, and are somewhat relative to the complexity/scale of the platform design. It becomes a sliding scale at the end of the day, but some general patterns emerge. Use memory not a database/file for high frequency trading. Ensure the client/processing end of your trading system is hosted in the same location (data center) as any stored data. Balance your tick data time frames against requirements and associated processing loads. (there is no sense bottlenecking your system CPU and I/O unnecessarily) How many instruments do you also intend to trade? What kind of reliability / SLA factors do you need? Analyse hosting costs / initial setup fees / ongoing costs relative to your IO frequency and size - and incorporate this into your technology selection and hosting location choices.
Then, you can worry less about different individual platform/service performance metrics, understanding that at the end of the day, if you can afford performance - you can buy it, and it is only getting faster each day; and focus on what matters 'most' (the trading strategies) which if profitable, will allow you to buy/account for any future desired/required data i/o performance requirements. This can be summarized also by concept of 'cost of entry', as for example to build a per tick high frequency automated trading platform is obviously going to require more investment/resources/complexity relative to a system which only stores and process hourly or daily data.
So whilst there is not perfect system I think, I would recommend to anyone building any form of automated trading is to ensure you are using cloud based services and not local user/system run-time applications/files/databases. I see many great 'little applications' people have built that will never scale appropriately at a code level (even if they are profitable or look pretty) because they were not built with a platform architecture mindset. Cloud services allow you to be A) more modular in your designs and B) provide optimal stability / performance / redundancy scale-ability. I see so many blogs of python script hack job trading 'code' that it brings me to tears that they (and the MT4/5 community EA people) don't understand the value of a system that can reboot, update, and have an internet outage gracefully.
Re data read/write performance; here are my 2 cents.
I think this is a very relative topic, and only relative to this thread since Chris is making a true trading class library 'platform'. What really matters imo is 'where' you are going to host your database, and 'how often' you are going to read/write data to it. Based on these dynamics driven by trading style - you have a plethora of options open to you. From local databases/file structures to cloud blobs / tables or relational database. Each can be appropriate (if not optimal) based on these underlying dynamics, and are somewhat relative to the complexity/scale of the platform design. It becomes a sliding scale at the end of the day, but some general patterns emerge. Use memory not a database/file for high frequency trading. Ensure the client/processing end of your trading system is hosted in the same location (data center) as any stored data. Balance your tick data time frames against requirements and associated processing loads. (there is no sense bottlenecking your system CPU and I/O unnecessarily) How many instruments do you also intend to trade? What kind of reliability / SLA factors do you need? Analyse hosting costs / initial setup fees / ongoing costs relative to your IO frequency and size - and incorporate this into your technology selection and hosting location choices.
Then, you can worry less about different individual platform/service performance metrics, understanding that at the end of the day, if you can afford performance - you can buy it, and it is only getting faster each day; and focus on what matters 'most' (the trading strategies) which if profitable, will allow you to buy/account for any future desired/required data i/o performance requirements. This can be summarized also by concept of 'cost of entry', as for example to build a per tick high frequency automated trading platform is obviously going to require more investment/resources/complexity relative to a system which only stores and process hourly or daily data.
So whilst there is not perfect system I think, I would recommend to anyone building any form of automated trading is to ensure you are using cloud based services and not local user/system run-time applications/files/databases. I see many great 'little applications' people have built that will never scale appropriately at a code level (even if they are profitable or look pretty) because they were not built with a platform architecture mindset. Cloud services allow you to be A) more modular in your designs and B) provide optimal stability / performance / redundancy scale-ability. I see so many blogs of python script hack job trading 'code' that it brings me to tears that they (and the MT4/5 community EA people) don't understand the value of a system that can reboot, update, and have an internet outage gracefully.
