Комментарии 37
Спасибо за перевод.
Не понятно, зачем надо было резко переключаться, можно было две системы некоторое время держать и делать мягче. Но это конечно дело вкуса.
Не понятно, зачем надо было резко переключаться, можно было две системы некоторое время держать и делать мягче. Но это конечно дело вкуса.
Это как продолжение 2009 – 2019 челленджа.
2009: Ребята, го все на Монго!
2019: Как перейти с Монго на Постгрес.
2009: Ребята, го все на Монго!
2019: Как перейти с Монго на Постгрес.
Хотел написать тоже самое, потому что так явственно нахлынул флешбек с хабра образца года 2011 когда я впервые читал про МонгоДб :).
С 2009 года Постгрес очень сильно шагнул вперед. И это очень хорошо, т.к. его разработчики следят за всеми новыми веяними и имплементируют полезные фишки. Вроде того же JSON/JSONB
Жаль, что не дали никакого сравнения производительности и удобства до и после миграции.
Да, сравнение производительности, конечно, было бы приятным бонусом. Но в данном контексте им, судя по всему, была важна не столько скорость, сколько простота и дешевизна поддержки. По скорости на монгу они не жаловались:)
У нас жалуются: несколько миллионов записей и система еле поворачивается. Я свой проект сразу начал на PostgreSQL и JSONB.
>Я свой проект сразу начал на PostgreSQL и JSONB
Господа фанаты (или работники?) Постгреса, вы пожста придумывайте не настолько смешные аргументы. Уж что что, а скорость это конёк Монги. Если не делать откровенно глупых вещей.
А Слон из РСУБД практически самый медленный. И JSONB ему не помог.
Господа фанаты (или работники?) Постгреса, вы пожста придумывайте не настолько смешные аргументы. Уж что что, а скорость это конёк Монги. Если не делать откровенно глупых вещей.
А Слон из РСУБД практически самый медленный. И JSONB ему не помог.
Я не выдумываю, а говорю то, что есть. А вот у вас вызывающее неверная информация.
>Я не выдумываю, а говорю то, что есть. А вот у вас вызывающее неверная информация.
Вызывающе безапелляцеонный комментарий :) Отвечать по существу не вижу смысла.
Вызывающе безапелляцеонный комментарий :) Отвечать по существу не вижу смысла.
Каков привет таков ответ ;)
Я в инете тоже видел всякие весёлые бенчмарки, где слон рвёт монгу.
Особой веры им нет, т.к. там рисуют какие-то астрономические insert rate-ы в духе 80к записей в сек.
У Монги я такое постоянно вижу из коробки. Но для реляционной субд это какая-то фантастическая хрень, как JDBC-драйвер не разгоняй. Что из Слона, что из Оракла удавалось выжимать 8-10к и хоть умри.
А по факту Монго надо сравнивать с РСУБД+ORM, а там вообще больше 500 INSERT в сек не выжмешь.
SQL Loader ораклячий и copy не предлагать, это абсолютно неудобоваримо для программера.
На мегабайтных JSONинах Монга раз в 10 быстрее.
Ещё Слон медленный и при работе с индексом. Была задача фильтровать загружаемые данные unique index -ом, на 300млн записей, когда уже в ОЗУ индекс не лез, Монго опять была в разы быстрее.
Особой веры им нет, т.к. там рисуют какие-то астрономические insert rate-ы в духе 80к записей в сек.
У Монги я такое постоянно вижу из коробки. Но для реляционной субд это какая-то фантастическая хрень, как JDBC-драйвер не разгоняй. Что из Слона, что из Оракла удавалось выжимать 8-10к и хоть умри.
А по факту Монго надо сравнивать с РСУБД+ORM, а там вообще больше 500 INSERT в сек не выжмешь.
SQL Loader ораклячий и copy не предлагать, это абсолютно неудобоваримо для программера.
На мегабайтных JSONинах Монга раз в 10 быстрее.
Ещё Слон медленный и при работе с индексом. Была задача фильтровать загружаемые данные unique index -ом, на 300млн записей, когда уже в ОЗУ индекс не лез, Монго опять была в разы быстрее.
Откуда такие бредовые цифры не знаю. Бартунову здесь как-то больше веришь, чем не известному троллю. Как я сказал, в нашей компании монга на несколько млн записей еле поворачивается при чтении, для постгреса это вообще не проблема.
>в нашей компании монга на несколько млн записей еле поворачивается при чтении
Свою голову надо иметь, а не на Бартунова ссылаться. И руки не в Ж, чтобы не было «монга на несколько млн записей еле поворачивается при чтении». У меня на 2 терабайта в самой большой базе и миллиард++ документов. Средний find отрабатывает за пару милисекунд.
Свою голову надо иметь, а не на Бартунова ссылаться. И руки не в Ж, чтобы не было «монга на несколько млн записей еле поворачивается при чтении». У меня на 2 терабайта в самой большой базе и миллиард++ документов. Средний find отрабатывает за пару милисекунд.
>сколько простота и дешевизна поддержки
Из статьи складывается впечатление, что там не очень умный человек решение принимал и просто из принципа решил себе уши отморозить. Зачем вообще платный саппорт? Качали бы свои кадры.
То, что у Постгреса в эксплуатации очень многое делается вручную, из того, что в Монге почти/полностью автоматическое это аксиома.
Из статьи складывается впечатление, что там не очень умный человек решение принимал и просто из принципа решил себе уши отморозить. Зачем вообще платный саппорт? Качали бы свои кадры.
То, что у Постгреса в эксплуатации очень многое делается вручную, из того, что в Монге почти/полностью автоматическое это аксиома.
Зачем вообще платный саппорт? Качали бы свои кадры.
Разные способы ведения бизнеса.
На западе, для любого зрелого бизнеса (хотя наверно не только на Западе, а вообще для любого зрелого бизнеса) очевидно, что с операционным риском — ключевая ИТ-система от которой зависит основной бизнес должна работать, что-то надо делать. И ответ почти всегда — это прозрачный саппорт от надежной конторы.
>для любого зрелого бизнеса очевидно, что с операционным риском — ключевая ИТ-система от которой зависит основной бизнес должна работать, что-то надо делать
Ну, наша контора платиновый партнер Маздая, ИТ бюджет в год просто астрономический. 10к рабочих станций на маздае, порядка 1000 своих серверов на маздае (MSSQL, шарепоинт и остальной мусор ). Админы упорно грызут этот кактус, саппортеры тоже. Проблем с обновлениями пресс (известный косяк винды), проблем с обновлением рабочих станций пресс (поменять XP на 7, потом на 10 очень трудозатратно), в итоге ещё полно мест где ХР стоит.
«прозрачный саппорт от надежной конторы» налицо. Платятся миллионы маздаю за воздух вместо того, чтобы увеличить штат на 50% и взять покомпетентнее народ. Который например сможет linux обслуживать. Выгода будет. Просто она не выгодна никому.
Ну, наша контора платиновый партнер Маздая, ИТ бюджет в год просто астрономический. 10к рабочих станций на маздае, порядка 1000 своих серверов на маздае (MSSQL, шарепоинт и остальной мусор ). Админы упорно грызут этот кактус, саппортеры тоже. Проблем с обновлениями пресс (известный косяк винды), проблем с обновлением рабочих станций пресс (поменять XP на 7, потом на 10 очень трудозатратно), в итоге ещё полно мест где ХР стоит.
«прозрачный саппорт от надежной конторы» налицо. Платятся миллионы маздаю за воздух вместо того, чтобы увеличить штат на 50% и взять покомпетентнее народ. Который например сможет linux обслуживать. Выгода будет. Просто она не выгодна никому.
А что у малазийской конторы есть в качестве альтернативы?
Написать свою ОС для десктопов?
Свою БД?
Свой SP?
Лучший не значит хороший, лучший запросто может быть «из двух плохих, один чуть менее плохой».
Написать свою ОС для десктопов?
Свою БД?
Свой SP?
Лучший не значит хороший, лучший запросто может быть «из двух плохих, один чуть менее плохой».
>у малазийской конторы
Ви это о чём?
>прозрачный саппорт от надежной конторы
Кстати, надежный саппорт у Слона это кто? Я так понял ПостгресПро это чуть ли не 3 чела, которые почти всё рабочее времязанимаются впариваниемездят по конференциям. Цитрус был, да всплыл. :)
Уж Монго inc на надежную контору намного больше похожи. Что там у них с Guardian не срослось уже никогда не узнаем, но не факт, что клиент адекватен.
В целом, повторюсь, подход Яндекса (при всём неуважении к яндексу) наиболее адекватный, может и платный саппорт куплен, но есть и свои эксперты по Слону.
Ви это о чём?
>прозрачный саппорт от надежной конторы
Кстати, надежный саппорт у Слона это кто? Я так понял ПостгресПро это чуть ли не 3 чела, которые почти всё рабочее время
Уж Монго inc на надежную контору намного больше похожи. Что там у них с Guardian не срослось уже никогда не узнаем, но не факт, что клиент адекватен.
В целом, повторюсь, подход Яндекса (при всём неуважении к яндексу) наиболее адекватный, может и платный саппорт куплен, но есть и свои эксперты по Слону.
;) где-то там мне привиделась Малайзия…
т.е. если вы новостной портал, или сеть стоматологических клиник, или сеть пиццерий, то вам как Яндексу нужны суровые парни шарящие в сорсах постгреса?
т.е. если вы новостной портал, или сеть стоматологических клиник, или сеть пиццерий, то вам как Яндексу нужны суровые парни шарящие в сорсах постгреса?
>суровые парни шарящие в сорсах постгреса
Вы передергиваете или и вправду считаете, что надо в сорцах СУБД ковыряться, чтобы быть экспертом по этой СУБД? Получается, что по MSSQL и Oracle вообще нет экспертов?
По своему опыту скажу, что для «сеть стоматологических клиник», «сеть пиццерий» и «новостной портал» вообще любая СУБД пойдет и на новые грабли (на которые никто до них не наступил) они не наступят с вероятностью 99.99%. Оставшийся 0.01% решится бэкапами и сменой/апгрейдом версии.
Вы передергиваете или и вправду считаете, что надо в сорцах СУБД ковыряться, чтобы быть экспертом по этой СУБД? Получается, что по MSSQL и Oracle вообще нет экспертов?
По своему опыту скажу, что для «сеть стоматологических клиник», «сеть пиццерий» и «новостной портал» вообще любая СУБД пойдет и на новые грабли (на которые никто до них не наступил) они не наступят с вероятностью 99.99%. Оставшийся 0.01% решится бэкапами и сменой/апгрейдом версии.
Я подозреваю тяжело сравнить производительность self-hosted mongo на своих VDS и Database as Service Postgres.
Хотя какие то ощущения должны быть и возможно они почти правда
Хотя какие то ощущения должны быть и возможно они почти правда
А причина миграции случайно не изменение лицензии MongoDB?
Интересно что поддержки не умеют обслуживать больших клиентов. OpsManager не смог помочь жирному клиенту. Хотя наверняка оно того стоило. Или могло стоить.
Мы так же умудрялись обжигаться на жирных клиентах. Их надо суппортить по другому. Только заранее о деньгах договориться, а обычно они не против платить.
Мы так же умудрялись обжигаться на жирных клиентах. Их надо суппортить по другому. Только заранее о деньгах договориться, а обычно они не против платить.
Через несколько лет ждем пост в стиле Uber'a «как Guardian мигрировал обратно на MongoDB»
Неизвестный автор, который даже в оригинале статьи не указан, почему-то тактично промолчал про архитектуру кластеров БД.
Мы теряли по крайней мере два месяца времени инженеров в год на управление БД.
Если у них было шардирование в mongo, и на её поддержу уходило до 2 месяцев в год, то сколько времени они тратят на поддержку шардирования в postgres? А write concern как осуществляется? Двайвера postgres до сих пор ничего не умеют же.
И если у них все нормально работало в собственном ДЦ, то почему все резко стало плохо при переезде на AWS? И при чем тут необходимость написания сотни скриптов? Mongodb до факапов накатывали руками? Или брали консталтинг? :|
Странненько (ц)
Большое спасибо, статья реально очень интересная. Очередной отличный пример внедрения PostgreSQL.
Но чтение немного омрачило:
простите, что? Имеется в виду, наверное, «отложенное» шифрование данных, когда система ничем другим не занята? Или что? Допускаю, что попросту пока нет аналогичной терминологии на русском.
Фраза звучит совершенно не по-русски.
Но чтение немного омрачило:
Шифрование в состоянии покоя.
простите, что? Имеется в виду, наверное, «отложенное» шифрование данных, когда система ничем другим не занята? Или что? Допускаю, что попросту пока нет аналогичной терминологии на русском.
По счастью, далеко не весь он хранится на сайте — всего за какие-то последние пару десятков лет
Фраза звучит совершенно не по-русски.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Миграция с Mongo на Postgres: опыт газеты The Guardian