Python-сообщество

o7412369815963
это просто придерание.

Тогда весь этот тред придирки к тому или иному решению.

o7412369815963
гарантии коуча ни чего не стоят когда сервер накроеться (совсем, краш винта и т.п.), хотя можно что-б коуч сохранял данные сразу на перфокарты, тогда надежность будет поболее, но производитльность пострадает.

Так не о том речь. При нашествии инопланетян, которые заберут все сервера, конечно, данные мы скорей всего потеряем при использовании любого хранилища.

o7412369815963
а монго гарантирует целостность данных при “целостноти” (стаблильности) оборудования. и этой гарантии для многих случаев хватает.

А вот это-то как раз и не так. Процесс MongoDB может умереть по одной лишь ему ведомой причине и потащить за собой базу. В этом и проблема. Причем, ещё год назад с этим было её хуже и случалось чаще, что вообще вычеркивало его применение в серьезных проектах.
Понятно, что политика multi-server durability это осознанный выбор авторов, но он очень сильно сужает сферу применения. А самое главное, они это, скажем так, не очень афишируют, подставляя тем самым особо доверчивых разработчиков.

zheromo
Коуч же в этом плане надежен и все данные оказываются на диске.

Неужели? А я так уверен, что данные оказываются на диске только в том случае, если включена прямая запись в контроллере RAID-массива и отключена оптимизация в ОС.

Daevaorn
Способ не важен. Важно то что другие хранилища эту гарантию дают, в том числе CouchDB.

Опять: неужели? А если у вас отключилось питание, то вы, значит, уверены, что ваши данные будут записаны на диск? Или все же это заивисит от аппаратной натройки?

Daevaorn
Скорость я имел ввиду.

Извините, если дал повод так думать. Я не считаю скорость главной хар-кой, но скорость - важная характеристика.

Daevaorn
Причем тут начинающие программисты?

Я не смог придумать более точного названия для людей, которые для разработки и тестирования используют конфигурацию, отличающуюся от продакшн-конфигурации не только производительностью, но и архитектурой.
Согласитесь, нелепо тестировать систему на своей рабочей машине, если эта система предполагает наличие, например, шарда или репликации в реальном времени.

Daevaorn
Большинство проектов в интернете живет на одной машине и им этого хватает, потому что они не высоко-нагруженные.

Напоминаю, что мы рассматриваем в этой теме как раз высоконагруженные системы, цитата автора топика: “в светлом будущем - 10 0000 клиентов”.

Lexander
неужели? А если у вас отключилось питание, то вы, значит, уверены, что ваши данные будут записаны на диск? Или все же это заивисит от аппаратной натройки?

Я уверен, что у меня останется снимок данных на какой их предыдущих моментов времени и при этом он будет консистентен. То что я потеряю те данные которые не смогли записаться в момент аварии, то это очевидно.

MongoDB же кораптит базу совсем и не хочет её воспринимать после аварии. Это плохо.

Lexander
Я не смог придумать более точного названия для людей, которые для разработки и тестирования используют конфигурацию, отличающуюся от продакшн-конфигурации не только производительностью, но и архитектурой.
Согласитесь, нелепо тестировать систему на своей рабочей машине, если эта система предполагает наличие, например, шарда или репликации в реальном времени.

Опять не о том. Single-server durаbility нужна не только для этого. Потому что даже продакшен окружения не всегда распределено. И в большинстве случаев это так.

Lexander
Напоминаю, что мы рассматриваем в этой теме как раз высоконагруженные системы, цитата автора топика: “в светлом будущем - 10 0000 клиентов”.

Вы расшифровали эту цифру?:-) Это десять или сто тысяч? Это что за “клиенты”, которые зарегистрированны и приходят раз в год на сервис, или это в месяц/день/час/минуту/секунду? Что они делают и какую активность генерят? Да и потом, если это даже сто в день, то это не очень и высокие нагрузки ещё. Так что это число просто ни о чём.
Говорить о нагрузках можно когда есть число rps, r/w ratio и т.п.

Daevaorn
MongoDB же кораптит базу совсем и не хочет её воспринимать после аварии. Это плохо.

Александр, а Вы случаем не это имеете ввиду - http://jira.mongodb.org/browse/SERVER-1614 - вроде как пофиксили не так давно.

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 и т.п. будем добиваться в рамках готовой стратегии наращивания мощности.

Lexander

zheromo
Коуч же в этом плане надежен и все данные оказываются на диске.

Неужели? А я так уверен, что данные оказываются на диске только в том случае, если включена прямая запись в контроллере RAID-массива и отключена оптимизация в ОС.

Еще стоит обязательно учесть воздействие космических лучей и нейтрино, а то глядишь чего…

Когда я выбирал между монго и коучем, монго я отмел сразу по причине того что после НОРМАЛЬНОЙ перезагрузки (это был виндовс) либо терялась часть данных, причем за большой промежуток времени либо портилась сама база, может если и НЕ ПЕРЕЗАГРУЖАТЬ компьютер, все было бы хорошо, но …

zheromo
… (это был виндовс) …

тогда все прояснилось… =) шутка

у нас в отделе, 4 вин-хоста с монгой и 3 линукс-хоста, ещё нигде ничего не пропало.
а на боевой машине периодический делается дамп базы (за 3 сек), для надежности

Отредактировано (Окт. 8, 2010 18:29:50)

zheromo
Еще стоит обязательно учесть воздействие космических лучей и нейтрино, а то глядишь чего…

То ли вы здесь смайлик забыли, то ли не в теме.

zheromo
Когда я выбирал между монго и коучем, монго я отмел сразу по причине того что после НОРМАЛЬНОЙ перезагрузки (это был виндовс) либо терялась часть данных

Боюсь вас огорчить, но тут точно дело не в Mongo.

Странно, почему никто не вспоминает о Redis (с особенности в сравнении с Couch), Cassandra, VoltDB, Memcached или даже действительно редком у нас, но таким близким к Mongo по возможностям языка Tokyo Cabinet?

Отредактировано (Окт. 9, 2010 12:59:40)

Lexander
Странно, почему никто не вспоминает о Redis (с особенности в сравнении с Couch), Cassandra, VoltDB, Memcached или даже действительно редком у нас, но таким близким к Mongo по возможностям языка Tokyo Cabinet?

я классифицирую примерно так:
я редис и мемкеш отношу к быстрым но не большим базам, т.к. в первую очередь это ram базы.
кассандра по возможностям, что-то на подобие коуча.
Tokyo Cabinet возможности запросов чуть поболее, но она тормозная (относительно)
про VoltDB не слыхал

o7412369815963
Касаемо “тормозных” баз.
Знаете, наверное, все СУБД позволяют настройками добиться хранения наиболее часто востребованных данных в памяти.
Причем все производители СУБД в качестве бескомпромиссного самого быстрого решения предлагают хранить данные именно в памяти. Всех - это значит действительно всех, как NoSQL, так и реляционных СУБД.
Сервера с десятками гигабайт памяти - не проблема. У всех поставщиков серверов есть решения со 128 ГБ памяти.

Поэтому возникает закономерный вопрос,- что такое по вашему большая БД?

Отредактировано (Окт. 9, 2010 21:08:17)