Yes, your NTFS database CAN reach up to 1 GB on a really large modern drive with ACL permissions set all over the place, but so what? When you have several GB of memory free kicking around would you not give that up for far more time on your laptop and quicker responses across the board?

And before you say a word about data integrity, we already have transactional filesystems to solve that problem...

PS - Keep in mind *DATA* and the filesystem database are distinctly different things (with larger files the database actually gets smaller)

When you have several GB of memory free kicking around

But who says that I have several GB of memory free kicking around? Right now my task manager says i have 50 megabytes free (out of 2 GB). Are you perhaps running some stone age operaring system that's incapable of putting the available memory to good use?

Edit: Also it's indexed with B+ trees, so lookup is very fast.

When a feature called "barriers" is turned off, ext4 will detect when a file is constantly being read and write from, and do that entirely in RAM. fsync() has no effect on this. This makes databases insanely fast, but at the cost of possible system integrity. Most desktop OSes turn barriers on, and server OSes tend to turn barriers off.

Bass said:

This is already done at least on Linux. Actually ext4 even caches writes, to hilarious effect.

 

When a feature called "barriers" is turned off, ext4 will detect when a file is constantly being read and write from, and do that entirely in RAM. fsync() has no effect on this. This makes databases insanely fast, but at the cost of possible system integrity. Most desktop OSes turn barriers on, and server OSes tend to turn barriers off.

That's bizarre, I mean usually database severs want to do their own caching, and control disk flushing since they know better than the OS.

CreamFilling512 said:

Bass said:

*snip*

That's bizarre, I mean usually database severs want to do their own caching, and control disk flushing since they know better than the OS.

I don't think most actually do, or if they do, they don't do a particularly good job of it. Really with DBs you expect that if you do an INSERT it will actually happen. So a lot of databases (at least Postgres and SQLite) call fsync after the completion of a simple write operation. Which on barriers enabled FS, tends to block until the data is actually written out to disk. Which is of course, slow.

Without barriers the kernel decides when it feels it is appropriate to actually write the data to disc.This means a lot of file operations (both read and write) are all happening entirely in RAM, and only when the disk is available and it doesn't hamper performence will the kernel persist the contents to disk. This can be as long as 60 seconds after the fsync request was made (or longer?).

You can fine tweak the performance vs data security, but the more data security you want, the less performance you are going to get (and vise-versa). Just a fact of life I guess.

Bass said:

CreamFilling512 said:

*snip*

I don't think most actually do, or if they do, they don't do a particularly good job of it. Really with DBs you expect that if you do an INSERT it will actually happen. So a lot of databases (at least Postgres and SQLite) call fsync after the completion of a simple write operation. Which on barriers enabled FS, tends to block until the data is actually written out to disk. Which is of course, slow.

 

Without barriers the kernel decides when it feels it is appropriate to actually write the data to disc.This means a lot of file operations (both read and write) are all happening entirely in RAM, and only when the disk is available and it doesn't hamper performence will the kernel persist the contents to disk. This can be as long as 60 seconds after the fsync request was made (or longer?).

You can fine tweak the performance vs data security, but the more data security you want, the less performance you are going to get (and vise-versa). Just a fact of life I guess.

Well I'm talking about the commercial database servers where scaling is necessary.  Like Microsoft SQL Server running Hotmail or something.  And if you've ever run MSSQL you know that it will consume all memory on the machine with the out-of-box configuration, because its doing its own disk caching.

CreamFilling512 said:

Bass said:

*snip*

Well I'm talking about the commercial database servers where scaling is necessary.  Like Microsoft SQL Server running Hotmail or something.  And if you've ever run MSSQL you know that it will consume all memory on the machine with the out-of-box configuration, because its doing its own disk caching.

Perhaps, but commercial databases tend to guarantee some kind of data integrity, which is impossible unless they persist the contents of a transaction. I don't think they would use write caching by default, as it is fundamentally dangerous to this objective.

I don't think a well designed DB would do extensive read caching either. It's something that is more readily done by a kernel. As everyone has been saying, that's read caching is what most FS do for you (including NTFS) for free.

A DB can provide detailed information about their file I/O requirements through an mmap call anyway.

Bass said:

CreamFilling512 said:

*snip*

Perhaps, but commercial databases tend to guarantee some kind of data integrity, which is impossible unless they persist the contents of a transaction. I don't think they would use write caching by default, as it is fundamentally dangerous to this objective.

 

I don't think a well designed DB would do extensive read caching either. It's something that is more readily done by a kernel. As everyone has been saying, that's read caching is what most FS do for you (including NTFS) for free.

 

A DB can provide detailed information about their file I/O requirements through an mmap call anyway.

Indeed, transactional databases require non cached writes (and it's not only about filesystem caching but also about hardware caching).

As for read caching: of course they cache reads, it would be insane not to do it. The filesystem has no magic orb to tell it what exactly to cache, read ahead, discard from cache etc.

CreamFilling512 said:

From what I understand from Windows internals stuff.  Any time you open a file regardless of how you do it, its implemented internally using memory-mapped files. File gets mapped to some pages in virtual memory, then it gets brought in by on-demand paging and some heuristics to do basic read-ahead, I imagine the paging file and on-demand paging of EXE/DLLs use the same mechanism.  But any kind of I/O APIs, like C's fread() or whatever, never issues I/O requests, you'll just get I/O requests if it touches some memory-mapped file and gets a page fault.

Yeah Windows has a similar call to mmap, and I assume also does paging.

Dexter said:

Bass said:

*snip*

Indeed, transactional databases require non cached writes (and it's not only about filesystem caching but also about hardware caching).

 

As for read caching: of course they cache reads, it would be insane not to do it. The filesystem has no magic orb to tell it what exactly to cache, read ahead, discard from cache etc.

It doesn't but an OS can accomplish a lot of the intelligent read caching by a paging algorithm, which keeps track of the most commonly read parts of a file. This is easy to implement with the information the kernel gets from mmap and subsequent use of the mmaped space. Most of the performence heavy lifting can be done by the kernel, which knows more about the characters of the persistent store (eg: location of the R/W head, etc).

It would be downright stupid for a DB to take all of this in it's own hands, but I am sure there is some legacy DBs out there who still do all of this, because they were written during a time where MS-DOS was considered advanced.

Bass said:

Dexter said:

*snip*

It doesn't but an OS can accomplish a lot of the intelligent read caching by a paging algorithm, which keeps track of the most commonly read parts of a file. This is easy to implement with the information the kernel gets from mmap and subsequent use of the mmaped space. Most of the performence heavy lifting can be done by the kernel, which knows more about the characters of the persistent store (eg: location of the R/W head, etc).

 

It would be downright stupid for a DB to take all of this in it's own hands, but I am sure there is some legacy DBs out there who still do all of this, because they were written during a time where MS-DOS was considered advanced.

No way man, the OS has no knowledge of the internal structure of the database.  You can certainly get better performance by doing more work.  Database servers optimize their layout on the physical disk.

CreamFilling512 said:

Bass said:

*snip*

No way man, the OS has no knowledge of the internal structure of the database.  You can certainly get better performance by doing more work.  Database servers optimize their layout on the physical disk.

You can optimize the internal structure of the database such that the OS will optimize reads to the fullest.

It's really no different then optimizing instructions, you have no control over branch prediction and cache usage on an x86 processor. But you can still optimize code for branch prediction and cache, by modifying the structure of your program.

Bass said:

Dexter said:

*snip*

It doesn't but an OS can accomplish a lot of the intelligent read caching by a paging algorithm, which keeps track of the most commonly read parts of a file. This is easy to implement with the information the kernel gets from mmap and subsequent use of the mmaped space. Most of the performence heavy lifting can be done by the kernel, which knows more about the characters of the persistent store (eg: location of the R/W head, etc).

 

It would be downright stupid for a DB to take all of this in it's own hands, but I am sure there is some legacy DBs out there who still do all of this, because they were written during a time where MS-DOS was considered advanced.

Any application (big enough, complex enough to worth the effort of doing it) can do better than the kernel at caching because an application will always know better than the kernel what data it needs. The kernel can at best obeserve the reads and the writes and some hints passed through the system calls and do some guesswork based on that. The kernel does not have a time machine to look into the future but the application might just have one.

Dexter said:

Bass said:

*snip*

Any application (big enough, complex enough to worth the effort of doing it) can do better than the kernel at caching because an application will always know better than the kernel what data it needs. The kernel can at best obeserve the reads and the writes and some hints passed through the system calls and do some guesswork based on that. The kernel does not have a time machine to look into the future but the application might just have one.

 

So I don't really agree. I think a program can provide enough hints to a kernel to let the kernel do all the real work. IE: Moving commonly read data to a certain part of a file. Again, similar to x86 optimization.

Bass said:

Dexter said:

*snip*

So I don't really agree. I think a program can provide enough hints to a kernel to let the kernel do all the real work. IE: Moving commonly read data to a certain part of a file. Again, similar to x86 optimization.

Seriously, do you really want/expect a database system to move gigabytes or terrabytes of data around just to keep the kernel happy?

Dexter said:

Bass said:

*snip*

Seriously, do you really want/expect a database system to move gigabytes or terrabytes of data around just to keep the kernel happy?

Why not? Isn't that exactly what happens when you invoke a database optimization?

Sometimes you have to move gigabytes or terrabytes of data to have optimal performance. Look up the hash table data structure.

Bass said:

Dexter said:

*snip*

Why not? Isn't that exactly what happens when you invoke a database optimization?

 

Sometimes you have to move gigabytes or terrabytes of data to have optimal performance. Look up the hash table data structure.

Bad analogy. A hashtable data structure moves data around because there's nothing better it can do. A database can do many things to get the best performance and it does just that.

CreamFilling512 said:

Hints are like, I am going to read sequentially, or I am going to read randomly.  It's not like, here's a hint describing this complex internal data structure that you could write a 10000 page book about.  If the OS was capable of such a level of heuristic it would be super slow, its just optimized for general use.

Listen, once it's in memory (the only thing a DB can actually do on it's own) it's not automagically optimized either. You are going to have to structure your data structures in such a way that they make optimial use of the hardware's cache as well. You can not avoid this. 

A lot of those really complex data structures (eg: the judy array) are so complicated is because they are designed around being cached. They can not cache themselves, because x86 does not allow this. So they must structure their data to be cached by the system implicitly.

Bass said:

CreamFilling512 said:

*snip*

Listen, once it's in memory (the only thing a DB can actually do on it's own) it's not automagically optimized either. You are going to have to structure your data structures in such a way that they make optimial use of the hardware's cache as well. You can not avoid this. 

 

A lot of those really complex data structures (eg: the judy array) are so complicated is because they are designed around being cached. They can not cache themselves, because x86 does not allow this. So they must structure their data to be cached by the system implicitly.

Normally if you are running a database you need to ensure the hard drive caching can be disabled.  It's not just about performance but you can't guarantee transactions with any caching going on outside the control of the server software.

Dexter said:

Bass said:

*snip*

Bad analogy. A hashtable data structure moves data around because there's nothing better it can do. A database can do many things to get the best performance and it does just that.

