так можно затестить только как сторонний FDW ходит из постгреса в mysql

)

Всмысле?

в смысле что это не будет походже на реальную работу на постгресе

Я вижу это себе так: поднимаем постгре на отдельном сервере, с помощью fdw подключаем его к продовской базе. Далее на отдельном сервере выкатываем ветку с приложением которое настроено на постгре, и перенаправляем на этот апстрим 1-10% запросов.

@schors есть же скрипты для перегонки из одной субд в другую, зачем себя так терзать ?

http://pgloader.io/ для этого очень хорош

в смысле что это не будет походже на реальную работу на постгресе

С точки зрения производительности согласен, но можно еще потестить логическую совместимость запросов, ошибки и т.д.

@schors есть же скрипты для перегонки из одной субд в другую, зачем себя так терзать ?

есть да? да просто странно это. вроде стандарты какие-то были. но это риторический вопрос. я думал может я пропрустил что

@chebotarevp и утыкаемся в сеть до мускуля. и медленность самого враппера

Я вижу это себе так: поднимаем постгре на отдельном сервере, с помощью fdw подключаем его к продовской базе. Далее на отдельном сервере выкатываем ветку с приложением которое настроено на постгре, и перенаправляем на этот апстрим 1-10% запросов.

там все хорошо пока запросы будут select * from table where id = 42

okay.jpg

https://wiki.postgresql.org/wiki/Converting_from_other_Databases_to_PostgreSQL

есть да? да просто странно это. вроде стандарты какие-то были. но это риторический вопрос. я думал может я пропрустил что

mysql, как бы сказать помягче, игнорирует многие стандарты. Скрипты часто сбоят, особенно на крупных проектах. Мне тут предстоит 300гб mysql конвертировать на днях, я распишу свои мытарства

неистово плюсую

@not_logan чем перегонять базу думаете ?

изучаем варианты как раз. скрипты конвертации дампа не вариант - дамп полностью калечится. PGLoader предварительно показал очень плохую производительность

https://github.com/mihailShumilov/mysql2postgresql

я бы вот это советовал

неработоспособно. Во-первых одноядерный (и зависает). Во-вторых он нам дамп сломал

О_О

у нас база во-первых сложная, во-вторых - большая

у вас видимо какая-то специфичное использование мускуля.

это не большая бд...

мы перегоняли и большие базы

Так что странно что ломается.

xx: интересно, а это полное задротство - подключать сейвы игры к системе контроля версий?

И снапсшоты

xx: интересно, а это полное задротство - подключать сейвы игры к системе контроля версий?

PITR вам в помощь http://postgrespro.ru/doc/continuous-archiving.html

xx: интересно, а это полное задротство - подключать сейвы игры к системе контроля версий?

есть шанс, что не сработает

есть шанс, что не сработает

Ну так всегда можно на другую ревизию откатить

xx: интересно, а это полное задротство - подключать сейвы игры к системе контроля версий?

Это круто! Почему я до такого не додумался

А зачем сейвы хранить в скв если можно и так сделать несколько разных сейвов в меню?

сделай так в bloodborne, плиз)

А зачем сейвы хранить в скв если можно и так сделать несколько разных сейвов в меню?

Вдруг потрутся, диск умрёт. А ты такой хоп и из гитхаба слил.

Вот у меня вчера появилась аналогичная идея - свое CV закачать на гитхаб в маркдауне. Коллеги могут делать пулл-реквесты со скиллами.

а еще можно маркет сейвов с разными ачивками =)

все придумано до нас

Была какая-то либа на питоне вроде бы, которая умела из markdown резюме выдавать pdf, html, etc. И в интернет это показывать.

resume.github.com

боян же

А я не знал, неплохо

что-то он скрытые данные не юзает https://resume.github.io/?MechanisM ну вроде и хорошо

раз уж тут все знают что такое системы контроля версий и гитхаб, кто-нибудь пишет модульные тесты для хранимок, есть CI, что используете, что нравится, что не нравится ?

Не пишем хранимки любой ценой, используем jenkins

Не пишем хранимки любой ценой, используем jenkins

два чая этому господину

Который по пушу в гитхаб начинает перемывать код разными анализаторами и тестировщиками

поддерживаю - не пишем хранимки и еще не используем триггеры)

Что же делать тем кто активно их использует ? :)

Что же делать тем кто активно их использует ? :)

страдать

боюсь другого ответа вы тут не получите

страдать

от чего же ?

Зачем страдать ? некоторые тестят через автотесты Cucember

