In my last post, I forgot to mention another MySQL related Sun Blueprints™ that was recently published: MySQL Guide for Sun Storage 7000 Unified Storage Systems by Bill Aiken and Krishnan Shankar.  MySQL and the Sun Storage 7000 is a great marriage because it delivers good performance, low cost, combined with ease of management.   Configuring system I/O can be a complex and frustrating task even for experienced systems administrators.   Start ups and smaller companies using MySQL typically just don't have the skill or time to tune the I/O interface of their database.   Here the …

In my last post, I forgot to mention another MySQL related Sun Blueprints™ that was recently published: MySQL Guide for Sun Storage 7000 Unified Storage Systems by Bill Aiken and Krishnan Shankar.  MySQL and the Sun Storage 7000 is a great marriage because it delivers good performance, low cost, combined with ease of management.   Configuring system I/O can be a complex and frustrating task even for experienced systems administrators.   Start ups and smaller companies using MySQL typically just don't have the skill or time to tune the I/O interface of their database.   Here the …

Well, here we are … the first post to the InnoDB blog.   Now there is a blog dedicated solely to InnoDB products and technology. The Innobase team will be posting here regularly on all manner of topics regarding the InnoDB storage engine.  We plan to provide timely updates and important technical information about InnoDB-related products including the built-in InnoDB distributed by MySQL, the InnoDB Plugin and InnoDB Hot Backup.  We invite you to visit regularly and post your comments.

We’ve borrowed the name “Transactions on” from the computer-science journal Transactions on Database Systems, published by the ACM society for computing professionals.  Like that journal, this blog will cover a wide range of database topics, specifically as they relate to InnoDB.

Users of InnoDB know a transaction is an atomic all-or-nothing set of changes made to a collection of data.  But …

Last week, I was at the NetApp office in North Sydney for the presentation on NetApp SnapManager for Oracle. It was good opportunity to learn more about NetApp snapshots while working on a project for one of our clients in Sydney. It was an especially interesting topic as I have some experience using Veritas Checkpoints (see my presentation on test systems refreshes), and it was interesting to see what’s different and new in the NetApp implementation. But I digress.

I learned that NetApp can provide access to the same LUNs via either Fiber-Channel (FC) or iSCSI. And this is when the interesting argument surfaced. Apparently, some companies aim to have the technology stack on their …

There are a couple of bookstores in my neighborhood. They could not be more different from one another.

The first is known to focus on best seller lists, to promote popular books, and use displays and traditional retail techniques to drive business. They seem to do well, year in, year out. The other bookstore is more of a community treasure, beloved by the neighborhood, with a focus on the (thoughtful) insights of their staff. Those insights are delivered via small note cards appended to shelving throughout the store, where books are displayed alphabetically, with library-like neutrality.

The first store is very market focused, changes with the season, and seems to be quite succesful. The latter store, beloved though it may be, struggles to stay in business.

Now you might consider that an awkward …

One thing we were guessing at with Massimo yesterday is, if you store
large blobs as disk data, how much will they consume DataMemory and
IndexMemory (primary key, each "chunk" has a hidden primary key, first 25x bytes
of blob stored in memory...)?

My empirical test showed that about 2% of the total size of blobs is needed for RAM
(25% of that is IndexMemory).

IMHO this is close to negligible, but in many situations not negligible
at all (may have close to TB of disk data -> 20GB of RAM needed for
disk data).

Also note that this is a minimum figure. If you actually have something
else than the blob (like other indexes) you of course use much more RAM.

The test was:
CREATE TABLE `jpgtest` (
`id` int(11) NOT NULL,
`jpg` blob,
PRIMARY KEY (`id`)
) TABLESPACE ts_1 STORAGE DISK ENGINE=ndbcluster;

One thing we were guessing at with Massimo yesterday is, if you store
large blobs as disk data, how much will they consume DataMemory and
IndexMemory (primary key, each "chunk" has a hidden primary key, first 25x bytes
of blob stored in memory...)?

My empirical test showed that about 2% of the total size of blobs is needed for RAM
(25% of that is IndexMemory).

IMHO this is close to negligible, but in many situations not negligible
at all (may have close to TB of disk data -> 20GB of RAM needed for
disk data).

Also note that this is a minimum figure. If you actually have something
else than the blob (like other indexes) you of course use much more RAM.

The test was:
CREATE TABLE `jpgtest` (
`id` int(11) NOT NULL,
`jpg` blob,
PRIMARY KEY (`id`)
) TABLESPACE ts_1 STORAGE DISK ENGINE=ndbcluster;

One thing we were guessing at with Massimo yesterday is, if you store
large blobs as disk data, how much will they consume DataMemory and
IndexMemory (primary key, each "chunk" has a hidden primary key, first 25x bytes
of blob stored in memory...)?

My empirical test showed that about 2% of the total size of blobs is needed for RAM
(25% of that is IndexMemory).

IMHO this is close to negligible, but in many situations not negligible
at all (may have close to TB of disk data -> 20GB of RAM needed for
disk data).

Also note that this is a minimum figure. If you actually have something
else than the blob (like other indexes) you of course use much more RAM.

The test was:
CREATE TABLE `jpgtest` (
`id` int(11) NOT NULL,
`jpg` blob,
PRIMARY KEY (`id`)
) TABLESPACE ts_1 STORAGE DISK ENGINE=ndbcluster;

The bursting of the internet bubble was good for the computer industry.

Many of us didn't like the medicine, but I can't remember a single customer upset at the idea of paying $20,000 for computing infrastructure that used to cost them $100,000. The price compression came from open source software, and a move toward general purpose servers, and resulted in companies formerly making 65% gross profit on products (Sun among them) facing a new reality.

But what doesn't kill you makes you stronger.

Since then, Sun's built the biggest open source software business around (see this report for details), from platform software to application infrastructure (even a …

FYI, Sun is announcing some sweet new storage stuff on Monday at 3:30pm PT.

I’m reviewing a few of the things they’re announcing, and hope to publish my thoughts here soon (one of them joins my production network tonight if all goes well). However, I’m at Disneyland with my kids (first trip!) from Monday through Thursday, so I don’t know (yet) when I’ll be able to write them up. Bear with me if it takes a few days.

But the gear is exciting, and the direction Sun is headed is even more exciting!

…