{"id":3685,"date":"2014-02-25T22:32:42","date_gmt":"2014-02-25T12:32:42","guid":{"rendered":"https:\/\/www.flamingspork.com\/blog\/?p=3685"},"modified":"2014-03-10T17:40:18","modified_gmt":"2014-03-10T07:40:18","slug":"ghosts-of-mysql-past-part-7-pbxt","status":"publish","type":"post","link":"https:\/\/www.flamingspork.com\/blog\/2014\/02\/25\/ghosts-of-mysql-past-part-7-pbxt\/","title":{"rendered":"Ghosts of MySQL Past, Part 7: PBXT"},"content":{"rendered":"

Recently, I\u00e2\u20ac\u2122ve been writing based on my linux.conf.au 2014 talk, which you can watch the recording of<\/a>. Also see Part 1<\/a>, Part 2<\/a>, Part 3,<\/a> Part 4<\/a>, Part 5<\/a> and Part 6<\/a>. My feed feel off Planet MySQL for a bit so you may have missed those posts – so feel free to go on a trip down memory lane before returning here for, well, more of a trip down memory lane.<\/p>\n

At the start of 2005, Paul McCullagh started working on a new transactional storage engine for MySQL. He announced it in early 2006, so the majority of initial development was done before Oracle bought InnoBase Oy.<\/p>\n

It’s at this point I should correct myself from my Part 5<\/a> where I was talking about when Maria started – it was actually at the start of 2005 when the project started, about 10 months before InnoDB Friday. I think this was mostly small scale work at first, before months later having a larger focus on it.<\/p>\n

But anyway, let’s talk about PBXT! It had a different architecture than InnoDB and thus could have an interesting set of performance characteristics. The shortest way to describe the original architecture is “kind of log based”. Rows are written to a log file and there’s a handle file that points to where the rows are in the log.<\/p>\n

Also, the design had both a fixed size and a variable sized part of the row. The fixed size part was stored alongside the handle in the record data file, so it was incredibly quick at getting the fixed size part of the row.<\/p>\n

Not having to write data twice and having really quick access to some columns gave PBXT a quite decent performance advantage for many work loads.<\/p>\n

The BLOB Streaming feature that was also worked on (originally just for PBXT and then for any engine) was quite ahead of its time. Think HandlerSocket but think of it done more correctly. HandlerSocket is an awful binary protocol that supports very limited operations and uses two TCP ports (one for reads, one for writes). The blob streaming used HTTP, something that anyone could use and manipulate and proxy and whatever you’d want.<\/p>\n

If we look at Paul’s Top 5 Wishes for storage engines<\/a>, an engine test suite and sane APIs (or at least documented) would clearly have helped. Having to do API tracing to discover when you should start a transaction is probably not the best way to attract developers – the amount of time that could have been saved given better interfaces in the server was immense (and not just for PBXT developers).<\/p>\n

So, why aren’t we all using PBXT now? Well… if MySQL had shipped with PBXT, it would possibly have been a different story. There was (and indeed is) a very uneven playing field for MySQL storage engines. If you’re in the main MySQL tree then you’re everywhere. If not, then you’ve got a heck of a lot of work on packaging and keeping up to date with various API changes (not to mention ABI, which since we’re talking C++ and since we’re talking MySQL, changed a lot). With InnoDB being “good enough” for many and actually being forced to improve due to challengers such as PBXT (as well as being in the tree) it just continued to have the majority of the users… and it’s not easy making money as a storage engine vendor – and developing a storage engine does cost money.<\/p>\n

With no more than a couple of people working on it at any one time, it’s amazing that PBXT had such a big influence – and we can likely credit many InnoDB performance improvement to PBXT being so much better in some areas.<\/p>\n

An interesting side story: I was sending some build fixes\/complier warning fixes and other minimal patches to Paul when MySQL belonged to Sun and he mentioned that perhaps it was time he had a contributor agreement. I pointed out the Sun contributor agreement as an example of one that could be used, and maybe he could just replace “Sun Microsystems” with “PrimeBase” and I could submit that to the Sun system – at the very least, it would be amusing. Paul said that sounded like a great idea and I submitted Sun’s contributor agreement (which it expected outside contributors to agree to) to Sun for them to agree to.<\/p>\n

Well… a few weeks later I got a response, and Sun wasn’t exactly keen on it – until I pointed out a few times that it was in fact their agreement and then finally it was all okay.<\/p>\n

If your company wants people to agree to a contributor agreement: see if they’d agree to it if it was for someone else. It was an interesting exercise.<\/p>\n

Further reading:<\/p>\n