Куча кода регулярно ломается при обновлении мажорных (а иногда и минорных) версий популярных библиотек, для этого и придумали всякие requirements.txt, virtualenv, контейнеры и т.п.
А тут переписывают значимую часть ядра языка на горизонте нескольких мажорных версий (5+ лет)
В psql-hackers когда-то было большое обсуждение патча с добавлением temporal tables согласно ANSI-стандарта. В итоге решили забить, т.к. решили, что это добавит много проблем при редактировании таблиц (удаление/добавление/смена типа поля) при относительно небольшой пользе. К тому же триггеры с таким функционалом каждый может написать под себя, не ограничиваясь стандартным функционалом и синтаксисом.
Вот как раз два примера кастомных реализаций на триггерах)
Ну правда жизни такова, что в больших DWH пользователей принято бить ногами за плохие запросы)) Вспоминая навскидку несколько примеров с конференций, в Авито, кажется, запросы рядовых пользователей вроде перехватывает парсер, проверяет план и не пропускает вопиющие косяки. В Тинькофф похожий сервис имеет говорящее имя "Инквизитор". И это не только Greenplum касается, а вообще всех крупных хранилищ. Слышал про кейсы, когда за плохие запросы в Snowflake в AWS аналитиков наказывали долларом (т.к. там непосредственную цену каждого запроса легко посчитать).
Возвращаясь к таблицам: При рандомной дистрибуции мы просто всегда будем получать Redistribute / Broadcast Motion и никогда не получим пользы от Greenplum как от MPP. Это всё равно, что гонять запросы между репликами обычного (причём устаревшего PostgreSQL). В идеальном мире надо стремиться выжимать из запросов максимум ситуаций, когда данные будут крутиться внутри одного слайса на отдельных сегментах, и только в конце собираться на мастере. Для этого нужны осмысленные с точки зрения бизнеса ключи дистрибуции.
Если распределить все ровненько по serial а Table4 random
Огромную партиционированную таблицу оставлять с random-дистрибуцией - плохая идея в любом случае. Стоит сделать суррогатный ключ и распределить таблицу по нему
Вот как будет работать броадкаст
При собранной статистике по всем таблицам броадкасты тут вряд ли случатся, будут Redistribute Motion Правда может произойти Broadcast Motion данных из Table 4, если по условию where Date = Дата выберется небольшой объём данных (относительно объёмов Table 1 - Table 3) из одной партиции Table 4 Если вместо inner join в запросе будут left join, то и такой кейс для broadcast исключён
-- Худшее, что тут может произойти - перекосы (skew) в промежуточных джойнах, которые можно наглядно отловить с помощью explain analyze. Самый простой способ от них избавиться - разобрать многоэтажные джойны на последовательные операции и оптимизировать их по отдельности (фильтровать null, выбирать distinct значения ключей для джойна и т.д.). Greenplum может переварить портянки на 10+ джойнов, но это редко является оптимальной формой запроса.
create table if not exists t (id int) partition by hash (id);
create table if not exists hash_p_1
partition of t for values with(modulus 2, remainder 1);
create table if not exists hash_p_0
partition of t for values with(modulus 2, remainder 0);
insert into t
select *
from generate_series(1,100);
select *
from hash_p_1;
Я постепенно пришёл к тому, что мне от редактора заметок действительно нужна только синхронизация между устройствами. И храню в детализированных заметках практически только то, чем пользуюсь почти ежедневно. "Холодные" данные собираю в большие слабоструктурированные заметки (Ctrl+F быстрее, чем категоризация)
Поэтому на последней картинке я бы был слева или справа.
Самый простой пример и то, что нам не понравилось в миграциях Liqubase (далее LB) это когда одна функция правится двумя разработчиками. LB при этом предлагает сделать каждому из них свою миграцию и, конечно, каждый положит в миграцию свой код функции. Что будет дальше? Дальше останется вариант того, что сольет свой Merge Request (далее MR) последним
Это в Liquibase решается предельно просто, работал на практике с этим подходом: надо всего лишь задать чёткие правила наименования YAML с чейнджсетами и/или структуру значений ключа id внутри этих чейнджсетов.
Например, разрабы X и Y делают параллельно два разных варианта апдейта функции func() с версии 1.0 на версию 1.1. Они оба должны сделать чейнджсеты с названием файла и id, например, "func()_1.1".
Допустим, разраб X первым закоммитил свою версию. Тогда разраб Y, во-первых, получит merge conflict, а во-вторых, автотесты не пропустят накат двух чейнджсетов Liquibase с одинаковым хэшем id
Контроль корректности наименований файлов в коммитах тоже можно автоматизировать
Ну я без сарказма и предъявы, мне правда интересно что (и зачем) можно напихать в условный compose, чтобы он полчаса билдился. Просто на схеме сервиса не видно ничего такого, что очевидно требовало бы таких объёмов, поэтому и зацепился глаз :)
Если не секрет, то хотя бы в общих чертах поделитесь, пожалуйста
Что ж там за список зависимостей для системы мониторинга серверов, который собирается 30 минут? o_O
Для референса, у меня на ноутбуке полноценные сборки Debian + Python + Postgresql с 20+ сторонними apt-пакетами и 20+ pip-пакетами билдятся с нуля минуты за 4 максимум с учётом времени загрузки бинарников по сети
Кто-нибудь вообще знает кейсы успешного внедрения "одной большой немецкой программы с 40-летней историей» в РФ?
Я просто сам был свидетелем эпичного фейла с её интеграцией в "одном большом телеком-операторе", и по сарафанному радио от коллег из других компаний слышал только такие же истории
Работал на сервере Neo4j 4.4 (он-прем) со 100 ГБ ОЗУ, там было около 25 миллионов вершин и около 100 миллионов рёбер в БД. Шуршал на он на оценку "удовлетворительно" - достаточно быстро для прода, но не поражал воображение и вообще не было запаса прочности для масштабирования.
Чтобы переварить миллиарды рёбер на Neo4j, нужен мини-ЦОД, наверно) И PG на том же железе работал бы не сильно хуже
Лучшее решение - собрать собственный фреймворк под свою конкретную задачу) Хранилище под капотом может быть и реляционным, и нет. Все основные алгоритмы обхода графов реализованы на всех доступных языках программирования, не надо изобретать велосипед.
Из того, что можно развернуть на коленке за 10 минут пробовал pgrouting в PostgreSQL и networkx в Python - отличные и простые инструменты, которые достаточно предсказуемо масштабируются) Ну и лично для меня большой плюс - в этих средах графы легко наложить и отобразить на географических картах в любой нужной проекции (или любой другой подложке)
БД Neo4j имеет собственный язык запросов Cypher. Запросы на нем выглядят лаконичнее и понятнее, чем аналогичные запросы для реляционной БД;
Чуть больше года занимался проектом на Neo4j и категорически не согласен с этим утверждением. Когда впервые увидел, что они всерьёз рекламируют Cypher как "overcoming SQL pain", просто всплакнул кровавыми слезами))
Neo4j хорошо работает только с максимально простыми, атомарными запросами. Начинаешь усложнять логику - план запроса летит в трубу. Из-за этого приходится строить километровые портянки с аккуратной трансляцией параметров из блока в блок через with или материализовывать промежуточные результаты во внешние системы/файлы.
Уже после опыта с Neo4j довелось поработать с графами в pgrouting, это было несказанное облегчение по всем аспектам)
Я бы выбрал Neo4j только как вспомогательный инструмент для каких-то простых задач по поиску связей (но, правда, практически с неограниченным масштабом, это большой плюс). Если в приоритете не масштаб, а сложная логика поиска/сложный ETL на графах - полно инструментов гораздо лучше.
Куча кода регулярно ломается при обновлении мажорных (а иногда и минорных) версий популярных библиотек, для этого и придумали всякие requirements.txt, virtualenv, контейнеры и т.п.
А тут переписывают значимую часть ядра языка на горизонте нескольких мажорных версий (5+ лет)
Не вижу проблемы и повода для ворчания
Нет солнца, дорого и массовое употребление алкоголя/веществ - всё как в Питере)
Так там тоже всё на триггерах)
В psql-hackers когда-то было большое обсуждение патча с добавлением temporal tables согласно ANSI-стандарта. В итоге решили забить, т.к. решили, что это добавит много проблем при редактировании таблиц (удаление/добавление/смена типа поля) при относительно небольшой пользе. К тому же триггеры с таким функционалом каждый может написать под себя, не ограничиваясь стандартным функционалом и синтаксисом.
Вот как раз два примера кастомных реализаций на триггерах)
Ну правда жизни такова, что в больших DWH пользователей принято бить ногами за плохие запросы))
Вспоминая навскидку несколько примеров с конференций, в Авито, кажется, запросы рядовых пользователей вроде перехватывает парсер, проверяет план и не пропускает вопиющие косяки. В Тинькофф похожий сервис имеет говорящее имя "Инквизитор".
И это не только Greenplum касается, а вообще всех крупных хранилищ. Слышал про кейсы, когда за плохие запросы в Snowflake в AWS аналитиков наказывали долларом (т.к. там непосредственную цену каждого запроса легко посчитать).
Возвращаясь к таблицам:
При рандомной дистрибуции мы просто всегда будем получать Redistribute / Broadcast Motion и никогда не получим пользы от Greenplum как от MPP. Это всё равно, что гонять запросы между репликами обычного (причём устаревшего PostgreSQL).
В идеальном мире надо стремиться выжимать из запросов максимум ситуаций, когда данные будут крутиться внутри одного слайса на отдельных сегментах, и только в конце собираться на мастере. Для этого нужны осмысленные с точки зрения бизнеса ключи дистрибуции.
Огромную партиционированную таблицу оставлять с random-дистрибуцией - плохая идея в любом случае. Стоит сделать суррогатный ключ и распределить таблицу по нему
При собранной статистике по всем таблицам броадкасты тут вряд ли случатся, будут Redistribute Motion
Правда может произойти Broadcast Motion данных из Table 4, если по условию where Date = Дата выберется небольшой объём данных (относительно объёмов Table 1 - Table 3) из одной партиции Table 4
Если вместо inner join в запросе будут left join, то и такой кейс для broadcast исключён
--
Худшее, что тут может произойти - перекосы (skew) в промежуточных джойнах, которые можно наглядно отловить с помощью explain analyze. Самый простой способ от них избавиться - разобрать многоэтажные джойны на последовательные операции и оптимизировать их по отдельности (фильтровать null, выбирать distinct значения ключей для джойна и т.д.). Greenplum может переварить портянки на 10+ джойнов, но это редко является оптимальной формой запроса.
Да, конечно
Пример:
Из-за этого уже превентивно перешёл на Debian 12.1
Интересно, когда уже поднимут 1С на Greenplum
Ох, я рассчитывал увидеть хотя бы FTS со стеммингом, а не like '%%'
Я постепенно пришёл к тому, что мне от редактора заметок действительно нужна только синхронизация между устройствами.
И храню в детализированных заметках практически только то, чем пользуюсь почти ежедневно. "Холодные" данные собираю в большие слабоструктурированные заметки (Ctrl+F быстрее, чем категоризация)
Поэтому на последней картинке я бы был слева или справа.
Ох, у меня прямо вьетнамские флэшбеки от склеивания Чукотки, страдал как-то с этим в PostGIS
Это в Liquibase решается предельно просто, работал на практике с этим подходом: надо всего лишь задать чёткие правила наименования YAML с чейнджсетами и/или структуру значений ключа id внутри этих чейнджсетов.
Например, разрабы X и Y делают параллельно два разных варианта апдейта функции func() с версии 1.0 на версию 1.1. Они оба должны сделать чейнджсеты с названием файла и id, например, "func()_1.1".
Допустим, разраб X первым закоммитил свою версию. Тогда разраб Y, во-первых, получит merge conflict, а во-вторых, автотесты не пропустят накат двух чейнджсетов Liquibase с одинаковым хэшем id
Контроль корректности наименований файлов в коммитах тоже можно автоматизировать
Ну я без сарказма и предъявы, мне правда интересно что (и зачем) можно напихать в условный compose, чтобы он полчаса билдился.
Просто на схеме сервиса не видно ничего такого, что очевидно требовало бы таких объёмов, поэтому и зацепился глаз :)
Если не секрет, то хотя бы в общих чертах поделитесь, пожалуйста
Что ж там за список зависимостей для системы мониторинга серверов, который собирается 30 минут? o_O
Для референса, у меня на ноутбуке полноценные сборки Debian + Python + Postgresql с 20+ сторонними apt-пакетами и 20+ pip-пакетами билдятся с нуля минуты за 4 максимум с учётом времени загрузки бинарников по сети
Всё стабильно, самая сложная часть в разработке фичи для PG - уговорить Тома Лэйна
Кто-нибудь вообще знает кейсы успешного внедрения "одной большой немецкой программы с 40-летней историей» в РФ?
Я просто сам был свидетелем эпичного фейла с её интеграцией в "одном большом телеком-операторе", и по сарафанному радио от коллег из других компаний слышал только такие же истории
Работал на сервере Neo4j 4.4 (он-прем) со 100 ГБ ОЗУ, там было около 25 миллионов вершин и около 100 миллионов рёбер в БД.
Шуршал на он на оценку "удовлетворительно" - достаточно быстро для прода, но не поражал воображение и вообще не было запаса прочности для масштабирования.
Чтобы переварить миллиарды рёбер на Neo4j, нужен мини-ЦОД, наверно)
И PG на том же железе работал бы не сильно хуже
Так называют стандартные, базовые, немодифицированные сборки
Для PostgreSQL - это его open-source версия: https://github.com/postgres/postgres
Лучшее решение - собрать собственный фреймворк под свою конкретную задачу)
Хранилище под капотом может быть и реляционным, и нет.
Все основные алгоритмы обхода графов реализованы на всех доступных языках программирования, не надо изобретать велосипед.
Из того, что можно развернуть на коленке за 10 минут пробовал pgrouting в PostgreSQL и networkx в Python - отличные и простые инструменты, которые достаточно предсказуемо масштабируются)
Ну и лично для меня большой плюс - в этих средах графы легко наложить и отобразить на географических картах в любой нужной проекции (или любой другой подложке)
Чуть больше года занимался проектом на Neo4j и категорически не согласен с этим утверждением. Когда впервые увидел, что они всерьёз рекламируют Cypher как "overcoming SQL pain", просто всплакнул кровавыми слезами))
Neo4j хорошо работает только с максимально простыми, атомарными запросами. Начинаешь усложнять логику - план запроса летит в трубу. Из-за этого приходится строить километровые портянки с аккуратной трансляцией параметров из блока в блок через with или материализовывать промежуточные результаты во внешние системы/файлы.
Уже после опыта с Neo4j довелось поработать с графами в pgrouting, это было несказанное облегчение по всем аспектам)
Я бы выбрал Neo4j только как вспомогательный инструмент для каких-то простых задач по поиску связей (но, правда, практически с неограниченным масштабом, это большой плюс). Если в приоритете не масштаб, а сложная логика поиска/сложный ETL на графах - полно инструментов гораздо лучше.