Market moves from external range liquidity to internal range liquidity because of inefficiencies / imbalances in the market. It's certainly not an amateur way, however one must combine that with other entry level models to take an entry. @nikhilalgo…
@ANL
1. I store tick data in a hyper table and have 5mins, 15mins, 1 hour materialised view on it which has continuous aggregate policy meaning these views will update as soon as there's new tick, similar to what you see on trade charts. I am doin…
@ANL Thanks for your input! I've actually been using TimescaleDB, and it has worked quite well for me in terms of storage, computation, and accessibility. It's a powerful choice for managing time-series data within a PostgreSQL environment. While Re…
@ANL You're absolutely right, handling real-time tick data for 650 instruments is no easy feat. To address this, I use TimescaleDB with continuous aggregates. It allows to precompute and continuously update data like OHLCV, ensuring minimal processi…
@ANL Check out the config here - https://aws.amazon.com/ec2/instance-types/ and cost comparison over here - https://instances.vantage.sh/?min_memory=16&min_vcpus=4. Go for linux machines instead of windows/mac, you'll save significantly on costs…
@ANL Which machine and config you're using / planning to use on AWS? Based on my experience, AWS is more reliable even in comparison with high end PC as network/electricity in some areas aren't in our control.
Coming to the cost aspects, I am usin…
It's a common belief that "buy market orders are matched with sell market orders," but the actual dynamics might differ. Considering the functioning of most exchange matching engines, the lowest ask typically takes precedence. This is because the ex…
The core idea is to estimate buying and selling volume based on how the current price relates to the bid-ask spread:
If the price moves towards (or beyond) the ask, it indicates buying activity.
If the price moves towards (or below) the bid, it ind…
Hey, I figured out the second query as well! For those of you trying to determine aggressive buying and selling volumes from tick data, here's a method I followed -
highest_bid = max([bid['price'] for bid in tick['depth']['buy']])
lowest_ask = min(…
Adding below the codes for community's benefit to compute volume for different time intervals based on the logic we discussed in this thread, I am using TimescaleDB to store tick level data and aggregating it to different time intervals in real time…
Thanks @rakeshr , can you see my second query and see if it's possible to derive this type of data? Platforms like GoCharting provides this type of data in real time and it doesn't look computationally heavy based on the pricing they are charging an…
Thanks buddy for the detailed explanation. I am familiar with the basics of the order book and how volume represents completed transactions where bids match offers. My query primarily revolves around the differentiation of volume, specifically in th…
Thanks for the response. Your approach aligns with what I had in mind. I'm not sure why Zerodha doesn't provide volume directly in their tick data; it might help avoid confusion.
This clears up one aspect for me. Now, I'm wondering how we can diffe…
