4 ms·

> The big question is: Do you need that kind of functionality? I agree that very large and complex infrastructures have their place - the problem is just that t

by fipar 4y ago

> The big question is: Do you need that kind of functionality? I agree that very large and complex infrastructures have their place - the problem is just that they import a ton of complexity and usually cost a lot. I think that's the key. Most of us aren't Google/Facebook/whatever. Yet lots of people want to mimic those. A simple stack with a relation database on a single machine still goes a long way. In fact, it goes a lot longer way today than it did 20 years ago. It's ok to scale when you need to, but I think premature scaling is the wrong way to go, especially since most things never get to FB/Google/etc size.

bluepizza 4y ago
I understand trying to keep complexity low. But I don’t understand how a relational database would be less complex than a simple key value store. Every time this argument pops up, I end up wondering if it’s really about architectural complexity, or if it’s about sticking with the old and known.
- _vertigo 4y ago
  A lot of relational databases offer a better (or more useful) consistency model than k-v stores, assuming your data isn’t just a bunch of keys and values. Having to worry about consistency can significantly your worsen complexity of your application code.
  - bluepizza 4y ago
    MongoDB is complex, that’s true. But DynamoDB or GCP Bigtable are pretty simple.
    - pjmlp 4y ago
      Simple indeed, they don't even offer anything that matches SQL flexibility.
      - bluepizza 4y ago
        Exactly my point. If the argument is to avoid unnecessary complexity, then how come a SQL database is the better choice?
        pjmlp 4y ago
        Because not having proper query language turns simple wishes into complex solutions.
        icod1 4y ago
        But it does have way to query, if you of course only know SQL and didn't bother to learn the MongoDB way to query then for you, the uninformed outsider, it might seem complex. But so does ArangoDB or Neo4j or GraphQL. Like, if you were never exposed to rxjs and are now trying to build things with it doing $stream.pipe( switchmap(), filter(), etc(), ) It does seem more complex than stream.map().filter().etc() but it's only so because you haven't put in the effort to learn that way.
        pjmlp 4y ago
        Sure, whatever. Now write DBA scale ISO SQL 2016 / Transact SQL / PL/SQL in that interesting Mongo flavoured language, including database engine debugger integration, and JIT compilation.
    - icod1 4y ago
      1. MongoDB is not complex, the driver structure sucks. Example Go's mgo driver by Gustavo Niemeyer was simple and effective, but abandoned. The official drivers is unnecessarily complicated. And Go's need to have "context" everywhere adds to this, but MongoDB is not complex. Idk I'm not some super genius and picking up MongoDB was really easy. Querying (aka aggregation pipelines), you have to think of that as "pipes in bash". It's in the words aggregation pipelines. find | groupby | sort | filter | select. Something like that. It's not SQL it's different, but not complex, sorry.
    - sausagefeet 4y ago
      In what context? A hosted database might be "simpler" to operatoe, but BigTable is quite complicated and does a lot of complex, low-level, work to be very fast.
- fipar 4y ago
  First, I'd say the key value store is actually older than the relational database, by at least a couple of decades. Of course, not the current ones, but we're also not using the relational database from the 80s so ... Now to try and answer your question, I think a relational database is a lot more complex than a simple key value store, but if it's a good implementation, it will hide this complexity from the user, and using the database will be rather simple. It can be as simple as a key value store since you can just use a relational database like one. Note that this hiding of complexity is by design, it is one of the main goals of the relational model, it's not accidental.
- democracy 4y ago
  Throw ACID requirements on top of a simple kv store and it is not a simple kv store any more
- deleted 4y ago
  [deleted]
democracy 4y ago
you stick with an old and known since its getting the job done, customer is happy and you can get a good night sleep too

by fipar 4y ago

bluepizza 4y ago

I understand trying to keep complexity low. But I don’t understand how a relational database would be less complex than a simple key value store. Every time this argument pops up, I end up wondering if it’s really about architectural complexity, or if it’s about sticking with the old and known.

_vertigo 4y ago
A lot of relational databases offer a better (or more useful) consistency model than k-v stores, assuming your data isn’t just a bunch of keys and values. Having to worry about consistency can significantly your worsen complexity of your application code.
- bluepizza 4y ago
  MongoDB is complex, that’s true. But DynamoDB or GCP Bigtable are pretty simple.
  - pjmlp 4y ago
    Simple indeed, they don't even offer anything that matches SQL flexibility.
    - bluepizza 4y ago
      Exactly my point. If the argument is to avoid unnecessary complexity, then how come a SQL database is the better choice?
      - pjmlp 4y ago
        Because not having proper query language turns simple wishes into complex solutions.
        icod1 4y ago
        But it does have way to query, if you of course only know SQL and didn't bother to learn the MongoDB way to query then for you, the uninformed outsider, it might seem complex. But so does ArangoDB or Neo4j or GraphQL. Like, if you were never exposed to rxjs and are now trying to build things with it doing $stream.pipe( switchmap(), filter(), etc(), ) It does seem more complex than stream.map().filter().etc() but it's only so because you haven't put in the effort to learn that way.
        pjmlp 4y ago
        Sure, whatever. Now write DBA scale ISO SQL 2016 / Transact SQL / PL/SQL in that interesting Mongo flavoured language, including database engine debugger integration, and JIT compilation.
  - icod1 4y ago
    1. MongoDB is not complex, the driver structure sucks. Example Go's mgo driver by Gustavo Niemeyer was simple and effective, but abandoned. The official drivers is unnecessarily complicated. And Go's need to have "context" everywhere adds to this, but MongoDB is not complex. Idk I'm not some super genius and picking up MongoDB was really easy. Querying (aka aggregation pipelines), you have to think of that as "pipes in bash". It's in the words aggregation pipelines. find | groupby | sort | filter | select. Something like that. It's not SQL it's different, but not complex, sorry.
  - sausagefeet 4y ago
    In what context? A hosted database might be "simpler" to operatoe, but BigTable is quite complicated and does a lot of complex, low-level, work to be very fast.
fipar 4y ago
First, I'd say the key value store is actually older than the relational database, by at least a couple of decades. Of course, not the current ones, but we're also not using the relational database from the 80s so ... Now to try and answer your question, I think a relational database is a lot more complex than a simple key value store, but if it's a good implementation, it will hide this complexity from the user, and using the database will be rather simple. It can be as simple as a key value store since you can just use a relational database like one. Note that this hiding of complexity is by design, it is one of the main goals of the relational model, it's not accidental.
democracy 4y ago
Throw ACID requirements on top of a simple kv store and it is not a simple kv store any more
deleted 4y ago
[deleted]

democracy 4y ago

you stick with an old and known since its getting the job done, customer is happy and you can get a good night sleep too