11 ms·

If All You Have Is a Database, Everything Looks Like a Nail

178 points by kiyanwang 6y ago

falcolas 6y ago
Missed the obvious pun: "Everything Looks Like a Null" I do wish practical database development/administration was taught in college. It's such a necessary skill...
- itsmemattchung 6y ago
  I've seen some really great courses offered by MIT and CMU on building database systems (will have to find the exact courses). And a database development course is something I would love to see from OMSCS (from Georgia Tech). Sadly, right now, the only DB course offered is not very rigorous and really targets how to use a database from an application development standpoint (i.e. create DB, tables, SQL queries etc)
  - valzam 6y ago
    I assume you are refering to this course https://www.youtube.com/watch?v=oeYBdghaIjc&list=PLSE8ODhjZXjbohkNBWQs_otTrBTrjyohi https://www.youtube.com/watch?v=oeYBdghaIjc&list=PLSE8ODhjZX... and the follow up advanced course https://www.youtube.com/watch?v=SdW5RKUboKc&list=PLSE8ODhjZXjasmrEd2_Yi1deeE360zv5O https://www.youtube.com/watch?v=SdW5RKUboKc&list=PLSE8ODhjZX...
- fermienrico 6y ago
  "Everything Looks Like a NULL"* No one likes to read sloppily formatted SQL.
  - EGreg 6y ago
    I like it
  - bigiain 6y ago
    "* Looks LIKE NULL" perhaps?
    - koolba 6y ago
      Nothing looks LIKE NULL as that would always evaluate to NULL, which would be filtered out in a WHERE clause.
- geogra4 6y ago
  Regular old sql Databases are not sexy so sadly they dont get the attention they truly deserve
  - edgyquant 6y ago
    I think they are. I learned to code running an old (hand written) forum as a kid (MySQL + PHP) I tend to use postgresql and python now days but my mind is heavily trained to use that relational core and when NoSQL became popular it was so annoying to see the “hackers” in my hometown writing slow systems in mongo and JS because they never were introduced to relational dbs and thought they were becoming deprecated. I’m glad that phase has passed and glad nosql has its place as a key value store (though I’m sure the younger hacker scene likely still relies on nosql as it doesn’t take as much effort to spin up a store and get results; in contrast you need to think ahead about what tables you create and how they relate to each other.)
  - asdfman123 6y ago
    I don't get that. Databases underlie everything. It's foundational.
    - dagw 6y ago
      When you are viewing the world through 19 year old eyes and a mind filled with naiveté and dreams of revolutionizing the world, then studying the technology literally your grandparents where using seems like taking a history class. Why waste your time with SQL when you could be studying CUDA backed, AI driven, graph databases?
      - asdfman123 6y ago
        Thankfully my dreams of a career in science were crushed before I pursued one in programming so I don't relate to that.
- boberoni 6y ago
  For people who are interested, Harvard's CS165[1] is a great course about how to build storage engines for relational databases. Topics include memory vs disk I/O, the memory hierarchy, buffer pools, B-Tree indexes, query optimization, and more. Throughout the course, you have a project to build a columnar relational datastore with C. I don't think the lecture videos are all publicly available, but you can learn a lot from the slides and readings. [1]: http://daslab.seas.harvard.edu/classes/cs165/ http://daslab.seas.harvard.edu/classes/cs165/
  - perfmode 6y ago
    Thanks for this link. Never before had I come across a course with learning objectives as aligned to my learning goals as this. Much appreciated.
  - anonymousDan 6y ago
    Looks great. What level of student would that course be aimed at do you know (e.g. 2nd year CS undergrad, 3rd year)?
    - boberoni 6y ago
      I would say, 3rd year or 4th year CS undergrad. Pre-requisites would include a foundational understanding of C pointers, tree data structures, and algorithmic complexity (i.e. time and space complexity).
- tluyben2 6y ago
  It used to be when I was in uni. Then everyone complained it was not cutting edge enough for the job market.
mikesabbagh 6y ago
Im an SRE, the architect decided some time ago that we needed a mongodb db deployed in our cluster. I fought against it at first, as it is best to get a managed solution instead. The dev's position was, "how hard can it be to operate a database? You can use a kubernetes operator now" lol I just slacked this article :) Thank you!!
- jeffbee 6y ago
  Hosted MongoDB is still hot garbage, it just costs more and you can't fix it yourself when Atlas has dropped the ball.
  - rpedela 6y ago
    Usually managed systems cost less if you factor in salaries. Like everything, it depends on the specifics though.
    - Frost1x 6y ago
      Lambda(TM) your entire infrastructure and save the most ;)
  - Raidion 6y ago
    I have several instances in production now, and it's honestly been pretty good. Not running anything over M30 though.
