-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
I'm thankful for their OpenZFS tuning doc which they developed as part of this server migration: https://github.com/letsencrypt/openzfs-nvme-databases
The one thing that I get hung up on when it comes to ZFS and SSDs is the wear pattern vs. HDDs. Take for example this quote from the README.md:
>We use RAID-1+0, in order to achieve the best possible performance without being vulnerable to a single-drive failure.
Failure on SSDs is predictable and usually expressed with Terabytes Written (TBW). Failure on spinning disk HDDs is comparatively random. In my mind, it makes sense to mirror SSD-based vdevs only for performance reasons and not for data integrity. The reason is that the mirrors are expected to fail after the same amount of TBW, the availability/redundancy guarantee is relatively unreliable.
Maybe someone with more experience in this area can change my mind, but if it were up to me, I would have used the mirror drives as hot-spares, and relied on a local HDD-based zpool for quick backup/restore capability.
Why are you assuming that their workload includes just one query per emitted certificate?
The reality is that they are storing information during challenges, implementing rate limiting per-account, supporting OCSP validation and a few other things.
You can investigate further if you really want to see the queries that they make against the database since their software (Boulder) is open source [1]. Most queries are in the files in the "sa" (storage authority) folder.
[1] https://github.com/letsencrypt/boulder/