151–160 of 280 posts
I'm considering moving away from MongoDB before I have to implement what seems to be an incredibly complicated architecture to get it to scale on the level tens/hundreds of millions of documents.
Earlier quoted context omitted.
I worked for 10gen (now MongoDB) for over 2 years (I left in December). Never once while I was there did they publish a benchmark: There was a [publicly] stated company policy to not publish or comment on benchmarks. If you have evidence otherwise (i.e. benchmarks published by the folks working on MongoDB) fine, but I take this as a deliberately inflammatory (and false) statement. EDIT: The global write lock was remo…
> database level lock But that's not anywhere close to good enough.
FTFY
Earlier quoted context omitted.
If this was a proprietary database we'd call that vendor lock-in and advocate an open source solution. 10gen is a company that earns it's revenue from selling support. They are highly incentivized to lure you in and trap you in a situation that requires a lot of consulting.
Or they could just be interested in adding useful features. PostgreSQL has HSTORE which is a useful but proprietary feature. Cassandra has the ability to have Lists/Maps as data types. Again useful but proprietary. If you are that concerned about database independence then do what everyone else does. Use an ORM, minimise coupling in your domain model and do as much as possible in the application layer.
Earlier quoted context omitted.
Mongo's really great for rapid prototyping. You don't need to worry about updating the schema at the db level, it can store any type of document in any collection without complaining, it's really easy to install and configure, the query language is simple and only takes a couple of minutes to learn, it's pretty fast in most use cases, it's pretty safe in most use cases, and it's easy to create a replica set once your…
> You don't need to worry about updating the schema at the db level What's your magic non-db level, supposedly-easier-than-updating-a-schema approach to renaming a field common to all existing documents in a collection, eg, rename an "author" field to "writer"?
Earlier quoted context omitted.
If this was a proprietary database we'd call that vendor lock-in and advocate an open source solution. 10gen is a company that earns it's revenue from selling support. They are highly incentivized to lure you in and trap you in a situation that requires a lot of consulting.
Or they could just be interested in adding useful features. PostgreSQL has HSTORE which is a useful but proprietary feature. Cassandra has the ability to have Lists/Maps as data types. Again useful but proprietary. If you are that concerned about database independence then do what everyone else does. Use an ORM, minimise coupling in your domain model and do as much as possible in the application layer.
Earlier quoted context omitted.
Do you always start with the perfect data structure? I find myself adding, removing, and restructuring schema often. Just as you think it's silly to use an "inferior" db during prototyping, I think it's silly to have to jump through hoops -- even minor ones -- while I'm just trying to experiment with a new technology or play with a concept, product design, or pet project. 99 times out of 100, I don't care if my proje…
> Do you always start with the perfect data structure? I find myself adding, removing, and restructuring schema often. Which is why it doesn't make any sense to claim that using MongoDB somehow eliminates needing to migrate your data as it evolves.
Sometimes you have to do update of records with a certain version number.
My opinions, for the record: MongoDB is a tool with some use cases. I'm more of an SQL+Memcache guy, if possible, but not religiously if a good argument is presented (that don't sound like "let's use .*, I want another keyword on my cv").
Earlier quoted context omitted.
The case for using it as a prototyping database is the best use-case I've seen for Mongo, however I'm not sure it's always a good idea. For a hack-weekend sort of project, fine, but if you are in any way attempting to make a product, it strikes me as the sort of thing that would be really difficult to change later down the line, and so worth investing the very little extra effort it takes to include your schema in th…
I feel the opposite way. If your application's data layer is sensibly designed, it shouldn't be too bad to switch to postgres when you need to. It may be tedious if you have a large codebase, but it won't be difficult . I think the up-front benefits of using mongo (especially as a sole developer/devops/sysadmin person) outweigh the difficulty of the changes you'll need to make later on, which will only happen as you…
I can't think of any codebases I've seen where intentionally choosing the storage backend you know you don't want to use (if the project is successful) would be a reasonable thing to do. Understate it if you must, but having to change your backend from mongo to postgres is not a desirable situation. Besides, if you're going to use postgres to scale, use it's features and write well optimized queries for it. The difference between a bad massively complex query and a well optimized one can be several orders of magnitude, and that optimization can indeed be difficult. It goes without saying that you wouldn't leave that to an ORM.
Previous versions of my startup's enterprise product used to be based on relational DBs (mostly Oracle, MySQL also). This year we switched to Mongo and dropped RDBMS support. RDBMS performance was fine most of the time as we're not doing big data really. Our problem was developing and maintaining a schema that holds lots of metadata many levels deep. Our app allows for unlimited user defined forms and fields, some of…
Can you explain why can't you do schemaless with an RDBMS?
From what I understand MongoDB is schemaless by storing all fields as one single JSON document. So what stops you from doing the same in an RDBMS - have a catch-all field "JSON" and store all your data there?
Varnish famously demonstrated how to use the kernel page cache effectively. MongoDB, though, is Squid-like. Its an interesting comparison. Every single MongoDB step has had the old timers groaning. Even with something solid like Tokutek's storage engine in it, its going to be a hard sell.
I'm confused by your comment. The beginning acknowledges the fact that MongoDB has a weak storage engine, but your conclusion is that, even with a strong storage engine like ours, there is still a problem. What other problems do you see? Are they something we could work on?
* you have to learn to do indexing right later (if you have to scale)
* failure and miss starting to occur (as you scale)
* more code to write to manage legacy schema and optional fields
The last is painful and ugly. Whereas if you start out with a good schema that last point is in a good hand. When you use SQL you always have the restraint that "xyz" attributes are repeating and you can just make a new relation, whereas with mongo you'd stuff 20 fields into a single collection. The refactoring is harder.
I will begin to migrate back to SQL for new projects.
Also ecosystem is richer in SQL. I have not seen a good ORM for Mongo. MongoEngine is fine but implementation + db have a lot of issues make that ORM a bit unusable from time to time. SQLAlchemy is good.
PS: For quick PoC and Hackathon projects sure prototyping with mongo is fine.