Очевидно что хранимки и триггеры немогут использвать те кто использует готовые ORM, просто потому что им это не удобно

И что нельзя от них избавиться? Обычно это экономия на спичках. Типа запилили код который работает в виде хранимки поближе к базе, побыстрее на 3% получилось. Но зато ни отлаживать ни поддерживать все это сил нет никаких.

ну в принципе это код. Сценарий простой - выкачиваем исходники, накатываем миграции - далее запускаем сценарий тестов. 1. Запрлняем БД 2. Тест 3. Чистим БД

Зачем страдать ? некоторые тестят через автотесты Cucember

страдать прийдется от отладки. В принципе если у вас "тупое" приложение - делайте базу просто с нуля

можно вообще кластер под тесты создавать и по результатам - убивать его обратно

кукумбер-то тут зачем?) я понимаю для e2e тестов - а вот в БД

@chebotarevp я сторонник использования хранимок и некотрого Data Layer "API" в частности

@chebotarevp я сторонник использования хранимок и некотрого Data Layer "API" в частности

каждому гвоздю - свой молоток. Лично я использую базу как "тупое" хранилище и всю логику стараюсь выносить в приложения. Кто-то делает наоборот. Главное - не пытаться усидеть на двух стульях - падать будет больно

@dbalakov а в чем проблема то ? взял функцию фходные данные выходные получил какой то результат

ну, есть plpgunit и pgtap, делаю свой "велосипед" для CI вот и интересуюсь )

проблем нет - просто он не нужен, имхо

И что нельзя от них избавиться? Обычно это экономия на спичках. Типа запилили код который работает в виде хранимки поближе к базе, побыстрее на 3% получилось. Но зато ни отлаживать ни поддерживать все это сил нет никаких.

е если не на 3%, а на 300% ?

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

Есть просто вещи которые быстро запилить не получится на стороне приложения, либо породит сотни тысяч запросов.

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

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

вот тут полностью согласен - только луше без хранимок - PG умный - можно всегда собрать хитрый запрос и DAO должен в этом помогать

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

е если не на 3%, а на 300% ?

Надо только конкретные случаи смотреть, в общем виде не могу ответить.

не всегда это можно, есть CTE конечно, но когда это вываливается в 200-400 строк ... то не проще ли обернуть в SQL функцию ?

не проще - у меня эти строчки генеряться в рантайме зачастую

это пока вы в их производительность не уперлись, а потом будете выводить...

Надо только конкретные случаи смотреть, в общем виде не могу ответить.

Если ускорение на 300%, но этот код может править лишь один деспотичный дбашник => bus factor=1 => риск для бизнеса.

тогда уж DBDшник

Если ускорение на 300%, но этот код может править лишь один деспотичный дбашник => bus factor=1 => риск для бизнеса.

PL/pgSQL вроде как очень прост

“это пока вы в их производительность не уперлись, а потом будете выводить...” - производительность чего?

выполнения запроса...

парсера/оптимизатора

Все языки +- одинаковые и тьюринг-полные, но это же не делает разработку проще. И на PLpgSQL можно такого наворотить что ничего не понятно будет. Уж лучше на питоне писать встроенные хранимки.

plpython это не хранимки ?

А почему тригеры не писать?

Все языки +- одинаковые и тьюринг-полные, но это же не делает разработку проще. И на PLpgSQL можно такого наворотить что ничего не понятно будет. Уж лучше на питоне писать встроенные хранимки.

нет, оно там работает не как декларативный sql , а как апп внутри бд

вопрос не к тому что можно натворить, а к тому насколько ты близко находишься к бд

и иногда изнутри сделать многие вещи сделать дешевле по времени.

А почему тригеры не писать? неочевидное поведение БД - где-то у тебя создание сущности (например) на хранимке, где-то в коде, где-то в триггере сложно отлавливать из-за чего тормозит и прочее

У меня были кейсы когда из 1-2 минут выполнения запросов пачками, это оптимизировалось до 20-100ms на стороне базы.

ну у меня был кейс когда оптимизация дала 2 порядка

больше чем в 100 раз

больше чем в 100 раз

мы знаем )

я уже понял, что в этом чате можно было не уточнять)

и иногда изнутри сделать многие вещи сделать дешевле по времени.

Ну ладно, может просто привести ряд примеров? А то так глядишь и я перейду в стан сторонников хранимок.

Извините, это потребует включения в тематику, а тут вступит в силу NDA

но возьмите массовые операции наподобие ленты в вк

как пример

ии какая там хранимка?)