On 02/25/2016 06:28 AM, Vojtěch Zeisek wrote:
Copy-on-write is terribly slowing down any DB. Also snapshots don't make sense for DB (use DB's tools). Maybe there are more problematic points. That is why Btrfs is the worst for any DB.
Indeed! back in the days when oracle didn't consider UNIX - Linux didn't exist then - worth bothering with, it made the case that the DBM should be managing disk access. Even when, grudgingly, oracle migrated to some of the Big iron UNIX implementation from SUN/servers, AIX/servers and HP/UX it still insisted on running on raw partitions and not a file system. I recall one Oracle support tech telling me that using files was was for toy databases lie dBase. The file system is just another layer of indirection. Having to play COW-games as well is an overhead. So why bother? I can think of two principal reasons. 1. Integrated backups. While the database-on-raw is efficient in one way, it makes backups awkward. It involves converting tables to files ("exporting") so that the normal backup tools can be used. Slow, inefficient and error prone. 2. File systems have got better. I often refer to the early days, the V7FS, the early Berkeley FFS. They were easy to understand, in some ways easier than MinixFS. But they were not by any means efficient even by the metrics of those days. Modern file systems are not only more efficient but have facilities that those antediluvian dinosaurs never had, such as expanded file space and size, large block allocation and preallocation, journalling and more. While BtrFS, like LVM and XFS, can span more than one volume, a more useful multi-spindle approach is available with RAID, again something that wasn't there when Oracle only ran on IBM mainfrmes. Ultimately though, the oracle experience is not the beast way of looking at things. Oracle, like the original DB2, was a huge single processor with multi-thread. That's not the way UNIX/Linux views things. The *NIX model is of small, possibly dynamic, processes that have a low creation overhead. This contrasts heavily with the mainframe and even the VAX/VMS model of the long lived, fixed number of process 'slots' and 'transient program area' area. Its why, at the time, UNIX was so revolutionary. UNIX-friendly databases were things like Progress which had a number of cooperating processes which could be brought up and discarded much the way that a large shell script might work in conjunction with there services like the line printer daemon. Somewhere along the line IBM realised that if it was to run DB2 efficiently on its UNIX-like AIX it had to move away from the monolithic model to something like Progress. Sort of. At the same time, the AIX file system - JFS - was very supportive, behaving line an integrated, journal version of LVM. It was easy to group tables to a logical volume that was striped and cached in a specific manner; hence tuning was very flexible. Add to that it being well integrated to IBM's multiprocessor support. The "downside", if you want to consider it that way, with MySQL/MariaDB or Postgress on line is that they are not architected for a specific filesystem :-) If you don't like that "downside" then go with one of the proprietary databases on BigIron. Its worth googling for the performance of databases on XFS, JFS, ext4 and so on. Not just the reports from phoronix, but others as well. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org