35 ms·
MongoDB gets support for multi-document ACID transactions
- overcast 9y agoNext up will be SQL compliance, and we'll be back to a relational database. I'm curious as to what the impact to speed will be, and what the use cases for these types of databases is now that the major SQL players support JSON.
- Waterluvian 9y agoThat's what I was wondering too. It feels like SQL and NoSQL will meet in the middle: JSON with SQL support, SQL with JSON support.
- overcast 9y agoWhich is why I'm depressed RethinkDB failed to take off :(
- mcintyre1994 9y agoThis is basically what Microsoft's Cosmos DB is, you store JSON documents, don't have to define a schema and you can query them with SQL.
- malloryerik 9y agoAnd you can also bake in graph relations, right? How has your experience been with CosmosDB?
- mcintyre1994 9y agoTo be honest I've only used it for pretty trivial things, I didn't do any joins. From the docs [0] it looks like they only have self joins, so joining on children or something like that but not across documents/collections. Depending how much graph relation stuff you need you might be better off just using the graph API. I have no experience with that though. Or they support a MongoDB API if that covers your needs too. Like I said I've only done basic stuff, but I really liked it - it's performant and really easy to set up and use. I used the Python API and it was really easy, then I switched to the Node one to try using it in Azure functions (Python library imports aren't really supported there) and that's nice too - it uses promises and works great. It also doesn't feel like a giant lockin (IMO) - their APIs work anywhere and there's no magic in Azure AFAIK to make you put your compute there if you're using the Database. [0] https://docs.microsoft.com/en-us/azure/cosmos-db/sql-api-sql-query https://docs.microsoft.com/en-us/azure/cosmos-db/sql-api-sql...
- egeozcan 9y ago"Mongres is a PostgreSQL extension that runs a custom background worker speaks mongo wire protocol." https://github.com/umitanuki/mongres https://github.com/umitanuki/mongres
- btown 9y agoThere's also https://www.torodb.com/stampede/docs/1.0.0-beta3/relational-schema/ https://www.torodb.com/stampede/docs/1.0.0-beta3/relational-... which tails the Mongo oplog and makes a fully-relational read replica, adding columns and indices as needed. An amazing (and free) shortcut to using analytics tools if Mongo's your main datasource.
- drmirror 9y agoI beg to differ. (Disclosure: I work for MongoDB.) Using JSON as your data model, rather than relational tables, lets you build different applications that don't need multi-document transactions as often, because the data is already together in a single document. But when you do need multi-document transactions (a small percentage of applications do, and only few use cases inside those applications), they are now available. There is no speed impact on cases when you don't use them. And most of the time, you shouldn't use them, otherwise you wouldn't be capitalizing on the advantages of JSON. I think that's a game changer, but then again: I do work for MongoDB.
- mason55 9y ago> otherwise you wouldn't be capitalizing on the advantages of JSON Shouldn't this be "otherwise you wouldn't be capitalizing on the advantages of a schemaless, document-oriented database"? The fact that it's JSON (vs. some other format) seems immaterial
- matwood 9y agoAs an aside, I hate the term 'schemaless' because there is always a schema. https://blog.jooq.org/2014/10/20/stop-claiming-that-youre-using-a-schemaless-database/ https://blog.jooq.org/2014/10/20/stop-claiming-that-youre-us...
- lukaseder 9y agoYep. Schema-on-read (E.g. MongoDB) or schema-on-write (E.g. Oracle)
- metheus 9y agoQuibble: “schemaless” isn’t accurate, MongoDB supports schema (JSON Schema, in fact). We often say “dynamic schema”. But your main point is good—- JSON isn’t the essence of it. And yet it’s part of it, in that you could store XML and still be a document DB; MongoDB definitely chose JSON as the medium deliberately.
- jeremiep 9y ago
- scarface74 9y agoI really don't need Sql compliance - I use C# and the Linq provider is pretty good.
- sixdimensional 9y agoJust remember, SQL is and always was "not only relational" - a play on the, should be long dead and buried acronym NoSQL (IMHO). Structured query language - I know for a fact from actually doing it (see Cache database, Hadoop schemaless SQL, even a product I worked on that was SQL to Mongo, heck the SQL standard itself) - guess what - it works with object/document stores too! Mongo could have implemented SQL on top of their storage engine a long time ago minus the joins. Instead they built their own query mechanisms. Mind you, mapreduce can't be reproduced explicitly in SQL, but SQL expressions can compile to Mapreduce (see Apache Hive), so even that was not an excuse. Edit: NoSQL served a purpose to remind people that there were other options other than relational databases (including those that predate the relational model and those that came after it), but man, what a terrible and misleading misnomer.
- munk-a 9y agoOn this point, the datastores that have insisted on using a query language that isn't SQL have always seemed to just be attempts at setting up walled gardens. Plenty of people have extended SQL when their needs required it (MySQL, PostgreSQL, Oracle, TSQL/MSSQL) but intentionally rejecting the basic format of SQL queries just seems like an attempt to setup a barrier to ever move off your DBMS. Speaking as someone who ported an application from MySQL to MSSQL there is still a lot of work required to remove those custom extensions, but the core of what you're doing can remain the same.
- egeozcan 9y ago> At its core, MongoDB is a document database and — almost by default — these kind of databases aren’t ACID compliant, especially when it comes to multi-document transactions. For the most part, that’s not a big deal for companies that use database systems like MongoDB because they are not trying to write to multiple documents at the same time. No. At least in the open-source world, you can see many applications make multi-document "transactions". I don't see how it would be different in companies using MongoDB. > Because of this, though, many MongoDB users still run relational databases in parallel with their document database. No. For the most part, they do write to multiple documents and not think about consistency. At least the situation seems to be getting remedied. Better late than never.
- adwhit 9y agoMongoDB has successfully played the 'hype first, features later' strategy. Now it is well on the way to being a decent swiss-army-knife database. The RethinkDB retrospective[0] contains a lot of insight into how MongoDB has succeeded despite being vastly inferior on a technical level back when it first launched. I have to admit them a certain respect for executing their strategy so successfully. Choice quote: Every time MongoDB shipped a new release and people congratulated them on making improvements, I felt pangs of resentment. They’d announce they fixed the BKL, but really they’d get the granularity level down from a database to a collection. They’d add more operations, but instead of a composable interface that fits with the rest of the system, they’d simply bolt on one-off commands. They’d make sharding improvements, but it was obvious they were unwilling or unable to make even rudimentary data consistency guarantees. But over time I learned to appreciate the wisdom of the crowds. MongoDB turned regular developers into heroes when people needed it, not years after the fact. It made data storage fast, and let people ship products quickly. And over time, MongoDB grew up. One by one, they fixed the issues with the architecture, and now it is an excellent product. It may not be as beautiful as we would have wanted, but it does the job, and it does it well. [0] http://www.defmacro.org/2017/01/18/why-rethinkdb-failed.html http://www.defmacro.org/2017/01/18/why-rethinkdb-failed.html
- andy_ppp 9y agoI agree here, but I’d go further; build things people want, not the idealistic future some day version where we eventually get to a priority feature for a lot of people like releasing fast scalable software quickly (I’m not saying Rethink didn’t do this but they prioritised correctness and sharding, features fewer people need). For most apps built with Mongo this transaction support isn’t a problem (until it is).
- nathan_long 9y agoBoth approaches have downsides. The TCP/IP stack was built and used while the OSI model was being designed, and it won all the mindshare. Perhaps it would have been better to have separate presentation and session layers, but we don't; the application layer handles that stuff. It works well enough. OTOH, this quote is wise: > It is easier to optimize correct code than to correct optimized code (Bill Harlan) I think this is doubly true for databases; at least with obfuscated code, you can recover the underlying meaning with work and exploration. Losing or corrupting data is the worst thing a database can do. Given "this will be correct and hopefully we can scale it" vs "this will be fast and hopefully we can keep it correct", I'd choose the former for any "source of truth" data every time. There are tricks for speeding up queries - indexes, cacheing (including materialized views), sharding, read replicas, etc. There are no tricks for recovering data you lost.
- neovive 9y agoHas anyone worked with MySQL JSON data types in production? For most projects, I prefer working in SQL via a query builder or ORM for abstraction, but find a few features that would benefit from denormalized JSON storage.
- toomuchtodo 9y agoUse PostgreSQL. https://www.postgresql.org/docs/10/static/datatype-json.html https://www.postgresql.org/docs/10/static/datatype-json.html
- mat_keep 9y agoor not, as the case may be https://www.mongodb.com/compare/mongodb-postgresql https://www.mongodb.com/compare/mongodb-postgresql
- furicane 9y agoYou're aware that the vendor will post gospel about their product on their own website? I'm not using Postgres, I use MySQL, but I can assert with 100% certainty that most of the "comparison" on that URL is just marketing bullshit. You're a prime example that this new-age bullshit works and that's what's worrying.
- mat_keep 9y agogreat. Do i declare i worked at mysql for 5 years as well? Both before and after Oracle acquisition
- furicane 9y agoHow's that relevant? You're neither lead architect nor does your employment at MySQL / Oracle mean anything. Many incapable developers score positions at big companies. Without facts, maths and measurement you can be Linus Torvalds for all I care. The article at the URL provided is simply marketing ploy. I'm experienced enough to notice what's wrong with the comparison, but I won't take that article apart to prove anything. If you believe Mongo is a product that helps you - perfect. Now, if you're thinking you'll convince me that it's great by berating another great product - well, that raises a red flag. Who says I've to use a single software vendor anyway?
- alyson-cabral 9y agoI'm the Product Manager on the Core Server responsible for the multi-document transactions project. For those of you interested in learning more about how we're building transactions in MongoDB, I suggest checking out this video that discusses creating WiredTiger timestamps to enforce correctness in operation ordering across the storage layer. The description is presented by Dr. Michael Cahill, the co-founder of the WiredTiger storage engine aquired by MongoDB. https://www.mongodb.com/presentations/wiredtiger-timestamps-enforcing-correctness-in-operation-ordering-across-the-distributed-storage-layer https://www.mongodb.com/presentations/wiredtiger-timestamps-...
- jbellis 9y agoHi Alyson, Thanks for the link! It looks like the video covers using timestamps to implement replicated mvcc correctly from primary to other replicas. The interesting next step is how you go from there to multi-document across different primaries. Or is this limited to documents in a single shard?
- alyson-cabral 9y agoIn 4.0, transactions will just be across replica-sets. The following release will have transactions across the entire sharded cluster (across multiple primaries).
- btown 9y agoLest we forget, we should wait for an Aphyr/Jepsen analysis before jumping to use this in production: it could go either the way of https://aphyr.com/posts/284-jepsen-mongodb https://aphyr.com/posts/284-jepsen-mongodb or https://jepsen.io/analyses/mongodb-3-4-0-rc3 https://jepsen.io/analyses/mongodb-3-4-0-rc3
- amelius 9y agoGood point! The code is almost completely new, so definitely a thorough testing is required.
- ChicagoDave 9y agoThis is interesting, especially for micro-service architectures (one table, one service) that need to modify multiple tables.
- BillinghamJ 9y agoNo, it doesn’t work for that use-case. It would all need to happen within a single service in a single invocation. To enable transactions across network boundaries, you need to enable the transactional safety at the application/API level. And, for the record, one service per table is a terrible idea. It would have none of the benefits of a service-oriented architecture, while adding all the complexity and caveats of a distributed architecture.
- ChicagoDave 9y agoExcept I've implemented it that way in highly visible, high traffic internal web applications that were lauded as some of the most successful transitions in company history in a very large corporation. So your argument is really legacy opinion and not relevant to micro-service architectures.
- BillinghamJ 9y agoNone of the things you've just said make any difference to the fact that it doesn't make sense and is a terrible idea. I fail to see in what way my statements are "legacy" or not relevant to micro-services. My company (Cuvva, insurance in the UK) runs a "micro" service architecture and deals with these problems every day. It is not possible to use DB-level locking/transactions across network boundaries. It's just as simple as that. It's not an opinion - it's a fact.
- thawkins 9y agoNot even using 'XA'?
- ChicagoDave 9y ago
- cracker555 9y agoIDM FULL VERSION https://www.idmcrack.ml/ https://www.idmcrack.ml/
- chasingthewind 9y agoI literally just finished making some code changes minutes ago to very carefully sequence a set of changes to some related documents to make sure that if write failures occur they'll have the least impact on our system. I've been very happy with our decision to use MongoDB because in the vast majority of cases I just don't need transactions, but there's that one place where using them will be a big win.
- scarface74 9y agoI keep hearing about how people have been burned by Mongo but nothing specific. Does anyone care to give any specifics?
- riku_iki 9y agoI never used MognoDB, but read many stories that few years ago MognoDB default configuration permitted data loss: server returned write success response to client without syncing data to replica or disk, and if your server died then your data gone. Additionally some time ago MongoDB had single-threaded writes with collection level lock, which could cause poor write performance.
- scarface74 9y agoThat's one thing I keep "hearing". The default configuration now is a WriteConcern of 1 - meaning at least the primary has to have written it successfully. You can choose 2 or majority among others.
- takeda 9y agoThat won't protect you, you can read the analysis for MongoDB from here: http://jepsen.io/analyses http://jepsen.io/analyses The last analysis looks good, but you need to note that this is only true with the strongest settings (this means that Mongo will be configured with slowest settings) also this analysis did not include node crashes or restarts.
- scarface74 9y agoI read it. From his analysis it seems like the loss of data will rarely happen in the real world if you have a WriteConcern of Majority and you don't have a large latency between nodes. One of the comments said that theoretically, that could also happen with any system if something happened between the time that it wrote to disk and the time it acknowledged it, you may have extra data. There are times though that you care more about speed than reliability - ie capturing string data for an IOT device, logging etc. There are even times that eventual consistentency is good enough. But definitely choose the right tool for the job. I wouldn't trust Mongo for financial data where transactions are a must. And in my preferred language - C#, if you write your code correctly, you can switch out your Linq provider from Entity Framework to the Mongo driver for instance without any major code rewrite so you aren't stuck with your choice.
- majidazimi 9y agoCall me when they added Triggers, Stored Procedures, Common Table Expressions, Window Functions,...
- jasondc 9y agoTriggers?? Where you add some application logic to the database, 10 years go by, and no one has any idea how the triggers work? Or even how to test them? I've never seen triggers used successfully in any production application (maybe they work at first, but give them time, and a few code changes).
- segmondy 9y agoYou test triggers the same way you test any code. You setup your preconditions, you execute any action, you assert your post condition. You can use something like http://pgtap.org/documentation.html http://pgtap.org/documentation.html to write your database tests. Triggers have a place in app development, and sometimes are the best things to use.
- hunterjrj 9y agoWhat you're describing is a fault in an organization's maturity with respect to documentation and NOT a fault of a database feature.
- wenc 9y agoTriggers are pretty much like stored procedures. They have their place. One of the major use cases of serverless functions is as triggers.
- ZenoArrow 9y ago> "I've never seen triggers used successfully in any production application" Triggers have one or two good use cases, and plenty of bad use cases. I would suggest the strongest use case is for data validation. Databases don't have very sophisticated type systems, and custom data types can cause headaches. Database triggers allow you to ensure that the data stored in fields matches a set of criteria. To give a basic example, if you had a customer table with an email address field, you could validate that the email address had an @ symbol using a code in an insert and/or update trigger. Of course, you should have similar checks within the software that sits on top of a database, but by putting the validation at a low level by using database triggers you can be more confident that the data integrity will be protected. As a second use case, if the triggers are being used to maintain data for audit or reporting purposes, that can be fine. However, aside from the audit/reporting use case, I would recommend avoiding using triggers which span multiple tables (unless there are some exceptional circumstances where it's the best option). Things get messy when you have a chain of tables, each with their own triggers that can update other tables within that chain. If you spot lots of code like that, run to the hills!
- outside1234 9y ago"Ship and iterate" almost always wins over "perfect and ship"
- mathieuuu 9y agoWe have been using mongo over the last three years on our project and it has been pretty smooth so far. However, lately I gave some thoughts into what our project would look like if we used PostgreSQL instead. I tried to figure out what problems Mongo solves that PostgreSQL doesn't. I am far from being a database expert, I just know enough basics to query what I need, so feel free to correct/complete the following: - Mongo has been built to store json objects -> Yes, but from what I understand benchmarks indicate that PostgreSQL is faster at reading/storing/indexing json/jsonb content. I don't think that it is good reason to use it. - Mongo is schemaless -> There might be some usecases, but I bet in most cases this problem can be worked around. Especially in a database with JSONB support. - MongoDB horizontal scaling is way easier than PostgreSQL. Yes, it seems that scaling horizontally Mongo is extremely easy compared to any other relational database. And ... that's it. But there is probably more. At the moment, here's how I would summarize MongoDB benefits if asked my opinion when starting a project: - For a small projects or a prototype: ease of use, ease of configuration, don't require too much thinking into my data model while I am experimenting - For a bigger project: horizontal scaling should be easier Does that sound accurate to you? Am I missing anything important?
- Pxtl 9y agoHonestly, the existence of Mongo is mostly an indictment about how user-hostile conventional RDBMS is. The fact that other DBs can do what Mongo does is not helpful when there is no easy workflow to do what Mongo does. The fact that I theoretically implement a web-based CMS in C and it could be more performant than all these web-language CMS products doesn't mean that C is better for making a CMS.
- vim_wannabe 9y agoMongo is truly the Javascript of databases. It's even made in JS!
- mat_keep 9y agoits mainly written in C++ and C
- krylon 9y agoI looked into MongoDB a couple of years back, because it was the hot thing at the time. About fifteen minutes in, I try to find out how to do transactions. That is strange, I thought, the manual says nothing about transactions. I asked a popular search engine and was a little shocked to find out there were no transactions. That was a dealbreaker for me. If MongoDB has now grown support for transactions, that changes things. I think I am going to look at it again sometime. EDIT: Typo
- metheus 9y agoWhile doing so, I recommend you think some about the meaning of embedding relationships vs. referencing them in other collections. MongoDB can do both (the aggregation framework provides joins in the form of the $lookup stage). If you have a “one-to-many(some)” kind of relationship, embedding is a good option, and gets you ACID semantics without even resorting to multi-statement transactions. If you have a “one-to-many(thousands or more)” kind of relationship, objectID references (a la foreign key) is more likely what you want.
- krylon 9y agoIt will be interesting to learn about database design in a non-relational environment. I guess you can replicate a relational structure in MongoDB, but then why not use an RDBMS in the first place? As far as I understand it, MongoDB's claim to fame is a) handling huge amounts of data and b) clustering. Neither of these apply to me, so the only reason to use Mongo would be data that does not match the relational model well. I am still looking for a use case, any use case, that might make a valid excuse to learn it, but so far I have come up empty. I am a little worried that I am facing a situation somewhat like the one when I tried to learn Lisp. Learning Lisp was very hard for me because I had absorbed the structured programming approach so deeply that the functional part of Lisp programming seemed downright alien to me. At first, at least. So for the time being, I cannot tell with any certainty if problems that are a good match for a document store are just so rare, or if I am just incapable of modeling my data in ways other than the relational model.
- 9y ago
- lkrubner 9y agoMost software developers have a negative impression of MongoDB, based on the many flaws that it had back in 2010. Among the people who did the best job of documenting those flaws, was Kyle Kingsbury, in his Jespen series: https://aphyr.com/posts/284-jepsen-mongodb https://aphyr.com/posts/284-jepsen-mongodb But it is important to realize that the team at MongoDB has actually been working with Kingsbury, for several years now, and they have slowly and patiently fixed the problems he identified. Consider how the situation had evolved by 2017: MongoDB 3.4 Passes Jepsen – The Industry’s Toughest Database Test Jepsen Evaluation Demonstrates MongoDB Data Safety, Correctness & Consistency On February 7th 2017, Kyle Kingsbury, creator of Jepsen, published the results of his tests against MongoDB 3.41. His conclusions: "MongoDB has devoted significant resources to improved safety in the past two years, and much of that ground-work is paying off in 3.2 and 3.4. MongoDB 3.4.1 (and the current development release, 3.5.1) currently pass all MongoDB Jepsen tests….These results hold during general network partitions, and the isolated & clock-skewed primary scenario." https://www.mongodb.com/mongodb-3.4-passes-jepsen-test https://www.mongodb.com/mongodb-3.4-passes-jepsen-test MongoDB has become an excellent document-store database. If you are still repeating FUD from 2010, then you are simply out of date. It's time to come up to speed on the reality of 2018.
- gshulegaard 9y agoWell...to the best of my knowledge the Mongo DB BI connector in 2018 is still Postgres: https://www.linkedin.com/pulse/mongodb-32-now-powered-postgresql-john-de-goes/ https://www.linkedin.com/pulse/mongodb-32-now-powered-postgr... Has this changed?
- metheus 9y agoJohn radically overstates his case in that article based on incomplete information; note that none of the code he points to is even 1.0 code. Nonetheless, it’s accurate enough to say that the 1.0 BI connector used Postgres code. It was definitely the fastest way to deliver it. 2.x was built from scratch, it uses no Postgres whatsoever.
- kstirman 9y agoYes this has changed. The BI Connector 2.0 is written in Go and uses the MySQL wire protocol: https://docs.mongodb.com/bi-connector/master/release-notes/ https://docs.mongodb.com/bi-connector/master/release-notes/
- truth_seeker 9y agoWow. In v3.6 they started supporting complex joins and in next major release ACID is also coming. It would make it most flexible database ever. I would love to see RocksDB as storage engine instead of WiredTiger in their future releases.
- nemo44x 9y agoYou might be interested in this: http://mongorocks.org/ http://mongorocks.org/ MongoDB has plug-able storage engines.
- truth_seeker 9y agoI think Percona's MongoDB version also supports RocksDB as storage engine but they are not keeping up with latest releases and hence new features offerings. Correct me if my assumption is outdated as of today.
- ralmidani 9y agoEvery time I hear about some NoSQL "breakthrough" that existed a while ago in SQL databases, I can't help but feel underwhelmed. In general, I'm convinced SQL is like Constitutional Democracy; it's not perfect, but it's better than any alternative humans have come up with so far.
- munk-a 9y agoThe consistency is really nice too. I've always hated the fact that column declarations are the first portion of a query and wanted them at the end but... I'd rather be slightly disappointed all the time than occasionally need to rewrite huge swathes of queries if we're changing DBMSs
- jaequery 9y agoMongodb can be quite a nightmare once you start requiring anything more than a 1:1 relationship, which is pretty much any kind of app that is doing anything meaningful. Having to resort to doing things like map/reduce for a simple group by / order is not the way to go IMO. I think you later truly realize the beauty of SQL once you get far down that rabbit hole. Initially I rode on the Mongo's NoSQL bandwagon when I saw that you can just save a JSON hash and thought that's the coolest thing in the world. But ever since I tried out Postgres's JSONB, I just can't go back to Mongo anymore. With Postgres, I have the best of both worlds, performance, relational data, and reliability. I don't have to sacrifice any of it. Also, I don't know who codes using raw SQL, it's been years languages have had ORMs that made queries look just like a Mongo query. Also, for anything else, like a super simple requirement of saving data (JSON), Firebase have fit that role perfectly. Mongo is starting to look like it's out of place in the eco system.
- metheus 9y ago> Having to resort to doing things like map/reduce for a simple group by / order is not the way to go IMO. Perhaps you are unaware, but that is a straw-man. That’s not how you’re supposed to with MongoDB. You’d use the aggregation framework: db.sales.aggregate( [ { $group : { _id : null, totalPrice: { $sum: { $multiply: [ "$price", "$quantity" ] } }, averageQuantity: { $avg: "$quantity" }, count: { $sum: 1 } } } ] ) https://docs.mongodb.com/manual/reference/operator/aggregation/group/ https://docs.mongodb.com/manual/reference/operator/aggregati... https://docs.mongodb.com/manual/reference/operator/aggregation/sort/#pipe._S_sort https://docs.mongodb.com/manual/reference/operator/aggregati... This has been the case since MongoDB 2.0, in 2012.
- spamizbad 9y agoAggregates carry with them a memory limit. We currently use MongoDB 3.4. It's definitely much improved. The replication protocol that came along with 3.4 has been very reassuring. But aggregate queries really do not give you the power of SQL. They are great for transforming stuff for a report, but I would avoid using them for anything else unless 1) it can be cached (and therefor properly invalidated) and 2) doesn't need to be "real time" Being a document, schema-less database, your "quality of life" as you scale with MongoDB is going to be heavily dependent on how you structure your documents and the types of their fields. Are you treating your collections like SQL tables? Have any many-to-many relationships in hot code paths? Welcome to hell. Its type system is also limited compared to modern SQL DBs. Storing IP addresses, and want to query them based on a given CIDR range? Postgres makes this eas, MongoDB has you writing code that does sub-queries.
- jonjojr 9y agoThat changes nothing for ArangoDB (https://docs.arangodb.com/3.3/Manual/Transactions/ https://docs.arangodb.com/3.3/Manual/Transactions/) as they have had this feature long before MongoDB. But MongoDB gets the headlines for the hype and being light years late to the party.
- callumjones 9y agoI find it telling of MongoDB's sales strategy that this is being covered by Techcrunch. I don't think you'd get the same coverage on Postgres (granted MongoDB is a company, vs PG is a project).
- khrm 9y ago"Every NoSQL attempts to add features until it can do relational ops and then ends with a sql layer plugin on top. Those who can't are replaced by ones which can." - Rehash of Zawinski's Law by me
- Bitcoin_McPonzi 9y agoWhat I like most about MongoDB is that it's "web scale" http://www.mongodb-is-web-scale.com/ http://www.mongodb-is-web-scale.com/ It's because of shards. Shards are the secret ingredient in the web scale sauce. They just work.
- NeoBasilisk 9y agoI will never stop loving this. Here is a youtube link in case anyone can't/won't run flash on that site. https://www.youtube.com/watch?v=b2F-DItXtZs https://www.youtube.com/watch?v=b2F-DItXtZs
- unclebucknasty 9y agoThis is funny. "NoSQL for the win! RDBMSs/SQL suck! Who needs ACID?" Years later: "MongoDB has added ACID transactions." "Awesome!"
- deleted 9y ago[deleted]
- santidh 9y agoIn general, the content that can be sent is defined as "anything that satisfies one's intellectual curiosity.