A modern DB (eg: Drizzle) is going to delegate as much responsibility to the kernel as possible. This makes the code simpler, and this easier to optimize. That's just how it is.

CreamFilling512 said:

Bass said:

*snip*

Normally if you are running a database you need to ensure the hard drive caching can be disabled.  It's not just about performance but you can't guarantee transactions with any caching going on outside the control of the server software.

Well I don't know about Windows, but there numerous parameters you can customize in Linux regarding the functionality of the file system or even the CPU scheduler. You can even swap out file systems and CPU schedulers completely, Linux is open source.

That's actually what Google does, they use the O(1) scheduler with a modern kernel, while the default scheduler tends to be CFS (the "Completely Fair Scheduler"). This is on top many other changes designed to make Linux perform really well for their specialized task.

In Android, Google uses CFS. But they might be adopting the Brain F**k Scheduler (BFS), which is reported to be really f**king fast, and yet it's algorithm is so simple that it's existance is a giant brainf**k of an engima. Kind of like some of Quake 3's rendering algorithms.

Bass said:

CreamFilling512 said:

*snip*

Well I don't know about Windows, but there numerous parameters you can customize in Linux regarding the functionality of the file system or even the CPU scheduler. You can even swap out file systems and CPU schedulers completely, Linux is open source.

That's actually what Google does, they use the O(1) scheduler with a modern kernel, while the default scheduler tends to be CFS (the "Completely Fair Scheduler"). This is on top many other changes designed to make Linux perform really well for their specialized task.

 

In Android, Google uses CFS. But they might be adopting the Brain F**k Scheduler (BFS), which is reported to be really f**king fast, and yet it's algorithm is so simple that it's existance is a giant brainf**k of an engima. Kind of like some of Quake 3's rendering algorithms.

Wasn't IBM working on hybrid drives a few years ago?

I am pretty far removed from my FileStructures course, but if putting the filesystem in 'memory' would speed things up, perhaps it would do to have the filesystem reside on a gig of SSD memory and still keep the files on actual spindles.

I've got a pair of 60G SSDs in striped as my OS disk, and let me tell ya, getting the entire OS off of the hard-drive seriously speeds things up.

Bass said:

Dexter said:

*snip*

A modern DB (eg: Drizzle) is going to delegate as much responsibility to the kernel as possible. This makes the code simpler, and this easier to optimize. That's just how it is.

I recall that major enterprise database engines like SQL Server have the ability, and for very high end specific performance , the desirability to store their data on unformatted raw disks. However, the lack of OS support means that this is not a recommended except where every ounce of performance is required. Otherwise it is easier and cheeper to throw a couple of Gb ram at the problem.

Bass said:

Dexter said:

*snip*

A modern DB (eg: Drizzle) is going to delegate as much responsibility to the kernel as possible. This makes the code simpler, and this easier to optimize. That's just how it is.

A modern DB (eg: Drizzle) is going to delegate as much responsibility to the kernel as possible.

Sorry, but I'm a PhD student who specializes in database engineering, and that statement goes contrary to everything I've been taught.

Well, just think crazily, but what happen when the HDD has no OS? Like remote storage that is shared with many servers? Remote storage is going thru fiber optic with high bandwidth obviously. What I see is the Live Mesh case. Cache on your computer and you don't know what's going on to the actual remote storage, let along the other sync device. And I am using Live Mesh, it is hardly good because synchronization is hard between devices.

And whats the point to store the FS when you still need to access the DB and get some data from a page or many pages? And if HDD is not spining, how do you know your FS on RAM is synced? And what about RAM for actual data caculations, they are RAM intensive on numerous occasions? If RAM runs out, you are going to drop FS on RAM? Just doesn't make any sense to me.

Anyway, FS on RAM? It sounds really really unsafe to begin with.

magicalclick said:

Are we talking about DB or OS or DBOS? I am confused.

 

Well, just think crazily, but what happen when the HDD has no OS? Like remote storage that is shared with many servers? Remote storage is going thru fiber optic with high bandwidth obviously. What I see is the Live Mesh case. Cache on your computer and you don't know what's going on to the actual remote storage, let along the other sync device. And I am using Live Mesh, it is hardly good because synchronization is hard between devices.

 

And whats the point to store the FS when you still need to access the DB and get some data from a page or many pages? And if HDD is not spining, how do you know your FS on RAM is synced? And what about RAM for actual data caculations, they are RAM intensive on numerous occasions? If RAM runs out, you are going to drop FS on RAM? Just doesn't make any sense to me.

 

Anyway, FS on RAM? It sounds really really unsafe to begin with.

 

magicalclick:  yeah this has went back and forth and i can see why you are lost....

the start of this was that the OP was talking about taking the NTFS "metadata" to a memory based system of some kind.

that he seemed to think that the raw data and the NTFS filesystem data could and should be handled differently.

at least that what i think the OP was saying.

then as the topic went on folks started talking about FS optimazation and how a DBMS might use the FS or might not.

so the term database has been used here 2 ways one as a normal database for say sql server and as the special data that a file system needs to manage.

Sven Groot said:

Bass said:

*snip*

Sorry, but I'm a PhD student who specializes in database engineering, and that statement goes contrary to everything I've been taught.

You have been tought that Drizzle team is trying to develop a heavy DB? Well PhD student or not, that is patently wrong.

Or you have been tought that the only good DB is a complicated DB? Well that's wrong too. The only good DB is a relational DB? That's also a load of crap.

There is a long history of people not agreeing with each other when it comes to what a good database design is. Maybe because there is no genuinely right way to do it.

Bass said:

Sven Groot said:

*snip*

You have been tought that Drizzle team is trying to develop a heavy DB? Well PhD student or not, that is patently wrong.

 

Or you have been tought that the only good DB is a complicated DB? Well that's wrong too. The only good DB is a relational DB? That's also a load of crap.

 

There is a long history of people not agreeing with each other when it comes to what a good database design is. Maybe because there is no genuinely right way to do it.

You have been tought that Drizzle team is trying to develop a heavy DB? Well PhD student or not, that is patently wrong.

 

Or you have been tought that the only good DB is a complicated DB? Well that's wrong too. The only good DB is a relational DB? That's also a load of crap.

I was challenging your assertion that a modern DB delegates to the kernel as much as possible (in the context of file I/O of this thread). I did not say any of the things you just accused me of saying.

Sven Groot said:

Bass said:

*snip*

I was challenging your assertion that a modern DB delegates to the kernel as much as possible (in the context of file I/O of this thread). I did not say any of the things you just accused me of saying.

If a kernel can do something that a DB does, it makes sense to remove that functionality and have the kernel do it. This reduces the amount of code the DB developer has to maintain. I don't see what your problem with this is at all.

Bass said:

Sven Groot said:

*snip*

If a kernel can do something that a DB does, it makes sense to remove that functionality and have the kernel do it. This reduces the amount of code the DB developer has to maintain. I don't see what your problem with this is at all.

The problem with that is that the kernel has no idea what your application is trying to do. The kernel has to serve every possible type of application, and will therefore need to do things so that they work well for all of them. When it comes to I/O, particularly things like caching and prefetching, there is no one strategy that works best in all scenarios. The kernel therefore uses a strategy that works pretty well for most scenarios, but probably isn't the optimal strategy for any of them.

The DBMS has the advantage that is knows exactly what it's doing. It knows far more about its data access and usage patterns than the kernel ever will, and can therefore use a caching and prefetching strategy that is far better than what the kernel could do. So a truly high performance DBMS will bypass the kernel in this instance and implement their own file I/O, because it knows it can do a better job than the kernel.

This isn't because the code in the kernel is somehow worse than that of the DBMS, nor does it mean DBMS developers are smarter than kernel developers. The only reason they do this is because the kernel is too generalised to provide the best solution, and the DBMS has far more information about what it wants to do and can therefore make much better decisions.

Sven Groot said:

Bass said:

*snip*

The problem with that is that the kernel has no idea what your application is trying to do. The kernel has to serve every possible type of application, and will therefore need to do things so that they work well for all of them. When it comes to I/O, particularly things like caching and prefetching, there is no one strategy that works best in all scenarios. The kernel therefore uses a strategy that works pretty well for most scenarios, but probably isn't the optimal strategy for any of them.

 

The DBMS has the advantage that is knows exactly what it's doing. It knows far more about its data access and usage patterns than the kernel ever will, and can therefore use a caching and prefetching strategy that is far better than what the kernel could do. So a truly high performance DBMS will bypass the kernel in this instance and implement their own file I/O, because it knows it can do a better job than the kernel.

 

This isn't because the code in the kernel is somehow worse than that of the DBMS, nor does it mean DBMS developers are smarter than kernel developers. The only reason they do this is because the kernel is too generalised to provide the best solution, and the DBMS has far more information about what it wants to do and can therefore make much better decisions.

The same arguments have been made in the past regarding cooperative vs preemptive multitasking. I assume you know who won in the end. The thing about any engineering project is there is limited resources. If you choose to optimize one part of your DB (file I/O), you probably are missing out somewhere else (eg: CPU cache). As I said before, the CPU cache is not programmable. So if you don't design your data structures with the CPU cache in mind, you are losing a ridiculously important optimization.

Another thing you conveniently leave out if that kernel developer and database developer many times work for the same company. Eg: Oracle and IBM are both Linux kernel developers (both interestingly have contributed file systems to the Linux kernel). There is contributions to the Linux kernel that were specifically designed around making databases faster. Sometimes this means tweaking the characteristics of the I/O scheduler and filesystem to improve their database performance, and not the other way around.

Anyway what is interesting about DB performance is depending on what DB vendor you ask, their DB is the fastest. So you can argue about DB performence all day and what approach is better, but MySQL/Oracle/DB2/SQLServer/SQLite are all the fastest DB in existence anyway.

Bass said:

Sven Groot said:

*snip*

The same arguments have been made in the past regarding cooperative vs preemptive multitasking. I assume you know who won in the end. The thing about any engineering project is there is limited resources. If you choose to optimize one part of your DB (file I/O), you probably are missing out somewhere else (eg: CPU cache). As I said before, the CPU cache is not programmable. So if you don't design your data structures with the CPU cache in mind, you are losing a ridiculously important optimization.

 

Another thing you conveniently leave out if that kernel developer and database developer many times work for the same company. Eg: Oracle and IBM are both Linux kernel developers (both interestingly have contributed file systems to the Linux kernel). There is contributions to the Linux kernel that were specifically designed around making databases faster. Sometimes this means tweaking the characteristics of the I/O scheduler and filesystem to improve their database performance, and not the other way around.

 

Anyway what is interesting about DB performance is depending on what DB vendor you ask, their DB is the fastest. So you can argue about DB performence all day and what approach is better, but MySQL/Oracle/DB2/SQLServer/SQLite are all the fastest DB in existence anyway.

The same arguments have been made in the past regardless cooperative vs preemptive multitasking.

Not really... If your claim is:

OS file handling -> Generic (good)

DBMS "file" handling -> Specific (unnecessary)

then Preemptive vs. Cooperative doesn't fall on the same scale. Pre-emptive vs Cooperative fall more on hardware vs software. And I believe you know which is better.

