Best Practices

so what are the next steps and best practices uh I already mentioned some of the best practices before so always look at your application that it’s using prepared statements it will save time on the server side and you can just send on the parameters instead of wiping the silver Parts the query again and again the important part is also paste queries usually if your data is big for example as I’m planning to have uh like worst case partitions that will have 365 rows it’s not that big but it’s still bigger than for example 10 I should basically have my queries paged and the page or the queries are generally paged by default out of the box with most of the drivers these days but still be careful about it watch it uh if you watched the session with amnon and normally before you already know how to watch for these things in the SQL dashboard so secure dashboard will tell you that you have a non-pepa statements or non-based queries and watch over them and then the important part is something that I mentioned again it is the sizing like because if you for example want to create application that wants to do 500 000 requests per second then of course you won’t be able to do it with three nodes that each one of them will have to CPU so you’ll just simply overload the cluster and uh uh the same goes like for the parallelism sometimes uh people don’t really connect to the server sizing with the client sizing and they just create too many clients and overload the server so there’s always good to have a control over the throttling and parallelism of the client as well so if you know that your cluster is able to maximally withstand 160 000 operations per second then you need to basically have some ways or some means of controlling the person on the clients that you don’t go over this 160 000 operations per second

uh there are some good by the way this this parallelism and all these things we blogged about it you can very easily find the blocks so you can Google for them and you can also check documentation and in documentation we uh suggest some tuning of the drivers as well so you can tune the client and the driver based on your loader machine or your client machine you can specify how many flight processes you want to have you can specify how many connections you want to do or just you can go for the Sila Hardware driver that is specifically tuned for the real-time vacancies and in this case basically you just you just get it uh automatically pre-tuned in a sense and you you can just focus on some fine level tuning and this and this main tuning we’ve already done for even the chargeable driver foreign

and finish your own UI or you can just pick another language and then just play with the rest access in in the language of your choice uh you can use this shardable drivers if you will have time I’ll try to check it maybe we will have so you can I will show it how to use it it’s actually fairly easy in Java because you just overload the drivers from the spring connector and of course you you can like you don’t have to go with my data model tuning with the time series data I think the data model will work fairly well even if you use the default uh compaction strategy incremental or size tiered but I I like uh I suggest or I recommend you to go and check the other compaction strategies and check how basically siwa can handle uh different shapes or different patterns of the data and and make them more accessible and in such case basically it will lower the latencies of accessing the data and of course I mentioned you can go and play with driver itself you can do some advanced Hard level tuning what is the documentation or check the configuration parameters check the sizing of the pool for the driver or as I said in Flight uh sessions and and then play with them tune them