Currently, my program have a lot of sessions at memory. Session is the object with unsigned int ID, some variables + possible long size std::map (different size from session to session).
I want to unload some sessions to disk, but does not know how to organize structure on the disk to have opportunity for fast session finding on disk to load it when need. How to fast find session by ID on disk? Maybe some indexes, but does not know how to use them… or maybe some additional variable?
*SQL Database * is not my variant, because stability, resource overuse, portability, compability etc. etc. etc. need to organize something like other databases do on disk.
thanks, and sorry for my english. please, edit my text if it have mistakes
Why on so many sites such as this do so many answer a simple question with, “Why do you want to do that?” or offer alternatives that are not answering the person? (Read the “Your Answer” box at the bottom of this page) It may be that there are better ways, or the person is pretty much wasting their time. But, they may be trying just for the fun of trying and coming up with a solution no matter how well it functions. @abrahab obviously wants to have a go at doing this (and he’s tried to make that very clear) so let him, just answer his question or if you don’t know the answer keep quiet.
@abrahab, one way is to use a binary file format to store the session data. Use a btree index for the session ids (Google btree) saved in a separate file, the value stored in the btree under each session id is a file pointer to the position in the data file where the binary record starts. The first bytes (short int, int, long) read from the file tell you the length of the record in bytes, read in those bytes and process them. Up to you to define the format of the session record (struct, whatever). If you edit/delete/insert a record you must update the btree for that record and any record being re-positioned within the data file.
It’s easier to use a DB but if this is what you want to do this will work and performance should be very good. If you want to search for specific values within the record you could build another btree with those values but that would be when to seriously consider going down the DB route.