We'll see | Matt Zimmerman

Julius Roberts: ZFS

This talk was a tour through the main features of the ZFS filesystem, showing how to work with storage pools and snapshots. It was useful to see the example commands and behavior in the context of a live command line session, as I haven’t got around to playing with it in an OpenSolaris VM yet.

Mark Atwood: memcached

I ended up in this talk in between other sessions I was attending. It outlined the sorts of places where memcached can be useful in applications. Beyond the obvious caching scenarios, Mark suggested using it to store an application’s working set (key/value dictionaries), user sessions and distributed rate limiting scoreboards.

Josh Berkus: Relational vs. Non-relational

I’ve followed with interest the NOSQL movement, and was interested to hear from Josh (of PostgreSQL Experts Inc.) what I expected would be a “relationalist” point of view.

He began by addressing some database myths. He stated that the “revolutionary new database designs” lauded by the non-relationalists are actually just new implementations of old ideas (e.g. CouchDB vs. Pick). He dismissed the “NoSQL” moniker as the wrong distinction to make: there are much more important and basic differences between database implementations than whether or not they use SQL. He explained that the relational model is orthogonal to support for ACID transactions, though I didn’t realize that was an active misconception. He also reminded us that we do not need to choose a single database for all of our possible needs, and should focus on choosing the system which fits our current application goals, or choosing multiple databases (e.g. MySQL and memcached, or [interestingly] PostgreSQL and CouchDB).

Relational OLTP databases tend to have more mature implementations of transactions, the ability to enforce data constraints and consistency, support complex reporting, and vertical scaling (but not horizontal).

SQL itself doesn’t map very well to many programming languages, but promotes application portability and enables the management of schema changes over time. “No-SQL” provides a more natural mapping, and allows programmers to act as DBAs.

His main reason to use an SQL-RDBMS was when the data will outlive current application implementations, because having a looser coupling between the database and application helps support a migration to a new implementation.

He compared the applicability of embedded key-value, distributed key-value, flat file, object, and document databases but I wasn’t able to take notes quickly enough through this segment.

His conclusion was to reiterate that “relational vs. non-relational” is the wrong way to look at the problem, and that we should instead choose the right tool for the job.