Some MySQL news to start. They call the engine Maria. “They” being MySQL AB co-founder Monty Widenius, and Maria being his new storage engine for MySQL. On his new blog, Monty Says, Monty says Maria is, “. . . a crash-safe alternative to MyISAM”, and continues with a very thorough FAQ.
On his MySQL Performance Blog, Peter Zaitsev responds to both the arrival of Maria and the new blog: “I’m really excited to see Monty speaking publicly again in the free form rather than in form of sanitized interviews and press releases we’ve seen during recent years. . . . It is still unclear how Maria will be integrated with MySQL (what version, which conditions etc) . . . Initial version has two main benefits compared to MyISAM – it has page cache for rows . . . and it will be (optionally) crash safe.” Peter also describes his early experiences with the new engine.
Kevin Burton’s NEW FeedBlog has some links to other Maria-related blogs, and has Kevin’s own thoughts on Maria and SSD: “InnoDB was generally designed for use with HDDs. . . . However, MyISAM on SSD wouldn’t suffer form the same performance hit due to lock contention. . . . So why not ditch InnoDB and just go with MyISAM? InnoDB is a bloated beast compared to MyISAM.”
Senior MySQL DBA Farhan Mashraqi has an item about the MYSQL “support gap”. Farhan writes, “A CTO of a large company confided in me. . . that they are so tired of searching for qualified MySQL DBAs that they may switch to Oracle. . . . Today, I hear that ValueCentric. . . . has decided to let go of MySQL . . . Folks, MySQL is a tool and you need to know how to use that tool to get the job done. Just because you have been able to successfully open a tool doesn’t mean that you know how to use it.”
On MySQL DBA – An Oracle DBA’s Journey, George Trujillo has similar ideas, and warns, don’t underestimate MySQL. “Because MySQL is so easy to install, people can forget or not realize that MySQL is a full blown database server. . . . As a MySQL DBA you are going to have to configure, tune and manage MySQL as a database server similar to how other database servers are managed. MySQL’s performance, scalablity, security and ease of administration are dependent on how MySQL is configured.”
Underestimating MySQL is perhaps what Curt Monash of DBMS2 does when he groups it (and others) with FileMaker. He asks, “What hard-core transactional applications have actually been built in MySQL, PostgreSQL, EnterpriseDB, or FileMaker?”. And he gets plenty of answers.
Roland Bouman doesn’t do rants normally, but he gets one going at another DBMS2 item. “I feel compelled to debunk the – IMO – downright slanderous post entitled ’14 reasons not to use MySQL or other mid-range database management systems'”
This notion — “MySQL is not a real (R)DBMS” — comes up a lot. To my relatively uneducated eye, it always seems obviously false, like defensive FUD from people whose interests lie with another DBMS. What do you think? I’d love to hear some discussion of this, so please leave a comment.
Is this another example of mixing the real with the unreal? Leo Hsu and Regina Obe of the Postgres OnLine Journal post a howto on using MS Access with PostgreSQL. “People who have never used Microsoft Access or anything like it and consider themselves hard-core programmers or database purists, dismiss Microsoft Access as a dangerous child’s toy, causing nothing but grief when real programmers and database administrators have to debug the disorganized mess of amateurs. . . . Beneath the croft of this dinkiness/dangerous toy is a RAD and Reporting tool that can connect to any database with an ODBC or ADO driver.”
Lewis Cunningham of PostgreSQL DB News has an item on EnterpriseDB “joining Amazon in the cloud”. “EnterpriseDB’s announcement, EnterpriseDB to Deliver OLTP Database Using Amazon Cloud, means that . . . you will now be able to get a robust, Enterprise-class database (that just happens to support SPL, EnterpriseDB’s PL/SQL compatible language) in the cloud. . . . It will be interesting to see what kind of guarantees can be offered on a service like this. OLTP processing requires very reliable computing, much more so than OLAP and reporting.”
To the Oracle blogs now. Eddie Awad’s blog claims that most developers are young and clueless about databases and SQL. At least, “thatâ€™s what Stephane Faroult claims in the third part of his three part video series about SQL database performance best practices.” Eddie has some thoughts on the claim, and little poll, and he has the videos, too, which are very good.
Pete Finnigan published a limited advisory on a bug fixed in the recent Critical Patch Update (CPU).
Log Buffer alumnus Beth Breidenbach hosts the Blog Carnival of Data Quality — Issue #3 on Confessions of a database geek.
The SQL Server scene suddenly lost an important and well loved member last week — Ken Henderson. Many SQL bloggers had something to say of Ken, including Crazy DBA, who offered his memories of Ken: “I learned yesterday that Ken Henderson passed away last Sunday. If anyone reading this blog does not know who he is, just do a Google search for Ken and the word ‘guru’, and you will get back plenty of links. Ken was one of the best in the industry, and he will be sorely missed.” External Links & References says, “If god grants me one wish . . . then I ask to rollback that transaction.”
Adam Machanic briefly points out news of the “release-to-manufacturing” of SQL Server 2008. But there may be more to say (and to read) about this as the announcement itself drew quite a lot of response, some of it very funny. Joel Spolsky of Joel on Software says, Microsoft can’t speak straight any more: “The guy who wrote [the announcement], Francois Ajenstat, ought to be ashamed of himself. Have some guts. Just say it’s late. We really don’t care that much. SQL Server 2005 is fine. As Judge Judy says, ‘Don’t piss on my leg and tell me it’s raining.'” He links to a wonderful send-up of the announcement.
That’s all for now. Don’t forget to get in touch if you’d like to publish an edition of Log Buffer yourself. If that’s too much involvement, LB editors always appreciate story submissions, so please send them to logbufferATpythian.com. Until next time!
Interested in working with David? Schedule a tech call.