Are You Sure You Want to Use MMAP in Your Database Management System? (2022)
This is a pretty old argument and IMO it&#x27;s far out of date&#x2F;obsolete.<p>Taking full control of your I&#x2F;O and buffer management is great if (a) your developers are all smart and experienced enough to be kernel programmers and (b) your DBMS is the only process running on a machine. In practice, (a) is never true, and (b) is no longer true because everyone is running apps inside containers inside shared VMs. In the modern application&#x2F;server environment, no user level process has accurate information about the total state of the machine, only the kernel (or hypervisor) does and it&#x27;s an exercise in futility to try to manage paging etc at the user level.<p>As Dr. Michael Stonebraker put it: The Traditional RDBMS Wisdom is (Almost Certainly) All Wrong. <a href="https:&#x2F;&#x2F;slideshot.epfl.ch&#x2F;play&#x2F;suri_stonebraker" rel="nofollow noreferrer">https:&#x2F;&#x2F;slideshot.epfl.ch&#x2F;play&#x2F;suri_stonebraker</a> (See the slide at 21:25 into the video). Modern DBMSs spend 96% of their time managing buffers and locks, and only 4% doing actual useful work for the caller.<p>Granted, even using mmap you still need to know wtf you&#x27;re doing. MongoDB&#x27;s original mmap backing store was a poster child for Doing It Wrong, getting all of the reliability problems and none of the performance benefits. LMDB is an example of doing it right: perfect crash-proof reliability, and perfect linear read scalability across arbitrarily many CPUs with zero-copy reads and no wasted effort, and a hot code path that fits into a CPU&#x27;s 32KB L1 instruction cache.