TOBY HEDE: Good morning everybody.
Friday. Yes. It's been a long week. I'm excited.
I'm highly caffeinated. So without further ado,
I present An Ode to 17 Databases in 33 Minutes.
I'm gonna mangle a large number of metaphors.
There'll be a lot of animated gifs.
I've learned that this week, if you see it like that,
there's Star Wars, Dungeons and Dragons,
and all of that's very, unfortunately, stereotypical.
So a bit of an indictment.
This whole thing started as a joke. Seventeen databases.
I actually did in five minutes. Thirty-three minutes is
worse. The whole thing is just a catastrophe, really.
But anyway.
We're gonna cover a whole bunch of different databases
and a little bit of the underlying theory, and
hopefully you'll walk out and you'll understand why to
use PostGres.
[laughter]
I'm Toby. You can find me on the internet.
I work at a company called Nine Fold.
V.O.: We're having a problem, there's no screen.
T.H.: Oh. No screens. Is that me?
Before it was, there was no red. So, now
there's no any, anything.
V.O.: Nothing.
T.H.: Hey.
AUDIENCE: Hey!
T.H.: I have no slides.
Well, you missed my beautiful slides. There's. You missed
the first animation. That's a shame. You missed the
list. It's awesome. You missed me and my excellent
job titles. So yes.
I work at Nine Fold. They have very kindly
flown me over here from Australia, which explains why
I sound like I come from the deep south.
Cause I do.
Most of this week, this has been me. So
today I'm finally over the jetlag just in time
to go home and have it all over again
next week.
So, a couple of quick facts about Straya. There
are much fewer syllables than you're used to using.
This is an, a genuine Australian politician. He's a
mining magnate billionaire and he is currently running a
MVP Jurrassic theme park with giant fiberglass dinosaurs. And
I, I for one am for it. So I
realize there wasn't enough Star Wars references so this
is just completely gratuitous.
Anyway. So. The thrust is that distributed systems are
hard and databases are fun. Pictured here is a
distributed system. You can see there's two app nodes
and then there's two, there's like a master/slave kind
of setup going on here as well. So we're
gonna talk about some of the complexities of running
these types of systems, and it's really fun stuff
once you get under the cover and start thinking
about some of the complexities.
So. NoSQL is a thing. We have NewSQL now.
I'm gonna be covering some of these things. We've
also got PostSQL, Post-Rock Ambient SQL. And there's a
whole gammit of these things. They all make my
brain explode and the, I think the trick to
understanding all of this stuff is to actually think
about some of what's happening underneath. And you can
make decisions about your databases.
Hopefully you're all familiar with some of the concepts
of traditional relational databases. We have Acid, which provides
certain guarantees about the way that your data behaves.
You can update data and be sure it was
updated. Things are isolated from each other. Things persist
over time.
Another thing that you may have heard of, this
is a, this is a leap that I need
to another animation, is a thing called the CAP
Theorem. So this gets talked about a lot when
we start talking about this new generation of databases.
CAP stands for consistency, availability, and partition tolerance, and
it provides, basically, some strong foundation for reasoning about
the way distributed systems behave and how they interoperate
and how they communicate. So I'm gonna give you
a brief introduction to how that all kind of
works.
So, the original CAP Theorem, as stated, was, is
called Brewer's Conjecture. A guy called Brewer just sort
of had this idea. It's actually on some really
awesomely-designed PowerPoint slides from some thing he did. And
he was saying that with consistency, availability, and partition
tolerance - so the data can, can only be
two of these things at any one time. So
the data can be consistent or it can be
accessible or it can handle network failures.
So people then took this conjecture and actually made
a formal kind of proof in, in much more
rigorous computer science terms. And actually said, it's impossible,
in an asynchronous network model, to implement a read/write
data object that is simultaneously available and is also
atomically consistent.
And so all of this stuff around NewSQL and
NoSQL and bleh, all of that stuff, is about
manipulating these different variables. There's also a thing called
Base but I'm not gonna talk about it cause
it's actually just a made-up acronym that has no
relevance to anything.
So, what, what does CAP actually, what, what are
we talking about here? And why is it important?
It's important, actually, because everything is already distributed. What
we do today is inherently a distributed system. You
have a browser talking to a server, an app
server, Rails server - cause we're at RailsConf -
and then that's talking to a PostGres database, or
a MySQL database or something even fancier and shinier.
That's a distributed system. And as we move into
more heavy client-based operations, that distribution is getting much
more front-loaded, so you, you've got state in the
browser that's now synchronizing with state on the server.
So we already actually suffer many of these problems.
This is a handy and completely untrue guide to
NoSQL systems and breaking them into this idea of
some things are available and some things are consistent.
So, all of that is almost but not quite
entirely untrue.
What the actual theorem says is that under a
network failure - so you've got multiple nodes and
they now can no longer communicate - you can
choose whether the data is consistent or whether the
data is available. And I have some demonstrations here
to just - it actually ends up being very
easy to understand.
So, here we have typical cluster of nodes working
together. We're gonna model some communication between them. So
there's a, there's a write on this system. It
comes in, that gets replicated across, and then on
the other system we now have that data coming
out. Someone's doing a read. And so this is
the kind of situation that we're talking about. So
whether you're doing master/slave setup in a relational database
or something trickier, this is kind of the way
it works. A node gets some data and it
gives it to another node, and they have the
same information.
So when there's a network partition, that, they no
longer can communicate. So a write comes in, and
now we have to make a decision. And all
of this is actually just science, as you can
tell from this diagram. If those two nodes can't
communicate, you can talk to the one that got
the write - that's consistent. It got the write.
It can now, can read out that same data.
That's all cool.
Or, you can have both nodes still communicating, and
now you have someone reading data that is no
longer in the write state. So we've got, you
know, we have updated a bank account. It's got
a hundred dollars in it. It used to have
ten dollars in it. These people are reading ten.
These people are reading a hundred. That's available. The
data is now not consistent. But all of the
nodes can send back that data.
And so all of the discussion about CAP Theorem
and, and you know, people even claiming, we've defeated
the CAP Theorem in our database at, you know,
low-low prices is incredibly awesome. Just remember this image.
Two things that cannot communicate cannot communicate. It's science.
And then when they can communicate, we're back into
the realm of normal operations and things get a
lot easier. If you were interested in any of
the guts of how these things work, definitely have
a look at a thing called jepsen, which is
this crazy motherfucker who is just analyzing the network
operations of a whole variety of distributed systems, and
it will, it's just, it will blow your mind.
OK. Good. That's, that's why. Now I remember.
So, here is our cast. We're about to go
on an adventure through a tortured maze of ridiculous
Dungeons and Dragons metaphors. But, first of all, a
shout out to the OwlBear. Yeah. The thing I
love about the OwlBear is they've taken the wrong,
the least scary aspects of a bear and an
owl, like if that was an owl with, you
know, if it had a bears head and wings,
that would be way more scary. Anyway.
It's just been bugging me for months. So.
PostGres. As we all know, it's MySQL for hipsters.
It's actually pretty good. So here's its character reference
sheet. We, it's a relational database. It has a
consistent model. So under conditions in network partition, you
know, your, your slave is not in contact with
the master, it's, it's essentially unavailable. That's the way
we treat it.
PostGres is actually really, really interesting tic, because it
has a bunch of cool stuff hidden underneath it.
So there's a thing called Hstore which is a
key-value store that's baked right in. So if you
need a lightweight key-value store and you're already running
PostGres in production, you, you have one. You don't
need to spin up any other thing. You can
actually do that today.
The really interesting thing about that is, you can
index those keys. You can do joins across an
Hstore reference into, across multiple tables. It looks and
feels exactly like the kind of thing that you're
already working with.
We've got, there's some things already baked into the
Rails ecosystem that make this really easy if you're
doing that kind of information. But the really exciting
thing about what PostGres is up to at the
moment is JSON. And 9.2, 9.3, and upcoming 9.4
have pretty much a fully baked in JSON document
database. And it is crazy awesome. The new one
is super high-performance. If you were sort of, it's
the same thing. If you're thinking, ah, you know,
documents would be easier for this use case, let's
install something else, we're actually, you already have one,
and it, it has all of those same properties.
You can index. You can do joins across your
normal table into the documents. It's crazy cool.
MySQL. It's pretty much the same as PostGres, is
my answer. But there's a slight caveat. So, you
know, I, I recall, they're a company. Many of
the same things apply. Like, this is why, you
know, they're, they're kind of in the same bucket.
For me, it doesn't particularly matter at the end
of the day. Whatever you happen to have expertise
in, it's cool. It's got some kind of interesting
things that you can do. You can switch out
storage engines to actually get your different performance profiles.
It is everywhere. It's got a thing called Handler
Socket, which is essentially raw, right. Access through a
low-level socket into the table infrastructure. There's some paper
with really high performance kind of things.
You can actually just sort of bypass the whole
SQL engine, which is kind of interesting. The other
thing that's happened since Oracle took over, which is
kind of a really good thing, is that there's
some alternatives. So MariaDB is sort of the, the
more open fork. There's a semi-commercial addition that has
lots of really high-performance features, and they basically run
binary compatible patches, that's Percona. And they have, like,
huge expertise. And this Toku is quite interesting. It's,
they're doing all of this crazy fractal indexing and
things for particular use cases on very large datasets.
But it still just looks and behaves in many
ways like the MySQL that you are kind of
used to.
So, there's some interesting things happening there. So these,
hopefully none of that's a huge surprise. That's databases.
You use it. It comes in the box, and
ActiveRecord talks to it.
So now we're gonna get slightly off the beaten
track. So, a lot of what we know SQL
comes from Dynamo, which was actually a paper that
Amazon released years ago. I'm not gonna labor too
much on this one. The paper's quite interesting. It
talks about how you make a distributed system.
The interesting thing is actually that Riak is essentially
an implementation of the underlying Dynamo theory. So Riak
is crazy awesome. This is what happens to you
when you run Riak in production.
[laughter]
I pretty much, like, it's a conversation I, I
often have with people is like, wouldn't it be
awesome to have a problem that needed Riak? And
it was like, yeah, that would be so cool.
I'd be like the awesomeness engineer.
So Riak is, it's just crazy-well engineered. They're doing
all sorts of interesting stuff. It's inherently, it just
understands clustering. You know, you add a new node,
it just, it's there. You know. With, with those
older kind of databases, it's, it's a pain in
the ass to actually get it working.
So, yeah, they're doing some really interesting things. It's
got a cloud storage thing so you've got an
S3-compatible API and all of these kind of stuff.
A lot of the magic of the way this
works is through consistent hashing. So, my slides are
all mucked up. But anyway.
So, basically what it does is it just partitions
all of your data into a giant hash ring.
Excuse me. Physical nodes then just own parts of
that hash. You add a new node or take
a node away and it repartitions all the rest
of the data across the remaining nodes. And all
of that is just completely in the background of
how Riak just works operationally.
So for large scale data and, you know, you,
you get away with, it has some really nice
operational characteristics that, that make it quite cool to
manage.
And then the other thing is, it's a very
simple API. It's key-value store, you can store JSON
documents in it, and it's just a bucket that
has keys, and then it's got other stuff on
top to retrieve data, do secondary indexes and searching
and all of that kind of stuff.
So, it's a very cool piece of tech.
So, the other one we've got is, Google. Fucking
annoying. And you'll see why in a second. So,
Google had this thing called BigTable that, again, kind
of comes out of the internal research. You have
access to it through some of their cloud properties.
As you can see, it's got, it's actually a
sparse distributed multidimensional sorted map, which is good, I
guess. I imagine. It's awesome.
The stuff they're doing with this is crazy. So
this is actually a, all, a couple years old
I think now. Some of these, some of the
information, so. Hundreds of petabytes of data, you know,
ridiculous numbers of operations a second. You do not
have any of these problems.
So, then they, they took this stuff, they were
like, ah, we've got BigTable. You know, that was,
that was fucking easy. Whatever. And so now they've
got two other things. They've got one called Spanner
and one called F-one, where they're basically doing, you
know, proper, sort of relational looking data across multiple
data centers and, you know, and. They're kind of
really pushing the boundaries of some of that CAP
stuff that's going on.
But all you need is a GPS in every
server, a couple of atomic clocks in each data
center, and you, great. So, Google's basically telling everyone
to, you know, just fuck off.
So, another one that I really, I really like,
and have used a long, a long time ago
in, in tech land, tech time, is Cassandra. Cassandra
is a column-oriented database. Eventually it's awesome. It's really
all about eventual consistency.
And you can see here, this is a man,
he eventually gets it right. So that's well done
to him there. So Cassandra's a lot like that.
And, again, you know, the cool thing is, it's
a sparse distributor multi dimensional sorted map. It, when
I was working with it, you, it was, you
had, you described your tables kind of thing in
XML and hated yourself, and then every time something
changed you rebooted the server and that took awhile
and, yeah, the whole thing was really difficult.
What it basically does is it takes the availability
side of the question. Like, that's its world model.
It has, again, a very simple clustering system. New
nodes, add in, the data gets streamed out. It
has a data model that is really complicated, and
I, even though I've used it, it's really hard
to explain how it actually works.
So column databases basically kind of invert the, the
whole table structure that you're used to from the
relational world. And the advantage is that, for some
types of data, and for some queries, it is
crazy blazing fast, cause you can just. Time series
are always a good one, where you can just
have long streams of time series and it will
actually put that on disk or next to each
other and you can just pull it all out.
The cool thing in the new versions of Cassandra
is that they've abstracted all of that out, and
you actually just get tables, so you can create
a table and give it a primary key, and
under the covers, it's setting up rows and column
families and columns and all of, all of these
really abstract concepts, and they've completely made some of
that go away. Which is really nice.
So you end up with something that looks a
lot like just SQL and, you know, a normal
table kind of structure. It's just clustering out lots
of nodes. It's very tunable, so you can actually
set up, you know, it writes to a node
and you can say, actually write to five nodes
and that's a quorem and now we're cool. So
you can tune how much redundancy you have.
So that's kind of cool. That is a reminder.
That went cold really fast. Thank you.
So, the next one on our list is Memcache.
Memcache, there was, there was a talk earlier in
the week that was describing using Memcache and caching
and it, it had a very interesting observation, which
was, it just works. He didn't even know what
version he was running in production, cause neh. Doesn't
matter. That API has been stable for ages.
And I know, I know what you're saying. It's
not a database. It's a cache. Technically true. But
it's interesting to think about, because the moment you
add caching, even if you've been ignoring the fact
that you had a distributed system before, with caching
you now really have a distributed system. You've got
data in one thing that may or may not
be fresh, and you've got data in your database
that, you know, you assume is up to date,
and now you've got a synchronization problem.
So, Memcache is actually really, you know, it's, it's
just rock solid, old as the hills technology, completely
simple. The API is everywhere. Lots of people actually
have made their, you know, key-value store they made
in the hacknight, which, you know, is a useful
hobby if you want to annoy everyone.
You have the, their API is actually the Memcached
API. It's got a handful of things. You can
set a key, you can replace one. It does
have something atomic operations so you can increment and
decrement so that there is some flexibility to actually
do a little bit of data storage in a,
in a more traditional sense.
It's actually a client-server model. Your, your driver is
responsible for the clustering in a way, so you
can have multiple Memcache nodes and the, the hashing
algorithm determines which node, which node a particular piece
of data is gonna be on.
That has the property of making it very, very
simple to use. And there's no cluster state. There's
no coordination that nodes have. Like, a lot of
the heavy lifting all of these other things are
doing is about coordinating around all of that information.
There's a whole bunch of awesome stuff just baked
into Rails. So you can just easily cache into
Memcache, or your normal Rails fragment mutations. All of
that kind of stuff.
And there's even some things we can, you can
actually put, push that into ActiveRecord and have, have
caching at that level as well.
Redis is an interesting one for the, the Rails
community. Cause it's basically a queue, now. Everyone seems
to be running Resq, Sidekiq, and, you know, Redis
is, again, one of those just pieces of technology
that is beautifully engineered, incredibly simple, incredibly robust. The
maintainers are just absolute, you know, scientists, I guess.
Just a whole other level of crazy algorithm stuff.
And they make blog posts and, you know, I'm
so stupid. I don't understand what you're talking about.
It's really fast, it's slightly hard to distribute. A
lot of that's in the pipeline with Redis. It's
much more, it's much more simple to, to stick
it on one node and increase the RAM. It's
mu, more complicated then Memcache. It's essentially just an
in-memory cache. It has a bunch of really interesting
data structures, though. I think if you've been confused
all week, now, which country I'm from, whether I
say dayta or dahta, so now I just changed
them randomly.
So, you can, you have hashes you have lists,
you have strings. You've got all sorts of other
interesting things. You can do optimistic locking and have,
you know, a bunch of operations that are essentially
batched. You can do sort of, there's long ways
of doing this kind of stuff. It's Resque and
Sidekiq both just make this, make it super simple
to do background tasks with Rails and install the
gem, have a worker, and it's all just magic.
It is Lua baked in, which is a whole
other thing. But Lua is a really cool programming
language that is designed for embeddability. But one of
the things that happens if you can actually write
little rule, Lua scripts that end up going into
the Redis server to do more complex operations. So,
in this case, this is a little script that
grabs something off a sorted hash and then deletes
them and then returns the first thing, like, then
returns what we had done. But it's, it's an
atomic kind of transactional way.
And, good news everybody! We've just invented stored procedures.
So that's very exciting. Except now they're much more
hip, because it's an in-memory database with a language
no one's heard of. So. We are rocking it.
Also, maybe use a queue. Just, I know it's
crazy. But, if you're actually queuing, using Redis as
your queue, maybe you have a queuing problem and
you have queues. They exist. They're a thing. It's
ridiculous. I know.
So, RabbitMQ is sort of the gold standard, and
Kafka is another one that was talked about earlier
this week, and it is crazy cool.
Where am I? Man. All right. Just gonna stretch.
I've lost count, so I don't know, now I'm
just gonna talk faster. Cool.
Neo4j is really interesting. It's a graph database. That's.
It's slightly hard to explain. But you, the way
I actually think about it, we'll just jump straight
to here, is it's almost but not quite entirely
unlike a relational database. The difference, essentially, is that
it is optimize for the connections rather than aggregated
data. So relational database, you, puts things in, in
a way where you can get a sum and
a count and like, that's kind of the heritage
of that kind of world view.
Whereas what the Neo4j people are doing is actually
thinking about connections between pieces of data, and for
some use cases, this is actually really, really amazing
stuff. So you have, a graph is basically a
collection of nodes, and those nodes can have relationships
between each other, and then a node just has
properties.
It's essentially an object database in a way. It's
like very similar to the way that we think
about objects. So it has some really nice properties
if you're working in a language like Ruby. And
then it just does stuff that, you know, in
a really intuitive way. So if we've got a
graph of movies and actors, you actually define a
relationship by name. Then an actor acts in a
movie. And then when you were doing your queries,
this is a language called Cypher, you actually, that's
a first-class thing.
Whereas in a relational world, you're, you're using a
foreign key, which has no semantic meaning at all.
You, you just have to remember that, you know,
an actor, you know, there's a table with an
actor id, and a movie id, and we're joining
across somewhere. Whereas Neo4j actually makes those relationships first
class citizens. So if you've got problems that are
graph problems, like social network friend cloud stuff, some
of that stuff, Neo4j just makes trivially easy in
a way that you would have had to do
a recursive self-join in PostGres and hate your life
and, you know.
Couch is cool. I guess. Pretty much that's my
opinion of it. It's really awesome. But, you can't
query it. So cool.
That's it. That's a slight disservice to Couch but,
you know, whatever. MongoDB, as we all know, it
is webscale and that's excellent. If you think of
it as Redis for JSON, that's good. Sixty percent
of the time, it works every time. Everyone's familiar
with that.
So, the thing that's really, I mean, Mongo, it
reminds me of My, MySQL. Like, Mongo is kind
of terrible, but MySQL was kind of terrible, too.
Like, when that came out, it didn't do transactions,
for example, and I, I was working in enterprise-y
land, and transactions are actually a thing. And, you're
like, you script kiddies with your database.
So Mongo feels like that, and not, you know,
what we learned is, if you make something that's
awesome and useful and everywhere and ubiquitous and it
doesn't work, you can make it work. And eventually,
you know, MySQL is a real database. So Mongo
feels a bit like that. It's come a massive
way, right about really early on with very early
versions.
It stores JSON. Well sort of it. It stores
BSON, anyway. That's just binary JSON basically. And it's
a, it's a really beautiful model to work with
in a development cycle, which is why think is
why there's, why there's so much appeal. You've just
got kind of, people treat it like an object
database. You've just got an object that's in there,
and you can pull out objects and manipulate them
and do all of this kind of crazy stuff.
The people who know what they're talking about, though,
with distributed systems, if the reason you're using Mongo
is because you think it's a panacea for all
of this, you know, we need to be webscale
and do all of this kind of stuff, that
is not a good reason to use it. Cause
there, there's still a lot of operational problems and,
and stuff going on.
This, this one is interesting. It's essentially, RethinkDB is
coming from the PostGres world view. Cause PostGres made,
you know, MySQL was like, whatever, we'll fix it.
PostGres was like, we'll do it right and it,
you can't use it cause it's so slow, but
at least it's correct. And they took lots of
iterations to make it usable. So Rethink is kind
of that school of thought. It's like, we're gonna
make it all correct first, and then we'll make
it usable. So it's very similar idea. JSON, you
know, they're trying to make it operationally great with
automatic clustering and all this kind of stuff. You
know. Who knows what it is and how it's
actually gonna behave in the real world. It's still
a very early piece of tech.
And that leads me into, there's a whole world
of databases around what I'm loosely calling the commercial
fringe. So Couchbase is the Couch guys and sort
of some commercial Memcached guys who got together to
make a hybrid something. Aerospike is, their marketing is
great. That's about the best you can say about
it.
So there's a whole bunch of people trying to
solve these problems in interesting ways. But all of
these ones cost money and, you know, they're, the
mileage varies and all of that kind of stuff.
The cool thing about open sources ones is you
get it and you try it and you hate
it and you go back to PostGres so it's
all fine.
So, Hyperdex. This is my favorite. Because they have
HyperSpace Hashing, and it is so cool. These guys
are making some really broad, amazing claims about the,
the kind of things that they can do. Crazy
fast. It's, it's a key-value store but it will
index, you know, it's not just a key but
it will index the properties of a value. So
now you can do que, you know, genuine queries
into the structure of objects that you're storing.
They've got a whole bunch of papers around what
they're doing. So, you can read that as, who
knows what it means. It maps objects to coordinates
in a multi-dimensioned Euclidean space. HyperSpace. And I'm like.
Take my money!
And there's a, there's a picture of HyperSpace. And,
like, I've read that like eight times. I don't
understand what's going on. But if, it does seem
to be true. They're trying to solve some of
these problems and, you know, they call themselves like
a second generation NoSQL thing, in a similar way
to Google, you know, kind of taking all of
this stuff and trying to push the science underneath
it forward.
So you can, you know, it's got a Ruby
client. You can use it now. It's got, just,
normal key-value. It's got atomic stuff. You can do
conditional ports, so this is some code that's basically
is only updating if the, only updating the current
balance if the, updating the balance if the current
balance is what we think it is. Otherwise some
other thread has updated it.
So there's some really interesting stuff they can do.
And they're guaranteeing those operations across the cluster. And
it's also got a transactional engine as well, so
that's really exciting.
Running out of time. HBase and Hadoop. You don't
have any of these problems. Don't worry about it.
You probably don't want to have any of these
problems. Cause this just ends up, you need to
install every fucking thing the Apache foundation has ever
made. And this isn't even the full list. This
is like, you probably need those.
I have a friend, he's a bit of a
dick, and he, he calls it, cause he, he
works in an actual big data organization, and he
just, he goes, oh, you people with your small
to medium data. So, yeah, like, most of us,
we don't have big data in any sense of
the word, really. Like, if, if it's got GB
on the end of it, meh. You're not there
yet.
So, again, this is just you know, Facebook is
using the hell out of this stuff, and they're
just like, this is all out of date. They're
like now just, they can't buy hard disks fast
enough. It's crazy. Yeah. There was a punch line
at the end of all of that.
But my friend, the guy who I said was
a bit of a dick, he, he recommends having
a look at this. And this is his quote,
if you want to appear really cool and underground,
then I reckon the next big thing is the
Berkeley Data Analytics Stack. So, there's a whole bunch
of people who are looking at that, you know,
crazy big data situation and trying to work out
what that means and what the future is.
And so Apache and Berkeley are kind of in
a cold war for that at the moment. And
then there's heaps of people in the enterprise space
because you can sell lots of products and or
services to large companies who think they have a
big data problem. So that's cool.
That's fine. This isn't, this is just a little
thing that's an embeddable document key-value store that you
can, it's just kind of a fun team and
has an API that looks very similar to the
Mongo one. And it just sits in process.
Oh, ElasticSearch. Every time I use it, I think,
why can you not be my database? It's awesome.
But it loses a couple of points there because
of its configurationability. It went, it works when you
know how to make it works, and it's crazy
complicated sometimes.
So anyway. Thirty. Four minutes over technically, I think.
Yeah. So that's good.
That's databases in a nutshell. I'm Toby Hede. I'm
around the conference if you want to talk about
databases. I think of myself as a lapa-, a
lap- a butterfly collector, I guess, is what I'm
looking for, of databases.
Yeah. So come and say hi. Cool.