5 ms·
Connection pooling is one area where NoSQL databases shine. Classic SQL is extremely stateful. It was designed was designed in a very different age when it was
by unscaled 3y ago
Connection pooling is one area where NoSQL databases shine. Classic SQL is extremely stateful. It was designed was designed in a very different age when it was expected to mostly be used directly by programmers and non-technical users and be as friendly as possible. The SQL standard defines some state that must be stored along with each session, such as temporary tables, current schema, current timezone etc. This means that sessions have a pretty significant memory overhead and generally require a thread on the server side (and probably the client-side too).
NoSQL databases got rid of many useful things when they replaced SQL with JSON query languages and simplified SQL dialect, but I think they got a net positive when they did away with statefulness and replaced that with a simple request/response APIs. With this small you can easily multiplex many in-flight requests on a TCP single connection, and let both the server and the client handle requests on-demand, without having to allocate any memory and threads that serve most of their time idling away. The client (and supposedly the server, if it's using io_uring) can run all I/O asynchronously and increase available concurrency even more.
In short, you can get more concurrency and better scaling predictability for the same hardware since you don't have to optimize the way your connection pools are balanced across different clients. It's really one of these few things which is pure fun and joy and unicorns and rainbows when I'm designing a service with a NoSQL DB.
- winrid 3y agoMongo, one of the largest NoSQL databases, uses a thread on the server per connection, and is known for using around 1mb per one of those connections.
- unscaled 3y agoFrankly speaking, Mongo is probably the worst NoSQL database out there, and it has given bad rep for other NoSQL database which do have their use cases, such Cassandra, DynamoDB, Couchbase and Redis (yes, let's not forget that Redis is also a NoSQL database, without the hype). Redis is well-known (and sometimes criticized) for being single-threaded, but managing a connection pool on the client side is still necessary, so my statement is obviously not true for ALL NoSQL databases. But it is at least true for Cassandra and as far as I understand for DynamoDB and Couchbase to some degree.
- winrid 3y agoNo statements will apply to all of anything, just thought I'd clarify since in ten years of working with nosql by large the largest deployments were with Mongo. Bad luck maybe :) There are reactive and non-reactive based SQL dbs too. I know someone at Amazon working on one. You can have state per connection and still use epoll or whatever. Even with NodeJS or Vertx you can open a connection against a worker pool, maintain state for that connection, and it doesn't require thread/process per connection. That's merely an implementation detail (and nice isolation for extensions etc).
- posnet 3y agoEverybody knows relational databases don't scale because they use joins and write to disk. Relational databases weren't built for Web Scale. MongoDB is Web Scale. You turn it on, and it scales right up. Shards are the secret ingredient in the Web Scale sauce.
- unscaled 3y agoDid I ever say that? I said "one area where NoSQL databases shine", "NoSQL databases got rid of many useful things", and "one of these few things which is pure fun [... with] NoSQL databases". Not sure how can you interpret this as me saying that Relational DBs are bad or that MongoDB is great.