Mongodb-可靠性问题是否仍然很重要? [英] Mongodb - are reliability issues significant still?

问题描述

我有几个sqlite数据库(大概是15GB)，总共约有100万行-所以不是很大.我正在查看mongodb，使用起来似乎很容易，尤其是当我想尝试对组成数据库的文档进行一些基本的自然语言处理时.

I have a couple of sqlite dbs (i'd say about 15GBs), with about 1m rows in total - so not super big. I was looking at mongodb, and it looks pretty easy to work with, especially if I want to try and do some basic natural language processing on the documents which make up the databases.

我过去从未与Mongo合作过，无需从头开始学习(将在python中工作).搜寻了一下之后，我遇到了一些有关Mongodb re的令人毛骨悚然的故事.可靠性.这仍然是一个主要问题吗?紧要关头，我当然会保留sqlite备份，但是我宁愿不必不断重建我的mongo数据库.

I've never worked with Mongo in the past, no would have to learn from scratch (will be working in python). After googling around a bit, I came across a number of somewhat horrific stories about Mongodb re. reliability. Is this still a major problem ? In a crunch, I will of course retain the sqlite backups, but I'd rather not have to reconstruct my mongo databases constantly.

只是想知道人们最近在Mongo上实际面对过什么样的数据损坏问题?这是一个大问题吗?

Just wondering what sort data corruption issues people have actually faced recently with Mongo ? Is this a big concern?

谢谢！

推荐答案

是的，在mongo中，持久性是一个大问题.您必须在mongodb中使用复制集以实现持久性(至少需要2台计算机)，否则，例如在电源故障时，您最多可以松散1分钟. mongo没有单一服务器的持久性，但据我所知它将针对1.7-1.8开发.崩溃后，您必须手动修复数据库，如果数据很大，则rapair操作可能要花费数小时.由于没有交易或苛刻的条件，因此不适合电子商务或银行应用程序.

Yes, durability is a big problem in mongo. You have to use replication sets in mongodb for durability (you need at least 2 machines), otherwise you can loose upto last 1 minute on a power fail for example. There is no single server durability in mongo, but it'll be developed for 1.7-1.8 as I know. After a crash you have to repair db manually and rapair operation may took hours if your data is large. There is no transaction or acid, so it's not suitable for an ecommerce or banking application.

您不应该使用mongo的开发版本(像1.3.x，1.5.x，1.7.x这样的奇数版本号是开发版本)，并且您更喜欢使用64位操作系统.如果您在网络上浏览有关mongo的灾难文章，则问题的根源在大多数情况下是这两个.

You should not use development versions of mongo (odd versiond number like 1.3.x,1.5.x,1.7.x are development versions) and you prefer to use 64 bit operating systems. If you digg into disaster articles on the web about mongo, the source of the problem is these two ones in most cases.

CouchDB，Cassandra和postgresql都具有很强的持久性(在cassandra和postgresql中，fsync默认为10毫秒)，因此它们都具有单服务器持久性.

CouchDB, Cassandra and postgresql all have strong durability (fsync is 10 milliseconds by default in cassandra and postgresql), so they all have single server durability.

如果您需要轻松实现可扩展性，容错能力和负载平衡； cassandra是最好的，但是查询选项很差.出现故障的节点可能会消失并在一段时间后恢复，这没问题，系统会自动修复.

If you need dead easy scalability, fault tolerance and load balancing; cassandra is the best, but with poor query options. Failing nodes may go away and come back after a period of time, no problem, system auto repairs itself.

编辑:mongo 1.8附带日记功能(允许持久性)，但这不是默认设置.还请看看此 http://news.ycombinator.com/item?id=2684423

mongo 1.8 came with journaling (allows durability) but it's not the default setting. Also take look at this http://news.ycombinator.com/item?id=2684423

此致

Serdar Irmak

Serdar Irmak

这篇关于Mongodb-可靠性问题是否仍然很重要?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！