From 3c213355213c9e2d5e02230d03a66fffc3229c23 Mon Sep 17 00:00:00 2001 From: Yann Esposito Date: Mon, 26 Oct 2015 18:04:45 +0100 Subject: [PATCH] talk about mongdb data loss --- articles/Two_years_with_clojure.html | 1 + articles/Two_years_with_clojure.md | 4 ++++ 2 files changed, 5 insertions(+) diff --git a/articles/Two_years_with_clojure.html b/articles/Two_years_with_clojure.html index b0895ba..2ff20a9 100644 --- a/articles/Two_years_with_clojure.html +++ b/articles/Two_years_with_clojure.html @@ -97,6 +97,7 @@

Nice until you reach the hard limit. At that time it was, Mongo 2.6. So there was a Database Level Lock.

Yes, I repeat: Database Level Lock. Each time you read or write, nobody could read or write at the same time.

And even using very expensive clusters, these can’t handle the hard limits.

+

The result, when the MongoDB was asked to write and read a lot (even using batches), you start to lose datas. If you can write them, let’s destroy them. Furthermore the code dealing with tweet insertion in MongoDB was really hard to manipulate. No correct error handling. In the end, data loss…

There is a lot to say about MongoDB and a lot was already written. But the main point is yes. MongoDB couldn’t be trusted nor used for intensive data manipulation.

Now, the situation might have changed. But there are better tools for the same job.

When we arrived, many client had already paid. And many product should come to life.

diff --git a/articles/Two_years_with_clojure.md b/articles/Two_years_with_clojure.md index 99a3d2b..f0fe10a 100644 --- a/articles/Two_years_with_clojure.md +++ b/articles/Two_years_with_clojure.md @@ -104,6 +104,10 @@ Each time you read or write, nobody could read or write at the same time. And even using very expensive clusters, these can't handle the hard limits. +The result, when the MongoDB was asked to write and read a lot (even using batches), you start to lose datas. +If you can write them, let's destroy them. +Furthermore the code dealing with tweet insertion in MongoDB was really hard to manipulate. No correct error handling. In the end, data loss... + There is a lot to say about MongoDB and a lot was already written. But the main point is yes. MongoDB couldn't be trusted nor used for intensive data manipulation.