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

Question

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

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

Просто интересно, какие проблемы с коррупцией данных, с которыми люди столкнулись недавно с Монго? Это большая проблема?

Спасибо!

Answer 1

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

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

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

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

EDIT: mongo 1.8 поставляется с журналом (позволяет прочность), но это не значение по умолчанию. Обратите также смотреть на это http://news.ycombinator.com/item?id=2684423

С уважением,

Сердар Ирмак

Answer 2

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

Answer 3

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

Прочность

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

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

Answer 4

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

Answer 5

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

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