Live data from Hacker News

Are You Sure You Want to Use MMAP in Your Database Management System? (2022)

db.cs.cmu.edu

21–30 of 182 posts

Re: Are You Sure You Want to Use MMAP in Your Database Management System? (2022)

#21
post #11

Many general-purpose OS abstractions start leaking when you're working on systems-like software. You notice it when web servers are doing kernel bypass to for zero-copy, low-latency networking, or database engines throw away the kernel's page cache to implement their own file buffer.

Web servers doing kernel bypass for zero-copy networking? Do you have a specific example in mind? I'm curious.

Re: Are You Sure You Want to Use MMAP in Your Database Management System? (2022)

#22
Another interesting limitation of mmap() is that real-world storage volumes can exceed the virtual address space a CPU can address. A 64-bit CPU may have 64-bit pointers but typically cannot address anywhere close to 64 bits of memory, virtually or physically. A normal buffer pool does not have this limitation. You can get EC2 instances on AWS with more direct-attached storage than addressable virtual address space on the local microarchitecture.

Re: Are You Sure You Want to Use MMAP in Your Database Management System? (2022)

#24
post #2

Memory-Mapped Files = access violations when a disk read fails. If you're not prepared to handle those, don't use memory-mapped files. (Access violation exceptions are the same thing that happens when you attempt to read a null pointer) Then there's the part with writes being delayed. Be prepared to deal with blocks not necessarily updating to disk in the order they were written to, and 10 seconds after the fact. Thi…

Linux throws a SIGBUS. A process should anticipate such I/O failures by implementing a SIGBUS handler, especially a database server.

For the second part of your comment, on Linux systems, there is the msync() system call that can be used to flush the page cache on demand.

Re: Are You Sure You Want to Use MMAP in Your Database Management System? (2022)

#26
post #13

Old timers will recall when using mmap was a prominently promoted selling point for the “no sql” dbms.

For documents it made access fast since there’s no joins, etc. that require paging from all over. The problem ended up being updates and compaction issues.

My memory is that the problem was ACID. The document stores didn’t promise to be reliable because apparently that didn’t scale.

And there was a very well known cartoon video discussion about it with “web scale” and “just write to dev null” and other classics that became memes :)

Re: Are You Sure You Want to Use MMAP in Your Database Management System? (2022)

#27
post #20

Earlier quoted context omitted.

mmap can be handy but usually is not a good idea when you care about ACID properties. So it tends to be most useful outside databases.

Can you give some examples where mmap is useful?

If your data is likely to already be in the system cache, memory mapping can achieve zero copying of the data, whereas reading will perform at least one memcpy. So there can be a performance advantage depending on the usage pattern.

Also, I've never tested this, but I believe mapped files will get flushed as long as the system stays running. So if you only need resilience against abnormal termination rather than system crashes, it seems like a good option?

Re: Are You Sure You Want to Use MMAP in Your Database Management System? (2022)

#28
post #21
post #11

Many general-purpose OS abstractions start leaking when you're working on systems-like software. You notice it when web servers are doing kernel bypass to for zero-copy, low-latency networking, or database engines throw away the kernel's page cache to implement their own file buffer.

Web servers doing kernel bypass for zero-copy networking? Do you have a specific example in mind? I'm curious.

Probably the most common example is sendfile() for writing file contents out to a socket without reading them into userspace:

https://man7.org/linux/man-pages/man2/sendfile.2.html

Re: Are You Sure You Want to Use MMAP in Your Database Management System? (2022)

#29
It sounds like a lot of the performance issues are TLB-related. Am I right in thinking huge-pages would help here? If so, it's a bit unfortunate they didn't test this in the paper.

Edit: Hm, it might not be possible to mmap files with huge-pages. This LWN article[1] from 5 years ago talks about the work that would be required, but I haven't seen any follow-ups.

[1]: https://lwn.net/Articles/718102/

Re: Are You Sure You Want to Use MMAP in Your Database Management System? (2022)

#30

Old timers will recall when using mmap was a prominently promoted selling point for the “no sql” dbms.

seems like all databases are moving towards the middle. Postgres has JSON support, MongoDB has transactions and also a columnar extension for OLAP type data. NoSQL seems almost meaningless as a term now. Feels like a move towards a winner takes all multi-modal database that can work with most types of data fairly well. Postgres with all of it's specialized extensions seems like it will be the most popular choice. The convenience of not having to manage multiple databases is hard to beat unless performance is exponentially better, Postgres with these extensions can probably be "good enough" for a lot of companies

reminds me of how industries typically start out dominated by vertically integrated companies, move to specialized horizontal companies, then generally move back to vertical integration due to efficiency. Car industry started this way with Ford, went away from it, and now Tesla is doing it again. Lots of other examples in other industries

Post reply on HN