Yeah, yeah. I think the difference of NoSQL versus SQL… I think the NoSQL isn’t necessarily key/value, it’s really more… There’s been a lot of databases that try to optimize for a certain domain, I guess, and that tends to be where they shine. If you have a database around time series data, you could really optimize big things with time series, if you have a database specific for that, or if you have a search database. This certain kind of domains that are more specific than the generic SQL. I think that’s where it tends to shine. As far as the aggregates… Yeah, if you’re trying to get a prototype out, know SQL really well; I would totally go for SQL, without a doubt. It’s probably not worth learning a new language or system to make something quick and simple.
The things that I like specifically about key/value is that there’s a lot of features that you think of that tend to be more around SQL databases, where it’s like, “Oh, you have a schema!” A schema and a key/value store can be just a serialization library. ProtoBufs is actually a good serialization library, and they give you things like versioning, just really quick encoding and decoding, and you layer that on top of a key/value store, and you’re starting to build your own database. It’s simple, but that’s a good thing.
[00:24:10.22] Another thing, when you think about SQL and the SQL language – and I’ve done SQL for years, and I still find it to be really frustrating when you get down to more complex queries. Your query language when you’re actually using a key/value store ends up being Go, which is awesome, because you can do anything you want in Go. So if you need to scan a table, or scan a set of keys and values, you can make an index inside of a key/value store… You can do all those things, and it’s really just Go code underneath that’s processing it. So you can do a lot to optimize. You no longer have these ideas like query planning. Your query planning is done before compile time, and you’re writing the code to actually do the query.