This troll job by MongoDB made me wonder if anyone is really hardcore in favor of NoSQL for general use-cases.
For further actions, you may consider blocking this person and/or reporting abuse
Read next
Say Goodbye to ElasticSearch: Discover MongoDB's Powerful Search Capabilities
Anuj Jindal -
I have <insert alternative noun> not Users
Mark Blandford -
OCI - Database Cloud Metrics - #1 Basic Management Metrics
Abhilash Kumar Bhattaram -
Meet Datomic: the immutable and functional database.
guto -
Latest comments (53)
That's absolutely preposterous.
Good, attention-getting marketing, though. Can't blame MongoDB.
But if you have a boss actually influenced by an ad like this, make sure they and you have both read Dan McCreary and Ann Kelly's Making Sense of NoSQL.
Each major flavor of non-relational database has something it's good at (and plain-old relational databases in turn have things they're good at). This book will explain why.
They basically break databases down into 5 major types in use today:
Interestingly, from what I hear at Salesforce talks, they present a user interface to their customers that, for all practical purposes, gives those customers a traditional "relational database," but on the back end, Salesforce has been migrating from storing what actually goes into those "databases" away from a relational database of their own and into a ... I think it was a columnar database, but I wouldn't swear to it.
Am using CouchDB for a project and, franquly, I like it. Have used MongoDB in the past too. But am a long time SQL user, but since I have worked with NoSQL and when I have the choice, I’ve ended up always choosing NoSQL.
NoSQL definitely has its place if you need "web scale", I'm not sure mongodb is the right tool for that job though. Most people use redis/memcached for a quick lookup cache, but the data is usually always in a relational store as the source of truth.
Real web scale use cases usually will use cassandra or other big boy tools :)
I'm not too familiar with mongodb as i haven't used it in a long time but it seems like mongodb tries to replace mysql/postgresql.
The question is, do you start a project using nosql as your main datastore? Or do you go with something more traditional that has known scale-out options.
I will just leave this here
if we're talking non-relational vs relational, there is an obvious need for non-relational databases and endless use-cases. document databases, graph databases, key-value store databases. the key-value store database is invaluable :P
Here is where things go wrong:
dev.to/0xrumple/comment/5e8l
Looking them how? by title?
That's not our job, that's algolia's job ;)
The most part I feel will get right, is the logical nesting of documents instead of m2m ugly relationships which have no actual benefit.
We do caching as explained here:
dev.to/0xrumple/comment/5ebp
I'm posting this here to make sure we are taking the right decision :)
Do you implement GraphQL on the controller layer? or on top on HTTP REST APIs?
Controller. Used the standard Java API for GraphQL, but the schema is dynamically generated when the entities are changed. The schema is not fixed, rather it is defined in data.
Thanks Peter... I will come with couple of questions when we start implementing the system :D
The answer for EACH one of your questions is YES !
But, what's the problem with copying one module from a workshop into another since it happens rarely?
But NO, the ACID philosophy turned out to not be not pretty much scalable comparing to the BASE (no black/white case, it always depends).
As far as I see, we will replace them with just one query: get document (track) by id.
For filtering and shaping the data, I liked the way GraphQL works, we might add that layer on top of the normal query / REST endpoint.
I know the lookup in mongo is a hell of an operator. But, let's avoid not seeing the forest for the trees... after all, (mongo and nosql) is like (bitcoin and blockchain).
If mongo makes the use of nosql hard, then there is dynamodb or firebase ;)
My applications are more like spreadsheets in that the user defines the data structures and relationships. They do this at runtime and the data structures are stored as data, but used when data is submitted. We have introduced referential links between entities and it is possible to create views which traverse the references. We have implemented GraphQL to be able to get data, which is also able to traverse between documents using references.
In relation to maintaining referential integrity because there is no coupling to the domain there really is only one area of the code that needs to worry about this. We reap other benefits from this approach, including a elegant security model which means we have fine grained access controls over what fields and documents are visible to users based on an access control policy.
Trying to author your own aggregations is folly. In our application we have been able to do complex data transformations easily by having easy to configure transforms which generate the aggregations. Doing it by hand would be a living nightmare.
Is MongoDB the best solution for everything? Nah. For highly structured data like telco call records SQL is the way. For apps that are tightly coupled to the domain, which is typically how things have been done, is fine. But... and this is a big but... the way we tightly couple applications to the data model is making our applications less flexible than they need to be.
Schemaless systems are opening the door. Ten years ago I was where you are now; SQL was the light and the truth. Today my view is broader and I have been given good reason to question the accepted orthodoxy. That said we can't be blind to the downsides.
It's a great model for document-like structures. This includes actual documents, but things like user records as well. If your data has a lot of single-entity structure to it, then I think the noSQL type databases are a better fit.
They also make development easier as they aren't as rigid. Playing with the "schema" is easier.
For mass record-like data I'd still use a relational DB.
Ideally, a good DB-engine would just provide both types of data and stop pretending one is "better" than the other. It's like trying to argue that functional is better than imperative when both combined is preferred.
The aggregation pipeline in MongoDB and Lookup mean that you can do meaningful queries using it now. There does appear to be a memory limit however as it merges the datasets in memory.
A wide developer once said "horses for courses", meaning you use the right tool for the job. For more than 20 years I worked with SQL of various flavours. However, a key discovery for me has been a different way of thinking about development; primarily the separation of the domain from the code and database schema.
Schamaless databases allow me to define data structures at runtime with ease. There is still a schema, but it is defined in data, not code. This means a huge degree of flexibility. If you are writing standard web applications that are bound to the domain model as you have been taught a SQL database will work just fine unless it is huge. The reason I adopted MongoDB wasn't about size, it was about flexibility.
My default database of choice is Postgres unless I understand that my data model or scalability requirements do not fit but it rarely happens.
SQL databases are more common than NoSQL which means bigger community, public knowledge is all around and even cloud providers provide the open source SQL databases as managed services which make it easy to use in production. Usually when it comes to NoSQL the cloud providers provide their own propriety solution.
Firestore by Firebase is a pretty nice DB to use. I know it's still in beta but I've been using it recently as a data store and it's quite nice. Also setup is next to nothing for it. I'm not saying it's a replacement for any of these other solutions but it's damn good.
Yes, me, but I will rest my case by doing the reverse, saying that SQL should have less believers :D
As I study databases more and more, the reasons to use a RDBMS/standard SQL are getting fewer and fewer. From the only hammer I knew how to use (a few years ago), I became an anti-SQL basically.
A few examples:
If you have a (fast iteration product) prototype/startup/small project there is no reason to waste precious time to handle a schema and applying migrations every day, so NoSQL is the smart choice.
If you have a huge project you would need a scalable DB, if you shard you will lose the benefits of relationships. You can insist on using SQL at this scale, but you will have to write/use something like Vitess.
*I don't include Spanner/CosmosDB/Cassandra in this topic, I'm referring to "regular SQLs" like mysql, oracle, sql server, postgres.
If you have (too) many relationships (2+ degrees of connections) you would want to move them into a Graph, and whats left probably could fit into a NoSQL.
If you have a financial product you would be crazy if you don't use an event-sourcing architecture (which can be later aggregated into SQLs, thats true).
If you want to store text for search, you would use something like ElasticSearch.
Let's not forget about TimeSeries (logs, analytics) and GeoData data, which none are best fit with SQL engines.
Like I said, fewer and fewer use cases the *SQL products have nowdays.
MongoDB is an all-around terrible choice for NoSQL. Also the company and their community are often ***holes about it.
Relational DB people on the other hand have jobs and employers that often also deploy traditionally boring "NoSQL" data stores. And again, nobody talks about it, because it is boring.