Хороший вопрос, правильный, для этого у Линстеда есть определение "транзакционного линка" (transaction link, т.е. линка у которого нет сроков действия), но поскольку мы не только про банк, то тут может быть понятие историчности, скажем, я наблюдал при реализации DV для крупного поставщика, когда строка в заказе без сторно "пропадала" задним числом в течении месяца, или появлялась новая строка. Или скажем менеджер по заказу менялся несколько раз, если есть хаб заказ и хаб сотрудние и линк менеджер по заказу, и тут надо поддерживать историчность для этого линка, т.е. если бы мы получили отчет с 5 по 10 сентября, то менеджер был бы один, а если 11 сентября то другой.
Вообще говоря, весь DV про то, чтобы получить отчет за август, как он выглядел 8 сентября, сегодня 16 октября, когда прошла масса изменений задним числом. Если нет изменений задним числом, и отчет нужен только как он выглядит сегодня, то DV вообще не нужен.
ER диаграмма ужасная, линии и объекты пересекаются и не видно, что от чего зависит.
Самое интересное в DV это линки, и по ним можно понять умеет автор в DV или нет. Любые транзакции, факты, проводки - это линк, а не хаб, в данной схеме h_order_detail - лишний, и должен быть линком.
Ну и тема историчности линков в статье не раскрыта, спойлер в самом линке не должно быть периода действия. Так же не раскрыта тема сателлита на линк.
Собственно самое ценное, это коэффициенты по слоям, и они сильно должны зависеть от выбранного способа моделирования данных и от того сколько показателей нужно взять из исходных данных. Без них статья особого смысла не имеет.
Основаная проблема с временными таблицами в PosgreSQL в том что это постоянное создание/удаление набора файлов, что достаточно дорого, и влияет на скорость. Скажем на том же PgConf про этот рассказывает каждый первый кто мигрует с Oracle или Ms Sql. Доходит до того, что народ делает не логируемую постоянную таблицу исполтзует ее как временнумю (заводит в ней поле с id временной сессии и асинхронной очисткой) и это бысттее.
Ну и да распухание pg_class.
Но опять же это зависит от интенствности использования, как любой инструмент требует вдумчивого применения и понимание сильных и слабых сторон.
В целом автор подсветил актуальную проблему: разделение и переход на 3х звенку и дальше микро сервисы выделил класс разработчиков которые работают с БД и при этом не умеют этого делать. Автор явно пишет:
приходится вносить изменения в код без полного понимания, надеясь, что всё заработает
при этом ссылаясь на:
Со временем, когда отцы-основатели данной хранимой процедуры покидают компанию, вместе с ними уходит и понимание того, как всё это должно функционировать. Новым сотрудникам, чтобы внести небольшие изменения, приходится собирать информацию по крупицам от тех, кто хоть как-то взаимодействовал с этим чудом инженерной мысли.
Но это касается любого кода. То же самое можно сказать о коде на С#, Java или Python, кто мешает в компании где работает автор, реализовать процессы документирования и сопровождения написанного кода, передачу знаний при увольнении и поддержания нужных компетенций?!
На мой взгляд проблема в другом, разработчики просто не умеют работать с БД, не могут прочитать код хранимой процедуры. Не владеют средствами отладки. Не владеют фреймворками БД для тестирования (а они есть). То что пишет автор про структуру серверов и не возможность тестирования кроме ничего боли и сочувствия из-за не правильной организации работы не вызывает. (разработчиков хранимых процедур легко можно изолировать теми же схемами и отдельными БД в PostgreSQL, чуть ли на каждом PgConf есть пару докладов про авторазвертывание копии БД для разработчика и тестов, я не говорю уже про CI/CD где можно просто еженощно проводить сборку и тестирование, и специфичные возможности отдельных СУБД)
К сожалению такой подход работы с БД встречается все чаще и чаще и если для фронтенда эта проблема решилась выделением отдельного класса разработчиков, никто же не говорит что функции в JS не нужны, то с другой стороны (БД) такого разделения не произошло или произошло не во многих компаниях, зачастую за разработку в БД и оптимизацию запросов отвечает DBA который НЕ РАЗРАБОТЧИК, если вообще выделеный DBA есть, а это не просто DevOps/сисадмин.
Что касается миграции - да это проблема, но с другой стороны не думайте, что если Вы в своем проекте не использовали хранимые процедуры - то перейдя на другую БД у Вас все будет хорошо. На проекте с БД в несколько десятков GiB да все будет ок. Но на других размерах у Вас будут проблемы, так как в разных БД по разному реализована изоляция записи и чтения, разная стоимость блокировок и транзакций, разная стоимость привычных Вам механизмов (например, в PostgreSQL гораздо медленнее временные таблицы чем в MS SQL или Oracle). Не говоря уже о других более мелких особенностях.
В итоге разработчик действительно либо не лезет в хранимки и делает все на том что он реально умеет и понимает, либо должен владеть БД так же, как своим основным языком разработки. Разделение я думаю тут проходит от нагрузки и размера БД.
С моей точки зрения, хранимки это инструмент который имеет право на жизнь и существенно облегчает работу с БД и повышает производительность, приведу несколько примеров:
Пакетирование нескольких SQL, например, EL-T - гораздо выгоднее разработчикам пакетировать несколько SQL по осуществлению одной сложной трансформаций, чем корячится с этим в Airflow или NiFi, такой код логически скомпонован, более эффективен и легко читается, чем набор процессоров или DAG (или Python код с вызовом SQL)
Работа с временными таблицами, с учетом, что временные таблицы живут в одной сессии, а трехзвенка использует connection pooling, то гарантировать выполнение последовательных SQL и жизнь временной таблицы проще в хранимке (естественно я знаю и другие способы, но так проще)
Использование хранимых функций в запросах, например, функция дает остаток на счете на заданное время, а далее эти остатки агрегируются. Без такой логики вместо простого запроса нужно затащить всю эту логику и данные в уровень приложения и там делать агрегацию, либо писать монструозный запрос.
Упрощение сложных запросов и разбиение их на части внутри хранимки (например, для стабилизации планов запросов), при этом хранимая функция может быть источником для других запросов. Т.е. select из хранимой функции
Обеспечения единого API работы с БД если приложений работы с БД несколько, тут спорно и не микросервисно, но реализация в БД базовых примитивов, при том что с БД работает 10 разных сервисов может помочь, и я такие реализации видел
Источник хранения и тестирования технологических скриптов, выполнение специфичных БД ориентированных действий - например, создание новых партиций по расписанию, перестроение индексов и т.п. Гораздо проще прямо иметь в БД проверенные и отлаженные процедуры, чем хранить SQL скрипты где то еще и путаться в их версиях.
Автор в любом случае молодец, что поднял такую больную тему, но все же рекомендую подняться чуть выше и понять, что каждый инструмент имеет смысл и свое назначение. Если в мире автора назначения инструменту нет, то не значит, что его нет совсем.
Тут скорее вопрос внешняя разработка или внутренняя. При внутренней - как Вы описали. При внешней скорее как в статье. Я бы не рискнул делать разработку на заказ, без подготовленных и согласованных заказчиком бизнес требований и технического задания и без документирования каждого шага. Иначе, потом сдавать заколеблешься.
У меня вопрос, как в анекдоте, а что в армии один солдат "бизнес-аналитик"?
Сам процесс построения описан корректно. Но где разделение по ролям? Где архитектор? Где системный аналитик?
Имхо, бизнес аналитик заканчивается на этапе информационного обследования и построение бизнес требований, а дальше дело архитектора, системных аналитиков и разработчиков.
Конечно, тут вопрос терминологии видов аналитиков, но как минимум архитектор должен быть на проекте точно.
Слишком поверхностно, новичок не поймет, так как не разжевано, а тем кто понимает и не надо.
Было бы не плохо: 1. привести сводную таблицу в которой видно различия в подходах 2. взять конкретный пример, и показать как он реализуется в разных подходах.
"Кроме того, объединение нескольких таблиц может приводить к блокировке большого объема данных на длительное время, что затруднит обновление данных другими операциями. "
Это что за такие блокировки? В Oracle читатели не блокируют никого.
Согласен со всеми предыдущими постами, дайте планы.
По факту в PL/SQL вариантами вы руками сделали Nested Loop, какие соединения в планах первых двух запросов.
И главное последний вариант:
where event_name = l_rec.event_name and (attribute_1 like '%XX_IF_ERRORS%' or attribute_1 is NULL)
второй вариант:
(upper(p.attribute_1) like '%' || t2.log_name || '%' or p.attribute_1 is NULL)
Т.е. upper есть в одном запросе и нет в другом, кроме того в первом запросе константа.
Итого: запросы не равнозначны, построен Nested Loop (на SQL это сделать можно, и непонятно почему не сделан), без планов статья смысла не имеет.
Хороший вопрос, правильный, для этого у Линстеда есть определение "транзакционного линка" (transaction link, т.е. линка у которого нет сроков действия), но поскольку мы не только про банк, то тут может быть понятие историчности, скажем, я наблюдал при реализации DV для крупного поставщика, когда строка в заказе без сторно "пропадала" задним числом в течении месяца, или появлялась новая строка. Или скажем менеджер по заказу менялся несколько раз, если есть хаб заказ и хаб сотрудние и линк менеджер по заказу, и тут надо поддерживать историчность для этого линка, т.е. если бы мы получили отчет с 5 по 10 сентября, то менеджер был бы один, а если 11 сентября то другой.
Вообще говоря, весь DV про то, чтобы получить отчет за август, как он выглядел 8 сентября, сегодня 16 октября, когда прошла масса изменений задним числом. Если нет изменений задним числом, и отчет нужен только как он выглядит сегодня, то DV вообще не нужен.
ER диаграмма ужасная, линии и объекты пересекаются и не видно, что от чего зависит.
Самое интересное в DV это линки, и по ним можно понять умеет автор в DV или нет. Любые транзакции, факты, проводки - это линк, а не хаб, в данной схеме h_order_detail - лишний, и должен быть линком.
Ну и тема историчности линков в статье не раскрыта, спойлер в самом линке не должно быть периода действия. Так же не раскрыта тема сателлита на линк.
Для какой модели данных? Камбал, Инмон, DataVault?
Собственно самое ценное, это коэффициенты по слоям, и они сильно должны зависеть от выбранного способа моделирования данных и от того сколько показателей нужно взять из исходных данных. Без них статья особого смысла не имеет.
Угу, такое у многих болит... я был по обе стороны баррикад и в целом разрыв очень большой, а как появились ORM стал вообще огромный
Основаная проблема с временными таблицами в PosgreSQL в том что это постоянное создание/удаление набора файлов, что достаточно дорого, и влияет на скорость. Скажем на том же PgConf про этот рассказывает каждый первый кто мигрует с Oracle или Ms Sql. Доходит до того, что народ делает не логируемую постоянную таблицу исполтзует ее как временнумю (заводит в ней поле с id временной сессии и асинхронной очисткой) и это бысттее.
Ну и да распухание pg_class.
Но опять же это зависит от интенствности использования, как любой инструмент требует вдумчивого применения и понимание сильных и слабых сторон.
Наверное хайп из-за кликбейтного заголовка.
В целом автор подсветил актуальную проблему: разделение и переход на 3х звенку и дальше микро сервисы выделил класс разработчиков которые работают с БД и при этом не умеют этого делать. Автор явно пишет:
при этом ссылаясь на:
Но это касается любого кода. То же самое можно сказать о коде на С#, Java или Python, кто мешает в компании где работает автор, реализовать процессы документирования и сопровождения написанного кода, передачу знаний при увольнении и поддержания нужных компетенций?!
На мой взгляд проблема в другом, разработчики просто не умеют работать с БД, не могут прочитать код хранимой процедуры. Не владеют средствами отладки. Не владеют фреймворками БД для тестирования (а они есть). То что пишет автор про структуру серверов и не возможность тестирования кроме ничего боли и сочувствия из-за не правильной организации работы не вызывает. (разработчиков хранимых процедур легко можно изолировать теми же схемами и отдельными БД в PostgreSQL, чуть ли на каждом PgConf есть пару докладов про авторазвертывание копии БД для разработчика и тестов, я не говорю уже про CI/CD где можно просто еженощно проводить сборку и тестирование, и специфичные возможности отдельных СУБД)
К сожалению такой подход работы с БД встречается все чаще и чаще и если для фронтенда эта проблема решилась выделением отдельного класса разработчиков, никто же не говорит что функции в JS не нужны, то с другой стороны (БД) такого разделения не произошло или произошло не во многих компаниях, зачастую за разработку в БД и оптимизацию запросов отвечает DBA который НЕ РАЗРАБОТЧИК, если вообще выделеный DBA есть, а это не просто DevOps/сисадмин.
Что касается миграции - да это проблема, но с другой стороны не думайте, что если Вы в своем проекте не использовали хранимые процедуры - то перейдя на другую БД у Вас все будет хорошо. На проекте с БД в несколько десятков GiB да все будет ок. Но на других размерах у Вас будут проблемы, так как в разных БД по разному реализована изоляция записи и чтения, разная стоимость блокировок и транзакций, разная стоимость привычных Вам механизмов (например, в PostgreSQL гораздо медленнее временные таблицы чем в MS SQL или Oracle). Не говоря уже о других более мелких особенностях.
В итоге разработчик действительно либо не лезет в хранимки и делает все на том что он реально умеет и понимает, либо должен владеть БД так же, как своим основным языком разработки. Разделение я думаю тут проходит от нагрузки и размера БД.
С моей точки зрения, хранимки это инструмент который имеет право на жизнь и существенно облегчает работу с БД и повышает производительность, приведу несколько примеров:
Пакетирование нескольких SQL, например, EL-T - гораздо выгоднее разработчикам пакетировать несколько SQL по осуществлению одной сложной трансформаций, чем корячится с этим в Airflow или NiFi, такой код логически скомпонован, более эффективен и легко читается, чем набор процессоров или DAG (или Python код с вызовом SQL)
Работа с временными таблицами, с учетом, что временные таблицы живут в одной сессии, а трехзвенка использует connection pooling, то гарантировать выполнение последовательных SQL и жизнь временной таблицы проще в хранимке (естественно я знаю и другие способы, но так проще)
Использование хранимых функций в запросах, например, функция дает остаток на счете на заданное время, а далее эти остатки агрегируются. Без такой логики вместо простого запроса нужно затащить всю эту логику и данные в уровень приложения и там делать агрегацию, либо писать монструозный запрос.
Упрощение сложных запросов и разбиение их на части внутри хранимки (например, для стабилизации планов запросов), при этом хранимая функция может быть источником для других запросов. Т.е. select из хранимой функции
Обеспечения единого API работы с БД если приложений работы с БД несколько, тут спорно и не микросервисно, но реализация в БД базовых примитивов, при том что с БД работает 10 разных сервисов может помочь, и я такие реализации видел
Источник хранения и тестирования технологических скриптов, выполнение специфичных БД ориентированных действий - например, создание новых партиций по расписанию, перестроение индексов и т.п. Гораздо проще прямо иметь в БД проверенные и отлаженные процедуры, чем хранить SQL скрипты где то еще и путаться в их версиях.
Автор в любом случае молодец, что поднял такую больную тему, но все же рекомендую подняться чуть выше и понять, что каждый инструмент имеет смысл и свое назначение. Если в мире автора назначения инструменту нет, то не значит, что его нет совсем.
Народ, по телекам Samsung решение для tpws не нашлось?
Я пробовал направлять на фильтрацию 443 udp - помогло на 1 день, вчера с утра перестало работать, пробовал запрещать 443 udp - не помогло.
В итоге ПК и андроиде - все работает, телек - нет.
Оно вчера работало идеально, сегодня перестало. Тут еще вопрос какой телек и какой провайдер.
Я думаю DPI отличается от провайдера к провайдеру.
Логика простая:
$SCRIPT $ARGS -запускает демона который курочит пакеты на 999 порту
а далее делаете сколько надо iptables -t nat -A PREROUTING -i br0 что бы отправить трафик по нужным портам и протоколам на обработку
у демона можно настроить список того что он обрабатывает через --hostlist $HOSTLISTFILE" , остальной трафик пойдет без изменений
Кусок скрипта про запуск:
SCRIPT=/jffs/zapret/tpws
PIDFILE=/var/run/tpws.pid
HOSTLISTFILE=/jffs/zapret/hostlist.txt
ARGS="--daemon --bind-addr 192.168.1.1 --port 999 --disorder --tlsrec=sni --split-pos=2 --pidfile $PIDFILE --hostlist $HOSTLISTFILE"
start() {if [ -f $PIDFILE ] && kill -0 $(cat $PIDFILE); then
echo 'Service TPWS is already running' >&2
return 1
fi
$SCRIPT $ARGS
iptables -t nat -A PREROUTING -i br0 -p tcp --dport 80 -j REDIRECT --to-port 999
iptables -t nat -A PREROUTING -i br0 -p tcp --dport 443 -j REDIRECT --to-port 999
iptables -t nat -A PREROUTING -i br0 -p udp --dport 443 -j REDIRECT --to-port 999
echo 'Started TPWS service'}
iptables -t nat -A PREROUTING -i br0 -p udp --dport 443 -j REDIRECT --to-port 999
Неа, VPN и обход DPI лечат, значит - блокируют
Если настроить на хосты TCP и UDP :
googlevideo.com
youtube.com
youtu.be
ytimg.com
youtube-ui.l.google.com
ytimg.l.google.com
ytstatic.l.google.com
youtubei.googleapis.com
То на компе и на телефоне работает.
Опции: --disorder --tlsrec=sni --split-pos=2
Телевизор Samsung перестал работать (вчера работал с теми же опциями)
Тут скорее вопрос внешняя разработка или внутренняя. При внутренней - как Вы описали. При внешней скорее как в статье. Я бы не рискнул делать разработку на заказ, без подготовленных и согласованных заказчиком бизнес требований и технического задания и без документирования каждого шага. Иначе, потом сдавать заколеблешься.
У меня вопрос, как в анекдоте, а что в армии один солдат "бизнес-аналитик"?
Сам процесс построения описан корректно. Но где разделение по ролям? Где архитектор? Где системный аналитик?
Имхо, бизнес аналитик заканчивается на этапе информационного обследования и построение бизнес требований, а дальше дело архитектора, системных аналитиков и разработчиков.
Конечно, тут вопрос терминологии видов аналитиков, но как минимум архитектор должен быть на проекте точно.
Слишком поверхностно, новичок не поймет, так как не разжевано, а тем кто понимает и не надо.
Было бы не плохо:
1. привести сводную таблицу в которой видно различия в подходах
2. взять конкретный пример, и показать как он реализуется в разных подходах.
"Кроме того, объединение нескольких таблиц может приводить к блокировке большого объема данных на длительное время, что затруднит обновление данных другими операциями. "
Это что за такие блокировки? В Oracle читатели не блокируют никого.
Согласен со всеми предыдущими постами, дайте планы.
По факту в PL/SQL вариантами вы руками сделали Nested Loop, какие соединения в планах первых двух запросов.
И главное последний вариант:
where event_name = l_rec.event_name and (attribute_1 like '%XX_IF_ERRORS%' or attribute_1 is NULL)второй вариант:
(upper(p.attribute_1) like '%' || t2.log_name || '%' or p.attribute_1 is NULL)Т.е. upper есть в одном запросе и нет в другом, кроме того в первом запросе константа.
Итого: запросы не равнозначны, построен Nested Loop (на SQL это сделать можно, и непонятно почему не сделан), без планов статья смысла не имеет.
Google rman trasportable tablespace
Не вопрос и в другую