Look, DBMSes DO have their own internal "file" / page / disk memory management... That's fact. Why? Because that code is more specific to their domain. DBMS loves contiguous blocks of memory... whereas, HDs have 1 to 2 Dimensions (spiral platters) to their storage.

PS. C9, fix the GD posting errors

Bass said:

Sven Groot said:

*snip*

The same arguments have been made in the past regarding cooperative vs preemptive multitasking. I assume you know who won in the end. The thing about any engineering project is there is limited resources. If you choose to optimize one part of your DB (file I/O), you probably are missing out somewhere else (eg: CPU cache). As I said before, the CPU cache is not programmable. So if you don't design your data structures with the CPU cache in mind, you are losing a ridiculously important optimization.

 

Another thing you conveniently leave out if that kernel developer and database developer many times work for the same company. Eg: Oracle and IBM are both Linux kernel developers (both interestingly have contributed file systems to the Linux kernel). There is contributions to the Linux kernel that were specifically designed around making databases faster. Sometimes this means tweaking the characteristics of the I/O scheduler and filesystem to improve their database performance, and not the other way around.

 

Anyway what is interesting about DB performance is depending on what DB vendor you ask, their DB is the fastest. So you can argue about DB performence all day and what approach is better, but MySQL/Oracle/DB2/SQLServer/SQLite are all the fastest DB in existence anyway.

Hrm, I think I lost count of how many times you switched the subject in this thread. Not to mention that you bring arguments for things that nobody argued about.

It's perfectly fine for a database to leave the caching to the filesystem if you want a lightweight codebase or if you don't have the resources to do it. The problem starts when you claim that the kernel can do caching better. I mentioned in short why it can't and Sven provided more details. Instead of answering to that you went on a rant about CPU cache, schedulers, algorithms and whatnot.

Dexter said:

Bass said:

*snip*

Hrm, I think I lost count of how many times you switched the subject in this thread. Not to mention that you bring arguments for things that nobody argued about.

 

It's perfectly fine for a database to leave the caching to the filesystem if you want a lightweight codebase or if you don't have the resources to do it. The problem starts when you claim that the kernel can do caching better. I mentioned in short why it can't and Sven provided more details. Instead of answering to that you went on a rant about CPU cache, schedulers, algorithms and whatnot.

Hrm, I think I lost count of how many times you switched the subject in this thread. Not to mention that you bring arguments for things that nobody argued about.

It's all part of the same argument. You'll just have to keep up.

It's perfectly fine for a database to leave the caching to the filesystem if you want a lightweight codebase or if you don't have the resources to do it. The problem starts when you claim that the kernel can do caching better. I mentioned in short why it can't and Sven provided more details. Instead of answering to that you went on a rant about CPU cache, schedulers, algorithms and whatnot.

The kernel can do caching better. You can claim that the software knows more about the characteristics of the data structures it uses, but the kernel knows more about the characteristics of the hardware it is running on.

Dexter said:

Bass said:

*snip*

Hrm, I think I lost count of how many times you switched the subject in this thread. Not to mention that you bring arguments for things that nobody argued about.

 

It's perfectly fine for a database to leave the caching to the filesystem if you want a lightweight codebase or if you don't have the resources to do it. The problem starts when you claim that the kernel can do caching better. I mentioned in short why it can't and Sven provided more details. Instead of answering to that you went on a rant about CPU cache, schedulers, algorithms and whatnot.

I also said the same thing, and he started talking about CPU caches for some reason.  Anyway this is basic engineering sense, it doesn't even really have anything to do with databases, you can almost always get better performance if you "roll it yourself".  Whether or not it is feasible to do this or worth the effort is what you need to decide as an engineer.  But when major commercial databases like Microsoft SQL,  that have massive budgets and huge teams of engineers, made a decision to roll their own caching scheme, maybe it's a good indication you're wrong about this?

Minh said:

Bass said:

*snip*

The same arguments have been made in the past regardless cooperative vs preemptive multitasking.

 

Not really... If your claim is:

 

OS file handling -> Generic (good)

DBMS "file" handling -> Specific (unnecessary)

 

then Preemptive vs. Cooperative doesn't fall on the same scale. Pre-emptive vs Cooperative fall more on hardware vs software. And I believe you know which is better.

 

Look, DBMSes DO have their own internal "file" / page / disk memory management... That's fact. Why? Because that code is more specific to their domain. DBMS loves contiguous blocks of memory... whereas, HDs have 1 to 2 Dimensions (spiral platters) to their storage.

 

PS. C9, fix the GD posting errors

I don't think preemptive vs. cooperative is a different analogy at all. Cooperative multitasking allows a process to decide how much CPU time it needs. In preemptive multitasking, this is decided for the process (although in some systems like POSIX/Windows, a process can suggest how should it be handled to the kernel).

Bass said:

Minh said:

*snip*

I don't think preemptive vs. cooperative is a different analogy at all. Cooperative multitasking allows a process to decide how much CPU time it needs. In preemptive multitasking, this is decided for the process (although in some systems like POSIX/Windows, a process can suggest how should it be handled to the kernel).

Cooperative multitasking would probably make more sense on a database server.  Normally the entire machine is dedicated to running the database server, so there is really only one process at a time.  You would lose the overhead of preemptive multitasking, and getting context switched at a bad time.

CreamFilling512 said:

Dexter said:

*snip*

I also said the same thing, and he started talking about CPU caches for some reason.  Anyway this is basic engineering sense, it doesn't even really have anything to do with databases, you can almost always get better performance if you "roll it yourself".  Whether or not it is feasible to do this or worth the effort is what you need to decide as an engineer.  But when major commercial databases like Microsoft SQL,  that have massive budgets and huge teams of engineers, made a decision to roll their own caching scheme, maybe it's a good indication you're wrong about this?

The CPU cache thing was in regard to Dexter's assertion that a DB shouldn't have to localize it's important data. Quite frankly to run efficiently on an x86 processor, it has no other choice. . I don't know how many of you ever did assembly programming. Although you can create a memory caching algorithm, you can't create your own processor caching algorithm on x86. That is hard-coded on the CPU by Intel/AMD. Performance degrades considerably on x86 if there is are many cache misses, which is the cache equivalent of a page fault. So your data structures must consider this in order to efficiently run on the architecture.

CreamFilling512 said:

Bass said:

*snip*

Cooperative multitasking would probably make more sense on a database server.  Normally the entire machine is dedicated to running the database server, so there is really only one process at a time.  You would lose the overhead of preemptive multitasking, and getting context switched at a bad time.

Well with that argument, a database server should BE a kernel right? Since it's going to do everything a kernel does! That is clearly the way to get the optimal performance.

Bass said:

CreamFilling512 said:

*snip*

The CPU cache thing was in regard to Dexter's assertion that a DB shouldn't have to localize it's important data. Quite frankly to run efficiently on an x86 processor, it has no other choice. . I don't know how many of you ever did assembly programming. Although you can create a memory caching algorithm, you can't create your own processor caching algorithm on x86. That is hard-coded on the CPU by Intel/AMD. Performance degrades considerably on x86 if there is are many cache misses, which is the cache equivalent of a page fault. So your data structures must consider this in order to efficiently run on the architecture.

The CPU cache thing was in regard to Dexter's assertion that a DB shouldn't have to localize it's important data

Are you insane?  I've said that I don't think the database should move data around to keep the kernel happy. That's not the same thing as "localizing" important data so it fits the CPU cache (or the harddrive).

The kernel can do caching better. You can claim that the software knows more about the characteristics of the data structures it uses, but the kernel knows more about the characteristics of the hardware it is running on.

Except the characteristics of the hardware are likely to be simpler than the characteristics of the data structures and access patterns. Which set of characteristics do you think will be easier to communicate to the other party?

Dexter said:

Bass said:

*snip*

 

Except the characteristics of the hardware are likely to be simpler than the characteristics of the data structures and access patterns. Which set of characteristics do you think will be easier to communicate to the other party?

Are you insane?  I've said that I don't think the database should move data around to keep the kernel happy. That's not the same thing as "localizing" important data so it fits the CPU cache (or the harddrive).

And why not? The kind of caching algorithm the Linux kernel uses is not all that different from what Intel microcode uses. You kill two birds with one stone. PS: Ad homiem is evidence of a losing argument.

Except the characteristics of the hardware are likely to be simpler than the characteristics of the data structures and access patterns. Which set of characteristics do you think will be easier to communicate to the other party?

Well a kernel can safely assume that important/commonly used data in memory will be near each other, because that's how optimizing compilers and high performence databases tend to structure their data. True story.

Bass said:

Dexter said:

*snip*

Are you insane?  I've said that I don't think the database should move data around to keep the kernel happy. That's not the same thing as "localizing" important data so it fits the CPU cache (or the harddrive).

 

And why not? The kind of caching algorithm the Linux kernel uses is not all that different from what Intel microcode uses. You kill two birds with one stone. PS: Ad homiem is evidence of a losing argument.

 

Except the characteristics of the hardware are likely to be simpler than the characteristics of the data structures and access patterns. Which set of characteristics do you think will be easier to communicate to the other party?

 

Well a kernel can safely assume that important/commonly used data in memory will be near each other, because that's how optimizing compilers and high performence databases tend to structure their data. True story.

 

Ad homiem is evidence of a losing argument.

Ha ha, look who's talking. You're twisting my words yet you claim "losing argument".

Well a kernel can safely assume that important/commonly used data in memory will near each other, because that's how optimizing compilers and high performence databases tend to structure their data. True story.

And how exactly does this relate to what I said? Or more generally, how exactly does this relate to caching?

Dexter said:

Bass said:

*snip*

 

And how exactly does this relate to what I said? Or more generally, how exactly does this relate to caching?

 

Ha ha, look who's talking. You're twisting my words yet you claim "losing argument".

Well I see you want to be on an equal footing with me on this. So I'll call you an insane person also. Insane person.

And how exactly does this relate to what I said? Or more generally, how exactly does this relate to caching?

This is the original point I am addressing:

Seriously, do you really want/expect a database system to move gigabytes or terrabytes of data around just to keep the kernel happy?

Okay I'm going to say this again. Please no more "NUH UHs" on this. I'm quite obviously right.

You can not write any explicit caching code to efficently cache things on an x86 processor. This algorithm is hardcoded into the control unit of the actual processor. The only way to get important data into cache (which is of course, what you want) is to "suggest" it to the proccessor by your data structures. This means working with the quirks of the branch predictor, and also localizing commonly accessed data.

Of course this is to keep the CPU happy and you are probably going to be like "well I didn't say CPU, so I am somehow correct, and you are wrong". Well buddy, you have to keep the CPU happy. A unhappy CPU is a cache missing CPU, and you MUST avoid this to have any reasonable performance.

And interestingly, by keeping the CPU happy, you also tend to make the kernel happy. Because the kernel isn't using some magical caching algorithm that Intel doesn't know about.

Kapeesh?

Bass said:

Dexter said:

*snip*

Ha ha, look who's talking. You're twisting my words yet you claim "losing argument".

 

Well I see you want to be on an equal footing with me on this. So I'll call you an insane person also. Insane person.

 

And how exactly does this relate to what I said? Or more generally, how exactly does this relate to caching?

 

This is the original point I am addressing:

