Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why some NoSQL DBs only let you perform transactions on a single data item

dbmsmusings.blogspot.com

Post reply on HN
Print view View original

41–50 of 56 posts

Re: Why some NoSQL DBs only let you perform transactions on a single data item

#41

Post by sammydavis »

arosenbaum wrote: post #30

Misleading 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:…

Could you describe where your system sits on the FIT spectrum that the article discusses? Do you believe that scheme for thinking about the trade-offs between isolation, throughput, and fairness doesn't hold for marklogic?

Re: Why some NoSQL DBs only let you perform transactions on a single data item

#42

Post by arosenbaum »

sammydavis wrote: post #41
arosenbaum wrote: post #30

Misleading 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:…

Could you describe where your system sits on the FIT spectrum that the article discusses? Do you believe that scheme for thinking about the trade-offs between isolation, throughput, and fairness doesn't hold for marklogic?

They absolutely apply to MarkLogic. We absolutely prioritize FI over T. Coordinating transactions, along with journaling, security and many other features costs in terms of throughput. Now, that cost is relative - our ingest rates are still very quick and we linearly scale. That said, copying JSON or XML into a distributed file system is way quicker.

I'm not sure the buckets provide much guidance in real life. One can configure a system, for an insert only batch load, to prioritize T without giving up FI for the data and transactions that aren't part of that load. If an FI system can load faster than an IT system, this distinction ends up not actually mattering. Plenty of folks who need FI are using products that don't provide it because of culture + budget.

Re: Why some NoSQL DBs only let you perform transactions on a single data item

#43

Post by dang »

arosenbaum wrote: post #30

Misleading 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:…

Ok, we added 'some' to the title.

Re: Why some NoSQL DBs only let you perform transactions on a single data item

#44

Post by lobster_johnson »

Rezo wrote: post #10
mooreds wrote: post #2

This 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.

I was just starting a new project and had to make a choice. I looked at the MongoDB 3.0.x release notes to see if the project has managed to improve in the last couple of years, and there are still way too many "data files are not correctly recovered following unexpected system restarts" and "race condition between inserts and checkpoints that could result in lost records" issues being fixed in each release for my li…

> after installing PostgreSQL on Ubuntu

Note that this is a mainly packaging and entirely the maintainer's fault: They typically run the database under a "postgres" user, so you'll have to do "sudo -u postgres createdb" or whatever. PostgreSQL itself doesn't care; if you install it from source and start the postmaster process as yourself, then you'll have full access right away.

That said, Debian/Ubuntu packages typically don't set up a default environment for you as a convenience. It's debatable what it should do. Create a user and database for root? Postgres maps, by default, POSIX users to database users. If you run "apt-get install postgresql-server-9.4", who should it create database users for?

Also, I'm not sure you're fair to the documentation you're referencing, which seems entirely reasoanble to me. Section 1.2 of the 94 manual's tutorial, "Architural Fundamentals", is pretty important, and it's short. But if you skip it, you'll get to the next section, "Creating a database", which tells you what need, and the next one goes into the SQL stuff. Both sections work if you've installed it from source (or Homebrew, which also runs Postgres as yourself). But it would be silly to expect this documentation to tell you how to specifically do it on Ubuntu.

Re: Why some NoSQL DBs only let you perform transactions on a single data item

#45

Post by arosenbaum »

judah wrote: post #19

On 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…

How can one possibly be eventually consistent for reads and ACID for updates? Unless you are saying the datasets available for fast queries cannot be updated consistently...Or are you just saying, you can read from replicas but maintain a single master...

Re: Why some NoSQL DBs only let you perform transactions on a single data item

#46

Post by arosenbaum »

joeclark77 wrote: post #37
mooreds wrote: post #2

This 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.

The idea is that you won't need database-wide transactions if your data is structured into "natural aggregates" such as orders, articles, profiles, etc. In a relational database, something as simple as an "order" has components in lots of different tables -- customer, product, order, line_item, shipping_method, etc -- so you have to lock all of those tables when doing an INSERT or UPDATE. In the ideal MongoDB impleme…

