Live data from Hacker News

Think before you Mongo

blog.runnable.com

41–50 of 101 posts

Re: Think before you Mongo

#41

Are there any key/value JSON databases that enforce JSON Schema (or some other schema language)? That seems way better to me in situations where you actually care about data integrity.

See the docs for document validation, available in 3.2 and later.

https://docs.mongodb.com/manual/core/document-validation/

Re: Think before you Mongo

#42
post #22
post #12

Earlier quoted context omitted.

I am yet to fail into this NoSQL trend. Yes, SQL does have its issues, but I am yet to work on any project where the relational data model doesn't fit. Plus all the stuff that we can do at the SQL engine level, specially data validation, is just great for the type of stuff we develop.

NoSQL is driven more by scaling issues than anything else. Joins and strong consistency are awesome but run head first into the CAP theorem and other concerns like single node performance on a sharded cluster. There is also the fact that no programming language lets you deal with relational data sanely in code, so you have the well known impedance mismatch heaeache. All popular languages I've seen offer hierarchical…

Mongo doesn't solve the impedance mismatch either, if you have 2 classes which have a many to many relationship you'll still need to think about it when you model datas, without any guarantee of consistency. Mongo DB barely make queries easier to write, without the power of SQL. How would you persist a "recursive" model with MongoDB while being able to do aggregation operations on the collection , like counting the number of models ? if you use a single collection for all the models, you'll then have to load all the models in the application code and count them in the code, where a simple COUNT would do the trick. With Mongo you're constently trying to reinvent SQL in the code. On the other hand, SQL allows one to write recursive queries for tree like structures.

I understand the trade offs in order to scale, but you can give up on joins WHEN it's time to scale. Mongo doesn't give one the choice at first place.

Re: Think before you Mongo

#44

I agree... but at this point, it's tough to see with all the ink that's been spilled on these issues for years how you could think anything else. Maybe I read HN too much, but the manifold problems with MongoDB have been widely publicized for the past 6 years... it seems pretty close to conventional wisdom that you're going to have those problems if you decide to use Mongo.

You have to separate between "Mongo the database" and "Mongo as it's used by companies"; the latter causes far more problems than the former.

I last used MongoDB seriously in 2012-2015. We had myriad operations problems including inconsistent indexing across shards (where some shards had an index created and others didn't, it was baffling), issues with the balancer not moving chunks properly, and more. Also it's just different than other DBs with its lack of transactional consistency (I think they've made progress on building this), but that's part of why it's fast.

However, the bigger problem is that document databases -- in general -- enable a kind of software development where the model sort of emerges over time, rather than being carefully designed from the beginning. Yes, it's flexible, but you pay an absolutely enormous cost down the line dealing with inconsistent documents. It's not like code where if you do something stupid, you can fix it over time with refactoring and "remodeling" -- data has mass. You can get into a situation where, with a large data set, it can take a week or more just to run the migration script required to scan an entire collection and rewrite a few billion documents into a new, better format.

There is no such thing as a "schemaless" database. That's like saying, oh sure, we just have a bunch of 1s and 0s in memory -- our data is "structureless". The question is whether the database enforces the schema, or not. And I think that in a lot of cases, it's a lot worse to have an "uncodified schema" than a rigid, but at least well-defined, one, that's consistent across the data at all points.

Sidenote: It's also occurred to me over the past few years that it's almost impossible to impose a consistent schema on a large enough dataset. If you truly are dealing with "big data" (TB/PB scale) maybe go straight to the document store of columnar because doing a migration is outright impossible, but don't be so quick to write it off for GB-scale datasets.

Re: Think before you Mongo

#45

Earlier quoted context omitted.

Yeah, drivers are not as good tho. That also counts, am I wrong?

I've had nothing but positive experience with RethinkDB drivers. RavenDB has good drivers for some languages, but admittedly not every language is well-supported. Still, I can't see a situation where I would choose a non-working datastore over a working datastore.

I'm having an excellent experience coding against RethinkDB in Tornado Python. A shift in programming style from conventional callbacks to use Tornado's gen.coroutine is necessary. Having made that shift it's become very easy to use coroutines in the server to stream RethinkDB's JSON result sets up to an AngularJS front end. End to end JSON makes for zero impedance and rapid development. I'm constantly rejigging my schema, indexes and joins as I go so it feels like RDBMS based dev in a lot of ways.

Re: Think before you Mongo

#46
post #7

Earlier quoted context omitted.

Please elaborate. This comment provides little to the discussion.

Not nodejs, but I am in the process of tracking down and event loop loop (e.g. emit( event_id ) somewhere in the path of an event lisener of that name). I assume this can happen within node too. The stack trace is amazing to see.

What tool are you using that allows you to see the stack trace on async events? That seems like a good debugger.

Re: Think before you Mongo

#47

Are there any key/value JSON databases that enforce JSON Schema (or some other schema language)? That seems way better to me in situations where you actually care about data integrity.

That'd just be Postgres. When you need an schema you use a normal table, when you need arbitrary JSON data you use a JSON schema.

I don't think so -- I'm looking for a database that will actually enforce a JSON schema for you -- I don't think Postgres has any built-in support for JSON schematization.

I could always do validation before inserting data, but that opens me up to error on my side which I'd like to avoid=)

Re: Think before you Mongo

#48
post #7

Earlier quoted context omitted.

Please elaborate. This comment provides little to the discussion.

Not nodejs, but I am in the process of tracking down and event loop loop (e.g. emit( event_id ) somewhere in the path of an event lisener of that name). I assume this can happen within node too. The stack trace is amazing to see.

Yes, it is.

Re: Think before you Mongo

#49

Are there any key/value JSON databases that enforce JSON Schema (or some other schema language)? That seems way better to me in situations where you actually care about data integrity.

See the docs for document validation, available in 3.2 and later. https://docs.mongodb.com/manual/core/document-validation/

Awesome, I had no idea they'd added that!

Re: Think before you Mongo

#50
post #22
post #12

Earlier quoted context omitted.

I am yet to fail into this NoSQL trend. Yes, SQL does have its issues, but I am yet to work on any project where the relational data model doesn't fit. Plus all the stuff that we can do at the SQL engine level, specially data validation, is just great for the type of stuff we develop.

NoSQL is driven more by scaling issues than anything else. Joins and strong consistency are awesome but run head first into the CAP theorem and other concerns like single node performance on a sharded cluster. There is also the fact that no programming language lets you deal with relational data sanely in code, so you have the well known impedance mismatch heaeache. All popular languages I've seen offer hierarchical…

Joins seriously have nothing to do with the CAP theorem, except inasmuch as multi-key read/write transactions do. Consistent multi-key read-only transactions and write-only transactions are actually not terribly difficult to do under serializability across partitions. Additionally, from a sheer performance and data perspective, centralized relational databases work just fine for real workloads. Unfortunately, pretty much zero real-world apps don't need multi-key read/write transactions, and modern businesses expect uptime that is unrealistic for a centralized system, so people are forced to replicate across datacenters. Ultimately what most people end up doing (regardless of database) is partitioning into small enough key groups that they can afford the highly expensive latency cost for maintaining high availability (across multiple datacenters) while maintaining consistency within each group for read/write transactions, and giving up on consistency across partitions for such operations (but usually maintaining consistency on read-only and write-only transactions). NoSQL can sometimes give you a clearer understanding of the cost/consistency tradeoff you're making, and hierarchical keys can make it much easier to partition, but joins really hardly enter into it.
Post reply on HN