Seriously, do you really want/expect a database system to move gigabytes or terrabytes of data around just to keep the kernel happy?

 

Okay I'm going to say this again. Please no more "NUH UHs" on this. I'm quite obviously right.

 

You can not write any explicit caching code to efficently cache things on an x86 processor. This algorithm is hardcoded into the control unit of the actual processor. The only way to get important data into cache (which is of course, what you want) is to "suggest" it to the proccessor by your data structures. This means working with the quirks of the branch predictor, and also localizing commonly accessed data.

 

Of course this is to keep the CPU happy and you are probably going to be like "well I didn't say CPU, so I am somehow correct, and you are wrong". Well buddy, you have to keep the CPU happy. A unhappy CPU is a cache missing CPU, and you MUST avoid this to have any reasonable performance.

 

And interestingly, by keeping the CPU happy, you also tend to make the kernel happy. Because the kernel isn't using some magical caching algorithm that Intel doesn't know about.

 

Kapeesh?

I'm quite obviously right

Yeah, you're right... about a completly different and unrelated problem. What problem? Ah, it was branch prediction. Ah no, sorry, that was about CPU cache. Ah no, wrong again it was about optimizing compilers. Oops, I've missed again. No, I bet it was about 42.

Dexter said:

Bass said:

*snip*

 

Yeah, you're right... about a completly different and unrelated problem. What problem? Ah, it was branch prediction. Ah no, sorry, that was about CPU cache. Ah no, wrong again it was about optimizing compilers. Oops, I've missed again. No, I bet it was about 42.

A system memory cache is a just a much slower and much bigger CPU cache.

In fact this is how the CPU sees the world:

Page fault: Geographical time

Cache miss: Snail time

In cache: Ferrari Enzo

You want your CPU to be riding that Ferrari as much as possible. That means NO DIRECT MEMORY ACCESS IF POSSIBLE. A big optimization thing (at least big as autovectorization) is to try to keep your working data on the cache, and never make the CPU explicitly access a piece of memory. Does that sound familiar? Isn't that exactly what you want to do with memory caching in general?

Oh wait, I can even make a fill in the blank:

The point of X caching is to keep as much working data in a fast memory store (in this case: Y) as possible.

I'm going to guess the reply: "irrelevant". LOLWUT?

Bass said:

Dexter said:

*snip*

A system memory cache is a just a much slower and much bigger CPU cache.

 

In fact this is how the CPU sees the world:

 

Page fault: Geographical time

Cache miss: Snail time

In cache: Ferrari Enzo

 

You want your CPU to be riding that Ferrari as much as possible. That means NO DIRECT MEMORY ACCESS IF POSSIBLE. A big optimization thing (at least big as autovectorization) is to try to keep your working data on the cache, and never make the CPU explicitly access a piece of memory. Does that sound familiar? Isn't that exactly what you want to do with memory caching in general?

 

Oh wait, I can even make a fill in the blank:

The point of X caching is to keep as much working data in a fast memory store (in this case: Y) as possible.

 

I'm going to guess the reply: "irrelevant". LOLWUT?

You have to write your database caching algorithms with the kernel and CPU/hardware behaviour in mind. You certainly don't just "leave it to the kernel" unless you're expecting performance not to be important. That's true of any bit of coding.

AndyC said:

Bass said:

*snip*

You have to write your database caching algorithms with the kernel and CPU/hardware behaviour in mind. You certainly don't just "leave it to the kernel" unless you're expecting performance not to be important. That's true of any bit of coding.

You want to leave "as much as possible" to the kernel though. Notice that's exactly what I said. Heh heh heh.

You guys are a riot.

Bass said:

Dexter said:

*snip*

A system memory cache is a just a much slower and much bigger CPU cache.

 

In fact this is how the CPU sees the world:

 

Page fault: Geographical time

Cache miss: Snail time

In cache: Ferrari Enzo

 

You want your CPU to be riding that Ferrari as much as possible. That means NO DIRECT MEMORY ACCESS IF POSSIBLE. A big optimization thing (at least big as autovectorization) is to try to keep your working data on the cache, and never make the CPU explicitly access a piece of memory. Does that sound familiar? Isn't that exactly what you want to do with memory caching in general?

 

Oh wait, I can even make a fill in the blank:

The point of X caching is to keep as much working data in a fast memory store (in this case: Y) as possible.

 

I'm going to guess the reply: "irrelevant". LOLWUT?

Feel free to continue rambling. I think I'll go drink my pan galactic gargle blaster now, thank you.

Dexter said:

Bass said:

*snip*

Feel free to continue rambling. I think I'll go drink my pan galactic gargle blaster now, thank you.

You just don't like admitting you are wrong huh? I noticed that in Tech Off too. You have to try to "correct" everyone. You can't correct what is already correct though, buddy.

Bass said:

Dexter said:

*snip*

Ha ha, look who's talking. You're twisting my words yet you claim "losing argument".

 

Well I see you want to be on an equal footing with me on this. So I'll call you an insane person also. Insane person.

 

And how exactly does this relate to what I said? Or more generally, how exactly does this relate to caching?

 

This is the original point I am addressing:

Seriously, do you really want/expect a database system to move gigabytes or terrabytes of data around just to keep the kernel happy?

 

Okay I'm going to say this again. Please no more "NUH UHs" on this. I'm quite obviously right.

 

You can not write any explicit caching code to efficently cache things on an x86 processor. This algorithm is hardcoded into the control unit of the actual processor. The only way to get important data into cache (which is of course, what you want) is to "suggest" it to the proccessor by your data structures. This means working with the quirks of the branch predictor, and also localizing commonly accessed data.

 

Of course this is to keep the CPU happy and you are probably going to be like "well I didn't say CPU, so I am somehow correct, and you are wrong". Well buddy, you have to keep the CPU happy. A unhappy CPU is a cache missing CPU, and you MUST avoid this to have any reasonable performance.

 

And interestingly, by keeping the CPU happy, you also tend to make the kernel happy. Because the kernel isn't using some magical caching algorithm that Intel doesn't know about.

 

Kapeesh?

See --- this long post by Bass right here.

This is why I want Channel 9 forums to switch to something with a little bit more maturity like SMF or phpBB or something. The delays in bringing up posts, the times when you can't get to page 2 of a thread, and the over-AJAXification of the current Channel 9 forums interrupts and distracts from a steady stream of posts like this one which are both highly entertaining, yet educational. 

If I had succumbed to the urge to just not visit the site a few minute ago (an urge fueled mainly by the usability of these forums), I would not have read this post.

Thanks.

Bass said:

Dexter said:

*snip*

A system memory cache is a just a much slower and much bigger CPU cache.

 

In fact this is how the CPU sees the world:

 

Page fault: Geographical time

Cache miss: Snail time

In cache: Ferrari Enzo

 

You want your CPU to be riding that Ferrari as much as possible. That means NO DIRECT MEMORY ACCESS IF POSSIBLE. A big optimization thing (at least big as autovectorization) is to try to keep your working data on the cache, and never make the CPU explicitly access a piece of memory. Does that sound familiar? Isn't that exactly what you want to do with memory caching in general?

 

Oh wait, I can even make a fill in the blank:

The point of X caching is to keep as much working data in a fast memory store (in this case: Y) as possible.

 

I'm going to guess the reply: "irrelevant". LOLWUT?

So you have information cached in memory. Unfortunately, you can't have everything cached in memory, because you just don't have that much memory. So at some point, the DBMS is going to have to read something from disk, and, most importantly, something else is going to have to be removed from the cache to make room from the new information. Deciding what piece of information to remove from the cache when space runs out is probably the hardest and most performance critical part of cache algorithms.

Now ask yourself: who has more information by which to decide what should be dropped from the cache? The OS kernel, or the DBMS itself?

Sven Groot said:

Bass said:

*snip*

So you have information cached in memory. Unfortunately, you can't have everything cached in memory, because you just don't have that much memory. So at some point, the DBMS is going to have to read something from disk, and, most importantly, something else is going to have to be removed from the cache to make room from the new information. Deciding what piece of information to remove from the cache when space runs out is probably the hardest and most performance critical part of cache algorithms.

 

Now ask yourself: who has more information by which to decide what should be dropped from the cache? The OS kernel, or the DBMS itself?

The OS kernel has a lot of information here.

(1) It can figure out where the most commonly read information is, and store those pages in memory. I know this may seem silly but the most commonly read information is wait for it... exactly what you want to be in memory. Thus the kernel does a pretty good job of finding exactly what needs to be in memory. The DB's data structures MUST be written to be automatically cached anyway. You can not use unpredictably spread out data structures (see why heap sort performs poorly on x86), you are quite limited in how you structure your data for performance due to the CPU cache. But seriously, I in all honestly can not see what a DB's domain specific caching algorithm could do better. Since you are the so called DB expert perhaps you could enlighten me?

(2) It has access to a lot of information about the persistent store (eg: the position of the head). So it knows exactly when it can pull some piece of data off the disk (often measurable in nanoseconds), while at at best the DB could query the kernel for this information (zomg cache miss / context switch), but more likely simply guesses and then has blocking stuff all nicely queued for unpredictable times on the kernel's I/O scheduler.

(3) It has access to an array of modern caching technologies like DMA. Remember what I said about cache misses and all that? Well you are passing data in and out of the CPU like an idiot and that's BAD BAD BAD for performance. Unfortunately this is the only realistic way to implement a user-mode file cache is to pass data in and out of the CPU like an idiot. You really want to do that? Be my guest. I'll take DMA over that any day.

At best, if you want to implement a cache in a DB you should be subservient to the kernel, passing it the right information so it can do it's job via it's sheer awesome kernel powers. As I said before, there is ways to ask the kernel to cache something for you and there are ways to structure your data that is conductive to caching. But one thing you should never do the kernel's job for it, because you will never do it as well.

fknight said:

Bass said:

*snip*

See --- this long post by Bass right here.

 

This is why I want Channel 9 forums to switch to something with a little bit more maturity like SMF or phpBB or something. The delays in bringing up posts, the times when you can't get to page 2 of a thread, and the over-AJAXification of the current Channel 9 forums interrupts and distracts from a steady stream of posts like this one which are both highly entertaining, yet educational. 

 

If I had succumbed to the urge to just not visit the site a few minute ago (an urge fueled mainly by the usability of these forums), I would not have read this post.

 

Thanks.

 

 

This is why I want Channel 9 forums to switch to something with a little bit more maturity like SMF or phpBB

An open-source php BBS hosting Channel-9 ...somehow, I don’t think so.

In the “old days” I would have suggested Community Server, but these days, I can’t even figure out what the hell Telligent are trying to sell, let alone figure out the status of the product... it seems to be a very confused company with an even more confusing website.

fknight said:

Bass said:

*snip*

See --- this long post by Bass right here.

 

This is why I want Channel 9 forums to switch to something with a little bit more maturity like SMF or phpBB or something. The delays in bringing up posts, the times when you can't get to page 2 of a thread, and the over-AJAXification of the current Channel 9 forums interrupts and distracts from a steady stream of posts like this one which are both highly entertaining, yet educational. 

 

