A friend of mine half-jokingly says that the only reason to put data into a database is to get it back out again. In order to get data out, we need to ensure some kind of durability. Relational databases offer single server durability through write-ahead logging and checkpoint mechanisms. These are tried and true methods of writing data to a replay log on disk as well as caching writes in memory.
It’s a bit early to be updating my goals for 2011, but I’m really excited about this one. Over the course of last week, I wrote an article about loading data into Riak. I had a brief conversation with Mark Phillips (blog | twitter) about adding some of the code to the Riak function contrib. This is where a sane person would say “Yeah, sure Mark, do whatever you want with my code.
While preparing for an upcoming presentation about Riak for the Columbus Ruby Brigade, I wrote a simple data loader. When I initially ran the load, it took about 4 minutes to load the data on the worst run. When you’re waiting to test your data load and write a presentation, 4 minutes is an eternity. Needless to say, I got frustrated pretty quickly with the speed of my data loader, so I hit up the Riak channel on IRC and started digging into the Ruby driver’s source code.
The Last Ten Years My career has been particularly interesting. I’ve been very fortunate to work with a variety of different languages, platforms, databases, frameworks, and people. I started off working with Perl on HP-UX. As I started automating more of my job, I added ASP.NET to the mix. Eventually I learned about databases, first with Oracle, then SQL Server, then with PostgreSQL, and finally back to SQL Server. Along the way I’ve held job a variety of different job titles – system administrator, system engineer, developer, consultant, architect, and database administrator.
When I initially started working with MongoDB, it was very easy to get started. I could create schemas, create data, and pretty much do everything I wanted to do very quickly. As I started progressing through working with MongoDB, I started running into more and more problems. They weren’t problems with MongoDB, they were problems with the way I was thinking about MongoDB.
I Know How Stuff Works The biggest mistake that I made was carrying over ideas about how databases work.
Once, long ago, men carved their knowledge into the walls of caves so that it would be available for all time. Unfortunately, their knowledge was tied to once place. Eventually, a forward thinking cave dweller thought about carving his knowledge into a clay tablet. He was savagely beaten to death and his family burned as witches. Eventually the other cave dwellers realized that it was probably a good idea to have a more portable way to store their knowledge and they too adopted this portable clay-based knowledge transfer system.
Favors for Favors Meteor in the Desert Sky Schedule Your Fun Stuff 5 Lessons We’ve Learned Using AWS – AWS is a strange monster and you need to pay close attention when you’re using it. Sharding with SQL Azure – You’re going to need to know this some day, might as well figure it out now. Masterless Distributed Computing with Riak Core – PDF Alert! Rusty Klophaus gave a presentation about how the guts of Riak (Riak Core) can be used outside of Riak to build masterless clusters – any node can go down and the cluster will still function.
Every database has secondary indexes, right? Not quite. It turns out that some databases don’t support them. Secondary indexes are important because they make it possible to perform more, quick, queries on a given chunk of data. What if we want to add secondary indexes to a database, how would we go about doing it? Looking at queries, there are a few basic ways that we actually query data:
Equality predicates Inequality predicates Multi-predicate queries We’re going to be using Riak as our example database
Steve Jones created this month’s topic: What the business says is not what the business wants. Despite the inflammatory title, it’s really about interacting with business: What issues have you had in interacting with the business to get your job done? I’m going to piss a lot of you off right now: it’s your fault. Ready to get more angry? Shut up and listen. Stop. Shut up. Listen. When you start having those gut reactions about terminology, proper technique, or anything else: shut up and listen.
Last week, I sent an email to the PASS Board of Directors. It said, in short, that I was stepping down from my seat on the board. In fact, here’s the email:
A few months ago I made a huge change in my career and stepped out of my role as a production DBA and into a new career working with new databases. The more time I spend with these databases, the more I realize that they need an exciting, vibrant community like we have here in PASS.