Mongodb - действительно ли проблемы надежности являются значительными все еще?
У меня есть несколько sqlite dbs (я сказал бы что приблизительно 15 ГБ), со строками приблизительно на 1 м всего - так не супер большой. Я смотрел на mongodb, и выглядит довольно легким работать с, особенно если я хочу попытаться сделать некоторую основную обработку естественного языка на документах, которые составляют базы данных.
Я никогда не работал с монго, в прошлом не должен был бы учиться с нуля (будет работать в Python). После поиска с помощью Google вокруг немного, я столкнулся со многими несколько ужасающими историями о ре Mongodb. надежность. Это - все еще основная проблема? В уплотнении я, конечно, сохраню резервные копии sqlite, но я не должен постоянно восстанавливать свои базы данных монго.
Просто удивление, какое повреждение данных вида выпускает людей, на самом деле недавно стояло с монго? Действительно ли это - большое беспокойство?
Спасибо!
5 ответов
Да, долговечность - большая проблема в монго. Вы должны использовать наборы репликации в mongodb для обеспечения надежности (вам нужно как минимум 2 машины), иначе вы можете потерять до последней минуты, например, при сбое питания. В mongo нет единой долговечности сервера, но, насколько я знаю, он будет разработан для 1.7-1.8. После сбоя вам необходимо восстановить базу данных вручную, и операция rapair может занять несколько часов, если ваши данные большие. Нет транзакции или кислоты, поэтому он не подходит для электронной коммерции или банковского приложения.
Вы не должны использовать разрабатываемые версии mongo (нечетные номера версий, такие как 1.3.x, 1.5.x, 1.7.x, являются версиями для разработки), и вы предпочитаете использовать 64-битные операционные системы. Если вы покопаетесь в статьях о монго, посвященных катастрофам, в большинстве случаев источником проблемы являются эти две статьи.
CouchDB, Cassandra и postgresql обладают высокой надежностью (fsync составляет 10 миллисекунд по умолчанию в cassandra и postgresql), поэтому все они имеют надежность на одном сервере.
Если вам нужна невероятно простая масштабируемость, отказоустойчивость и балансировка нагрузки; cassandra - лучший вариант, но с плохими параметрами запроса. Неисправные узлы могут уйти и вернуться через некоторое время, без проблем, система автоматически восстанавливается.
РЕДАКТИРОВАТЬ: mongo 1.8 шел с журналированием (обеспечивает надежность), но это не настройка по умолчанию. Также посмотрите http://news.ycombinator.com/item?id=2684423
С уважением,
Сердар Ирмак
Как уже говорили другие, MongoDB сейчас не имеет устойчивости на одном сервере. К счастью, настроить многоузловую репликацию очень просто . Вы даже можете установить вторую машину в другом центре обработки данных, и данные будут автоматически реплицироваться на нее в реальном времени!
Если запись должна завершиться успешно, вы можете заставить Mongo не возвращаться после вставки / обновления до тех пор, пока эти данные не будут реплицированы на n ведомых. Это гарантирует, что у вас будет не менее n копий данных. Наборы реплик позволяют добавлять и удалять узлы из кластера на лету без каких-либо значительных усилий; просто добавьте новый узел, и он автоматически синхронизирует копию данных. Удалите узел, и кластер перебалансируется. Он очень хорошо разработан для использования на нескольких машинах с несколькими узлами, работающими параллельно; это предпочтительная настройка по умолчанию, по сравнению с чем-то вроде MySQL, который ожидает, что одна гигантская машина будет выполнять свою работу, и вы можете затем соединить подчиненные устройства, когда вам нужно масштабировать. Это другой подход к хранению и масштабированию данных, но он очень удобен, если вы потратите время на то, чтобы понять разницу в предположениях и о том, как построить архитектуру, которая использует его сильные стороны.
«MongoDB поддерживает автоматизированную архитектуру сегментирования, позволяющую горизонтальное масштабирование на нескольких узлах». - source Таким образом, вам нужно запустить несколько узлов для балансировки и поддержки аварийного переключения. Если вы хотите запустить единственный экземпляр, который не выйдет из строя при внезапном отключении питания, вам понадобится что-то, поддерживающее ACID , например couchDB. При этом я использую mongo на работе в течение месяца, и он не сломался у меня, однако мы скоро переходим на кластер из 6 узлов.
Долговечность
В товарах используются разные подходы. к прочности. CouchDB - это "только аварийный" дизайн, где БД может прекратить в любое время и остаться последовательный. MongoDB возьмёт другой подход к прочности. На машине сбой, тогда один запускал бы RepairDatabase () операция, когда запускается снова (аналогично MyISAM). MongoDB рекомендует использовать репликацию - LAN или WAN - для истинной надежности, которую может данный сервер навсегда быть мертвым. Обобщить: CouchDB лучше долговечен, когда используя один сервер без репликация.
Цитата с официального сайта mongodb.org .
Mongo не обладает свойствами ACID, в частности долговечностью. Таким образом, вы можете столкнуться с проблемами, если процесс не завершится чисто или машина потеряет мощность. Вы должны реализовать резервное копирование и избыточность, чтобы справиться с этим.
Я не вижу проблемы, если у вас есть те же данные в резервных копиях sqlite. Вы всегда можете пополнить свои базы данных MongoDb. Заправка займет всего несколько минут.