In Part 1 of this article, I took you through some of the reasons why a column-oriented database based on MySQL can be compelling. We also examined the architecture of InfiniDB, which is an open source analytic, reporting, and read-intensive database, and how its modular design helps you scale both up and out. Now let’s kick the tires of the database so you can see these things in action.

I have for the first time seen a client implement MySQL Resource Limits. I got the following error tying to connect to the database.

$ mysql -udba -p
ERROR 1226 (42000): User 'dba' has exceeded the 'max_user_connections' resource (current value: 10)

I see from the documentation the ability to see the limits in the mysql.user table. I see this is included in the SHOW GRANTS output.

SHOW GRANTS for 'dba'@'%';
+--------------------------------------------------------------------------------------------------------------------------------------------+
| Grants for dba@%                                                                                                                         |
+--------------------------------------------------------------------------------------------------------------------------------------------+
| GRANT ALL …

So you're using explicit transactions. Everything appears to work (every query gives the expected result) until you get to COMMIT.

Then you get an exception thrown from COMMIT. What happened?

Usually this would be because the server has been shut down, or you've lost the connection.

The problem is, that you can't assume that the commit failed, but you also can't assume it succeeded.

A robust application must make NO ASSUMPTION about whether a failed commit did, indeed, commit the transaction or not. It can safely assume that either all or none of it was committed, but can't easily tell which.

So the only way to really know is to have your application somehow remember that the transaction MIGHT have failed, and check later.

Possible solutions:

• Ignore it and deal with any inconsistencies manually, or decide that you don't care :)
  …

We know all too well that most companies face database scalability and administration problems. We're working hard to make RethinkDB as fast, scalable, and flexible as possible. We use a little bit of magic and a lot of engineering for today's hardware and access patterns. You can help by telling us what your infrastructure and workloads look like. We want you to tell us about your database problems, and in exchange we'll send a RethinkDB sweatshirt to the best responses.

You can find the survey at http://www.rethinkdb.com/survey/. If you'd like us to follow up with you, make sure to check off the last checkbox. If you're in the Bay Area, we'll be happy to …

In this installment of my Drizzle Replication blog series, I'll be talking about the Transaction Log. Before reading this entry, you may want to first read up on the Transaction Message, which is a central concept to this blog entry.

The transaction log is just one component of Drizzle's default replication services, but it also serves as a generalized log of atomic data changes to a particular server. In this way, it is only partially related to replication. The transaction log is used by components of the replication services to store changes made to a server's data. However, there is nothing that mandates that this particular transaction log be a required feature for Drizzle replication systems. For instance, Eric Lambert is currently working on a Gearman-based replication service which, …

If you want a quick overview of the InfiniDB architecture and feature set, check out Part 1 of an article I wrote for the MySQL Dev Zone.

Part 2 of the article should post tomorrow and will have examples of bulk load operations and queries so you can see how InfiniDB works.  Let me know what you think. And be sure to download InfiniDB and kick the tires yourself.

If you want a quick overview of the InfiniDB architecture and feature set, check out Part 1 of an article I wrote for the MySQL Dev Zone.

Part 2 of the article should post tomorrow and will have examples of bulk load operations and queries so you can see how InfiniDB works.  Let me know what you think. And be sure to download InfiniDB and kick the tires yourself.

We’re pleased to welcome you to InfiniDB and infinidb.org! Today, Calpont is making available the open source version of our analytic database, which we’ve named InfiniDB. InfiniDB is designed to handle analytic applications, data warehouses and marts, read-intensive applications, and read shards of large Web applications. To do that effectively, we’ve tried our best to provide a feature set that’s capable of handling medium to very large data volumes and giving you faRead More...