14 ms·
Relational databases aren’t dinosaurs, they’re sharks
- arielweisberg 5y agoSQL is just a label for a whole bunch of query language dialects. Schema, stability, performance, fault tolerance, and the full laundry list of things is available in either form.
- pier25 5y agoThe term NoSQL is meaningless. It only means that a database is not SQL (d'oh) but people (such as the author of the article) use it as if it meant anything beyond that. Talking about "NoSQL tradeoffs" implies all non SQL databases share similar features, operational models, use cases, etc, which is simply not true. For example, DynamoDB, Mongo, and Fauna have absolutely nothing in common.
- codefreakxff 5y agoYour comment made me read the article and I find the article’s language sufficiently abstract by say things like “many NoSQL databases”, etc Perhaps your comment was meant to say that in general talking about tradeoffs can fall into that trap, but the article here looks like a good discussion
- pier25 5y ago> I find the article’s language sufficiently abstract by say things like “many NoSQL databases”, etc I'd say it's more vague than abstract. For example, what dbs is the author referring to when saying things like "NoSQL databases generally make tradeoffs around these guarantees." when referring to ACID? This seems to be an outdated view. These days, all major NoSQL databases offer transactions with ACID guarantees.
- pbourke 5y agoAt this point we all generally understand that NoSQL means a system that lacks one or more of: the SQL language, a relational model or ACID guarantees. It’s a useful shorthand for all of that.
- pier25 5y agoIf that's the case, it wouldn't make sense to talk about NoSQL tradeoffs as if all NoSQL dbs were actually similar in any way. Eg: Fauna is considered a NoSQL database and doesn't have any of the drawbacks the article mentions. It has ACID guarantees, a relational model, and strong consistency. Mongo and Dynamo also offer transactions with ACID guarantees these days. Etc.
- jbverschoor 5y agoWhat's the benefit then? Just use a CSV file. It's usually faster than any of the "NoSQL" systems out there, and used to be on par in terms of consistency and data-safety with mongodb. Actually better if you only append data.
- chrisandchris 5y ago> The term NoSQL is meaningless. It only means that a database is not SQL (d'oh) but people (such as the author of the article) use it as if it meant anything beyond that. […] Except that it does not. It does mean „Not Only SQL“, and not „no SQL“.
- erk__ 5y agoI think that is a more recent backronym and was not the original, so it is wrong to say that what the above post said is incorrect.
- glimmung 5y ago'backronym' - like it, thank you.
- sigg3 5y agoI think you're wrong. I distinctly recall NoSQL being hailed as a move away from SQL, as in you'd never need SQL again. This turned out to be misleading, so the Not Only SQL was suggested as an alternative name. See e.g. https://hostingdata.co.uk/nosql-database/ https://hostingdata.co.uk/nosql-database/
- jhgb 5y agoThat might depend on who you're asking: http://www.strozzi.it/cgi-bin/CSA/tw7/I/en_US/nosql/Home%20Page http://www.strozzi.it/cgi-bin/CSA/tw7/I/en_US/nosql/Home%20P...
- rendall 5y ago@chrisandchris is correct. NoSQL means "Not Only SQL" Furthermore, the article is uninformed and writes as if "NoSQL" is an alternative paradigm to SQL. In fact, NoSQL covers a whole range of paradigms and approaches, from key-value, to document, to graph, to more exotic flavors. Some of which can even be queried with SQL ACID can be a feature of other database paradigms as well, if necessary. With MongoDB Atlas, for instance, an engineer can ensure that data consistency is high priority across clusters. Or not, if that's not important. On top of all that, table-based database management systems are designed to prioritize saving hard drive space over cpu cycles. As cpu cycles have become more expensive relative to "hard drive space", the need for this kind of database has declined.
- jbverschoor 5y agoNaming in tech is shit anyway. It's loaded with marketing mumbo jumbo. NoSQL should mean: No-SQL, No SQL query language, and therefore no required implementations of the SQL standard (tables, relations, transactions etc). A lot of "NoSQL" databases actually include an SQL layer. Heck. CSV is NoSQL too. The transaction model is one of the things which would be nice to be able to select (eventual-consistent, non-consistent, consistent). In case you have different performance requirements. Similar to UDP vs TCP. But again, it has nothing to do with no-sql. There was a term - object database. But it was old, so it couldn't be used. Then it was document store / database. Caching and naming things are the most difficult parts. But instead of selecting a name that makes sense and reflects a system/architecture/we, we let some marketing people (read - advocates) promote a new, seo-clean, name.
- tibyat 5y agotitle of the year
- roenxi 5y agoTradeoffs, and also circumstances where the trade off is made. It is all very well to say "X is better than Y" but in practice there needs to be an "at task Z" qualifier. The relational data model is the best model for arbitrary data - by definition we know nearly nothing about the data and that gets us schema control, guidelines for how to normalise data and joins mostly for free. In practice unless there is a complete understand your data before starting work (ie, nearly never) the first attempt should be to model it relationally. Then if that proves unsuitable - or the scale is so large that even the relational model is too demanding - only then response is to fall back to something else.
- laurent92 5y agoFor some reason, Java developers didn’t like writing SQL, so we introduced Hibernate which “does SQL for you”. Hibernate creates appallingly bad SQL, so “databases are slow”. Particularly when using a getter on a lazy-loaded relationship. A query might end up taking 1ms per record instead of 10ms for 10k records. You can rewrite all you want in Hibernate and greatly improve performance, but you often need to introduce Projections, lazy/nonlazy flags, in the end you program Hibernate more than you would have written basic SQL. Ah, also you’re writing JQL not SQL, so you need to learn “how it’s written in JQL”. But every Java developer is happy, because it’s Java. Phew, at least you didn’t write SQL! - Any storage, even file or memory storage, can perform better on production than Hibernate. - Devspeed is much faster without Hibernate. Source: I’m a founder, initiated a few apps, one is on prod making money after 2 weeks, the other one is still losing money after 18 months, guess which one uses React-Spring-Hibernate and which one used jQuery-Freemarker-Dropwizard. - But if you want competent developers, React-Spring-Hibernate makes you look young and cool. It’s sad, because frameworks are as difficult as the maximum difficulty our developers can handle, and if they’re not, they will add a layer. Conclusion: People have no love for databases because they’ve put too many layers before them. But they are not the problem.
- tuatoru 5y agoWhat ORMs have taught me: Just Learn SQL https://wozniak.ca/blog/2014/08/03/1/index.html https://wozniak.ca/blog/2014/08/03/1/index.html
- Rapzid 5y agoI like how the very first paragraph walks back the title.
- gunnarmorling 5y agoHibernate isn't at all meant to avoid understanding or writing SQL; rather, it is meant to map result sets of queries to managed object graphs, track mutations to the loaded graphs, and synchronize those changes efficiently back to the database. The SQL generated by Hibernate is as good or bad as you tell it to; something like inappropriate config causing the n+1 SELECT you describe will instantly show up in any decent dev workflow. You're not bound to JPQL, you can very well use SQL directly too if that benefits your situation. As any powerful tool, Hibernate ORM requires good knowledge of it in order to use it efficiently and effectively. Use it if you have the problems which it solves; don't use it, if you don't have those problems. Disclaimer: former Hibernate core team member
- thatwasunusual 5y agoGreat article, and I this particularly brought back memories for me: > [...] in some instances you might work with vast quantities of data, or deal with transactional systems that just don’t easily fit the operational limitations of relational databases. And in those cases, you should consider moving some, or all, of your data into a non-relational database. I've worked with a big application that utilised this approach with good results. The overall problem was that we had an application tailored for a specific country, but needed to expand to other countries. One of the specific problems was that we needed to store addresses and related data differently for each of the countries' users, and this didn't fit well with the current database schema. Our solution was to move the typing of this information to the application layer, and just store the arbitrary data in a NoSQL solution. This worked perfectly, and to my knowledge it's still working without a glitch. This was before RDBMS solutions supported JSON, and if I were to do this again, I'd probably just continue to use MySQL, PostgreSQL or whatever, and store it as JSON in the database. So, yes, you can get the best of both worlds, but I would _never_ use a NoSQL solution to store all the application's data, independent of the type of application.
- jseban 5y agoI think your solution here was to move the typing to the application layer, which kind of makes sense because that's where you know the locale. But why also move the data to NoSQL, I don't see what that would add. If you had already removed the typing from the relation DB I think that would have worked as well, or am I missing something?
- thatwasunusual 5y agoThe main problem was that we were unable to store the different types of addresses because of their different "layouts" in a "relational way."
- hnfong 5y agoI don't quite understand "was before RDBMS solutions supported JSON "... did (for example) MySQL not support storing JSONs as binary blobs or text before?
- po1nt 5y agoI feel like relational databases improved much since MongoDB came around. Since then there were tons of small projects but none handled the atomicity and solidness as good as SQL databases.
- d4tocchini 5y agoRelational databases may be ACID, but no, they do not "give us" ACID. Take LMDB as an example. LMDB is a fast low-level KV storage engine. NoSQL here, but with full ACID semantics & usable as a backend for whichever DB flavor you so wish to implement. LumoSQL and the older sqlightning are sqlite implementations backed by LMDB.
- mastrsushi 5y ago> Relational DBs are Sharks > OOP is the Roman numerals of paradigms > C is a PDP assembler that thinks it’s a compiler Yup, everything popular is evil and bad. Run away to your ivory towers.
- jeremyjh 5y agoYou might have missed the fact that sharks are awesome.
- mastrsushi 5y agoOh My God
- dang 5y agoWe've banned this account for repeatedly posting unsubstantive comments and ignoring our request to stop. If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html.
- mastrsushi 5y agoIt doesn’t seem like I’m banned
- dang 5y agoComments by banned users still go through, but they're only visible to you and any other users who have "showdead" turned on in their profile. If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html.
- Rapzid 5y ago
- tomcam 5y agoA far more nuanced article than the clickbait (not a problem to me) title implies. Also the clearest definition of ACID I can recall.
- aenis 5y agoAnother consideration is that, at scale, no sql is way cheaper. I run a service with approx. 900k daily users, each generating about 210 object writes and reads that need to execute within 50ms, and I am running this on firestore for about $350 a month, incl. Elb, waf, regionally replicated compute, managed NLP and translate. I sync the no sql stuff to bigquery for analytical usage. Cheap, and scales without any problems as long as one observes the recommended patterns. And all of that scaled from a 5 user POC without a single adjustment in the infra setup or architecture. Not doing relational again.
- HWR_14 5y agoAnd what do you think that would cost with an RDBMS? I see approx. 2000 writes and reads (presumably combined) a second. Depending on how big those objects were, it seems doable in a single computer running SQL. Also, and this is neither here nor there, I thought Firebase hit a hard user limit of 1,000,000 daily users.
- zepolen 5y agoThat's more the benefits of cloud rather than nosql though. 200 writes/second is not even scale, a single instance would handle that fine, with beefy hardware you could do 100x that. You could even run it in cloud, for about $50/month, and as a bonus use the same instance to perform the analytics which will be real time. Not to mention enjoying much better data integrity.
- HWR_14 5y agoWhich cloud lets you rent a beefy SQL server for $50/mo? This is actually really useful info to me, as we're looking at needing to migrate to a new provider soon.
- zepolen 5y agoI mean you're going to have to be more specific than that, some clouds have high cpu but expensive disk, others the reverse. $50/mo will not get you both, but it will easily get you 200tx/s.
- lmilcin 5y agoThe choice of technology by developers and their managers is guided in large part by trends rather than by wholly rational decision process. The type of database should be dictated by the application requirements. Relational databases provide some exceptional guarantees while also being able to run quite large systems. This means, when you have: 1. Relational data, 2. Queries that are not known beforehand, 3. Data that can fit one server or can be sharded to fit, that RDBMS is probably the best choice for you. You may not like SQL as a language but at least there is large body of knowledge on how to use SQL effectively for your problem, how different choices affect performance, etc. And a lot of very good tools to help you with that. I have seen time and time again small teams to "revolt" against SQL databases choosing something like Cassandra or MongoDB. The effect that the team spends now years learning the new database, complicates their application to provide same functionality they got from SQL for free, contorts the data to the new paradigm. My team chose, years ago, before I came, to use MongoDB for what is very relational problem. This resulted in huge duplication, performance issues and complexity on the application side. No, the team does no longer have SQL problems. Instead we have other problems that consume large part of our focus, rather than use it to make the product better.
- MikeDelta 5y agoTrue, I've also seen enterprises where central architects decide for what framework/solution the whole company should go. The answer to questions like 'what is the best DB' is online always 'depends on your use case', but in enterprises is usually 'what upstairs decided'.
- lmilcin 5y agoAnd the reason for this is there is usually "a guy" that mistakes his current love for X with X being better than every other competing product. Sometimes what happens is that somebody buys X, X is expensive, and so now everybody must use X for everything (even if it is not strictly needed). Usually because it looks silly when X is being paid for on an ongoing basis but not being used for anything important.
- chousuke 5y ago
- j16sdiz 5y agoI don’t understand why we still need these kind of article.. After all these years, I thought the advantage and trade-off of different database should be well-understood. But the fact is, there are still lots of mis-infomation floating around. It looks like the lesson we have learnt are not communicated to border groups of engineers.
- int0x2e 5y agoI'll provide my own anecdote - I was a part of a team that ended up choosing a document-store for a small service that services ~500 users (total, concurrent figure is far lower), where writes are uncommon, and where we ended up building ourselves all the tooling that common SQL tools offer for free. Why? Because people think RDBMS are dead. No matter how much I tried explaining it was the wrong choice - we still went for it.
- tharkun__ 5y agoI've made this comment a few times on HN, one very recently - so apologies if someone reads it twice now - but your comment really wants to make me do it again. When I talked to my dad about RDBMS he was like "weeeelll, sure, there's things like DB2 UDB that do relational but performance wise, nothing beats reading the data straight by key in exactly the format you need.". DB2 UDB: "Initial release: 1987; 34 years ago". I.e. what he would rather use and is sort of the NoSQL equivalent is _even older than that_. DBM (Ken Thompson - released by AT&T in 1979) comes to mind, tho I don't remember exactly what it was he was using/referring to, which would have been something that would rather run on S/360 and S/370 systems. It's been a while. Background: he started off with 360 assembler and worked all his working life on IBM Mainframes and the various technologies in and around it. They had it all and they had it before it came to "us". We're just re-inventing most of these things on much cheaper and more open hardware and software. All that to say: We still need these kinds of articles, because people "tend to forget". Or not even check "prior art". There was a recent article and comments around even research papers essentially being re-done and presented as novel research. And on some level that is even correct, because the authors genuinely came up with the same ideas and research as the original authors did. But 20+ years after the fact.
- martincmartin 5y agoBut MongoDB is web scale.
- adolph 5y agoThat would make MUMPS implementations Coelacanths? Or maybe cephalopods? https://en.wikipedia.org/wiki/MUMPS https://en.wikipedia.org/wiki/MUMPS
- snicker7 5y agoA database being relational is (mostly) orthogonal to it being ACID. ACID is generally a property of the underlying storage engine (a key-value store, generally).