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

Failing with MongoDB

blog.schmichael.com

Post reply on HN
Print view View original

61–70 of 128 posts

Re: Failing with MongoDB

#61

Post by i34159 »

gojomo wrote: post #58

Maybe there's a niche for "PostgreNoSQL", a layer atop Postgres that you start using like a NoSQL solution. (Perhaps, it's string keys and JSON blob values.) It's not very efficient, except for simple keyed lookups, but it works enough for a quick start. Then, as you use it, the system optimizes itself (or makes suggestions) based on actual access patterns. A subset of objects could be a formal, indexed table? Have i…

Conversely, you could have a NoSQL layer below Postgres, where PG stores and indexes metadata which tells it which, of many, small NoSQL dbs to find the actual data in. These data dbs then can be sharded/replicated across physical systems as you like. You loose some raw speed on reads, but avoid a global write lock and the system scales quite well. I've started playing around with such a system with https://github.com/cloudflare/SortaSQL

Re: Failing with MongoDB

#62

Post by lucian1900 »

Sadly, MongoDB blows for actual usage. It locks, it's not crash-only, it has mutable data.

CouchDB is much better (you're as likely to lose data as with Postgres), but is potentially less efficient (no BSON).

Re: Failing with MongoDB

#63

Post by rkalla »

japherwocky wrote: post #38
viraptor wrote: post #7

Earlier quoted context omitted.

If I never expect the dataset to grow past 1GB and a single server, why would I use anything else? It doesn't really fail - none of the issues described were "failures" really. [edit: just to be clear, it didn't crash and burn, I don't think performance issue == failure] The data loss was not confirmed either: "There appears to be some data loss occurring" and in small deployments you can just use transaction log. Th…

what do you think of redis? I feel the same way about Mongo for the most part, but have been considering switching.

If you can model your data in redis data structures it is excellent. Keep in mind that there is no preferred mechanism for operating redis when data is larger than ram. There is vm and diskstore, both deprecated by antirez, and a focus on data sets that fit in ram.

If you can do both of those things, it is awesome.

Re: Failing with MongoDB

#64

Post by rkalla »

icey wrote: post #52
plasma wrote: post #49

Ravendb (www.ravendb.net) is a solid competitor.

"Raven is an Open Source (with a commercial option) document database for the .NET/Windows platform." I'm not sure it's a competitor at all. RavenDB is a CouchDB clone for .Net that requires a commercial license for proprietary software.

Well put.

Re: Failing with MongoDB

#65

Post by hello_moto »

Joakal wrote: post #40
hello_moto wrote: post #21

Earlier quoted context omitted.

If you change your schema once every 2-3 days, something wrong with whomever leading the software project. That's like writing a software with zero planning or lack of knowledge for the problem domain. I don't care if it is a startup or not. Come up with a very simple idea, draw the models in ER diagram, implement that stuff. It's very hard to imagine that tomorrow suddenly all relationships need to be changed. Even…

As a startup, change of minds is pretty normal to the point that it's far more better to have the tools to quickly implement it rather than plan/document it well. The only documentation is the general gist behind the database. If it prototypes well, then further refine it with ER diagrams for future maintenance. Why is planning everything without validation better than above?

small to medium changes? find a better migration tools.

large changes? throw away and start over; tools like Rails can help you get up and running really quickly.

I rarely see people go back and fix the mess.

Re: Failing with MongoDB

#67

Post by hello_moto »

japherwocky wrote: post #41
hello_moto wrote: post #4

Earlier quoted context omitted.

There are tons of reasons for that. Let me pull some of them from my butt: Reason #1: Devs aren't Ops. Reason #2: Devs need something new on their resume. Reason #3: Certain type of Devs would read blogs and get excited and skipping scientific mumbo-jumbo and directly take the blogs as _the_ source of truth. Reason #4: It's easy to bootstrap (schemaless, etc) your weekend project. Dealing with DB apparently is tediou…

Well here's a fuck you back from a dev: my time is finite and everyone wants a piece of it; If I can save an hour a day by never having to think about my database? If I can shave a week or two of labor off a project? It's really easy to work with. This is why people keep using it.

Back at you boy. I'm a dev. I hate dealing with other dev that wasted my time just because he ain't lover with RDBMS and decided to write more code and add more infrastructure components (that includes message queue unless you absolutely have no choice).

My time is finite. Ops time is finite. Obviously you decided to dick around with mine and Ops. How bout I send you to the QA department to write automation and software tools so you don't dick around with production code?

You can write with any language and any storage systems you'd like there.

Re: Failing with MongoDB

#68

Post by absconditus »

mnutt wrote: post #44
Devilboy wrote: post #6

Earlier quoted context omitted.

Right there with you. The excuses I hear for not wanting to use a good 'ole RDBMS just does not make sense to me sometimes. CREATE TABLE too hard? Time consuming? Difficult? Those who do not study the history of databases are doomed to repeat it. Soon we'll add back row-level write locks, transaction logging, schemas, multiple indexes and one day they wake up with MongoSQL.

You say that like it's a failure on the devs' part, but that's kind of like blaming regular users for not switching to Linux because they don't like editing network configuration files.* It's masking the problem that there are real developer-friendliness issues with the existing databases. And taunting users will not get them to switch back. * but then Linux distros get network autoconfiguration and suddenly it's obv…

This is exactly why I do not believe that what we do is engineering. Engineers do not refuse to use proven techniques and technologies because they are "too hard" and instead use easier methods that have serious shortcomings.

Re: Failing with MongoDB

#69

Post by sausagefeet »

viraptor wrote: post #10
hello_moto wrote: post #4

Earlier quoted context omitted.

There are tons of reasons for that. Let me pull some of them from my butt: Reason #1: Devs aren't Ops. Reason #2: Devs need something new on their resume. Reason #3: Certain type of Devs would read blogs and get excited and skipping scientific mumbo-jumbo and directly take the blogs as _the_ source of truth. Reason #4: It's easy to bootstrap (schemaless, etc) your weekend project. Dealing with DB apparently is tediou…

Why do I get the feeling that you're an op and look down on development people? If that's really true, try to start developing some project and see how you like frequent schema changes, trying to synchronise schemas with peers, resolving relation issues when merging features, etc. On the other hand if you abstract your interaction with data enough, you can change the whole backend later once it's stable and not care…

> If that's really true, try to start developing some project and see how you like frequent schema changes, trying to synchronise schemas with peers, resolving relation issues when merging features,

How does something like MongoDB actually help with this, though? Certainly a lack of a schema lets you be more nimble in changing it, but you still have to write code to handle whatever schema you decide rather than letting a battle tested RDBMS handle it. I think NoSQLs have their uses but not forcing correctness on your data as a feature is not one of them. But I also believe in static typing.

Re: Failing with MongoDB

#70

Post by latch »

icey wrote: post #52
plasma wrote: post #49

Ravendb (www.ravendb.net) is a solid competitor.

"Raven is an Open Source (with a commercial option) document database for the .NET/Windows platform." I'm not sure it's a competitor at all. RavenDB is a CouchDB clone for .Net that requires a commercial license for proprietary software.

Which has a ton of magic baked into the driver making it unlikely you'll get your data back out via anything but .NET.
Post reply on HN