emodendroket 6y ago
If you're in a position to worry about outgrowing your data storage strategy you either really, really muffed it or you're doing pretty well for yourself.
- mikesabbagh 6y ago
  or u work in an enterprise
  - closeparen 6y ago
    If every one of Walmart’s 2.1 million employees used an enterprise system every day, that system would be less than 1% the scale of Snapchat (250 million DAUs). Internet scale and enterprise scale are completely different animals.
    - funcDropShadow 6y ago
      But Snapchat, as most web-scale companies, doesn't care whether a single operation gets lost and whether a small number of user have data loss. Whereas Walmart, at least, should care whether every single employee got his salary or whether the taxes for him were booked properly. Therefore a lot of "solutions" of so-called web-scale companies are to naive for an enterprise.
      - emodendroket 6y ago
        All the more reason that a traditional SQL database is well suited for many enterprise applications.
  - jeltz 6y ago
    Most of the databases at big enterprises are tiny. Just because the company is big does not mean every department of it handles tons of data.
- arthurcolle 6y ago
  Or your project relies on significant data ingestion and produces artifacts based on that data... There are tons of examples of this.
CreRecombinase 6y ago
I often feel like bioinformatics is like this steampunk alternate reality where, because HPC clusters don't generally do database administration, all the technology and the ecosystem has developed has been built on flat files. Let me tell you, it's not great.
- LifeIsBio 6y ago
  It’s fine, you can just nest stuff by having a tsv in which one of the columns has an arbitrary number of values separated by commas. One of those values might even be some map structure with pairs indicated with equals and pairs separated by pipes. It’ll all be just fine.
  - nickpeterson 6y ago
    We heard you liked delimiters, so we put delimiters in your delimiters, now you can delimit without limit.
    - grenoire 6y ago
      >delimit without the limit Oh man, you just made my day.
    - JackMorgan 6y ago
      Wow, this week at a new job I just found 50 database columns that contain a serialized php array, this makes me laugh. Also does anyone know how to cheaply migrate PHP arrays into actual relational tables, I'm, uh, asking for a friend.
- adev_ 6y ago
  You got half of your answer in your sentence. That's not only bioinformatic but the entire HPC world tends to avoid database. They usually prefer HDF5 or similar, and there is reasons to that. It is much easier to scale one million node accessing a flat file over a DFS than it is over to a database.
  - 6y ago
dmtroyer 6y ago
two years into a job with a dozen applications where sharing databases amongst them is the defacto standard. there aren't even any views. I feel like I'm in a never ending loop of debugging and troubleshooting and never have time to burn it all to the ground. it is time to move on.
jb1991 6y ago
And if all you have is a hammer, everything looks like C++.
Glyptodon 6y ago
I think > "Isolate applications. Keep different applications away from other applications’ tables." is only good advice if the tables are application specific data and you don't do microservices in that stupid braindead way that makes it so that everything from the admin panel to data visualization are their own "applications" with their own databases and doing things that would be even the simplest of queries becomes a project in writing what are effectively bad performance joins via random http APIs. IE have a data model and understand where the most painless boundaries are, don't throw up dozens of DBs for the hell of it.
- harlanji 6y ago
  There’s a model of software based around shipping events around, and subscriptions between systems. The purposes of separation are at least a couple important, perhaps you know. Each has a DB, often embedded, that is suitable and materialized from the subscriptions and its own; mutated predictably.
  - Glyptodon 6y ago
    Transmitting events is fine, I like transmitting and receiving events. But if you end up having a bunch of DBs with a lot of overlap I don't know how much you're gaining as it pretty much turns into another permutation of DB sharding. Of course microservices done wrong doesn't mean event-based systems done right are bad.
    - rualca 6y ago
      > But if you end up having a bunch of DBs with a lot of overlap I don't know how much you're gaining You're gaining component isolation and separation of concerns, and the ability to scale services horizontally without bothering about shared state. Also, you gain the ability to develop each system without having any constraint imposed by third parties. In other words, you're making your service not only simpler but also more robust, easier to operate and maintain.
      - 6y ago
