- Relational Databases
- Concurrency Control
- Distributed databases
- random read is important.
- OK, some databases use it
- No, we cannot control the memory-disk ourself
mmap + msync + madvise.
- IMDB, influxdb, sqlite, mongodb use it.
- File storage
- Page layout
- tuple layout
- data representation
- system catalogs
- maintaining 1 or more database files
- organize files like collection of pages.
Page is like page in System, but managed by database.
Organization of pages in memory: Page manage like operating systems… You can have pd and pe.
For bulk operations in index order a larger page size can give a noticeable, sometimes significant, performance increase. For very random access, particularly many small writes, there is similar potential for significant performance reduction.
Header | Data
Header fixed size.
tuple can be stored SLOTTED
Header || slots —> || <— tuples ||
Log structure like bitcask, I wrote it XD.
- build indexs
- periodically compact logs
- header for:
- visibility info
- bit map
we can denormalize the tuple data, if b->a, you can store B-A, called pre-join.
mongodb use it.
Recordid : Page + bios/slot
- tuple: sequential of bytes.
- data storage
- TIME/DATE/TIMESTAMP: 32/64 bits unix epoch
- varchar/TEXT/BLOB: header with length and follow by data
- can use overflow to store data outside
- can use external files
DB has oltp and olap, here is image: http://cacm.acm.org/magazines/2011/6/108651
n-ary: called nsm, row storage.
dsm: use fixed-length offset or tuple id to represent
memory <—> disk
- Spacial control
- temporal control
Page table has:
- dirty flag
- Pin/Reference counter
UnpinPage will be used to manage pages.
I’m not familiar with pre-fetching, so don’t ask me…
I also know nothing about scan sharing…
most os use
O_DIRECT to avoid system cache.