2 comments

  • dangoodmanUT6 minutes ago
    &gt; DbOptions::durable()<p>&gt; Appended to the WAL without a per-write sync<p>So… it’s not durable? Durable doesn’t mean “survives a process restart”, it means “durably saved to persistent storage”. For example, this “durable” mode wouldn’t survive power loss.
  • nine_k31 minutes ago
    I suppose the insane speed is due to this:<p>&gt; <i>TurboKV&#x27;s persisted Bloom-filter format uses hardware AES.</i><p>Also, built-in LZ4 compression.<p>I would expect SIMD to be used for scans.
    • haberman7 minutes ago
      I assume this is for hashing. I&#x27;ve seen several hashing algorithms turn to hardware AES instructions before, but I haven&#x27;t seen any evidence that this technique outperforms state-of-the-art hashes like RapidHash (<a href="https:&#x2F;&#x2F;github.com&#x2F;Nicoshev&#x2F;rapidhash" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Nicoshev&#x2F;rapidhash</a>) in either quality or speed.
    • rgbimbochamp29 minutes ago
      Those help but the main write speed gain is the WAL, that uses preallocated mmap segments to avoid a write(2) per durable mutation while preserving crash recovery. AES hashing mainly helps Bloom filter point lookups and LZ4 mainly helps SSTable I&#x2F;O. Scans benefit indirectly, but don’t yet use a custom SIMD merge loop.
      • dangoodmanUT12 minutes ago
        Iirc that’s how badger handles the WAL as well