If I had succumbed to the urge to just not visit the site a few minute ago (an urge fueled mainly by the usability of these forums), I would not have read this post.

 

Thanks.

 

 

Thank you for the kind words.

Bass said:

Sven Groot said:

*snip*

The OS kernel has a lot of information here.

(1) It can figure out where the most commonly read information is, and store those pages in memory. I know this may seem silly but the most commonly read information is wait for it... exactly what you want to be in memory. Thus the kernel does a pretty good job of finding exactly what needs to be in memory. The DB's data structures MUST be written to be automatically cached anyway. You can not use unpredictably spread out data structures (see why heap sort performs poorly on x86), you are quite limited in how you structure your data for performance due to the CPU cache. But seriously, I in all honestly can not see what a DB's domain specific caching algorithm could do better. Since you are the so called DB expert perhaps you could enlighten me?

 

(2) It has access to a lot of information about the persistent store (eg: the position of the head). So it knows exactly when it can pull some piece of data off the disk (often measurable in nanoseconds), while at at best the DB could query the kernel for this information (zomg cache miss / context switch), but more likely simply guesses and then has blocking stuff all nicely queued for unpredictable times on the kernel's I/O scheduler.

 

(3) It has access to an array of modern caching technologies like DMA. Remember what I said about cache misses and all that? Well you are passing data in and out of the CPU like an idiot and that's BAD BAD BAD for performance. Unfortunately this is the only realistic way to implement a user-mode file cache is to pass data in and out of the CPU like an idiot. You really want to do that? Be my guest. I'll take DMA over that any day.

 

At best, if you want to implement a cache in a DB you should be subservient to the kernel, passing it the right information so it can do it's job via it's sheer awesome kernel powers. As I said before, there is ways to ask the kernel to cache something for you and there are ways to structure your data that is conductive to caching. But one thing you should never do the kernel's job for it, because you will never do it as well.

It can figure out where the most commonly read information is, and store those pages in memory.

But that just plainly isn't true. The kernel can figure out only what was the most common information in the past, and then hope that this will still be true in the future. But there are many access patterns where this simply isn't true. The kernel cannot know if an application is going to have an access pattern for which this strategy doesn't work. Only the application can know that. Hence, the application can do better.

And CPU caching isn't relevant to this discussion for several reasons: 1. The timing gap between memory and disk is greater than that between CPU cache and memory. 2. CPU cache is a few MB at best, file cache is typically multiple GB. 3. The kernel does not manage the CPU cache, the CPU does that.

And the simple fact is that SQL Server and Oracle and other high-performance DB systems do in fact do their own caching. Are you saying the people who develop those databases are all wrong?

figuerres said:

magicalclick said:

*snip*

magicalclick:  yeah this has went back and forth and i can see why you are lost....

 

the start of this was that the OP was talking about taking the NTFS "metadata" to a memory based system of some kind.

that he seemed to think that the raw data and the NTFS filesystem data could and should be handled differently.

at least that what i think the OP was saying.

 

then as the topic went on folks started talking about FS optimazation and how a DBMS might use the FS or might not.

 

so the term database has been used here 2 ways one as a normal database for say sql server and as the special data that a file system needs to manage.

Figuerres, Thanks for clearing that up.t

To TP: it would be cool if you can make a prototype and demonstrate how good it is.

To Bass. It is called NTFS. I guess you need a new stuff called DBFS.

For FS, I think I will list out some of the things we want in the future:

1) DB in mind.

2) Faster directory lookup to reduce lattency. Ideally directory lookup in RAM.

3) Multi-user support. (need good sync to all users when directory lookup is in RAM)

4) Security. No external driver, or FS, or whatever can access/modify its content without the FS.

I am not really keen on this topic, so please don't laugh, hehe.

magicalclick said:

figuerres said:

*snip*

Figuerres, Thanks for clearing that up.t

 

To TP: it would be cool if you can make a prototype and demonstrate how good it is.

To Bass. It is called NTFS. I guess you need a new stuff called DBFS.

 

For FS, I think I will list out some of the things we want in the future:

1) DB in mind.

2) Faster directory lookup to reduce lattency. Ideally directory lookup in RAM.

3) Multi-user support. (need good sync to all users when directory lookup is in RAM)

4) Security. No external driver, or FS, or whatever can access/modify its content without the FS.

 

I am not really keen on this topic, so please don't laugh, hehe.

 

1) Depends what you mean by DB. You can consider NTFS as being a domain specific DB. It's not relational, it doesn't process SQL queries but it stores and retrieves data, a lot of data. Incidentaly NTFS uses B-Trees which are also commonly used in databases.

2) Already done. NTFS (and probably most other filesystems) caches file metdata in RAM. Go enumerate a directory containing a large number of files. You'll likely see a ton of disk activity. Do that again. No disk activity this time.

3) Already done. File metadata caching occurs in kernel, not in the application. This means that there's only one instance of that data so there's no need for some sort of "good sync".

4) Already done. Unless you're an administrator you cannot access the disk directly, you must go through the filesystem. Also if you're not an administrator you cannot load drivers. In general this has less to do with the filesystem, it's a generic kernel problem.

Bass said:

Sven Groot said:

*snip*

The OS kernel has a lot of information here.

(1) It can figure out where the most commonly read information is, and store those pages in memory. I know this may seem silly but the most commonly read information is wait for it... exactly what you want to be in memory. Thus the kernel does a pretty good job of finding exactly what needs to be in memory. The DB's data structures MUST be written to be automatically cached anyway. You can not use unpredictably spread out data structures (see why heap sort performs poorly on x86), you are quite limited in how you structure your data for performance due to the CPU cache. But seriously, I in all honestly can not see what a DB's domain specific caching algorithm could do better. Since you are the so called DB expert perhaps you could enlighten me?

 

(2) It has access to a lot of information about the persistent store (eg: the position of the head). So it knows exactly when it can pull some piece of data off the disk (often measurable in nanoseconds), while at at best the DB could query the kernel for this information (zomg cache miss / context switch), but more likely simply guesses and then has blocking stuff all nicely queued for unpredictable times on the kernel's I/O scheduler.

 

(3) It has access to an array of modern caching technologies like DMA. Remember what I said about cache misses and all that? Well you are passing data in and out of the CPU like an idiot and that's BAD BAD BAD for performance. Unfortunately this is the only realistic way to implement a user-mode file cache is to pass data in and out of the CPU like an idiot. You really want to do that? Be my guest. I'll take DMA over that any day.

 

At best, if you want to implement a cache in a DB you should be subservient to the kernel, passing it the right information so it can do it's job via it's sheer awesome kernel powers. As I said before, there is ways to ask the kernel to cache something for you and there are ways to structure your data that is conductive to caching. But one thing you should never do the kernel's job for it, because you will never do it as well.

Eh, more crap. You're calling a 30 years old (or maybe even older) technology like DMA a modern thing. Sure, 30 years ago there was no CPU cache but it's not like CPU cache is extremly new either.

And you have no clue about how non cached file I/O works and you claim that it's not possible to implement user mode caching because of lack of DMA?

And you call people idiots for moving data in and out of the CPU cache. Do you perhaps have a wonder CPU with 1 terrabyte of cache so people can stop acting like idiots while moving their database in and out of the CPU cache?

You might as well throw in the kitchen sink. It will probably weight more than flawed arguments.

PS:

Technical notes for people unfamiliar with x86 hardware and file caching (at least on Windows):

PCs included DMA since the early days. Back then it was used to transfer data from the floppy disk to memory and for a couple of other things. AFAIR it was even possible to progam it to transfer from memory to memory.

It is certainly possible to use DMA to transfer data directly from disk to application memory. There are some restriction to the size, memory address and file offset (basically they need to be multiple of disk sector size) but that's hardly a problem for databases because they organize data in pages and th page size is a multiple of sector size (at least on SQL Server).

It should also be noted that kernel file caching does not always come for free. For example if you're reading a file by using a "read" style call then the kernel has no choice but to copy the file data from its cache to the application provided buffer. Not extremly slow but certainly not free either.

Sven Groot said:

Bass said:

*snip*

But that just plainly isn't true. The kernel can figure out only what was the most common information in the past, and then hope that this will still be true in the future. But there are many access patterns where this simply isn't true. The kernel cannot know if an application is going to have an access pattern for which this strategy doesn't work. Only the application can know that. Hence, the application can do better.

 

And CPU caching isn't relevant to this discussion for several reasons: 1. The timing gap between memory and disk is greater than that between CPU cache and memory. 2. CPU cache is a few MB at best, file cache is typically multiple GB. 3. The kernel does not manage the CPU cache, the CPU does that.

 

And the simple fact is that SQL Server and Oracle and other high-performance DB systems do in fact do their own caching. Are you saying the people who develop those databases are all wrong?

But that just plainly isn't true. The kernel can figure out only what was the most common information in the past, and then hope that this will still be true in the future.

If you design your data structures correctly, it SHOULD be true in the future.

But there are many access patterns where this simply isn't true.

And they don't belong in databases.

The kernel cannot know if an application is going to have an access pattern for which this strategy doesn't work. Only the application can know that. Hence, the application can do better.

I don't think that's actually true. For many data structures, you can not reliably predict where an element will be located on a restructure. If you can, you can ask the kernel to cache that part of the file for you anyway. See the readahead syscall. Which is exactly how readahead daemons like preload work! They don't go around implementing their own file caching, that would be stupid. They let the kernel do it for them, as any good DB implementation would.

And CPU caching isn't relevant to this discussion for several reasons: 1. The timing gap between memory and disk is greater than that between CPU cache and memory. 2. CPU cache is a few MB at best, file cache is typically multiple GB. 3. The kernel does not manage the CPU cache, the CPU does that.

1. It may be, but having too many direct memory accesses with effect system performance in a very bad way.

2. CPU Cache is a few MB at best, so lets ignore it? That sounds like a plan chief.

3. The fact that the CPU manages the CPU cache is exactly why it's important. You can not program a CPU cache, because that is a right reserved only for the immortals who design hardware, and you are but a mortal software developer. The best you could do is structure your data in a way that is conductive to CPU caching. If you are going to do this anyway, why not structure your data in a way that is conductive to the kernel caching? Hmm? The kernel is like the CPU's prophet to software. Like most prophets, he is mortal and software like all other software, but is bestowed on by the immortals with certain miracles. But you shouldn't ignore his powers, for he speakiths directly to the hardware, and knows it's demands. You do not.

Dexter said:

Bass said:

*snip*

Eh, more crap. You're calling a 30 years old (or maybe even older) technology like DMA a modern thing. Sure, 30 years ago there was no CPU cache but it's not like CPU cache is extremly new either.

 

And you have no clue about how non cached file I/O works and you claim that it's not possible to implement user mode caching because of lack of DMA?

 

And you call people idiots for moving data in and out of the CPU cache. Do you perhaps have a wonder CPU with 1 terrabyte of cache so people can stop acting like idiots while moving their database in and out of the CPU cache?

 

You might as well throw in the kitchen sink. It will probably weight more than flawed arguments.

 

PS:

Technical notes for people unfamiliar with x86 hardware and file caching (at least on Windows):

 

PCs included DMA since the early days. Back then it was used to transfer data from the floppy disk to memory and for a couple of other things. AFAIR it was even possible to progam it to transfer from memory to memory.

 

