Thursday, September 10, 2009

MyQuery 3.1.1 ready with a minor (but nasty) bugfix.

As noted in a previous post, I have released MyQuery 3.1. A user found a nasty little unnecessary bug that caused a crash in the profile dialog, when the Group by status checkbox was clicked when there was no data. This has now been fixed and a 3.1.1 version it available on Sourceforge for download.

/Karlsson

Wednesday, September 9, 2009

Released: MyQuery 3.1 Beta

MyQuery 3.1 is now ready for download from Sourceforge! There is a bunch of cool features, but the theme was Convenience and DBA Features. On top of this, UTF-8 support has also been added, not in a terribly advanced way, but it should work for most needs.

Among the new features are:
  • Events dialog to manage MySQL events
  • Much enhanced Drag-and-drop support. Drag a tables, index or column from the dictionary window to the editor, and the CREATE statement will be pasted for you.
  • SQL variables dialog, with helptext and manual links for most variables.
  • SQL Profiling support, including the ability to compare the profile of two different queries.
In addition, there has been some bug fixes, memory leak fixes, and as usual (you are sitting down now, right), updated documentation. I still have a few things to add, like online documentation, some NDB features and stuff like that, but MyQuery is getting pretty feature packed now, in particular when it comes to DBA features.

There are three different download files available from Sourceforge as above:
  • A pdf - Documentation.
  • MyQuery_3_1_setup.zip - The binary installer for Windows, including a setup program and the documentation pdf.
  • MyQuery_3_1.zip - The full sourcecode.
I want to add a few things in next release:
  • Support for the InnoDB pluging INFORMATION_SCHEMA tables, including a lock graph.
  • Support for NDB objects, such as tablespaces and stuff.
  • A few wizards.
  • Support for other storage engine specific features.
  • User and authorization management dialogs.
But that is for version 3.2, which will be a while. Keep me posed with any suggestions, ideas, bugs etc.

Cheers
/Karlsson

Tuesday, September 8, 2009

SSD disks... Bah!

SSD disks seems to be the hot and cool new disk technology. And I have to admit I don't understand why this is so hot. I think it's useful alright, but really, putting an ancient block level interface that dates back to the 1970's or so, to access a persistent, random access and fast media just seems backwards to me. Why? Because by doing this, we retain compatability with that old block-level access of course, but we loose performance and we loose random access.
Properly used, flash based memory should provide fast, persistent random-access memory, that is the promise of the technology, right? Any many seems copncered with what filesystem to use on SSD disks? Hey, com on, it's just like RAM! Slower, yes, by persistent. I don't need blcok level access, it doesn't help and the interfaces are inherently slow. And if the underlying media is random access, why, for heavens sake why?

Yes, I know there are a few issues to solve with Flash storage still, and that it will eventually "burn-out", but it seems like those problems are being worked on and a much smaller than what they used to be.

No, I don't want an SSD optimized filesystem, but I don't want to access flash over a serialized stoarge anyway! Can we instead have a standardized means of accessing flash as it should be accessed: Random access! Persistent! SSD is just a stop-gap solution for the real thing, in my mind. And yes, I understand that things take a while to develop. And yes, I understand that compatability with older equipment, hardware and OSes are a good thing. But the real McCoy here is, hey, you gessed it, a means of random access to flash! The issues with erasing flash should also be possible to solve, probably in software. So we probably need a software layer here.

Maybe we should be virtualizing RAM to flash. Maybe we should add some new interface for a "persistent malloc". Maybe applications should not need to be Flash aware (I think they should, as only the application knows what data needs persistence and what does not). But in any case, applications should be able to access Flash as true Random access, although I do understand that there are limites to this in terms of erasing. That is the problem I want fixed, not a new filesystem!

In a database, putting the transaction log on flash should be great, for example, but there are many more uses. Can we see a Flash based MySQL Storage Engine. No, not one optimized for SSD, one that accesses Flash directly!

But SSD's should, in my mind, should eventually be gone. Which is not the same thing as it will happen. We used the silly IDE interface for way too long, for example.

/Karlsson