aledalgrande 6y ago
Fascinating. These problems have been around for years and they are not going away.
0xbadcafebee 6y ago
The biggest hindrance to good engineering is everyone not knowing everything. I know that sounds stupid. But I can't explain enough to most developers why they need to understand how to safely deploy database changes before they can even consider writing an application that uses a database. And I can't explain enough to the architects why the developers need to be given agency and options and allowed to make their own decisions and just implement what works. Both seem to be lacking critical insight and so we always end up with slightly-crappy things that work just enough to "ship", and spend the rest of the time trying to shore up why it always breaks.
lmm 6y ago
Relational databases are just "the way we do things around here". They may have been smart at one point, but they haven't made sense since we started putting web frontends on our applications (it's not a coincidence that the most successful "database" for that was MySQL which, at the time, supported approximately none of the alleged virtues of databases), they certainly don't make sense now. There's one thing that SQL databases are good for: semi-ad-hoc reporting queries (and their transactional stuff is grossly overengineered for this use case, so remember to turn it off). Produce a read-only SQL database for your analysts/data scientists to use, either regular dumps or updated in real time. But you absolutely must treat it as write-only from the point of view of your live system; doing programmatic queries of an SQL database is madness on several levels: SQL is not machine-friendly, the performance characteristics of any given query are obscure, and the transaction system means you're virtually guaranteed to deadlock yourself sooner or later.
- rswail 6y ago
  Relational queries and ACID are still absolute requirements for managing your data. Web frontends are just that, frontends. Is there something mathematically changed that means that relational logic is somehow now false? MySQL was a hack that people that didn't understand relational databases used as a glorified K/V store. It was "fast" compared to the alternative of postgres, but of the three qualities of good, cheap, fast, MySQL only won on the last of those and for a definition of "fast" that most of those web frontends didn't need. "SQL is not machine-friendly"? Why not? It's also not that relevant to the performance of a relational query. That's driven by the performance characteristics, which are driven by the query planner using the statistical analysis of that data. "...the transaction system means you're virtually guaranteed to deadlock..." you mean, if you try to break ACID, then the database enforces constraints to stop you and make you reconsider your data access properly? That's like saying Rust's borrow checker doesn't allow you to program race conditions. Storing JSON in a K/V store and doing joins in code is a regression, not an advance. Not expressing your data's constraints as actual constraints means that bugs can happen that shouldn't.
  - lmm 6y ago
    > Relational queries and ACID are still absolute requirements for managing your data. Web frontends are just that, frontends. Is there something mathematically changed that means that relational logic is somehow now false? The web request/response model makes ACID pointless. The whole point of ACID is that if two users try to update something at the same time, you won't lose either of their updates. No web app implements that: if user A loads the edit page and then user B loads the edit page and makes an edit, their update is going to be lost when A saves the page. (Or maybe the webapp implements its own locking, but it won't - and can't - use database transactions for it, because there's no way to know whether the user is still editing or has closed the page). > MySQL was a hack that people that didn't understand relational databases used as a glorified K/V store. It was "fast" compared to the alternative of postgres, but of the three qualities of good, cheap, fast, MySQL only won on the last of those and for a definition of "fast" that most of those web frontends didn't need. Exactly! MySQL did none of the things that "good" databases do, and yet MySQL-based companies were far more successful. Conclusion: the things that "good" databases do aren't actually that valuable. > "SQL is not machine-friendly"? Why not? It's irregular, hard to generate safely, and hard to parse. It makes no sense as a machine-to-machine interfaces (and it was never designed as one). > That's driven by the performance characteristics, which are driven by the query planner using the statistical analysis of that data. Only if the query is complex enough for those to be a dominant factor. For a simple primary-key lookup, today's databases typically spends 3x as long parsing the SQL as actually executing the query. > "...the transaction system means you're virtually guaranteed to deadlock..." you mean, if you try to break ACID, then the database enforces constraints to stop you and make you reconsider your data access properly? That's like saying Rust's borrow checker doesn't allow you to program race conditions. It's just the opposite: SQL databases rely on magically figuring out the locking for you, and don't give you enough visibility or tooling to let you manage it in a safe way. You can't look at a query and know which locks it will take, in which order, unless you're intimately familiar with that particular database's internals. Application programmers know to make sure every thread obtains locks in the same order, or ideally use higher-level abstractions. in SQL queries you don't have that option. > Storing JSON in a K/V store and doing joins in code is a regression, not an advance. Not expressing your data's constraints as actual constraints means that bugs can happen that shouldn't. I'm all for type safe datastores (and RDBMS type systems are pretty limited: no decent collection types, no aggregates unless you count temporary tables which come with a giant set of pitfalls). I can believe that referential integrity could be worthwhile. But SQL is a very poor interface, and datbase-level ACID is worse than useless in today's (web-based) architectures.
