refamedic.blogg.se - Mongodb compass current topology does not support sessions

Even here in 2017 there is less tooling support for MongoDB than there is for relational databases simply because it is newer.For example, to join data one has to issue multiple queries and do the join on the client. In general, MongoDB creates more work (e.g.This is how it obtains most of its benefits. MongoDB does not support transactions.MongoDB does not have a schema in case you have a special use case that can take advantage of that.

MongoDB has a faster write speed because it does not have to worry about transactions or rollbacks (and thus does not have to worry about locking).

MongoDB is easier to shard (use in a cluster) because it doesn't have to worry about transactions and consistency.

As a result, it can handle a higher load in terms of queries per second and is thus often used if you have a massive # of users.

MongoDB has a lower latency per query & spends less CPU time per query because it is doing a lot less work (e.g.

By then you will understand your storage needs more and will likely be looking for a very tailored critical section / use case. Keep in mind that any data solution is likely to need to be revisited and rewritten continuously as your application scales up. If you are struggling to make this choice then pick the one that most appeals to you. However, at the end of the day its hard to declare either one superior or even to identify broad situations that favor either one. They both obviously do things differently under the hood. Both have their zealots that will feel the decision is obvious. Take Away: Today, the differences between mongodb and an SQL database feel more and more like the differences between Java & C# or maybe Node & Java. Every time the users make a change to their test cases the tools they are using to analyze their results also has to change.Īs an alternative, SQL based storage engines have strengthened support for free-form columns such as Postgres' JSONB data type or MySQL's JSON data type. I will re-emphasize my point on migration though. MongoDB allowed me to store the free-form test results, in a way that is searchable, without needing a strict schema. The test cases themselves (and thus the different result columns) are created by the end user. For example, I am working with test result data generated by a testing & execution solution. I haven't used it for performance in depth since they added these transactions so I cannot comment on that.įurthermore, I have recently been working with unstructured data and the schemaless property of MongoDB has been more of a benefit than the below answer might suggest. For one thing, MongoDB supports multi-document transactions now which throws into question a fair number of the points I've brought up. This answer is specific to MongoDB (as opposed to the vast array of other data storage options out there which are not relational databases).Įvery now and then this answer gets a vote and I get a pang of guilt because I've felt for a while it has grown into a stale answer. Sorry to add another answer but none of the answers here are very satisfactory.