Design problem: Updating database from a low latency C++ application

I am developing a low latency application in C++. I also need to update the databases of my processing and all state chan开发者_StackOverflowges. In order to save on latency involved in calling Database updates, I am using local data structures (in-memory) in my application.

But I still need to update databases also. Should I use a separate thread for updating databases? How can I save on database latency and still keep the databases up-to-date.

For minimal latency, you'll definitely want a database thread (I"ll call it DBT).
However, if updates are frequent, you'll want to buffer changes, and have the DBT merge whatever updates it can before they get pushed to the actual database. If player.x = 1, then player.x = 2, the DBT can skip the first one. If updates are very fast, and the data set isn't immense, you may consider regular full dumps instead of running updates. Eg, like "saving" what you're doing every 60 seconds, instead of sending the database a list of every action done. The answer would depend a lot on what you're doing. There isn't a one-size-fits-all answer here.

There is one definitely good solution: save to database as seldom as possible. You dont have to call saving every second, in most cases you can safely call DB once per minute or even less frequently.

Combining the given answers and applying my own thoughts, I am thinking of implementing the following strategy:- - On the fly, update the local data structure and dump to a file rather than database - A separate thread for database will read from a file and dump it to database (actually will have to take a lock and move the existing file and copy the contents to database)

What you say? Any loopholes in this solution above.