Nobody else has said it, so I'll do it: This website is horrible. The font color is #888888 on a white background, which is very hard for me to read. And I can't even fix it by disabling a CSS style in the web inspector panel like I usually would because the CSS styles are hard-coded into style attributes on spans for each paragraph! What is this, a website from the 90s? How is it so horrible, given that other random Blogspot blogs I'm checking have sensible markup?
Why some NoSQL DBs only let you perform transactions on a single data item
21–30 of 56 posts
Re: Why some NoSQL DBs only let you perform transactions on a single data item
#22On the .NET stack, RavenDB[0] supports transactions on multiple items[1]. RavenDB is a nice middle ground: eventual consistency for queries for speed, but ACID for create, update, and load (one or more items by ID). It uses transactions throughout, so a failure in the midst of 10 writes will rollback all of them, as one would expect in a traditional relational database. [0]: http://ravendb.net/ [1]: http://ravendb.ne…
It does indeed look nice, however the pricing looks worse than MS SQL in the long run (for the enterprise version).
Re: Why some NoSQL DBs only let you perform transactions on a single data item
#23Nobody else has said it, so I'll do it: This website is horrible. The font color is #888888 on a white background, which is very hard for me to read. And I can't even fix it by disabling a CSS style in the web inspector panel like I usually would because the CSS styles are hard-coded into style attributes on spans for each paragraph! What is this, a website from the 90s? How is it so horrible, given that other random…
You know how when you write something in Microsoft Word, and then copy it out into an editor, it takes terrible and broken HTML markup with it? That is exactly what has happened. The author has written the post in Word copied it to blogspot, and wham, bam, thank you ma'am, you get that clusterfuck.
Re: Why some NoSQL DBs only let you perform transactions on a single data item
#24ZODB ( http://www.zodb.org/en/latest/ ) is a NoSQL database that has been around for almost twenty years now. It's a Python-specific NoSQL database that allows persisting of arbitrary objects in a tree structure. It not only has multi-object transactions, transaction savepoints for memory efficiency's sake (both optimistic and normal), a pluggable 3-way conflict resolver, two-phase commit and support for long-running…
ZODB is no database. ZODB is a persistance layer. Where is the SQL in ZODB? The level of sophistication in the query interface is laughable.
Re: Why some NoSQL DBs only let you perform transactions on a single data item
#25Nobody else has said it, so I'll do it: This website is horrible. The font color is #888888 on a white background, which is very hard for me to read. And I can't even fix it by disabling a CSS style in the web inspector panel like I usually would because the CSS styles are hard-coded into style attributes on spans for each paragraph! What is this, a website from the 90s? How is it so horrible, given that other random…
Also - when you swipe the page right (to go Back in a mobile browser), it instead navigates you to the previous blog entry. Argh.
Re: Why some NoSQL DBs only let you perform transactions on a single data item
#26This was very helpful. I am in my first project with MongoDb after a lot of experience with RDBMs and I do miss transactions. There are other things I miss more: foreign keys (dobt use dbrefs!), joins, and SQL, though. Unfortunately this application is new, so we haven't yet seen the benefit of schemaless data changes.
If this new application is something that will be in production and important to a business, I would seriously question the decision to use MongoDB over PostgreSQL.
I'm not saying it's a bad decision or that MongoDB is bad in general. I'm saying it's a decision that should not be taken lightly. If you've done the analysis and feel strongly that MongoDB's the perfect fit, then cool.
However, I think people routinely discount the operational overhead that comes with using something like MongoDB. For example, they don't think about how it's much harder to find good devops people with experience maintaining a MongoDB sharded cluster, or they don't think about what happens when the CFO wants to hook the DB up to Excel and run some queries. And I'm not even talking about the additional development complexity due to implementing integrity checks and manual transaction rollback/compensation in your application code.
Those problems can be all be solved though. It just takes more effort/money. So, you need to be sure MongoDB offers advantages to offset that.
In my opinion, schemaless data changes are not even close to offsetting the overhead, and concerns about scaling beyond MySQL or PostgreSQL are probably premature optimization. Not that those are your reasons – just reasons I often hear.
And of course, I'm making a lot of assumptions, for example that the team has experience writing & operating systems on top of an RDBMS. If the rest of the team are MongoDB wizards and you're the only one new to it, then that's a different situation.
Re: Why some NoSQL DBs only let you perform transactions on a single data item
#27Nobody else has said it, so I'll do it: This website is horrible. The font color is #888888 on a white background, which is very hard for me to read. And I can't even fix it by disabling a CSS style in the web inspector panel like I usually would because the CSS styles are hard-coded into style attributes on spans for each paragraph! What is this, a website from the 90s? How is it so horrible, given that other random…
Don't despair. If you have access to the console, copy & paste this and knock yourself off:
[].slice.call(document.querySelectorAll('#post-body-2680112629272717029 *')).forEach(ele => ele.style.color = 'black')Re: Why some NoSQL DBs only let you perform transactions on a single data item
#28ZODB ( http://www.zodb.org/en/latest/ ) is a NoSQL database that has been around for almost twenty years now. It's a Python-specific NoSQL database that allows persisting of arbitrary objects in a tree structure. It not only has multi-object transactions, transaction savepoints for memory efficiency's sake (both optimistic and normal), a pluggable 3-way conflict resolver, two-phase commit and support for long-running…
ZODB is no database. ZODB is a persistance layer. Where is the SQL in ZODB? The level of sophistication in the query interface is laughable.
It is a database, not a relational database.
Re: Why some NoSQL DBs only let you perform transactions on a single data item
#29What is the percentage of web applications that really need all that scaling? How many database instances does Hypothes.is need? What about Airbnb? Duolingo? Feedly?
Exactly.
To handle massive loads, you can trade away transactional integrity and get increased performance AND a whole new range of complicated problems that was more or less solved for you, that you now have to take care of yourself.
For some applications, the tradeoff is not a problem - and in others it requires a lot of work, up to more or less your own implementation of distributed transactions.
I have this feeling that I can't shake off , that a lot of people think relational (transactional) databases are complicated, and fail to see why they actually are complicated. This probably is not the category of people that truly need to solve their performance problems though.
Re: Why some NoSQL DBs only let you perform transactions on a single data item
#30Misleading title: Abadi specifically called out particular NoSQL DB's, he wasn't generalizing to all NoSQL DB's. MarkLogic (http://www.marklogic.com) is an Enterprise Database used by many large organizations as a system of record for information traditionally stored in RDBMS or Mainframe.
Joe Hellerstein gave a wonderful keynote at ACM SoCC last year that is a great read for all who are interested in this subject: http://db.cs.berkeley.edu/jmh/talks/SoCC14-keynote.pdf
MarkLogic has had transactions since version 1.0. The same mechanisms that enable multi-statement transactions are also critical for overall reliability. A recent Gartner study ranked MarkLogic as #3 for reliability (not NoSQL databases, all databases).
Many on HN may have not heard of MarkLogic as we are not open source. We are, however, the largest NoSQL ISV by employee count (and probably other measures also.)
I am VP, Product Strategy for MarkLogic (ExIngres, ExCohera)