Why would you ever write a new database? Particularly an in-memory database, which, back in 2009, made zero sense to the ruling database class of the time. Salvatore Sanfilippo didn’t really care. He wasn’t trying to change anyone’s minds about what a database should be. He just needed to scale a real-time analytics engine, and MySQL couldn’t do so cost-effectively.

So he built Redis, as one does, and changed the database market forever.

[ Also on InfoWorld: Remember when open source was fun? ]
In a series of conversations with open source project founders like Sanfilippo over the past few weeks, I’ve been struck by how often they started with trying to answer a specific need — an “itch,” in the open source parlance — but ended up changing the way whole product categories work. They weren’t trying to be clever. They were just trying to be useful.

Which makes me wonder. If your organization is trying to figure out new ways to innovate, have you tried encouraging your employees to dive more deeply into open source?

Explore new things

Sometimes we get stuck in the comfortable routines of legacy technology. Sanfilippo said as much in a Twitter conversation, pointing out that it’s “possible to explore new things” in certain software fields even if everything looks “solved.” The relational database (RDBMS) market was somewhat stagnant for decades. Yes, we saw new functionality emerge, and even cool new open source databases (MySQL, PostgreSQL), but we kept shoving things into rows and columns because that was the “right way” to work with data.

Even though it wasn’t. Not always, at least. And maybe not even most of the time.

Yes, some data absolutely fits the relational model, particularly systems of record like an ERP system. But as the world has moved to systems of engagement, very little of that data is structured/semi-structured. The relational model requires data be flattened into two-dimensional, tabular structures. A document database like MongoDB, by contrast, offers a rich, dynamic data model that better fits with the structure of objects in modern programming languages.

This isn’t to say that one database is better than another; each does its job well. Rather, it’s to suggest that we wasted a lot of years trying to squeeze unstructured data into a relational format. We figured the database was a “solved” problem, as Sanfilippo put it. That mistake cost us significant amounts of productivity.

#redis #databases #twitter conversation

How Redis scratched an itch — and changed databases forever
1.20 GEEK