It is certainly possible to use DMA to transfer data directly from disk to application memory. There are some restriction to the size, memory address and file offset (basically they need to be multiple of disk sector size) but that's hardly a problem for databases because they organize data in pages and th page size is a multiple of sector size (at least on SQL Server).

 

It should also be noted that kernel file caching does not always come for free. For example if you're reading a file by using a "read" style call then the kernel has no choice but to copy the file data from its cache to the application provided buffer. Not extremly slow but certainly not free either.

Welcome back Dexter!

I didn't say it was impossible to implement caching without DMA, I just said it was incredibly stupid. Since your entire argument is based on a false premise, there is little more I can say.

Bass said:

Dexter said:

*snip*

Welcome back Dexter!

 

I didn't say it was impossible to implement caching without DMA, I just said it was incredibly stupid. Since your entire argument is based on a false premise, there is little more I can say.

Well, it seems that you failed to read the "technical notes" part of the post. I guess you consider yourself familiar with inner kernel/hardware details. In that case you should also know that it is possible to use DMA even if caching is not done in kernel.

Unfortunately this is the only realistic way to implement a user-mode file cache is to pass data in and out of the CPU like an idiot.

Did you say "false premises"?

Dexter said:

Bass said:

*snip*

 

Did you say "false premises"?

You give a reasonable explination for how DMA works, and it's history. I'm not aware of any user-mode way of doing DMA, that's something that seems to be reserved to kernel space (as virtually any hardware control). If you know a way feel free to enlighten me.

But as so far as it makes any difference to the argument, using DMA is far better then not. If you start taking memory management in your own hands, if you are implementing your own cache by memcpy'ing things around you are effectively not using DMA so any data you write to this cache has to go through the CPU. If you let the kernel handle this file caching for you, this is not a problem.

Bass said:

Dexter said:

*snip*

You give a reasonable explination for how DMA works, and it's history. I'm not aware of any user-mode way of doing DMA, that's something that seems to be reserved to kernel space (as virtually any hardware control). If you know a way feel free to enlighten me.

 

But as so far as it makes any difference to the argument, using DMA is far better then not. If you start taking memory management in your own hands, if you are implementing your own cache by memcpy'ing things around you are effectively not using DMA so any data you write to this cache has to go through the CPU. If you let the kernel handle this file caching for you, this is not a problem.

seems to be reserved to kernel space

So you make a bunch of claims but you actually don't have a clue how this works? You have some nerve.

Of course one's going to use DMA. Not only that using PIO mode would be terrible inefficient but AFAIK it's not even possible with adapters like AHCI. Or SCSI.

And there's no reason why DMA cannot be used to transfer data to user mode space. Note that I'm talking about data tranfer and not about DMA programming. All the application has to do is to issue a properly aligned, non cached, asynchronous read request. The kernel will take care of programming the DMA (or the disk adapter which in turn will program the DMA) with the memory address and size specified by the application and that's all there is to it. There's no memcpy, no CPU cache trashing and no requirement for the application to have low level access to the hardware.

Dexter said:

Bass said:

*snip*

 

So you make a bunch of claims but you actually don't have a clue how this works? You have some nerve.

 

Of course one's going to use DMA. Not only that using PIO mode would be terrible inefficient but AFAIK it's not even possible with adapters like AHCI. Or SCSI.

 

And there's no reason why DMA cannot be used to transfer data to user mode space. Note that I'm talking about data tranfer and not about DMA programming. All the application has to do is to issue a properly aligned, non cached, asynchronous read request. The kernel will take care of programming the DMA (or the disk adapter which in turn will program the DMA) with the memory address and size specified by the application and that's all there is to it. There's no memcpy, no CPU cache trashing and no requirement for the application to have low level access to the hardware.

 

So you make a bunch of claims but you actually don't have a clue how this works? You have some nerve.

Well I am not like you Dexter. I don't act like I know everything, and I actually value input from others. And this I apologize for. 

And there's no reason why DMA cannot be used to transfer data to user mode space. Note that I'm talking about data tranfer and not about DMA programming.

But what you seem (oops I said "seem", I have some nerve!) to be saying is that you indeed need to make a syscall to do DMA, which is what I assumed ("assumed"? you must be raging by now). Thank you for proving yourself wrong once again.

Bass said:

Dexter said:

*snip*

So you make a bunch of claims but you actually don't have a clue how this works? You have some nerve.

Well I am not like you Dexter. I don't act like I know everything, and I actually value input from others. And this I apologize for. 

 

And there's no reason why DMA cannot be used to transfer data to user mode space. Note that I'm talking about data tranfer and not about DMA programming.

 

But what you seem (oops I said "seem", I have some nerve!) to be saying is that you indeed need to make a syscall to do DMA, which is what I assumed ("assumed"? you must be raging by now). Thank you for proving yourself wrong once again.

Well I am not like you Dexter.  I don't act like I know everything, and actually value input from others. And this I apologize for. 

I don't know everything either. But I keep my mouth shut when I have no clue about what people are talking about.

But what you seem to be saying is that you indeed need to make a syscall to do DMA, which is what I assumed. Thank you for proving yourself wrong once again.

And what exactly is wrong? The whole thing was about an application bypassing the kernel cache, not about an application bypassing the whole kernel.

Dexter said:

Bass said:

*snip*

 

And what exactly is wrong? The whole thing was about an application bypassing the kernel cache, not about an application bypassing the whole kernel.

 

No Dexter,

Here is my primary arguments:

• If you design a DB, you want to delegate as much responsibility to the kernel as possible (Sven was almost insulted by this.)
• An OS can accomplish a lot of the intelligent read caching by a paging algorithm, which keeps track of the most commonly read parts of a file.
• In a modern kernel, you can control the functionality of the paging algorithm in many many ways (eg: mmap and readahead in Linux), to the point where I am not sure what this magical "domain-specific" DB cache that neither of you explained can do better.
• It would be downright stupid for a DB to take all of this in it's own hands, but I am sure there is some legacy DBs out there who still do all of this, because they were written during a time where MS-DOS was considered advanced.
• Implementing a file cache entirely in userspace (eg. malloc + memcpy) is downright idiotic.

Dexter said:

magicalclick said:

*snip*

1) Depends what you mean by DB. You can consider NTFS as being a domain specific DB. It's not relational, it doesn't process SQL queries but it stores and retrieves data, a lot of data. Incidentaly NTFS uses B-Trees which are also commonly used in databases.

2) Already done. NTFS (and probably most other filesystems) caches file metdata in RAM. Go enumerate a directory containing a large number of files. You'll likely see a ton of disk activity. Do that again. No disk activity this time.

3) Already done. File metadata caching occurs in kernel, not in the application. This means that there's only one instance of that data so there's no need for some sort of "good sync".

4) Already done. Unless you're an administrator you cannot access the disk directly, you must go through the filesystem. Also if you're not an administrator you cannot load drivers. In general this has less to do with the filesystem, it's a generic kernel problem.

Thanks for clearing that up. Now, I don't understand all the blah anymore. Well, better leave it to you guys.

Bass said:

Sven Groot said:

*snip*

But that just plainly isn't true. The kernel can figure out only what was the most common information in the past, and then hope that this will still be true in the future.

 

If you design your data structures correctly, it SHOULD be true in the future.

 

But there are many access patterns where this simply isn't true.

 

And they don't belong in databases.

 

The kernel cannot know if an application is going to have an access pattern for which this strategy doesn't work. Only the application can know that. Hence, the application can do better.

 

I don't think that's actually true. For many data structures, you can not reliably predict where an element will be located on a restructure. If you can, you can ask the kernel to cache that part of the file for you anyway. See the readahead syscall. Which is exactly how readahead daemons like preload work! They don't go around implementing their own file caching, that would be stupid. They let the kernel do it for them, as any good DB implementation would.

 

And CPU caching isn't relevant to this discussion for several reasons: 1. The timing gap between memory and disk is greater than that between CPU cache and memory. 2. CPU cache is a few MB at best, file cache is typically multiple GB. 3. The kernel does not manage the CPU cache, the CPU does that.

 

1. It may be, but having too many direct memory accesses with effect system performance in a very bad way.

2. CPU Cache is a few MB at best, so lets ignore it? That sounds like a plan chief.

3. The fact that the CPU manages the CPU cache is exactly why it's important. You can not program a CPU cache, because that is a right reserved only for the immortals who design hardware, and you are but a mortal software developer. The best you could do is structure your data in a way that is conductive to CPU caching. If you are going to do this anyway, why not structure your data in a way that is conductive to the kernel caching? Hmm? The kernel is like the CPU's prophet to software. Like most prophets, he is mortal and software like all other software, but is bestowed on by the immortals with certain miracles. But you shouldn't ignore his powers, for he speakiths directly to the hardware, and knows it's demands. You do not.

Look, I agree that in 99.9% of the cases, you do want to leave this to the kernel. I just believe that very high performance databases are one of the cases where you don't.

Of course you want to delegate as much as possible, but experience has shown that you can in fact get better performance, in many cases much better, by doing it yourself. And it's not just caching. High-performance applications tend to do their own scheduling and memory management as well. Yes, it's an enormous amount of work, so the only reason people do this is because it makes a clear, measurable difference.

They let the kernel do it for them, as any good DB implementation would.

So you contend that SQL Server, Oracle, IBM DB2 and other databases that dominate the TPC-C and TPC-H benchmarks are all in fact not any good because they do their own caching?

Sven Groot said:

Bass said:

*snip*

So you contend that SQL Server, Oracle, IBM DB2 and other databases that dominate the TPC-C and TPC-H benchmarks are all in fact not any good because they do their own caching?

I think he is more refering to stuff like C#. Kernel took care of lower level stuff and DB people took care of higher level stuff. But, that only works for lazy people like me. For pure DB people, I am sure they want to do everything themselves to get a better performance than general kernel.

Sven Groot said:

Bass said:

*snip*

So you contend that SQL Server, Oracle, IBM DB2 and other databases that dominate the TPC-C and TPC-H benchmarks are all in fact not any good because they do their own caching?

Of course you want to delegate as much as possible, but experience has shown that you can in fact get better performance, in many cases much better, by doing it yourself. And it's not just caching. High-performance applications tend to do their own scheduling and memory management as well. Yes, it's an enormous amount of work, so the only reason people do this is because it makes a clear, measurable difference.

What "clear, measurable" difference? Every DB vendor claims they are the fastest DB. Even SQLite claims it's the fastest DB. That's right, a barely 200kB shared library DB is claiming victory. MySQL/Oracle has similar comparisons, showing how they are the fastest. You can probably find that if you visit their websites, I've seen them before. Every DB vendor is going to claim it's the fastest. It's a sales tactic. There is no objectivity here.

If you want to argue with me on this, argue on a technical level. Explain exactly what this DB file caching algorithm can do not the kernel can not. I'd like to know. I've asked repeatedly, but I've got no answers. Speak to me with data structures and algorithms. You are a DB expert, you should know this. You guys can't think it's just some kind of fact that should be assumed. CS doesn't work that way.

Bass said:

Sven Groot said:

*snip*

