2

The In-Memory-DB should be initialized/loaded from the filesystem DB. Later the In-Memory-DB should be written back to the filesystem.

What is the best approach here? Should I "simply" copy the tables, or is there an other way?

Please ignore the fact that In-Memory data might get lost, for what ever reason.

Chriss
  • 5,157
  • 7
  • 41
  • 75
  • And what happens if power is lost to the system? Say goodbye to all the data you just wrote to your database! "Causing a lot of I/O operations" is not necessarily a bad thing in and of itself, perhaps you should explain **why** this is a problem you (think) you need to solve. – Ian Kemp Nov 04 '20 at 14:18
  • 1
    @IanKemp No need to downvote, its a tecnical question, let me edit it first. – Chriss Nov 04 '20 at 14:59
  • At the end of the day, your approach will probably work. But are you **certain** that NAND write endurance is actually a problem here? Unless you're using very low-quality NAND, and/or your device is performing a disproportionately large number of writes to the DB, and/or the device is expected to last many years without being replaced, it's likely that trying to implement a solution that could lead to data loss is going to take more time and effort, and cause a lot more pain in the long run, than simply using better NAND or just replacing the device every so often. – Ian Kemp Nov 04 '20 at 15:19
  • Assuming that you **do** need to limit writes, I would instead suggest some sort of buffering system: a queue that holds the most recent N events, and when that queue gets full, then bulk write it to the underlying storage. This means you will lose only the events in that queue on power loss, while the write count will be decreased by a factor of N. That for me is a simpler, safer solution that should be good enough to mitigate any NAND P/E cycle issues. – Ian Kemp Nov 04 '20 at 15:26

0 Answers0