throwaway122kk 6y ago
Arghh the biggest issue in current place (I be leaving before year end) is the amount of "engineers" who are pathologically afraid of relational database. You have dozens microservices per teams, split between k8s, meso, aws, azure, physical servers each on using everything under the moon to store data up to storing files in s3 Needless to say the amount of issues due to data inconsistencies is incredible. And of course the amount of actual users of the overall product is tiny being an enterprise products, maybe few thousand concurrent users at peak. They now want regional replication and screwed due to so many sources of data. Where postgres alone would have done
- andy_ppp 6y ago
  This is standard practice in the micro services world, bin ACID compliance and replace it with network partitions because you’re so fashionable you have no users and no data. In the system I’m working on (it’s mongodb tastic) someone had added a try catch around everything (EVERYTHING) that reverts the service manually in the catch block. I don’t need to explain to people here how moronic rolling your own transactions like this is... Everywhere using micro services appears to be the same :-/
- hinkley 6y ago
  I currently have a bunch of clowns who are indistinguishable from most of the clowns in my profession. Application slow? We’ll just add caches instead of trying to create an architecture. “But we have an architecture.” No, you don’t. You have a set of idioms that you arrange like dominoes until an answer you like comes out the other end. That’s only an architecture in the way suffering is a personality. You don’t need more caches. You need an architecture and dynamic programming. Someone save me from promise caches. First couple times they were so cool, now they’re a golden hammer for lack of even the most rudimentary of data flow analysis.
  - wpietri 6y ago
    I've long thought that caching is to software architecture what ketchup is to diner food. Something's not right with your meal? Just apply more ketchup.
deleted 6y ago
[deleted]
jpcooper 6y ago
I like the idea the author mentions of message queues in the database. It also sounds like it would be easier to separate if need be. I also like the idea of keeping everything in a single database as long as possible. Even if it turns out not to scale, it is a lot easier to figure out your business logic in that environment. Anything which avoids microservice madness and Kubernetes keenness as long as possible is very attractive to me. Maybe slightly contrary to the spirit of the article, but a few days ago there was talk about implementing the backend in your database here: https://news.ycombinator.com/item?id=25290339 https://news.ycombinator.com/item?id=25290339. Someone mentioned how Cloudfare was initially implemented on a single Postgres database: https://news.ycombinator.com/item?id=22883548 https://news.ycombinator.com/item?id=22883548
- LoSboccacc 6y ago
  I agree against microservices where they aren't in real need, and that a single database can go along way if well designed, since ram today is abundant everywhere and stuff like moving indexes on dedicated disks with dedicated iops is as easy as ever. but why the hate against kubernetes? even your bog standard java three tier app gets some tangible benefit from being dockerized (repeatability, whole os image versioning) and placed in a node that abstract everything else (load balancing, routing, rolling deployments etc) at the lowest level, it's just a descriptor for infrastructure, it impacts nothing of your app or business logic unless you want it to. even single node testing environments are covered one way or another (my fav now is minikube), the only real limit is one having a requirement for self hosting.
  - valenterry 6y ago
    > but why the hate against kubernetes? You seem to equate kubernetes and containerization. Kubernetes is just too complex for most usecases, that's all. There are simpler solutions (in the sense of less powerful) that still allow using containers and scale-out but are less maintenance.
    - LoSboccacc 6y ago
      you need something to run the containers anyway, and with all the management overhead docker and other systems adds, one can just cut the chase and let an orchestrator do it
