Daevaorn
Я уверен, что у меня останется снимок данных на какой их предыдущих моментов времени и при этом он будет консистентен. То что я потеряю те данные которые не смогли записаться в момент аварии, то это очевидно.
Эти 2 предложения описывают 2 взаимоисключающих факта: данные консистентны и часть данных потеряна :)
К тому же мы ведь немного о другом: о durability, а не о consistancy. В применении к серверам и БД - это ведь разные вещи. Гм, я даже не могу сходу придумать что значит consistancy для сервера.
Как вы переводите durability? И durability чего имеет ввиду: сервера, данных в базе в рамках ACID, системы в целом?
Я считаю, что невозможно обеспечить durability системы исключительно программными средствами. Тот, кто утверждает обратное, либо рекламщик, либо поверивший рекламщику. По крайней мере до первого серьезного аппаратного сбоя :)
Daevaorn
MongoDB же кораптит базу совсем и не хочет её воспринимать после аварии.
Уточните, пожалуйста, вы имеете ввиду, что она не работает сразу после запуска как Couch (а требует проверки и, при необходимости, ремонта базы) или что портит безвозвратно данные?
Daevaorn
Потому что даже продакшен окружения не всегда распределено. И в большинстве случаев это так.
Мы все еще о больших системах или о разных? :)
Вектор развития MongoDB определен достаточно четко ее разработчиками. И новые инструменты направлены
Тогда это ошибка проектировщика системы. Как можно использовать MongoDB, которая изначально
из коробки, с настройками по-умолчанию (это важное замечание, т.к. возможность на самом деле есть) не обеспечивает single server durability!
Хочется single server durability - берите Couch и надейтесь, что ваше железо вас не подведет.
А если при этом нужна еще и дополнительная функциональность, то почему об этом не подумали заранее?
Daevaorn
Вы расшифровали эту цифру?:-) Это десять или сто тысяч?
Неужели так трудно? Реальных вариантов то всего два ;)
Daevaorn
Говорить о нагрузках можно когда есть число rps, r/w ratio и т.п.
Если речь идет о работающем продукте - да, если же речь идет только о проектировании (перечитайте первый пост - этот как раз наш случай), то указанные данные по количеству клиентов и сфере деятельности - соц. сеть - следует трактовать как “большое кол-во данных, которые попадают в систему неравномерно с вероятными непостоянными пиковыми нагрузками”. И этого достаточно. Необходимой производительности системы для обеспечения пиковых rps, r/w ratio и т.п. будем добиваться в рамках готовой стратегии наращивания мощности.