>I would not recommend NoSQL for something like a banking Many of the leading banks in the world have replaced Oracle with NoSQL (generally MarkLogic) for key systems. Abadi explained quite clearly why NoSQL is not incompatible with transactions and updates.

Re: Why some NoSQL DBs only let you perform transactions on a single data item

#47

Post by hardwaresofton »

As previously noted, title is misleading. Also, pick a better document store (though you should note that rethink only guarantees operations on single documents as atomic):

http://rethinkdb.com/

Yes, "better" is subjective, but rethink has a good page detailing the differences (between rethink and mongo):

http://www.rethinkdb.com/docs/rethinkdb-vs-mongodb/

Feature-list type breakdown:

http://www.rethinkdb.com/docs/comparison-tables/

And pay attention to the guarantees that it provides/doesn't provide when you pick. I think this is a big part of what separates novice developers form middle-tier developers. There are always tons of choices, for just about everything in software these days, and your job is to figure out how best to solve which problem you're facing, in a way that future generations won't hate you for.

Re: Why some NoSQL DBs only let you perform transactions on a single data item

#49

Post by manigandham »

arosenbaum wrote: post #30

Misleading 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:…

Do you have info or can you point to anything where I can learn about MarkLogic without all the marketing speak on the site? It's really hard to get any info about how the software actually looks like and works and compares to other options out there...

Re: Why some NoSQL DBs only let you perform transactions on a single data item

#50

Post by Rezo »

lobster_johnson wrote: post #44
Rezo wrote: post #10

Earlier quoted context omitted.

I was just starting a new project and had to make a choice. I looked at the MongoDB 3.0.x release notes to see if the project has managed to improve in the last couple of years, and there are still way too many "data files are not correctly recovered following unexpected system restarts" and "race condition between inserts and checkpoints that could result in lost records" issues being fixed in each release for my li…

> after installing PostgreSQL on Ubuntu Note that this is a mainly packaging and entirely the maintainer's fault: They typically run the database under a "postgres" user, so you'll have to do "sudo -u postgres createdb" or whatever. PostgreSQL itself doesn't care; if you install it from source and start the postmaster process as yourself, then you'll have full access right away. That said, Debian/Ubuntu packages typi…

I respectfully disagree. After reading the "Getting Started" guide, you might reasonably believe a developer would be setup and happily coding away, but in my experience it fails at the very first steps.

Which is fine, if you want to keep a high bar, but don't be surprised when people still think the product is "harder to use" than MongoDB or whatever in 2015. Blaming maintainers does nothing for the users, take ownership of the experience! If you want to be seen as approachable and easy to use, you have to actually target people new to PostgreSQL and not write the basic guide assuming you're compiling from source on Solaris or have a dedicated site DB administrator. The magic phrase "sudo -u postgres createdb" does not appear anywhere on postgresql.org that I can see, and as a experienced user you know that's not the end of it (can I use psql as my regular user after running it? No, of course not. There's many more entirely undocumented arcane incantations left!). I claim, it is in fact impossible to get up an running with no previous knowledge if all you have access to is the postgres site. Thankfully there's Stackoverflow, so at least some users are still getting through the gauntlet.

Sorry for the rant. I get a bit frustrated when I see a great project that I love dropping users through a bad onboarding experience (I know, contributions welcome...)

Just for reference, check out: https://docs.mongodb.org/manual/tutorial/install-mongodb-on-... https://docs.mongodb.org/getting-started/node/ In fact, you get different sets of documentations for the whole matrix of OS * ENV (Shell, Node, Python, C++, Java, C#). When the docs have their target audience down to a T ("Why yes, I AM a C++ developer on OS X! This looks like the perfect fit!"), it's easy to see why they're so popular.

Post reply on HN