Hacker News Reader

Comment by felipeccastro | Hacker News Reader

I use Rails and Mongo at work. There is a schema, enforced declaratively at the application layer (mongoid). With Rails Console querying the database ad hoc is even easier than with SQL, thanks to mongoid api and Ruby’s expressiveness. There are no transactions, but single document writes are atomic. Performance is pretty good; the one hardship I run into is that the mongoid api is so high level that you don’t see when you’re firing way too many queries at the dB (but that’s an ODM issue, not mongo’s, other ODMs might not do that).

View on HN

> schema, enforced declaratively at the application layer

Nobody has just one app forever. Any org that gets big enough is going to be uncertain about how many apps depend on a particular database, much less whether they’re all in the same language and bundle the same schema rules. Customer service builds weird support tools, accounting and compliance build weird reports …

Make sure each datastore has a clear owner, and access it via that API rather than directly. If you really must share a datastore, use a schema registry. Sharing between multiple applications doesn't really work for SQL database either (e.g. if you have multiple applications writing to your database in transactions then you're virtually guaranteed to get deadlocks).

This only works in theory.

In reality sometimes access via an API is way too slow or is lacking flexibility.

And I don't get this: "(e.g. if you have multiple applications writing to your database in transactions then you're virtually guaranteed to get deadlocks)"

Isn't this why transactions exist in the first place?

depends on what level of isolation and how it's done, MVCC avoids deadlocks, but if you manually lock any row/table, you can still run into deadlocks. but the DBMS' transaction manager will notice and timeout one of the transactions, failing it.

While MVCC avoids deadlocks, you'll still get a lot of failed transactions if they all operate on the same data at the same time, which you'll have to retry, but I'll take that over data inconsistency

> (e.g. if you have multiple applications writing to your database in transactions then you're virtually guaranteed to get deadlocks).

That assumption is only true if the DB is continually used by different applications. The reality is more likely a large number of applications used by a relatively small set of users, so most of the time there won't be any application writing, and it would be extremely rare for multiple applications to write at the same time.

Are rare deadlocks better than frequent ones? That sounds like a good way to not know you have problems.

Quite often you have several applications that look up each other's data, but mostly write to their own tables.

(But indeed, with uncoordinated development, deadlocks can occur. Still better than data corruption.)

I feel like the issue with nosql is that it's largely unnecessary when newsql databases exist.

This may continue to work, as long as performance is not your primary consideration (you have little data and few queries), you don't have to evolve the schema much, and no programming errors or ad-hoc updates introduce data that fail to follow the schema at the DB level.

So, it might be adequate for a small and carefully maintained project, likely like many alternatives.

Or do you use a high-load, distributed, replicated / sharded Mongo configuration? Then I'd gladly listen to more details.

Reply on news.ycombinator.com