Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am sorry if this is not a constructive enough question.. Coming from the SQL world I'm just trying to wrap my head around this. After reading a lot about MongoDB, I've become very enthusiastic about it and consider using it for an upcoming application (in combination with Meteor).
However, I came across this blog post, which describes the troubles Diaspora ran into when using it and states "you should never use MongoDB". The examples she's giving sound pretty convincing.
Are these true problems with MongoDB, or were they using it wrong? Is this article now outdated and are there better ways for doing what they're doing (duplicate data for instance, like users being linked to each other, to posts and to comments, is a very common use case)?
Yes, there is a plenty of cases when mongodb not feet good, some of them are
When data perfectly described with 'table' metaphor (better using
SQL)
When you need ACID and transactions out of the box
When your workflow extremely oriented to write operation
When you need to generate complex cross-data reports
Data model have strongly relational view (a lot of connected
instances)
There is a lot of others, but this is just something which comes to my head fast.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I want to go with Xamarin.Forms project. Now, I am bit confuse for consuming Rest API for this project. Performance matters.
There are many available but can any body please suggest me which should be best for Xamarin.Forms(.Net Standard)?
Microsoft Http Libraries or third party libraries like Refit, RESTSharp, PortableRest, etc.
Please suggest
All of these options are viable. I think the performance differences between these libraries will be marginal. So, it mostly comes down to what you feel comfortable with.
I like to use Refit because it will take a lot of redundant code out of your hands and you just have to focus on the contract. All the code for the actual calls is generated at compile-time (and thus won't impact your performance at runtime).
Also have a look at how well the library is maintained and if it's active. If you choose one that is already inactive for a while, chances are that you will start relying on older software versions which might not be what you want.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Did someone try developing a GraphQL instead of RESTful API? Can someone give real life (not only theoretical) pros and cons. Basically from my research I found that the GraphQL power is to get exactly what you need nothing more. Where with REST APIs, you often have to make a series of requests and you can easily get back more information than you really needed.
Is it worth the time spent on researching and learning GraphQL? Any bugs or showstoppers that get your attention?
This question is primarily opinion-based.
But from my experience:
Multiple requests on a RESTful-API for just one thing often indicates a lack in the API design, namely the needed resource was not available and therefore stuff needs to be gathered from different resources to compensate for this.
A REST-API that could be easily replaced by GraphQL indicates, that the API was in fact a CRUD-HTTP-API, what is considered an Anti-Pattern among REST-Evangelists.
Also worth noting is, that GraphQL puts responsibilty on the client, because the backing API is reduced to be a datastore that just needs to be queried. REST on the other hand enforces the behaviour of the client and therefore reduces responsibility on it. The client gets reduced to be something similar to a browser.
There are cases the one or the other approach would yield better results, but that greatly depends on your situation.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I already have a .Net Web project running on MongoDB where I store some news/feed data.
After a while I needed a faster way to track "who shared what" and "how to find relationships depending on these information".
Then I came up with an idea to use graphDB to track related feeds and users.
Since the system is already running on MongoDB, I am thinking of leaving the data in Mongo and creating the graph representation in Neo4J for applying a graph search.
I do not want to migrate all my data to Neo4J because many people telling me MongoDB's I/O performance is way better than Neo4J and they also pointed out Sharding feature.
What would you suggest in this situation?
And If I follow my idea, will it be a good practice?
Personnally I think there are no unique answer and best practices. It is common usage to use polyglot persistence systems.
Now everything is based on your context and there are points we can't just reply for you :
How much time do you have (learning a new technology is not a matter of days until you can use it in production and sleep good )
How much money you can invest in the project , sharding is, AFAIK, a neo4j enterprise feature and licenses have a cost if you're not opensource or commercial company. Also hosting costs for Neo4j in cluster mode.
How much data ? As long as your graph can fit in memory, you'll not run I/O issues.
Now, away from these points, yes you can in a first instance trying to map neo4j on top of mongoDB.
Maybe try to do incremental migrations, and at then end of the process, maybe ask you the following questions, WHY do you need MongoDB to handle graph structures ?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am going to start learning NOSQL databases (in practices, already done my researches and understood the concepts and modeling approaches).
I am working with time series data and both cassandra and mongodb are recommended for this use case.
I would like to know which one takes less time to learn? (Unfortunately, I don't have much time to spend on learning)
PS: I noticed that there are more tutorials and documentations with mongoDB (am I correct?)
Thank you!
Having used them both extensively, I can say that the learning curve isn't as bad as you might think. But as different people learn and absorb information at different rates, it is difficult to say which you will find easier or how quickly you will pick them up. I will mention that MongoDB has a reputation of being very developer-friendly, due to the fact that you can write code and store data without having to define a schema.
Cassandra has a little steeper learning curve (IMO). However that has been lessened due to the CQL table-based column families in recent versions, which help to bridge the understanding gap between Cassandra and a relational database. Since tutorials for MongoDB have been mentioned, I will post a link to DataStax's Academy, which offers a free online course you can take to introduce yourself to Cassandra. Specifically, the course DS220 deals with modeling your data.
With both, a key concept to understand is that you must break yourself of the relational database idea where you want to build your tables/collections to store your data most-efficiently. In non-relational data modeling you will want to model your tables/collections to reflect how you want to query your data, and this might mean using redundant data in some places.
qMongoFront is a qt based mongodb gui application under linux. It's free and opensouce. If you want to learn mongodb, qMongoFront is a good choice.
http://sourceforge.net/projects/qmongofront/
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am trying to learn NoSQL, and am implementing that in a project I am working on now as a means to pick it up. I understand there are no hard rules around it. But I'd be happy to read on some of the following:
Guidelines on how to structure a NoSQL document.
Moving from a RDBMS to a NoSQL thinking.
Difference between storing data in a NoSQL to that from RDBMS
Thanks!
I do have previous experience in RDBMS, and have been working with them for years.
Every concept will require to learn new thinking. Your question is to general for a specific
answer.
You will structure and work with CouchDB documents in another way as with MongoDB documents. In CouchDB you will do queries with MapReduce. In MongoDB you have a flexible query interface similar to a RDBMS.
A Key-Value store requires a completely new way of thinking. You have to know your query patterns before you are able to structure your content the right way. You have no index, so you have to build your own structure.
One blog that gives a lot of NoSql information is http://nosql.mypopescu.com
Update
The Riak people have some interresting questions too:
Will my access pattern be read-heavy, write-heavy, or balanced?
Which datasets churn the most? Which ones require more sophisticated conflict resolution?
How will I find this particular type of data? Which method is most efficient?
How independent/interrelated is this type of data with this other type of data? Do they belong together?
How much will I need to do online queries on this data? How quickly do I need them to return results?