Of course you want to delegate as much as possible, but experience has shown that you can in fact get better performance, in many cases much better, by doing it yourself. And it's not just caching. High-performance applications tend to do their own scheduling and memory management as well. Yes, it's an enormous amount of work, so the only reason people do this is because it makes a clear, measurable difference.

 

What "clear, measurable" difference? Every DB vendor claims they are the fastest DB. Even SQLite claims it's the fastest DB. That's right, a barely 200kB shared library DB is claiming victory. MySQL/Oracle has similar comparisons, showing how they are the fastest. You can probably find that if you visit their websites, I've seen them before. Every DB vendor is going to claim it's the fastest. It's a sales tactic. There is no objectivity here.

 

If you want to argue with me on this, argue on a technical level. Explain exactly what this DB file caching algorithm can do not the kernel can not. I'd like to know. I've asked repeatedly, but I've got no answers. Speak to me with data structures and algorithms. You are a DB expert, you should know this. You guys can't think it's just some kind of fact that should be assumed. CS doesn't work that way.

What "clear, measurable" difference?

Well, let's look at the top ten results of the TPC-C. If SQLite is so great, why isn't it in there? Or the TPC-H, for that matter. Or check the huge amount of research being done on this topic. Apparently every single one of the papers was a waste of time because the kernel can do better anyway.

I've asked repeatedly, but I've got no answers.

I've answered repeatedly, but you keep igoring it. It isn't a matter of algorithms, it's a matter of information. The database knows its own usage patterns, and can therefore make better caching decisions even when using the same algorithms as the kernel.

And yes, it would be great if the applications could feed sufficiently detailed information to the kernel so that it could do better. But if that's so easy, then why aren't more applications doing it?

Sven Groot said:

Bass said:

*snip*

I've answered repeatedly, but you keep igoring it. It isn't a matter of algorithms, it's a matter of information. The database knows its own usage patterns, and can therefore make better caching decisions even when using the same algorithms as the kernel.

 

And yes, it would be great if the applications could feed sufficiently detailed information to the kernel so that it could do better. But if that's so easy, then why aren't more applications doing it?

Well, let's look at the top ten results of the TPC-C. If SQLite is so great, why isn't it in there?

Maybe because they don't test it? Did you even bother looking before you pasted that link?

I've answered repeatedly, but you keep igoring it. It isn't a matter of algorithms, it's a matter of information. The database knows its own usage patterns, and can therefore make better caching decisions even when using the same algorithms as the kernel.

What exactly would a database know that could possibly aid it in caching? That's not exactly obvious is it? Then why make an assumption that you can not even answer?

But seriously, let's talk algorithms.

You are building a DB, and you store your DB information in a file or a series of files, right?

You have to somehow access those files, by using some kind of file api (eg: fopen, fseek), or something like mmap.

Now you want to cache something, what do you do? Explain the functions a typical DB would use to cache something. And then explain exactly how this is better then using readahead. Because I can not explain this, and you apperently can.

And yes, it would be great if the applications could feed sufficiently detailed information to the kernel so that it could do better. But if that's so easy, then why aren't more applications doing it?

First of all, only modern kernels (eg: Linux 2.6) have the syscall that allows processes to suggest parts of a file be in the kernel's file cache. I don't think Windows any similar syscall, or if it does, it's poorly documented because I've looked hard. So you might be SOL on Windows support, and that's probably one of many reason Drizzle doesn't work on Windows.  Secondly, there are applications that do use it (I even named one), so your entire permise is wrong. Thirdly, you wouldn't know if Oracle/DB2 et al. do it, because they are closed source. Forthly, well I think 1, 2, and 3 were enough in this case.

Bass said:

Sven Groot said:

*snip*

Well, let's look at the top ten results of the TPC-C. If SQLite is so great, why isn't it in there?

 

Maybe because they don't test it? Did you even bother looking before you pasted that link?

 

I've answered repeatedly, but you keep igoring it. It isn't a matter of algorithms, it's a matter of information. The database knows its own usage patterns, and can therefore make better caching decisions even when using the same algorithms as the kernel.

 

What exactly would a database know that could possibly aid it in caching? That's not exactly obvious is it? Then why make an assumption that you can not even answer?

But seriously, let's talk algorithms.

 

You are building a DB, and you store your DB information in a file or a series of files, right?

You have to somehow access those files, by using some kind of file api (eg: fopen, fseek), or something like mmap.

Now you want to cache something, what do you do? Explain the functions a typical DB would use to cache something. And then explain exactly how this is better then using readahead. Because I can not explain this, and you apperently can.

And yes, it would be great if the applications could feed sufficiently detailed information to the kernel so that it could do better. But if that's so easy, then why aren't more applications doing it?

 

First of all, only modern kernels (eg: Linux 2.6) have the syscall that allows processes to suggest parts of a file be in the kernel's file cache. I don't think Windows any similar syscall, or if it does, it's poorly documented because I've looked hard. So you might be SOL on Windows support, and that's probably one of many reason Drizzle doesn't work on Windows.  Secondly, there are applications that do use it (I even named one), so your entire permise is wrong. Thirdly, you wouldn't know if Oracle/DB2 et al. do it, because they are closed source. Forthly, well I think 1, 2, and 3 were enough in this case.

 

 

Now you want to cache something, what do you do?

As I've said a million times, but you keep ignoring, it isn't about when you want to cache something. It's about when you want to remove something from the cache. Let's say the DB is executing an execution plan that accesses two tables A and B. Unfortunately, table A isn't cached, and B is currently the least recently used table in the cache. Based on regular LRU policy, reading A would place it in the cache and push B out, so then B would subsequently be read from disc. But the DB knows the execution plan, it knows it's going to read B next, and so it knows removing B from the cache at this point is a bad decision. The kernel doesn't know that.

That's just one simple example. There is 40 years of research on this point, and no, I don't know it all, nor do I have the time to read all of it and create a summary for you.

First of all, only modern kernels can do things like readahead. I don't think Windows any similar functionality, or if it does, it's poorly documented, because I've looked hard.

So basically what you're saying is that you can't delegate this functionality to the kernel, because most kernels in use in production systems today don't expose the functionality that allow you to do this. Thanks for proving my point.

Note that I have never claimed that this is a universal truth that will never change. Perhaps in the future you can give enough information information to the kernel so you can rely solely on the caching it provides. That would be great. All I'm saying that in current production databases, this isn't the case. And this isn't because the developers of those databases were idiots, as you seem to be implying.

These people don't implement their own caching schemes because they have nothing better to do. I'm sure they started out without explicit caching, but then they profiled it and found they were hitting the disc more often than was needed. That's how performance optimization works: you start with a simple solution, measure it, then try to improve. That's where these caching solutions come from. They didn't set out thinking "well I've heard that we have to cache things manually, so let's not measure it and do it regardless". That's not how these things work.

Sven Groot said:

Bass said:

*snip*

So basically what you're saying is that you can't delegate this functionality to the kernel, because most kernels in use in production systems today don't expose the functionality that allow you to do this. Thanks for proving my point.

 

Note that I have never claimed that this is a universal truth that will never change. Perhaps in the future you can give enough information information to the kernel so you can rely solely on the caching it provides. That would be great. All I'm saying that in current production databases, this isn't the case. And this isn't because the developers of those databases were idiots, as you seem to be implying.

 

These people don't implement their own caching schemes because they have nothing better to do. I'm sure they started out without explicit caching, but then they profiled it and found they were hitting the disc more often than was needed. That's how performance optimization works: you start with a simple solution, measure it, then try to improve. That's where these caching solutions come from. They didn't set out thinking "well I've heard that we have to cache things manually, so let's not measure it and do it regardless". That's not how these things work.

Let's say the DB is executing an execution plan that accesses two tables A and B. Unfortunately, table A isn't cached, and B is currently the least recently used table in the cache. Based on regular LRU policy, reading A would place it in the cache and push B out, so then B would subsequently be read from disc. But the DB knows the execution plan, it knows it's going to read B next, and so it knows removing B from the cache at this point is a bad decision. The kernel doesn't know that.