qaq 6y ago
One thing that many devs don't pay much attention to is as soon as you go with SOA/microservices and separate DBs you are now in the realm of distributed systems with all the fun that entails.
tannhaeuser 6y ago
Tell WordPress, Drupal (what's left of it anyway) and co who're storing HTML fragments, templates, and other markup as BLOBs "in the database".
jpalomaki 6y ago
One thing to consider is backups. How can I restore my application to a previous known and valid state after hw/sw/human error. If the application state is split for example between database and message queue having consistent backups becomes harder.
heavenlyblue 6y ago
And if you don’t even have a database, nothing is realistically possible.
mark_l_watson 6y ago
I was hoping that the author would talk about RDF data stores. It may take a while, but I expect some combination of RDF and relational databases with virtual RDF and SPARQL support will do a lot to solve data silo problems. That said, good article.
kazinator 6y ago
Why do blobs cause transactional problems? Create the blob. GIve it an ID. Give it a path/URL. Do all that before going anywhere near the database, at which point the blob is all settled an immutable. Then, stick the tiny record into the database which identifies the blob. Done; the blob is now live, from the POV of the database consumers.
einpoklum 6y ago
The article should be named, "If all you have is a transactional database, certain kinds of things look like nails". My interest is analytical, non-document DBMSes, and the text is mostly irrelevant in my world :-(

178 points by kiyanwang 6y ago

Missed the obvious pun: "Everything Looks Like a Null" I do wish practical database development/administration was taught in college. It's such a necessary skill...

itsmemattchung 6y ago
I've seen some really great courses offered by MIT and CMU on building database systems (will have to find the exact courses). And a database development course is something I would love to see from OMSCS (from Georgia Tech). Sadly, right now, the only DB course offered is not very rigorous and really targets how to use a database from an application development standpoint (i.e. create DB, tables, SQL queries etc)
- valzam 6y ago
  I assume you are refering to this course https://www.youtube.com/watch?v=oeYBdghaIjc&list=PLSE8ODhjZXjbohkNBWQs_otTrBTrjyohi https://www.youtube.com/watch?v=oeYBdghaIjc&list=PLSE8ODhjZX... and the follow up advanced course https://www.youtube.com/watch?v=SdW5RKUboKc&list=PLSE8ODhjZXjasmrEd2_Yi1deeE360zv5O https://www.youtube.com/watch?v=SdW5RKUboKc&list=PLSE8ODhjZX...
fermienrico 6y ago
"Everything Looks Like a NULL"* No one likes to read sloppily formatted SQL.
- EGreg 6y ago
  I like it
- bigiain 6y ago
  "* Looks LIKE NULL" perhaps?
  - koolba 6y ago
    Nothing looks LIKE NULL as that would always evaluate to NULL, which would be filtered out in a WHERE clause.
geogra4 6y ago
Regular old sql Databases are not sexy so sadly they dont get the attention they truly deserve
- edgyquant 6y ago
  I think they are. I learned to code running an old (hand written) forum as a kid (MySQL + PHP) I tend to use postgresql and python now days but my mind is heavily trained to use that relational core and when NoSQL became popular it was so annoying to see the “hackers” in my hometown writing slow systems in mongo and JS because they never were introduced to relational dbs and thought they were becoming deprecated. I’m glad that phase has passed and glad nosql has its place as a key value store (though I’m sure the younger hacker scene likely still relies on nosql as it doesn’t take as much effort to spin up a store and get results; in contrast you need to think ahead about what tables you create and how they relate to each other.)
- asdfman123 6y ago
  I don't get that. Databases underlie everything. It's foundational.
  - dagw 6y ago
    When you are viewing the world through 19 year old eyes and a mind filled with naiveté and dreams of revolutionizing the world, then studying the technology literally your grandparents where using seems like taking a history class. Why waste your time with SQL when you could be studying CUDA backed, AI driven, graph databases?
    - asdfman123 6y ago
      Thankfully my dreams of a career in science were crushed before I pursued one in programming so I don't relate to that.
boberoni 6y ago
For people who are interested, Harvard's CS165[1] is a great course about how to build storage engines for relational databases. Topics include memory vs disk I/O, the memory hierarchy, buffer pools, B-Tree indexes, query optimization, and more. Throughout the course, you have a project to build a columnar relational datastore with C. I don't think the lecture videos are all publicly available, but you can learn a lot from the slides and readings. [1]: http://daslab.seas.harvard.edu/classes/cs165/ http://daslab.seas.harvard.edu/classes/cs165/
- perfmode 6y ago
  Thanks for this link. Never before had I come across a course with learning objectives as aligned to my learning goals as this. Much appreciated.
- anonymousDan 6y ago
  Looks great. What level of student would that course be aimed at do you know (e.g. 2nd year CS undergrad, 3rd year)?
  - boberoni 6y ago
    I would say, 3rd year or 4th year CS undergrad. Pre-requisites would include a foundational understanding of C pointers, tree data structures, and algorithmic complexity (i.e. time and space complexity).
tluyben2 6y ago
It used to be when I was in uni. Then everyone complained it was not cutting edge enough for the job market.

mikesabbagh 6y ago

Im an SRE, the architect decided some time ago that we needed a mongodb db deployed in our cluster. I fought against it at first, as it is best to get a managed solution instead. The dev's position was, "how hard can it be to operate a database? You can use a kubernetes operator now" lol I just slacked this article :) Thank you!!

jeffbee 6y ago
Hosted MongoDB is still hot garbage, it just costs more and you can't fix it yourself when Atlas has dropped the ball.
- rpedela 6y ago
  Usually managed systems cost less if you factor in salaries. Like everything, it depends on the specifics though.
  - Frost1x 6y ago
    Lambda(TM) your entire infrastructure and save the most ;)
- Raidion 6y ago
  I have several instances in production now, and it's honestly been pretty good. Not running anything over M30 though.

emodendroket 6y ago

If you're in a position to worry about outgrowing your data storage strategy you either really, really muffed it or you're doing pretty well for yourself.

mikesabbagh 6y ago
or u work in an enterprise
- closeparen 6y ago
  If every one of Walmart’s 2.1 million employees used an enterprise system every day, that system would be less than 1% the scale of Snapchat (250 million DAUs). Internet scale and enterprise scale are completely different animals.
  - funcDropShadow 6y ago
    But Snapchat, as most web-scale companies, doesn't care whether a single operation gets lost and whether a small number of user have data loss. Whereas Walmart, at least, should care whether every single employee got his salary or whether the taxes for him were booked properly. Therefore a lot of "solutions" of so-called web-scale companies are to naive for an enterprise.
    - emodendroket 6y ago
      All the more reason that a traditional SQL database is well suited for many enterprise applications.
- jeltz 6y ago
  Most of the databases at big enterprises are tiny. Just because the company is big does not mean every department of it handles tons of data.
arthurcolle 6y ago
Or your project relies on significant data ingestion and produces artifacts based on that data... There are tons of examples of this.

CreRecombinase 6y ago

I often feel like bioinformatics is like this steampunk alternate reality where, because HPC clusters don't generally do database administration, all the technology and the ecosystem has developed has been built on flat files. Let me tell you, it's not great.

LifeIsBio 6y ago
It’s fine, you can just nest stuff by having a tsv in which one of the columns has an arbitrary number of values separated by commas. One of those values might even be some map structure with pairs indicated with equals and pairs separated by pipes. It’ll all be just fine.
- nickpeterson 6y ago
  We heard you liked delimiters, so we put delimiters in your delimiters, now you can delimit without limit.
  - grenoire 6y ago
    >delimit without the limit Oh man, you just made my day.
  - JackMorgan 6y ago
    Wow, this week at a new job I just found 50 database columns that contain a serialized php array, this makes me laugh. Also does anyone know how to cheaply migrate PHP arrays into actual relational tables, I'm, uh, asking for a friend.
adev_ 6y ago
You got half of your answer in your sentence. That's not only bioinformatic but the entire HPC world tends to avoid database. They usually prefer HDF5 or similar, and there is reasons to that. It is much easier to scale one million node accessing a flat file over a DFS than it is over to a database.
- 6y ago

dmtroyer 6y ago

two years into a job with a dozen applications where sharing databases amongst them is the defacto standard. there aren't even any views. I feel like I'm in a never ending loop of debugging and troubleshooting and never have time to burn it all to the ground. it is time to move on.

jb1991 6y ago

And if all you have is a hammer, everything looks like C++.

Glyptodon 6y ago

I think > "Isolate applications. Keep different applications away from other applications’ tables." is only good advice if the tables are application specific data and you don't do microservices in that stupid braindead way that makes it so that everything from the admin panel to data visualization are their own "applications" with their own databases and doing things that would be even the simplest of queries becomes a project in writing what are effectively bad performance joins via random http APIs. IE have a data model and understand where the most painless boundaries are, don't throw up dozens of DBs for the hell of it.

harlanji 6y ago
There’s a model of software based around shipping events around, and subscriptions between systems. The purposes of separation are at least a couple important, perhaps you know. Each has a DB, often embedded, that is suitable and materialized from the subscriptions and its own; mutated predictably.
- Glyptodon 6y ago
  Transmitting events is fine, I like transmitting and receiving events. But if you end up having a bunch of DBs with a lot of overlap I don't know how much you're gaining as it pretty much turns into another permutation of DB sharding. Of course microservices done wrong doesn't mean event-based systems done right are bad.
  - rualca 6y ago
    > But if you end up having a bunch of DBs with a lot of overlap I don't know how much you're gaining You're gaining component isolation and separation of concerns, and the ability to scale services horizontally without bothering about shared state. Also, you gain the ability to develop each system without having any constraint imposed by third parties. In other words, you're making your service not only simpler but also more robust, easier to operate and maintain.
    - 6y ago

aledalgrande 6y ago

Fascinating. These problems have been around for years and they are not going away.

0xbadcafebee 6y ago

The biggest hindrance to good engineering is everyone not knowing everything. I know that sounds stupid. But I can't explain enough to most developers why they need to understand how to safely deploy database changes before they can even consider writing an application that uses a database. And I can't explain enough to the architects why the developers need to be given agency and options and allowed to make their own decisions and just implement what works. Both seem to be lacking critical insight and so we always end up with slightly-crappy things that work just enough to "ship", and spend the rest of the time trying to shore up why it always breaks.

lmm 6y ago

Relational databases are just "the way we do things around here". They may have been smart at one point, but they haven't made sense since we started putting web frontends on our applications (it's not a coincidence that the most successful "database" for that was MySQL which, at the time, supported approximately none of the alleged virtues of databases), they certainly don't make sense now. There's one thing that SQL databases are good for: semi-ad-hoc reporting queries (and their transactional stuff is grossly overengineered for this use case, so remember to turn it off). Produce a read-only SQL database for your analysts/data scientists to use, either regular dumps or updated in real time. But you absolutely must treat it as write-only from the point of view of your live system; doing programmatic queries of an SQL database is madness on several levels: SQL is not machine-friendly, the performance characteristics of any given query are obscure, and the transaction system means you're virtually guaranteed to deadlock yourself sooner or later.

