Mongodb - проблемы надежности все еще значимы?

Question

У меня есть пара sqlite dbs (я бы сказал, около 15 ГБ), всего около 1 м строк - так что не очень большой.Я смотрел на mongodb, и с ним довольно легко работать, особенно если я хочу попробовать выполнить базовую обработку естественного языка для документов, составляющих базы данных.

Я никогда не работал с Mongoв прошлом не пришлось бы учиться с нуля (буду работать на питоне).Немного погуглив, я наткнулся на несколько ужасающих историй о Mongodb re.надежность.Это все еще главная проблема?Конечно, я сохраню резервные копии sqlite, но мне не придется постоянно восстанавливать базы данных mongo.

Просто интересно, с какими проблемами порчи данных люди сталкивались в последнее время с Mongo?Это большая проблема?

Спасибо!

Answer 1

Как уже говорили, MongoDB не обладает долговечностью на одном сервере. К счастью, очень просто настроить репликацию из нескольких узлов. Вы даже можете настроить второй компьютер в другом центре обработки данных и автоматически реплицировать данные на него в режиме реального времени!

Если запись должна завершиться успешно, вы можете заставить Mongo не возвращаться после вставки / обновления, пока эти данные не будут реплицированы на n ведомых. Это гарантирует, что у вас есть как минимум n копий данных. Наборы реплик позволяют добавлять и удалять узлы из вашего кластера на лету без какой-либо значительной работы; просто добавьте новый узел, и он автоматически синхронизирует копию данных. Удалите узел, и кластер перебалансирует себя. Он очень разработан для использования на нескольких машинах, причем несколько узлов работают параллельно; это предпочтительная настройка по умолчанию по сравнению с чем-то вроде MySQL, которая ожидает, что одна гигантская машина выполнит свою работу, с которой вы можете затем соединить подчиненных, когда вам нужно будет выполнить масштабирование. Это другой подход к хранению и масштабированию данных, но очень удобный, если вы потратите время на то, чтобы понять разницу в допущениях и узнать, как построить архитектуру, которая использует ее сильные стороны.

Answer 2

Да, долговечность - большая проблема в монго. Вы должны использовать наборы репликации в mongodb для долговечности (вам нужно как минимум 2 машины), в противном случае вы можете потерять до последней 1 минуты, например, при сбое питания. В Монго нет долговечности одного сервера, но, как я знаю, он будет разработан для 1.7-1.8. После сбоя вы должны восстановить базу данных вручную, и операция восстановления может занять часы, если ваши данные велики. Там нет транзакции или кислоты, поэтому он не подходит для электронной коммерции или банковского приложения.

Вы не должны использовать версии разработки mongo (нечетные номера версий, такие как 1.3.x, 1.5.x, 1.7.x - версии для разработчиков), и вы предпочитаете использовать 64-битные операционные системы. Если вы покопаетесь в статьях о стихийных бедствиях в Интернете о монго, источником проблемы в большинстве случаев являются эти два.

CouchDB, Cassandra и postgresql обладают высокой стойкостью (fsync по умолчанию составляет 10 миллисекунд в cassandra и postgresql), поэтому все они имеют стойкость на одном сервере.

Если вам нужна невероятно легкая масштабируемость, отказоустойчивость и балансировка нагрузки; Кассандра самая лучшая, но с плохими вариантами запросов. Неисправные узлы могут исчезнуть и вернуться через некоторое время, без проблем, система автоматически восстанавливает систему.

РЕДАКТИРОВАТЬ: Mongo 1.8 поставляется с журналированием (обеспечивает долговечность), но это не настройка по умолчанию. Также взгляните на это http://news.ycombinator.com/item?id=2684423

С уважением,

Сердар Ирмак

Answer 3

"MongoDB поддерживает архитектуру автоматического разделения, позволяющую горизонтальное масштабирование между несколькими узлами." - source Таким образом, вам нужно запустить несколько узлов для балансировки и поддержки отработки отказа. Если вы хотите запустить один экземпляр, который не выйдет из строя при внезапном отключении питания, вам нужно что-то, поддерживающее ACID , например couchDB. Это говорит о том, что я использую Монго на работе в течение месяца, и он не сломался, однако мы скоро переходим к кластеру из 6 узлов.

Долговечность

В продуктах используются разные подходы долговечности. CouchDB является дизайн "только для сбоя", где БД может прекратить в любое время и оставаться последовательны. MongoDB взять другой подход к долговечности. На машине сбой, тогда бы запустить операция repairDatabase (), когда запуск снова (аналогично MyISAM). MongoDB рекомендует использовать репликацию - либо LAN, либо WAN - для истинной долговечности, поскольку данный сервер может навсегда быть мертвым. Подвести итоги: CouchDB лучше при долговечности, когда используя один сервер без репликация.

Цитата с официального сайта mongodb.org .

Answer 4

Mongo не обладает свойствами ACID, в частности, долговечностью. Таким образом, вы можете столкнуться с проблемами, если процесс не завершается полностью или аппарат теряет питание Вы должны реализовать резервное копирование и избыточность, чтобы справиться с этим.

Answer 5

Я не вижу проблемы, если у вас есть те же данные в резервных копиях sqlite. Вы всегда можете пополнить свои базы данных MongoDb. Пополнение займет всего несколько минут.