Okay, so you need to allocate some space for the entire A, memcpy it over (poor CPU). Then leave table B in memory (it's already there as you said), but you have to drop something right? So drop table C? What if the execution which the DB doesn't know about deals with table C? In your contrived example, if that was the case, having no user-mode cache would actually be faster. Woops!

Even if your cache implementation gained awesome kernel powers, ie. caching was actually efficient thanks to ring0 technologies, I still think the BEST cache algorithm would simply be "keep commonly accessed data in memory". Why? Because that, is commonly accessed data is likely .. accessed. It's a brainf**k I know, but the simple solution in this case might be the overall fastest. When you pull some commonly accessed data out of memory, chances are, you going to be put it right back anyway. All your are doing is delaying the inevitable page fault. Thus defeating the purpose of a complex heuristics  algorithm that wastes clock cycles thinking what decision to fail on next.

To see a similar philosophy in action, see O(1) vs CFS vs BFS. You can put plenty of contrived examples that show BFS should be the slowest piece of sh!t on the planet. But overall, it hauls *.

So basically what you're saying is that you can't delegate this functionality to the kernel, because most kernels in use in production systems today don't expose the functionality that allow you to do this. Thanks for proving my point. Note that I have never claimed that this is a universal truth that will never change. Perhaps in the future you can give enough information information to the kernel so you can rely solely on the caching it provides. Perhaps in the future you can give enough information information to the kernel so you can rely solely on the caching it provides. That would be great.

Okay, this kind of functionality is new in that it's not 30 years old.  But it's been around for something like 6-7 years, as so far is Linux is concerned. Certainly not something "in the future". Unless "the future is now". I'm sure Windows has it too, it's probably just one of those "undocumented APIs", because Prefetch could not realistically work having some control over the kernel cache. But I am sure you know all about this already, since you are a DB/caching expert.

All I'm saying that in current production databases, this isn't the case. And this isn't because the developers of those databases were idiots, as you seem to be implying.

I said it was idiotic to do this now. When a lot of these DBs were first designed, MS-DOS was considered advanced. Even MySQL, despite being a more modern DB then the rest, is "archaic" enough that a fork is in process to "modernize" it (in order to make it faster, interestingly enough), and a big part of that is removing stuff like user-mode caching. "LOLWUT? Removing code is improvement??? Blasphemy! I MEASURE PROGRESS IN SLOCS!"

Bass said:

CreamFilling512 said:

*snip*

The CPU cache thing was in regard to Dexter's assertion that a DB shouldn't have to localize it's important data. Quite frankly to run efficiently on an x86 processor, it has no other choice. . I don't know how many of you ever did assembly programming. Although you can create a memory caching algorithm, you can't create your own processor caching algorithm on x86. That is hard-coded on the CPU by Intel/AMD. Performance degrades considerably on x86 if there is are many cache misses, which is the cache equivalent of a page fault. So your data structures must consider this in order to efficiently run on the architecture.

No, it really doesn't matter at all.  A database server is going to be I/O limited, not CPU limited, why would you optimize something like that?  If the server needs to read I/O by making a system call, its going to switch context and there goes your whole cache anyway, so why do we care about CPU cache again?

CreamFilling512 said:

Bass said:

*snip*

No, it really doesn't matter at all.  A database server is going to be I/O limited, not CPU limited, why would you optimize something like that?  If the server needs to read I/O by making a system call, its going to switch context and there goes your whole cache anyway, so why do we care about CPU cache again?

A database server is going to be I/O limited, not CPU limited, why would you optimize something like that?

The fact that a database server is I/O limited is exactly why you want to access time. Think for a moment on why that would be so.

If the server needs to read I/O by making a system call, its going to switch context and there goes your whole cache anyway, so why do we care about CPU cache again?

The kernel doesn't even need to involve the CPU all that much to read I/O to memory. Come on, pay attention to the rest of the debate, I mentioned this before and Dexter even elaborated on the point.

Bass said:

CreamFilling512 said:

*snip*

A database server is going to be I/O limited, not CPU limited, why would you optimize something like that?

 

The fact that a database server is I/O limited is exactly why you want to access time. Think for a moment on why that would be so.

 

If the server needs to read I/O by making a system call, its going to switch context and there goes your whole cache anyway, so why do we care about CPU cache again?

 

The kernel doesn't even need to involve the CPU all that much to read I/O to memory. Come on, pay attention to the rest of the debate, I mentioned this before and Dexter even elaborated on the point.

Everytime you issue a kernel-mode I/O request you are doing a system call, throwing up an interrupt, and causing a thread context switch to kernel-mode regardless of if the kernel actually has to go to disk for the data or not.  You are thrashing the CPU cache by doing this.

Bass said:

Sven Groot said:

*snip*

Let's say the DB is executing an execution plan that accesses two tables A and B. Unfortunately, table A isn't cached, and B is currently the least recently used table in the cache. Based on regular LRU policy, reading A would place it in the cache and push B out, so then B would subsequently be read from disc. But the DB knows the execution plan, it knows it's going to read B next, and so it knows removing B from the cache at this point is a bad decision. The kernel doesn't know that.

 

Okay, so you need to allocate some space for the entire A, memcpy it over (poor CPU). Then leave table B in memory (it's already there as you said), but you have to drop something right? So drop table C? What if the execution which the DB doesn't know about deals with table C? In your contrived example, if that was the case, having no user-mode cache would actually be faster. Woops!

 

Even if your cache implementation gained awesome kernel powers, ie. caching was actually efficient thanks to ring0 technologies, I still think the BEST cache algorithm would simply be "keep commonly accessed data in memory". Why? Because that, is commonly accessed data is likely .. accessed. It's a brainf**k I know, but the simple solution in this case might be the overall fastest. When you pull some commonly accessed data out of memory, chances are, you going to be put it right back anyway. All your are doing is delaying the inevitable page fault. Thus defeating the purpose of a complex heuristics  algorithm that wastes clock cycles thinking what decision to fail on next.

 

To see a similar philosophy in action, see O(1) vs CFS vs BFS. You can put plenty of contrived examples that show BFS should be the slowest piece of sh!t on the planet. But overall, it hauls *.

 

So basically what you're saying is that you can't delegate this functionality to the kernel, because most kernels in use in production systems today don't expose the functionality that allow you to do this. Thanks for proving my point. Note that I have never claimed that this is a universal truth that will never change. Perhaps in the future you can give enough information information to the kernel so you can rely solely on the caching it provides. Perhaps in the future you can give enough information information to the kernel so you can rely solely on the caching it provides. That would be great.

 

Okay, this kind of functionality is new in that it's not 30 years old.  But it's been around for something like 6-7 years, as so far is Linux is concerned. Certainly not something "in the future". Unless "the future is now". I'm sure Windows has it too, it's probably just one of those "undocumented APIs", because Prefetch could not realistically work having some control over the kernel cache. But I am sure you know all about this already, since you are a DB/caching expert.

 

All I'm saying that in current production databases, this isn't the case. And this isn't because the developers of those databases were idiots, as you seem to be implying.

 

I said it was idiotic to do this now. When a lot of these DBs were first designed, MS-DOS was considered advanced. Even MySQL, despite being a more modern DB then the rest, is "archaic" enough that a fork is in process to "modernize" it (in order to make it faster, interestingly enough), and a big part of that is removing stuff like user-mode caching. "LOLWUT? Removing code is improvement??? Blasphemy! I MEASURE PROGRESS IN SLOCS!"

Okay, so you need to allocate some space for the entire A, memcpy it over (poor CPU).

Since you seem incapable to accept that usermode caching can be done without memcpy despite the fact I explained how it can be done, would you be so kind to explain to us why we should bother to provide more evidence?

And when all you can say is "the kernel is awesome" and the "cache is intelligent" do you expact us to provide complete technical arguments? Since when "awesomeness" is a technical word? Or "brainf**k"?

You bring a lot of stuff into discussion but you fail to provide any decent example on how the said stuff might be used. readahead? sure, why not. Let's say what this readahead is all about:

ssize_t readahead(int fd, off64_t offset, size_t count);

So, the database has to tell the kernel to bring in memory a specific portion of the file. Woops. The database has to know that! The horror! The sheer stupidty of the database having to know what parts of the file it needs! How's that any different from the database doing non cached read operations? And your fancy pants readahead call turns out to be a synchronous call. Not the best way to achieve high performance.

mmap? Sure, why not? To your advantage servers have moved to 64 bits and mapping huge files is less of an issue. It would be fun to see you using mmap with a 50 GB database on a 32 bit system. You'll have to keep call mmap and munmap all day long. And you'll probably trigger a lot of page faults in the process. I'm not even bothering to ask how to deal with writes when mmap is involved. Feel free to figure out for yourself if you think you're soo cool and everyone else is an idiot.

HDD's head position? What a good joke, probably from a Sci Fi book. Yes, sure, there are disk I/O scheduling algorithms that take into account the position of the head. Except that:

- what the kernel does is keep track of where on the drive the last operation was performed, it does not get this information from the drive. Since high performance databases tend to used dedicated drives they can keep track of this too. Not that they need to to do so because at the end of the day they don't bypass the disk driver. In any case, there's no "zomg" context switch required for this. In the worst case the database needs to retrieve the drive geometry from the kernel but since that doesn't change over time it can be done only once, at startup.

- even some, "modern", consumer drives can do command queueing (ever heard of NCQ?). Good look trying to keep track of head's position with those drives. Though you won't need to do that, they do command queueing so the kernel doesn't need to do it.

- should I bother to mention SAN storage? Those boxes with tens or hundreds of drives where a read/write request can be spread to multiple drives?

Keeping commonly accessed data in memory? Sure, why not? But what exactly constitues "commonly accessed data" in a database given the fact that it can process a wide number of queries and each query might require completly different data?

Bass said:

Sven Groot said:

*snip*

Of course you want to delegate as much as possible, but experience has shown that you can in fact get better performance, in many cases much better, by doing it yourself. And it's not just caching. High-performance applications tend to do their own scheduling and memory management as well. Yes, it's an enormous amount of work, so the only reason people do this is because it makes a clear, measurable difference.

 

What "clear, measurable" difference? Every DB vendor claims they are the fastest DB. Even SQLite claims it's the fastest DB. That's right, a barely 200kB shared library DB is claiming victory. MySQL/Oracle has similar comparisons, showing how they are the fastest. You can probably find that if you visit their websites, I've seen them before. Every DB vendor is going to claim it's the fastest. It's a sales tactic. There is no objectivity here.

 

If you want to argue with me on this, argue on a technical level. Explain exactly what this DB file caching algorithm can do not the kernel can not. I'd like to know. I've asked repeatedly, but I've got no answers. Speak to me with data structures and algorithms. You are a DB expert, you should know this. You guys can't think it's just some kind of fact that should be assumed. CS doesn't work that way.

See a million-and-one benchmarks of SQL Server running in Threaded mode (kernel handles scheduling) vs Fiber mode (SQL Server manages scheduling). Prior to the enormous amount of work done in Server 2008 R2 (much of which was driven by SQL Server), fiber mode won absolutely hands down.

You keep coming back to the argument that MRU is always the best caching policy. But there is lots of CS research out there that proves that simply isn't the case. And a basic assumption of all CS is that the more you know about a problem in advance, the easier it is to provide the optimal solution.  

Bass said:

Sven Groot said:

*snip*

Let's say the DB is executing an execution plan that accesses two tables A and B. Unfortunately, table A isn't cached, and B is currently the least recently used table in the cache. Based on regular LRU policy, reading A would place it in the cache and push B out, so then B would subsequently be read from disc. But the DB knows the execution plan, it knows it's going to read B next, and so it knows removing B from the cache at this point is a bad decision. The kernel doesn't know that.

 

Okay, so you need to allocate some space for the entire A, memcpy it over (poor CPU). Then leave table B in memory (it's already there as you said), but you have to drop something right? So drop table C? What if the execution which the DB doesn't know about deals with table C? In your contrived example, if that was the case, having no user-mode cache would actually be faster. Woops!

 

Even if your cache implementation gained awesome kernel powers, ie. caching was actually efficient thanks to ring0 technologies, I still think the BEST cache algorithm would simply be "keep commonly accessed data in memory". Why? Because that, is commonly accessed data is likely .. accessed. It's a brainf**k I know, but the simple solution in this case might be the overall fastest. When you pull some commonly accessed data out of memory, chances are, you going to be put it right back anyway. All your are doing is delaying the inevitable page fault. Thus defeating the purpose of a complex heuristics  algorithm that wastes clock cycles thinking what decision to fail on next.

 

To see a similar philosophy in action, see O(1) vs CFS vs BFS. You can put plenty of contrived examples that show BFS should be the slowest piece of sh!t on the planet. But overall, it hauls *.

 

So basically what you're saying is that you can't delegate this functionality to the kernel, because most kernels in use in production systems today don't expose the functionality that allow you to do this. Thanks for proving my point. Note that I have never claimed that this is a universal truth that will never change. Perhaps in the future you can give enough information information to the kernel so you can rely solely on the caching it provides. Perhaps in the future you can give enough information information to the kernel so you can rely solely on the caching it provides. That would be great.

 

Okay, this kind of functionality is new in that it's not 30 years old.  But it's been around for something like 6-7 years, as so far is Linux is concerned. Certainly not something "in the future". Unless "the future is now". I'm sure Windows has it too, it's probably just one of those "undocumented APIs", because Prefetch could not realistically work having some control over the kernel cache. But I am sure you know all about this already, since you are a DB/caching expert.

 

All I'm saying that in current production databases, this isn't the case. And this isn't because the developers of those databases were idiots, as you seem to be implying.

 

I said it was idiotic to do this now. When a lot of these DBs were first designed, MS-DOS was considered advanced. Even MySQL, despite being a more modern DB then the rest, is "archaic" enough that a fork is in process to "modernize" it (in order to make it faster, interestingly enough), and a big part of that is removing stuff like user-mode caching. "LOLWUT? Removing code is improvement??? Blasphemy! I MEASURE PROGRESS IN SLOCS!"

You appear to be under the assumption that memcpy has to be implemented by a big CPU loop copying data around in physical memory. Or that a database that was managing it's own memory allocation and caching algorithms would work in different sized units to memory pages.

Challenge your assumptions.