Всё верно, но мы верим, что постепенно FOSS вытесняет проприетарный софт — и это неспроста. Плюсы сильно перевешивают минусы. Прежде всего, всегда можно понять, как именно что работает — и иногда исправить проблему, не дожидаясь вендора, или же добавить то, что проприетарный вендор никак не сделает. Мне лично никогда не хватает документации закрытого софта, которым активно пользуюсь, и всегда хочется залезть в код, чтобы понять нюансы поведения.
Спасибо вам за обзор, MG88! Было очень интересно узнать о реальном опыте с Actifio (главный конкурент Delphix — оба решения мы держим в радаре и видно, что они ориентируются исключительно на крупные компании), в картинках
Удивило, что клонирование занимает ~15 минут. Вот как раз тут Database Lab явно выигрывает — мы очень постарались, чтобы клон поднимался и был готов к работе именно за секунды. В итоге это открывает возможности привоза таких БД в CI-контекст и это очень важно — получаем автоматизацию тестирования, частые тесты (например, изменений схемы БД), лучшее покрытие ими и качество разработки. Я думаю, что в будущем все компании к этому придут так или иначе.
Мы явно интересуемся и занимаемся близкими темами — был бы рад познакомиться и пообщаться; если взаимно, пинганите меня на nik@postgres.ai.
Один из возможных вариантов — повреждение данных, приводящее к сбою чекпоинта,
надо мониторить логи на предмет ошибок. Там запросто может быть видна причина, почему не проходят чекпоинты.
И вообще, логи Постгреса мониторить больше — было бы круто (как мы неоднократно обсуждали). Начать хотя бы с FATAL-ов. Да хотя бы даже сегфолты отлавливать и алёртить про них.
Ну и осталось ещё один шаг в рассуждениях сделать, чтобы понять, что раз ORM никак не помогает в оптимизации, то она, наоборот, мешает (затрудняет доступ к реальному SQL, часто производя ту самую неотформатированную, малопредсказуемую и малоуправляемую лапшу, о которой уже была речь выше).
Думаю, тут мы уже всё прояснили и копать больше некуда.
Ага, «вычисляемый атрибут». MySQL? Теперь я ничего не имею против того, что вы не любите хранимки и плохо меня понимаете. Подождите ещё несколько лет, пока их, а также транзакционный DDL, недостатки поддержки целостности данных (типа stackoverflow.com/questions/2115497/check-constraint-in-mysql-is-not-working) допилят до нормального состояния. В MySQL 8 и свежих MariaDB дела с некоторыми из этих вещей уже сильно лучше, советую обновиться.
А лучше переезжайте уже на Постгрес, чтобы понять, что такое нормальные хранимки, поддержка целостности, транзакционность DDL, больше современных фич стандартного SQL.
Код каждого объекта — в отдельном файле, конечно же в git. В качестве системы миграций — sqitch.org (или другая, есть много разных со своими плюсами-минусами. Только обязательно что-то выбрать надо — ничего страшного и стыдного нет, что вы ещё это не сделали, все через это когда-то проходили). Для версионирования хорошо помогают схемы (каждая версия — в отдельной схеме). Также по этим темам полезно послушать доклады Яндекса, Авито и других крупных компаний. Много чего можно найти тут: www.youtube.com/playlist?list=PL6sRAkPwcKNnwScnpKomNXechZQ3WZe1j
Отматываем чуть назад и ждём обоснований ваших прошлых утверждений. Напоминаю:
> А эксперт по оптимизации ORM скажет ровно обратное :-)
Вопрос: Я всегда с удовольствием готов изучать что-то новое.
Расскажите, что это за зверь такой.
> Да ровно то же самое, только в другом месте…
Вопрос: А чего и как он там оптимизирует, не имея нормальных средств для диагностики (статистика, explain) и собственно оптимизации (индексы, параметры СУБД, БД и её объектов)?
Верно. Тут ключевое даже не временные таблицы или CTE, а RTT — сетевая сложность. Хранимка даёт возможность отработать всё на сервере с использованием индексов и алгоритмов СУБД и выдать уже краткий результат без лишнего бегания туда-сюда.
Что касается рефакторинга. Мне немного сложно понять, о чём тут речь, т.к. я много лет в tmux+vi и не понимаю, о какой IDE тут речь и о каких её средствах.
Но как-то похоже на то, что подразумевается, что код хранимки — это что-то такое, что где-то там запрятано в недрах БД. Это, конечно, не так (а если так — это беда и так делать нельзя). Хранимка — это обычный код, должен быть в git, версионироваться и нормально рефакториться. Другое дело, что, может быть, «find usages» вашей IDE пока не поддерживают plpgsql (а может, поддерживают? доступные плагины смотрели?).
Вы только что описали стандартный сценарий, в котором вся идея ORM – асбтрагироваться от SQL и «ненавистной базаданщины» — сводится на нет.
Да, именно так обычно и происходит при росте нагрузки и проблемах с производительностью — SQL-лапша, созданная в недрах ORM, шевелит волосы у DBA и, чтобы снизить энтропию, запрос фиксируется или начинается нормальная работа по оптимизации. Завод по производству (ORM) со всей его дурной мощью вдруг становится не нужен, программист получает нормально отформатированный и отдаженный SQL (или хранимку! об этом я и говорил изначально — её отлаживать проще, когда нужно ехать, а не «шашечки») и вся роль этой лапшефабрики сводится к дёрганию метода query(..) или аналога, а такой метод есть и в самом драйвере вашего любимого языка к СУБД.
Есть много статей на тему «почему ORM – зло», наблюдаю их лет 15 ежегодно. Тема очень, очень и оченьхоливарная, но в целом сводится к тому, что лучше тратить время на изучение SQL, чем на штуку, которая позволяет якобы от него отойти.
На самом деле, если рассуждать дальше, PostgREST и подобные прокладки — в целом тоже похожее зло. Но всё же чуть меньшее, потому что:
меньше степеней свободы (сложнее отсрелить себе ноги, используя какую-нибудь ООП-ориентированную конструкцию, трансляция GET/POST/PATCH/PUT в SQL гораздо более примитивная вещь, чем ORM),
поощряется изучение SQL так или иначе — когда определяете вьюшки, вы испольузете SQL и это проще отлаживать,
аналогично с хранимками, чем больше их используете, тем глубже понимаете работу БД и делаете вещи более оптимально, SQL внутри PL/pgSQL – абсолютно родное и естественное тело (var1 := 0; – это на самом деле select 0 into var1;. А как легко и приятно писать штуки типа if (select count(1) from blabla) > 0 then ... !).
Какой-то не особо пока известный науке зверь получается.
А чего и как он там оптимизирует, не имея нормальных средств для диагностики (статистика, explain) и собственно оптимизации (индексы, параметры СУБД, БД и её объектов)?
Это было актуально ещё когда многие здесь комментирующие ходили в начальную школу. Посмотрите, как реализована логика в любой АБС-ке. Код на PL/SQL не считается злом, почему он должен считататься злом на PL/pgSQL?
Крупные, очень крупные проекты не боятся хранимок. Их боится в основном те, кто в целом СУБД боится.
Есть мнение (и не только моё), что хранимки-то как раз *гораздо* проще оптимизировать, чем ORM. Спросите любого эксперта по оптимизации SQL, что ему будет удобнее — SQL в хранимке или ActiveRectord и прочие.
Спасибо вам за обзор, MG88! Было очень интересно узнать о реальном опыте с Actifio (главный конкурент Delphix — оба решения мы держим в радаре и видно, что они ориентируются исключительно на крупные компании), в картинках
Удивило, что клонирование занимает ~15 минут. Вот как раз тут Database Lab явно выигрывает — мы очень постарались, чтобы клон поднимался и был готов к работе именно за секунды. В итоге это открывает возможности привоза таких БД в CI-контекст и это очень важно — получаем автоматизацию тестирования, частые тесты (например, изменений схемы БД), лучшее покрытие ими и качество разработки. Я думаю, что в будущем все компании к этому придут так или иначе.
Мы явно интересуемся и занимаемся близкими темами — был бы рад познакомиться и пообщаться; если взаимно, пинганите меня на nik@postgres.ai.
Николай Самохвалов,
Postgres.ai Founder
надо мониторить логи на предмет ошибок. Там запросто может быть видна причина, почему не проходят чекпоинты.
И вообще, логи Постгреса мониторить больше — было бы круто (как мы неоднократно обсуждали). Начать хотя бы с FATAL-ов. Да хотя бы даже сегфолты отлавливать и алёртить про них.
Ну и осталось ещё один шаг в рассуждениях сделать, чтобы понять, что раз ORM никак не помогает в оптимизации, то она, наоборот, мешает (затрудняет доступ к реальному SQL, часто производя ту самую неотформатированную, малопредсказуемую и малоуправляемую лапшу, о которой уже была речь выше).
Думаю, тут мы уже всё прояснили и копать больше некуда.
Это ответ на вопрос «как разместить в git».
А лучше переезжайте уже на Постгрес, чтобы понять, что такое нормальные хранимки, поддержка целостности, транзакционность DDL, больше современных фич стандартного SQL.
Код каждого объекта — в отдельном файле, конечно же в git. В качестве системы миграций — sqitch.org (или другая, есть много разных со своими плюсами-минусами. Только обязательно что-то выбрать надо — ничего страшного и стыдного нет, что вы ещё это не сделали, все через это когда-то проходили). Для версионирования хорошо помогают схемы (каждая версия — в отдельной схеме). Также по этим темам полезно послушать доклады Яндекса, Авито и других крупных компаний. Много чего можно найти тут: www.youtube.com/playlist?list=PL6sRAkPwcKNnwScnpKomNXechZQ3WZe1j
Отматываем чуть назад и ждём обоснований ваших прошлых утверждений. Напоминаю:
> А эксперт по оптимизации ORM скажет ровно обратное :-)
Вопрос: Я всегда с удовольствием готов изучать что-то новое.
Расскажите, что это за зверь такой.
> Да ровно то же самое, только в другом месте…
Вопрос: А чего и как он там оптимизирует, не имея нормальных средств для диагностики (статистика, explain) и собственно оптимизации (индексы, параметры СУБД, БД и её объектов)?
Что касается рефакторинга. Мне немного сложно понять, о чём тут речь, т.к. я много лет в tmux+vi и не понимаю, о какой IDE тут речь и о каких её средствах.
Но как-то похоже на то, что подразумевается, что код хранимки — это что-то такое, что где-то там запрятано в недрах БД. Это, конечно, не так (а если так — это беда и так делать нельзя). Хранимка — это обычный код, должен быть в git, версионироваться и нормально рефакториться. Другое дело, что, может быть, «find usages» вашей IDE пока не поддерживают plpgsql (а может, поддерживают? доступные плагины смотрели?).
Вы только что описали стандартный сценарий, в котором вся идея ORM – асбтрагироваться от SQL и «ненавистной базаданщины» — сводится на нет.
Да, именно так обычно и происходит при росте нагрузки и проблемах с производительностью — SQL-лапша, созданная в недрах ORM, шевелит волосы у DBA и, чтобы снизить энтропию, запрос фиксируется или начинается нормальная работа по оптимизации. Завод по производству (ORM) со всей его дурной мощью вдруг становится не нужен, программист получает нормально отформатированный и отдаженный SQL (или хранимку! об этом я и говорил изначально — её отлаживать проще, когда нужно ехать, а не «шашечки») и вся роль этой лапшефабрики сводится к дёрганию метода query(..) или аналога, а такой метод есть и в самом драйвере вашего любимого языка к СУБД.
Есть много статей на тему «почему ORM – зло», наблюдаю их лет 15 ежегодно. Тема очень, очень и очень холиварная, но в целом сводится к тому, что лучше тратить время на изучение SQL, чем на штуку, которая позволяет якобы от него отойти.
На самом деле, если рассуждать дальше, PostgREST и подобные прокладки — в целом тоже похожее зло. Но всё же чуть меньшее, потому что:
var1 := 0;– это на самом делеselect 0 into var1;. А как легко и приятно писать штуки типаif (select count(1) from blabla) > 0 then ...!).Какой-то не особо пока известный науке зверь получается.
А чего и как он там оптимизирует, не имея нормальных средств для диагностики (статистика, explain) и собственно оптимизации (индексы, параметры СУБД, БД и её объектов)?
Я всегда с удовольствием готов изучать что-то новое.
Расскажите, что это за зверь такой.
это не я решил, а весь мир решил и уже давно. Похоже, я недостаточно ясно эту мысль донёс.
На моих глазах целая команда рубистов заменялась одним человеком, готовым писать SQL и коллекции тестов в postman/newman.
Что именно с производительностю? PostgREST ведь stateless, запускайте его на N машинах, часть из которых направляйте на read-only реплики.
Как я понимаю, проблема была в Постгресе самом? Что именно тормозило-то?
Крупные, очень крупные проекты не боятся хранимок. Их боится в основном те, кто в целом СУБД боится.
madlib.apache.org
Загибаться БД может по массе причин. В основном это монструозные бездумные запросы от ORM-ок. Хватит уже валить на хранимки и хватит их бояться.