rswail 6y ago
Relational queries and ACID are still absolute requirements for managing your data. Web frontends are just that, frontends. Is there something mathematically changed that means that relational logic is somehow now false? MySQL was a hack that people that didn't understand relational databases used as a glorified K/V store. It was "fast" compared to the alternative of postgres, but of the three qualities of good, cheap, fast, MySQL only won on the last of those and for a definition of "fast" that most of those web frontends didn't need. "SQL is not machine-friendly"? Why not? It's also not that relevant to the performance of a relational query. That's driven by the performance characteristics, which are driven by the query planner using the statistical analysis of that data. "...the transaction system means you're virtually guaranteed to deadlock..." you mean, if you try to break ACID, then the database enforces constraints to stop you and make you reconsider your data access properly? That's like saying Rust's borrow checker doesn't allow you to program race conditions. Storing JSON in a K/V store and doing joins in code is a regression, not an advance. Not expressing your data's constraints as actual constraints means that bugs can happen that shouldn't.
- lmm 6y ago
  > Relational queries and ACID are still absolute requirements for managing your data. Web frontends are just that, frontends. Is there something mathematically changed that means that relational logic is somehow now false? The web request/response model makes ACID pointless. The whole point of ACID is that if two users try to update something at the same time, you won't lose either of their updates. No web app implements that: if user A loads the edit page and then user B loads the edit page and makes an edit, their update is going to be lost when A saves the page. (Or maybe the webapp implements its own locking, but it won't - and can't - use database transactions for it, because there's no way to know whether the user is still editing or has closed the page). > MySQL was a hack that people that didn't understand relational databases used as a glorified K/V store. It was "fast" compared to the alternative of postgres, but of the three qualities of good, cheap, fast, MySQL only won on the last of those and for a definition of "fast" that most of those web frontends didn't need. Exactly! MySQL did none of the things that "good" databases do, and yet MySQL-based companies were far more successful. Conclusion: the things that "good" databases do aren't actually that valuable. > "SQL is not machine-friendly"? Why not? It's irregular, hard to generate safely, and hard to parse. It makes no sense as a machine-to-machine interfaces (and it was never designed as one). > That's driven by the performance characteristics, which are driven by the query planner using the statistical analysis of that data. Only if the query is complex enough for those to be a dominant factor. For a simple primary-key lookup, today's databases typically spends 3x as long parsing the SQL as actually executing the query. > "...the transaction system means you're virtually guaranteed to deadlock..." you mean, if you try to break ACID, then the database enforces constraints to stop you and make you reconsider your data access properly? That's like saying Rust's borrow checker doesn't allow you to program race conditions. It's just the opposite: SQL databases rely on magically figuring out the locking for you, and don't give you enough visibility or tooling to let you manage it in a safe way. You can't look at a query and know which locks it will take, in which order, unless you're intimately familiar with that particular database's internals. Application programmers know to make sure every thread obtains locks in the same order, or ideally use higher-level abstractions. in SQL queries you don't have that option. > Storing JSON in a K/V store and doing joins in code is a regression, not an advance. Not expressing your data's constraints as actual constraints means that bugs can happen that shouldn't. I'm all for type safe datastores (and RDBMS type systems are pretty limited: no decent collection types, no aggregates unless you count temporary tables which come with a giant set of pitfalls). I can believe that referential integrity could be worthwhile. But SQL is a very poor interface, and datbase-level ACID is worse than useless in today's (web-based) architectures.

