All I need is a schemaless version of postgres (with ACID-compliance and everything), does anyone know of one?
Failing with MongoDB
31–40 of 128 posts
Re: Failing with MongoDB
#32Seems to me they used the wrong setup they should have looked at a replicaset setup with secondaries for read and sharding if they needed more write performance and nonblocking reads. That said version 2 has less locking problems and I understand they are working on finer grained locking.
Re: Failing with MongoDB
#33Re: Failing with MongoDB
#34Seems to me they used the wrong setup they should have looked at a replicaset setup with secondaries for read and sharding if they needed more write performance and nonblocking reads. That said version 2 has less locking problems and I understand they are working on finer grained locking.
Sorry, this is a pretty poorly written blog post. We're definitely using sharding+replica sets.
Replication of any kind won't help you with a high write load as secondaries have to apply the same number of writes as primaries.
Re: Failing with MongoDB
#35Seems to me they used the wrong setup they should have looked at a replicaset setup with secondaries for read and sharding if they needed more write performance and nonblocking reads. That said version 2 has less locking problems and I understand they are working on finer grained locking.
Sorry, this is a pretty poorly written blog post. We're definitely using sharding+replica sets. Replication of any kind won't help you with a high write load as secondaries have to apply the same number of writes as primaries.
They seem to be very aware of the problem and focused on solving it as soon as possible. I guess it's just a matter of time. Compared to how long it took MySQL to mature into a stable platform I've been pretty impressed at their responsiveness and quick improvements so far :).
Re: Failing with MongoDB
#36Earlier 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…
Everything else in a software project changes frequently, especially during the early days. "Fundamentals" don't help you know more ahead of time and it's really nice to be able to quickly adjust when you come across something you hadn't anticipated. I tried building a small side project with Postgres about 8 months ago (after not really doing rdbms stuff for 18 months before) and was amazed at how inflexible it felt…
Could you elaborate please? What were you doing and what made it feel frustrating and inflexible exactly?
Re: Failing with MongoDB
#37Earlier quoted context omitted.
Not a bad business strategy. Kinda like MySQL back then right?
Sadly, it seems that "give them free crap and then charge for fixes" is a very common business model in the open source world.
I am really happy that this does not exist in the PostgreSQL community despite many of the core developers being consultants who live off solving their clients' problems with PostgreSQL. Maybe this is because it is a community project with no single company in control of it.
Re: Failing with MongoDB
#38Why is a database that fails so easily and most of the time even loses data so popular? Is it really all just a huge marketing budget?
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.
Re: Failing with MongoDB
#39Earlier 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…
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 about it up-front.
This is a conception of data that is more true in theory than it is in practice. In practice, if you want to query your data and efficiently, you'll need to worry about how it's stored. You'll have to worry about the failure cases.
Of course, it is definitely application dependent. If you're just writing a Wordpress-replacement, you can probably choose whatever data store you want and just write an abstraction layer on top of it (especially if you don't care about performance). On the other hand, if you're looking at querying and indexing terabytes (or more) of data, you'll have to work very closely with your data store to extract maximum performance.
Re: Failing with MongoDB
#40Earlier quoted context omitted.
Migration tools are great once you stop changing the schema very often like it happens when a project starts. This of course depends on the project... if you can have a full design from the start, it's probably going to work too. If you don't know the exact requirements or way to get there - not so much.
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?