Why you should not use MongoDB

This article was reproduced from: Http://www.oschina.net/translate/why-you-should-never-use-mongodb
(only reproduced, does not mean that the site and bloggers agree to the views or confirm the text of the information)

Disclaimer: I don't build the database engine, but I build a web app. I run about 4-6 different projects each year, so I've built a lot of web apps. I've experienced applications that have different needs and different data storage requirements. I've deployed most of the data stores you've heard or never heard of.

 

Diaspora project  

 

"distributed social network" diaspora Basically no one is concerned about the thing. The main technical difference between diaspora and Facebook is the invisibility of end users: It's a "distributed" section.

 

diaspora infrastructure is not on a separate network address. There are hundreds of independent diaspora servers. The code is open source, so if you want, you can build your own server. Each server, called a pod, has its own database and its own collection of users, and can interoperate with other diaspora pods that have their own databases and user sets.

 

Each pod communicates with other pods through an HTTP-based API. Once you create an account on a pod, it's actually pretty boring, unless you focus on someone else. You can focus on other users on your pod, and you can also focus on other users on the pod. These things happen when the person you're following publishes an update on another pod: The update goes into the database of the author's pod. Your pod will receive notifications via API. The update is stored in your pod's database. You can look at recent events and you'll find this release mixed with the release of other people you care about. Comments work the same way. In any single release, some reviewers might come from the same pod as the publishing author, while others might come from other pods. Anyone who has permission to view this release will see all the comments, as you would expect, as if everyone were on a single logical server.

Who cares? This architecture has the technical and legal advantages. The main advantage of technology lies in the fault-tolerant mechanism This is an important fault-tolerant system that every office should have. If any of the pods are down, this will not cause any other downtime. The system survives, and even expects, the segmentation of the network. Here are some interesting political hints-for example, if you're in a country where you can't access Facebook and Twitter on an external network, your pod will still be running locally and connected to other people in your country, even if you can't access the outside.

so that's the architecture of the system. Let's take a look at this architecture from a single pod.

 

This is a Rails application Each pod is a ruby on Rails application, with a database at the back end, originally MongoDB. In a way, this codebase is a ' typical ' rails application-it has a visual and programmable UI, some Ruby code, and a database. But in other ways, it is by no means typical. so that's the code part. Let's consider what kind of data we have stored.

 

> I don't think the meaning of the word is what you think it means all photos from RUBYFRIENDS.C Om. Thanks to Matt Rogers, Steve Klabnik, Nell Shamrell, Katrina Owen, Sam Livingston-grey, Josh susser, Akshay khole, Pradyumna Dandwate and Hephzibah Watharkar's contribution to #rubyfriends!

Why you should not use MongoDB