throwaway122kk 6y ago

Arghh the biggest issue in current place (I be leaving before year end) is the amount of "engineers" who are pathologically afraid of relational database. You have dozens microservices per teams, split between k8s, meso, aws, azure, physical servers each on using everything under the moon to store data up to storing files in s3 Needless to say the amount of issues due to data inconsistencies is incredible. And of course the amount of actual users of the overall product is tiny being an enterprise products, maybe few thousand concurrent users at peak. They now want regional replication and screwed due to so many sources of data. Where postgres alone would have done

andy_ppp 6y ago
This is standard practice in the micro services world, bin ACID compliance and replace it with network partitions because you’re so fashionable you have no users and no data. In the system I’m working on (it’s mongodb tastic) someone had added a try catch around everything (EVERYTHING) that reverts the service manually in the catch block. I don’t need to explain to people here how moronic rolling your own transactions like this is... Everywhere using micro services appears to be the same :-/
hinkley 6y ago
I currently have a bunch of clowns who are indistinguishable from most of the clowns in my profession. Application slow? We’ll just add caches instead of trying to create an architecture. “But we have an architecture.” No, you don’t. You have a set of idioms that you arrange like dominoes until an answer you like comes out the other end. That’s only an architecture in the way suffering is a personality. You don’t need more caches. You need an architecture and dynamic programming. Someone save me from promise caches. First couple times they were so cool, now they’re a golden hammer for lack of even the most rudimentary of data flow analysis.
- wpietri 6y ago
  I've long thought that caching is to software architecture what ketchup is to diner food. Something's not right with your meal? Just apply more ketchup.

