It handles millions of users, with dozens to hundreds of thousands of queries per second, and some TBs of daily changes, with a single Postgres cluster. > So relational is usually the default/general choice if you don't need performance at scale.ĭefine scale. Due to the limitations to ACID operations in MongoDB -and the lack of them in other NoSQL systems-, you might see spurious effects of document in one form appearing or disappearing while being migrated. * At all times, you are dealing with potentially significant consistency issues.
#MONGODB PERFORMANCE VS POSTGRES CODE#
* Once migration is done, you need to undone all these "duplicated" code paths.
#MONGODB PERFORMANCE VS POSTGRES UPDATE#
Worse, depending on your migration code, you probably need to update the document in the $old form it is in the $old form, but in the $new form if it is in the $new form. They are not trivial neither, as they need to support now cases in which the pre-updated document is in two possible forms. * Change all your queries to do an "union" between the results you get from the $old model (those documents not migrated yet) and the $new model (those already migrated). Since you want this to be incremental (without downtime) you necessarily need to deal with, among others: When you do a data migration of the kind we're talking here, let's say you are reversing how embeds who (you had employees embed departments, and now you want departments embed employees), you need to do a whole collection rewrite. You can do transactions as big as you want (I have seen single transactions of multi-TB of changes). Postgres supports fully atomic DML and DDL operations. > the chance you can atomically update a system, whatever kind of database you're using, isn't something you necessarily get So relational is usually the default/general choice if you don't need performance at scale. I'm not disputing relational databases are more flexible, and mostly simpler when a single instance does the job (though you generally pay back some complexity transforming relational data into the form your clients need). It should be a layer with clear separation of concerns, the implementation should be shared so you don't have redundant implementations, etc. That generally does exist with nosql and is a maintenance burden, but should not be deeply embedded in your app. I guess you're talking about the need for code somewhere to take a more explicit role in managing storage.
At a high-level, the point of nosql is to store your data more directly in the way your app wants to consume it, so data reorg follows the needs to the app, not the other way around. > Last but not least, you need to recode your application heavily. So for data access pattern changes between components we're talking about incremental migration in any case, that needs to maintain compatibility until all dependent clients/components are updated. You either don't have reliable control of all clients, middleware components and data stores or can't pay the price of downtime. You don't need to break things though.Īnyway, from my perspective, the chance you can atomically update a system, whatever kind of database you're using, isn't something you necessarily get. Yes, I'm thinking of incremental migrations. But its complexity, performance and rewriting needs to adapt to changes are what are not, apparently, advertised, after our observations. It is a first-class operation, well advertised. The reference model, and their $lookup operator, are not a corner case nor a hidden downplayed option.
MongoDB requires data modeling, is not "schema-less", and this is pervasive through their official documentation. We will be very happy to analyze it.Īll in all, this is an exercise of data modeling, for a given dataset. If anyone considers that there's a better way to represent this data model (problem statement), that would still answer all the "business" questions (queries) considered in the post, please send a Merge Request to the repository. The repository also contains all the query examples used in the post. This is explained in the post and references to official MongoDB documentation are provided. And actually we considered the two models that MongoDB themselves consider for data modelling: embedded and reference. Second, and regardless of the above statement, the exercise here is to model a data model that is, necessarily, two (or three) pieces of related data. So this is, from this perspective, very apples-to-apples IMHO. So any database, RDBMS or NoSQL or whatever, will need to deal with data that is related to other bits of data. While I understand is tempting to easily conclude that this is apples-to-oranges or that "obviously a relational database is better at data relationships", I recommend to dive deeper into the topic.įirst of all, almost all data models you may think of are in some or another way relational (call it "related data", if you prefer).
0 kommentar(er)
