А что делать, если озарения нет? Стоим курим? То что Вы пишите, это какой то бред, ну натворил ты за дофига денег по 12 часов в день пару лет. А потом что? Сможете продуктивно работать так лет 20-30? И задачу решать надо когда надо, а не когда будет творческое настроение и озарение. Разработчик должен быть выспавшийся и готовый к работе в рабочее время.
P.S. "Творцы нам тут нафиг не нужны ..." (С) Пелевин ;-)
У меня с утра самые свежие мозги, поэтому я обычно занимаюсь с утра большими и творческими задачами. А на мелочь и рутину оставляю 2-3 часа вечером, когда мозги уже не нужны.
Если начинать с мелочи и рутины, то она пожрет все. Тут главное, для себя определится, и вовремя остановится с большой задачей, когда наступает время рутины.
Но все конечно зависит от рода деятельности. Если ямы копать, то пофиг. А если программировать, то нет.
Ну и любая попытка планировать вызывает у меня уважение...
Вам платят за работу, если за субботу не платят, Вы не работаете
Вам платят за работу, если за будние платят, Вы работаете, не халявите
Начальник увидел, и сделал выводы, что Вы можете работать в субботу и в следующий раз придет, а что такого
Оно еще раз, я понимаю интересно, сам такой, но на перспективе 10-20 лет, эти переработки это взаймы у себя будущего, и поверьте возврат этого долга ой какой страшный.
Звучит как: ошибки в коде - зло. Но время от времени их надо делать, что уж тут, всего не предусмотришь.
Переработка по просьбе руководителя - это ошибка руководителя. Да ошибки бывают, да бывают форс-мажоры. Но, любая ошибка - это повод подумать как не повторить ее в дальнейшем, а не забить со словами "всё не предусмотришь ".
Собственно Вас минусуют именно за подход, а не за переработки...
Публикацию Вами результатов TPC-DS в описанном Вами формате безусловно приветствую и буду ждать.
Я прихожу на хабр за информацией. Ваша статья содержит цифры в отрыве о того как они получены и без объяснения почему. Какую информацию я должен вынести из статьи?! Что очередной вендор показал свою систему в выгодном свете?! Я таких тестов видел примерно от каждого первого вендора. Я даже не могу сделать выводы, о задачах где данные системы показывают свое превосходство и самое главное для меня, почему, как это следует из архитектуры систем?
Если для чтения и понимания статьи нужно запросить у Вас дополнительную информацию, то зачем мне такая статья.
Какова методика тестирования? Какая схема данных? Где SQL запросы? Где конфиг файлы систем? Были ли эксперты по тюнингу каждой системы? и т.п.
За такими цифрами должен лежать отчет на 100500 страниц, а так это просто не очень хорошо пахнущая самореклама как в анекдоте получается:
Старенький дедушка приходит к врачу: — Доктор, мне нужна ваша помощь, у меня проблемы с потенцией. Могу со своей бабкой только три раза в неделю. — И сколько ж вам лет, — спрашивает врач. — 85. — Так вы, голубчик, половой гигант, — изумляется доктор. — Но доктор, моему соседу тоже 85, и он рассказывает, что у них с бабкой секс ежедневно. — Голубчик, так вы тоже рассказывайте!
Про "не mvcc" хранилища давно слежу, и EDP пыталось, по zheap новостей уже лет 5 нет. Реально там скорее всего все упирается, в то что индексы не версионируются.
В Oracle undo управляемое зло, в PostgreSQL - MVCC не управляем, стандартная беда на фоне долгой транзакции регулярно меняется одна строка (например, остаток на счету кассы) и привет... в индексе на одну строку 100500 записей и столько же записаей в heap и оно быстро не лечится. В оракле у вас со snapshot to old слетит сам долгий запрос, в PostgreSQL раком встанет вся система.
Полностью согласен. Open Source в итоге приводит к двум вариантам:
внутри компании появляется "как бы вендор" который отвечает за сборку
выбирается вендор типа Postgres Pro
Оба варианта имеют свои плюсы и минусы ... но оба не бесплатные ( в первом случае ЗП и риски в случае ошибки или не вовремя закрытой уязвимости, во втором такая же модель оплаты как с Oracle)
В целом текст не своевременный. Я понимаю, что если не попадать под регулирование, Oracle "лучшая бесплатная СУБД" в России (как в 90х), но в целом серьезный бизнес все же хочет ТП, тот же Oracle не возможно использовать без патчей. Так что тут выбор в пользу Postgre SQL очевиден (опять же в пользу скорее вендорских решений, типа Postgre Pro), и все остальное пустое.
Если технически, на мой взгляд, 7 основных вопросов к PostgreSQL относительно Oracle если сравнивать:
1. Богомерзкий MVCC (vacuum, bloat, отсутствие версионирования в индексах)
2. Партиционирование (отсутствие глобальных индексов и все что за собой тянет, нет автосоздания партиций, плюс тормоза на большом количестве партиций)
3. Зависимости (dependicies). Тут можно спорить нужны хранимки или нет, но если используете те, то тут Oracle c механизмом зависимостей побеждает
4. Мониторинг - тут все просто, Oracle дает гораздо больше телеметрии (AWR, ASH, SQL Monitor) по сравнению с PostgreSQL, вплоть до контроля плана выполнения в реальном времени, да такое есть в Postgres Pro (но мы то тут про ванилу, а Postgres Pro не торопится такие фишки отдавать в Open Source).
5. Кэш запросов, оутлайны и хинты. В Oracle это есть и не возникает ситуация, когда на 50 Тб базе вдруг после очередного сбора статистики поехали планы.
6. Exadata - тут все просто, сопоставимого решения для Postgres SQL нет, оно можно вспомнить про Greenplum/Citus, но Exadata умеет в обе нагрузки OLTP и OLAP, а с PostgreSQL обе задачи не закрывает, тут надо бить решение на части.
7. Golden Gate - ничего сопоставимого нет от Open Source, Debezium - жалкое подобие и 10% от функционала и скорости.
Хороший вопрос, правильный, для этого у Линстеда есть определение "транзакционного линка" (transaction link, т.е. линка у которого нет сроков действия), но поскольку мы не только про банк, то тут может быть понятие историчности, скажем, я наблюдал при реализации DV для крупного поставщика, когда строка в заказе без сторно "пропадала" задним числом в течении месяца, или появлялась новая строка. Или скажем менеджер по заказу менялся несколько раз, если есть хаб заказ и хаб сотрудние и линк менеджер по заказу, и тут надо поддерживать историчность для этого линка, т.е. если бы мы получили отчет с 5 по 10 сентября, то менеджер был бы один, а если 11 сентября то другой.
Вообще говоря, весь DV про то, чтобы получить отчет за август, как он выглядел 8 сентября, сегодня 16 октября, когда прошла масса изменений задним числом. Если нет изменений задним числом, и отчет нужен только как он выглядит сегодня, то DV вообще не нужен.
ER диаграмма ужасная, линии и объекты пересекаются и не видно, что от чего зависит.
Самое интересное в DV это линки, и по ним можно понять умеет автор в DV или нет. Любые транзакции, факты, проводки - это линк, а не хаб, в данной схеме h_order_detail - лишний, и должен быть линком.
Ну и тема историчности линков в статье не раскрыта, спойлер в самом линке не должно быть периода действия. Так же не раскрыта тема сателлита на линк.
Собственно самое ценное, это коэффициенты по слоям, и они сильно должны зависеть от выбранного способа моделирования данных и от того сколько показателей нужно взять из исходных данных. Без них статья особого смысла не имеет.
А что делать, если озарения нет? Стоим курим?
То что Вы пишите, это какой то бред, ну натворил ты за дофига денег по 12 часов в день пару лет. А потом что? Сможете продуктивно работать так лет 20-30? И задачу решать надо когда надо, а не когда будет творческое настроение и озарение. Разработчик должен быть выспавшийся и готовый к работе в рабочее время.
P.S. "Творцы нам тут нафиг не нужны ..." (С) Пелевин ;-)
Ну это зависит от интересности досуга ;-)
Нее, так тоже не работает.
У меня с утра самые свежие мозги, поэтому я обычно занимаюсь с утра большими и творческими задачами. А на мелочь и рутину оставляю 2-3 часа вечером, когда мозги уже не нужны.
Если начинать с мелочи и рутины, то она пожрет все. Тут главное, для себя определится, и вовремя остановится с большой задачей, когда наступает время рутины.
Но все конечно зависит от рода деятельности. Если ямы копать, то пофиг. А если программировать, то нет.
Ну и любая попытка планировать вызывает у меня уважение...
Тут сразу три вещи:
Вам платят за работу, если за субботу не платят, Вы не работаете
Вам платят за работу, если за будние платят, Вы работаете, не халявите
Начальник увидел, и сделал выводы, что Вы можете работать в субботу и в следующий раз придет, а что такого
Оно еще раз, я понимаю интересно, сам такой, но на перспективе 10-20 лет, эти переработки это взаймы у себя будущего, и поверьте возврат этого долга ой какой страшный.
Ну да, я про это же.
Но нужно учится переключаться, иначе просто можно сгореть...
И не надо бежать тут же делать/проверять.
Звучит как: ошибки в коде - зло. Но время от времени их надо делать, что уж тут, всего не предусмотришь.
Переработка по просьбе руководителя - это ошибка руководителя. Да ошибки бывают, да бывают форс-мажоры. Но, любая ошибка - это повод подумать как не повторить ее в дальнейшем, а не забить со словами "всё не предусмотришь ".
Собственно Вас минусуют именно за подход, а не за переработки...
"Решение находится и в субботу " - это не повод тут же бежать его проверять. Пришла идея в нерабочее время, запиши, проверишь в рабочее.
Более того, часто замечал, что решение придумал вечером, не на работе, а утром обдумав нашел лучше, или нашел изъяны в старом.
Многие не понимают, что мы бежим не спринт, а марафон, и перерабатывая мы гробим здоровье и самое главное приучаем начальство, что так можно.
Да бывают авралы - авария, проблемы у клиента, последний этап внедрения, но это все должно быть учтено и компенсировано.
Публикацию Вами результатов TPC-DS в описанном Вами формате безусловно приветствую и буду ждать.
Я прихожу на хабр за информацией. Ваша статья содержит цифры в отрыве о того как они получены и без объяснения почему. Какую информацию я должен вынести из статьи?! Что очередной вендор показал свою систему в выгодном свете?! Я таких тестов видел примерно от каждого первого вендора.
Я даже не могу сделать выводы, о задачах где данные системы показывают свое превосходство и самое главное для меня, почему, как это следует из архитектуры систем?
Если для чтения и понимания статьи нужно запросить у Вас дополнительную информацию, то зачем мне такая статья.
Какова методика тестирования? Какая схема данных? Где SQL запросы? Где конфиг файлы систем? Были ли эксперты по тюнингу каждой системы? и т.п.
За такими цифрами должен лежать отчет на 100500 страниц, а так это просто не очень хорошо пахнущая самореклама как в анекдоте получается:
Старенький дедушка приходит к врачу:
— Доктор, мне нужна ваша помощь, у меня проблемы с потенцией. Могу со своей бабкой только три раза в неделю.
— И сколько ж вам лет, — спрашивает врач.
— 85.
— Так вы, голубчик, половой гигант, — изумляется доктор.
— Но доктор, моему соседу тоже 85, и он рассказывает, что у них с бабкой секс ежедневно.
— Голубчик, так вы тоже рассказывайте!
Ну там на диаграмме клубок связей, она не читабельна.
Если есть линк, то тогда вообще не понятно, зачем нужен h_order_detail. Все должно решаться линком.
Линк на линк не правильно согласен.
DV умеет и то и другое, в этом его и прелесть.
Как я писал основное это agile в разработке хранилища и версионность.
Не нужна версионность данных, можно сильно упростить и выкинуть сателлиты.
Тут просто они в списке очень избирательно представлены....
А так их десятки. Где тот же Postgres Pro, Areanadata?
А вот Астра есть...
Кто заплатил, тот в список и попал или как?
Той же Arenadata нет
Про "не mvcc" хранилища давно слежу, и EDP пыталось, по zheap новостей уже лет 5 нет. Реально там скорее всего все упирается, в то что индексы не версионируются.
В Oracle undo управляемое зло, в PostgreSQL - MVCC не управляем, стандартная беда на фоне долгой транзакции регулярно меняется одна строка (например, остаток на счету кассы) и привет... в индексе на одну строку 100500 записей и столько же записаей в heap и оно быстро не лечится. В оракле у вас со snapshot to old слетит сам долгий запрос, в PostgreSQL раком встанет вся система.
Полностью согласен. Open Source в итоге приводит к двум вариантам:
внутри компании появляется "как бы вендор" который отвечает за сборку
выбирается вендор типа Postgres Pro
Оба варианта имеют свои плюсы и минусы ... но оба не бесплатные ( в первом случае ЗП и риски в случае ошибки или не вовремя закрытой уязвимости, во втором такая же модель оплаты как с Oracle)
В целом текст не своевременный. Я понимаю, что если не попадать под регулирование, Oracle "лучшая бесплатная СУБД" в России (как в 90х), но в целом серьезный бизнес все же хочет ТП, тот же Oracle не возможно использовать без патчей. Так что тут выбор в пользу Postgre SQL очевиден (опять же в пользу скорее вендорских решений, типа Postgre Pro), и все остальное пустое.
Если технически, на мой взгляд, 7 основных вопросов к PostgreSQL относительно Oracle если сравнивать:
1. Богомерзкий MVCC (vacuum, bloat, отсутствие версионирования в индексах)
2. Партиционирование (отсутствие глобальных индексов и все что за собой тянет, нет автосоздания партиций, плюс тормоза на большом количестве партиций)
3. Зависимости (dependicies). Тут можно спорить нужны хранимки или нет, но если используете те, то тут Oracle c механизмом зависимостей побеждает
4. Мониторинг - тут все просто, Oracle дает гораздо больше телеметрии (AWR, ASH, SQL Monitor) по сравнению с PostgreSQL, вплоть до контроля плана выполнения в реальном времени, да такое есть в Postgres Pro (но мы то тут про ванилу, а Postgres Pro не торопится такие фишки отдавать в Open Source).
5. Кэш запросов, оутлайны и хинты. В Oracle это есть и не возникает ситуация, когда на 50 Тб базе вдруг после очередного сбора статистики поехали планы.
6. Exadata - тут все просто, сопоставимого решения для Postgres SQL нет, оно можно вспомнить про Greenplum/Citus, но Exadata умеет в обе нагрузки OLTP и OLAP, а с PostgreSQL обе задачи не закрывает, тут надо бить решение на части.
7. Golden Gate - ничего сопоставимого нет от Open Source, Debezium - жалкое подобие и 10% от функционала и скорости.
Хороший вопрос, правильный, для этого у Линстеда есть определение "транзакционного линка" (transaction link, т.е. линка у которого нет сроков действия), но поскольку мы не только про банк, то тут может быть понятие историчности, скажем, я наблюдал при реализации DV для крупного поставщика, когда строка в заказе без сторно "пропадала" задним числом в течении месяца, или появлялась новая строка. Или скажем менеджер по заказу менялся несколько раз, если есть хаб заказ и хаб сотрудние и линк менеджер по заказу, и тут надо поддерживать историчность для этого линка, т.е. если бы мы получили отчет с 5 по 10 сентября, то менеджер был бы один, а если 11 сентября то другой.
Вообще говоря, весь DV про то, чтобы получить отчет за август, как он выглядел 8 сентября, сегодня 16 октября, когда прошла масса изменений задним числом. Если нет изменений задним числом, и отчет нужен только как он выглядит сегодня, то DV вообще не нужен.
ER диаграмма ужасная, линии и объекты пересекаются и не видно, что от чего зависит.
Самое интересное в DV это линки, и по ним можно понять умеет автор в DV или нет. Любые транзакции, факты, проводки - это линк, а не хаб, в данной схеме h_order_detail - лишний, и должен быть линком.
Ну и тема историчности линков в статье не раскрыта, спойлер в самом линке не должно быть периода действия. Так же не раскрыта тема сателлита на линк.
Для какой модели данных? Камбал, Инмон, DataVault?
Собственно самое ценное, это коэффициенты по слоям, и они сильно должны зависеть от выбранного способа моделирования данных и от того сколько показателей нужно взять из исходных данных. Без них статья особого смысла не имеет.