deleted 6y ago

[deleted]

jpcooper 6y ago

I like the idea the author mentions of message queues in the database. It also sounds like it would be easier to separate if need be. I also like the idea of keeping everything in a single database as long as possible. Even if it turns out not to scale, it is a lot easier to figure out your business logic in that environment. Anything which avoids microservice madness and Kubernetes keenness as long as possible is very attractive to me. Maybe slightly contrary to the spirit of the article, but a few days ago there was talk about implementing the backend in your database here: https://news.ycombinator.com/item?id=25290339 https://news.ycombinator.com/item?id=25290339. Someone mentioned how Cloudfare was initially implemented on a single Postgres database: https://news.ycombinator.com/item?id=22883548 https://news.ycombinator.com/item?id=22883548

LoSboccacc 6y ago
I agree against microservices where they aren't in real need, and that a single database can go along way if well designed, since ram today is abundant everywhere and stuff like moving indexes on dedicated disks with dedicated iops is as easy as ever. but why the hate against kubernetes? even your bog standard java three tier app gets some tangible benefit from being dockerized (repeatability, whole os image versioning) and placed in a node that abstract everything else (load balancing, routing, rolling deployments etc) at the lowest level, it's just a descriptor for infrastructure, it impacts nothing of your app or business logic unless you want it to. even single node testing environments are covered one way or another (my fav now is minikube), the only real limit is one having a requirement for self hosting.
- valenterry 6y ago
  > but why the hate against kubernetes? You seem to equate kubernetes and containerization. Kubernetes is just too complex for most usecases, that's all. There are simpler solutions (in the sense of less powerful) that still allow using containers and scale-out but are less maintenance.
  - LoSboccacc 6y ago
    you need something to run the containers anyway, and with all the management overhead docker and other systems adds, one can just cut the chase and let an orchestrator do it

qaq 6y ago

One thing that many devs don't pay much attention to is as soon as you go with SOA/microservices and separate DBs you are now in the realm of distributed systems with all the fun that entails.

tannhaeuser 6y ago

Tell WordPress, Drupal (what's left of it anyway) and co who're storing HTML fragments, templates, and other markup as BLOBs "in the database".

jpalomaki 6y ago

One thing to consider is backups. How can I restore my application to a previous known and valid state after hw/sw/human error. If the application state is split for example between database and message queue having consistent backups becomes harder.

heavenlyblue 6y ago

And if you don’t even have a database, nothing is realistically possible.

mark_l_watson 6y ago

I was hoping that the author would talk about RDF data stores. It may take a while, but I expect some combination of RDF and relational databases with virtual RDF and SPARQL support will do a lot to solve data silo problems. That said, good article.

kazinator 6y ago

Why do blobs cause transactional problems? Create the blob. GIve it an ID. Give it a path/URL. Do all that before going anywhere near the database, at which point the blob is all settled an immutable. Then, stick the tiny record into the database which identifies the blob. Done; the blob is now live, from the POV of the database consumers.

einpoklum 6y ago

The article should be named, "If all you have is a transactional database, certain kinds of things look like nails". My interest is analytical, non-document DBMSes, and the text is mostly irrelevant in my world :-(