51–60 of 75 posts
It is kind of odd that speed is the main motivation to switch from MySQL. Horizontal scaling is the usually given reason. From what I have seen Mongo achieves most of its speed by not using fsync by default. There were some slides floating around a while ago that showed Postgres at about the same speed by turning off fsync.
Earlier quoted context omitted.
Funny, I've been using MongoDB for well over a year, and I use it not for scalability/durability, but because it's so nice to develop on top of. Simply put: it gives you a much more natural way to persist the objects you work with in the OO language of your choice. It's a joy to use. Until I used it, I didn't realize how unnatural it was to map OO programming to an RDBMS. We work with objects in our languages. We don…
It's a joy to use. We work with objects in our languages. We don't work with rows of data. And I totally get that, I really do, but to me, that's more of an issue of personal preference, and less of an issue of a clear advantage. There's nothing wrong with personal preferences. For instance, I like schemas that aren't easily changed, and a clear separation of logic and data, and I prefer to think of data as rows, not…
I still think of data as rows in MongoDB, but the lack of a fixed schema makes life seriously easy. That means my schema is defined in the application (and only the application) and is subject to versioning. Want an extra column? Just add it to your application and you're done. No need to promote a slave and cycle through while waiting hours upon hours for each table to build.
Earlier quoted context omitted.
This is because you are simply never updating your schema: if you actually want to rename a field, change a datatype, or reorganize your content, you are still going to need to run a migration, and now it won't even be possible to transanction lock the upgrade (better database servers, like PostgreSQL, can do multiple whole-daabase schema modifications within a transaction while still allowing non-conflicting access)…
The OP question was "during development". I obviously change the schema in production too: sometimes keeping null-values will work, sometimes a migration will be needed. My point is that I only do the "production" migration when needed and once per release that requires it, while I can tweak the schema at ease while developing. If you have a large-enough volume of data, you will meet the situation where just adding a…
Works like a charm. No migration headaches.
Alright, so, I fully understand the scalability reasons for using MongoDB, but I need someone to clearly explain to me when NoSQL would be a better solution than SQL from a development standpoint . Because like someone pointed out, Postgres without fsync can be just as fast. What is the advantage of giving up the ability to use SQL and the associated relational algebra that has long been established in that query lan…
For example, it's extremely awkward in SQL to find all the elements in a tree. There are at least 4 hacks I know of to fix this, none totally satisfactory. In a NOSQL context you can just store the entire tree - your implementation becomes straightforward and simple. In general though I agree with you. I can whip out SQL queries in seconds that would take me minutes to write against Mongo, even though they're all tec…
Now, in order to find all the elements in a tree, you can't do that from a tree table because the data doesn't do anything. The nodes just sit there as they should. In order to find all the elements you have to walk the tree. Don't expect the static data in a table to walk itself. Now, if you create a path table then you can find all the nodes in a tree or sub tree with a simple query. The columns for such a table are node ID, parent node ID, ancestor node ID, sequence number, and level. Every time the nodes in your tree table change, update the data in your path table. Create a path table for node name sorted ascending, another path table for node name sorted descending and if needed a path table sorted on node ID.
If you want all the elements for a sub tree you just do 'select node ID, ... from node_name_path where ancestor_id = 6 order by sequence'. Super simple if you apply a little graph theory to the problem, take note that trees and paths are different things and divide the problem into one concern for storage and the other for calculating.
If you want help doing this let me know. It is totally satisfactory, instantaneous and free of hacks. mckinley1411.removethedotandthis@gmail.com
Earlier quoted context omitted.
This is because you are simply never updating your schema: if you actually want to rename a field, change a datatype, or reorganize your content, you are still going to need to run a migration, and now it won't even be possible to transanction lock the upgrade (better database servers, like PostgreSQL, can do multiple whole-daabase schema modifications within a transaction while still allowing non-conflicting access)…
The OP question was "during development". I obviously change the schema in production too: sometimes keeping null-values will work, sometimes a migration will be needed. My point is that I only do the "production" migration when needed and once per release that requires it, while I can tweak the schema at ease while developing. If you have a large-enough volume of data, you will meet the situation where just adding a…
Alright, so, I fully understand the scalability reasons for using MongoDB, but I need someone to clearly explain to me when NoSQL would be a better solution than SQL from a development standpoint . Because like someone pointed out, Postgres without fsync can be just as fast. What is the advantage of giving up the ability to use SQL and the associated relational algebra that has long been established in that query lan…
I recently evaluated a lot of different database systems too for a new project, and settled on MongoDB for a key part of it. While it has many positives (the above, plus performance and scalability) one of the negatives that worries me a little bit is the "running with scissors" feeling of not having database-enforced table schemas. Ultimately, we'll find out firsthand whether that leads to disaster or not, and whether it's a net win. My bet now is net win.
Only had 5 days with MongoDB and I found it a good alternative for persistence of basic data structure in Python, my main concern was something that can $set individual elements of a JSON instead of retrieving the whole doc and modify it.
i ran into the same question
Where are the "MongoDB is Web Scale" jokes? crickets. If you are not using MongoDB, you are missing out badly and are probably developing at a much slower rate than someone who is.
MongoDB is web scale. No downvotes this time, please! http://www.xtranormal.com/watch/6995033/
Earlier quoted context omitted.
For example, it's extremely awkward in SQL to find all the elements in a tree. There are at least 4 hacks I know of to fix this, none totally satisfactory. In a NOSQL context you can just store the entire tree - your implementation becomes straightforward and simple. In general though I agree with you. I can whip out SQL queries in seconds that would take me minutes to write against Mongo, even though they're all tec…
You just store the entire tree? Then how do you get a subtree? I don't think you're solving anything by just storing the whole tree as one thing. I mean you can do that in SQL too if you want.
And yes, XML/XPath support in SQL databases allows them to act as schema-free document stores. However, they aren't optimized for that, so indexing inside the document is limited. OTOH, SQL DB vendors might be able to add that quicker than NoSQL vendors can improve tool support and querying. OTOH you have to deal with XML instead of JSON. OTOH...
It's a trade off.
Earlier quoted context omitted.
Kinda depends on the use case. Let's say you have a caching layer and update a subtree in your RDBMS. Then you need to go find all values referencing that object and invalidate them. That's potentially a lot of complexity. Of course you could cache only parent objects and fetch the subtree on demand (cache or db). Hello slow. So I prefer to not use words like "usually" as it truly depends on your application and use…
I do not see how the caching comment here applies, and I think it is telling that this example still includes updating a subtree. I am wondering if you think by "library" I mean "cache layer": I don't. So, either the NoSQL solution you are using is incredibly dumb (and your schema is pretty much "id->blob") or it is internally going to have to do just as many joins against separately stored data objects in order to r…
I agree that Postgres can do this - I've done it before. But I think you're a bit wrong to dismiss document databases so quickly.
Firstly, the subtree update problem isn't a huge problem. MongoDB allows dot notation to update items within a document. Yes, it is may well have to do just as much work as a SQL database in the update case, but I don't care. I'd prefer it is implemented in the database than something I have to do myself.
Secondly, the schema-free nature of a document database is a killer-feature for me. I have truly schema-free tree data (different levels of the tree have different, unknowable-in-advance data stored against them). Yes, I can implement this in a SQL database schema, but it's going to be an ugly schema (eg, I'll have to use rows to store things that should be columns). It will also be slow because of the hierarchical walking needed in the queries. (Although Postgres helps some here with hierarchical query support).