Persistence recommendation

I have an RPI-3 with around 700 items.
Now i run JDBC MariaDB as persistence against a Synology with Maria DB 10.
Now it is really slow on startup and restoring all values.
What do you recommend to speed up startup?

/Mike

Try mapDB, it stores one value per item only, so not historical data, but quick for restore on startup. Just for the record, you will then need to modify your rules so that the correct persistence service is queried if you do charting or use historical values in calculations.

1 Like

I go with @lipp_markus
MadDB is made for that

For his second point, just make sure your default db remains the same and you should be ok.
You will need to remove the restoreOnStartUp setting in Maria or you’ll get conflicts.

+1 for MapDB
~500 items being restored on startup here: 13 seconds, 162 milliseconds OH2 service full startup (OH2.4.0.S1460) with several bindings kicking in also.

Is it not any issues with ssd wearout with mapdb?

/Mike

Why would there be?

Alot of writing on ssd?

/mike

If you have a busy system (lot of item updates), mapdb will write a lot to the disk as well.

Maybe but with the SDD controller smoothing out the NAND gates wear the Write level of a 250GB SSD is still between 60Tb and 120Tb

See:

According to tests the Write level is actually way higher than that

So even with 12TB in 250 days you’d expect a 4 year life for your drive before it fails but realistically it will be double that.

The best way to deal with that would be to move the MAPdb database to RAM and get it committed to file only when booting and/or stopping OH.

That would be a nice feature.

/Mike

You can do that today by configuring mapdb to write to /tmp or whatever you have mounted as tmpfs.

But this is missing the point and big picture Even if you move mapdb, any other persistence service, any of the writes to log files, any swapping will still keep hitting your disk.
SD cards are worse than SSDs but both are affected by wearout sooner or later, and counting TBW isn’t really properly accounting for the fact that it’s always the same files/sectors on disk again and again that OH is writing to.
Check out this standard post.

OH don’t do that. The drive controller does that. And SSDs should manage that and move the writes around the disc to balance the wear level. At least the good ones do.

Well, a) you don’t know if yours is ‘a good one’ and b) this is a common misconception. SSDs are built with a multi-user fileservice in mind where the sum of users keeps creating/deleting files over and over. Wear levelling does not work well or even not at all when you keep writing to existing files which is what you typically do in OH persistence and logging. It’s even worse with SD because SSDs still have a DRAM cache to ‘collect’ many write commands and bundle them into one, but don’t get fooled to believe wear levelling will apply always.

@mstormi You would need to find an exceedingly cheap SSD for anything like what you wrote to apply. And by that I mean something like an SD-card or USB stick, which I wouldn’t even call an SSD, but it might apply to the OP question about the RPI-3. Modern SATA/PCIe SSDs, even cheap ones, are very unlikely to suffer from the problems you listed.