SELECT
ol.id,
COALESCE(p.name, g.name, s.name) AS item_name
FROM order_lines ol
LEFT JOIN products p
ON p.id = CASE WHEN ol.type = 'A' THEN ol.item_id ELSE NULL END
LEFT JOIN gift_cards g
ON g.id = CASE WHEN ol.type = 'B' THEN ol.item_id ELSE NULL END
LEFT JOIN subscriptions s
ON s.id = CASE WHEN ol.type = 'C' THEN ol.item_id ELSE NULL END
WHERE EXISTS (
SELECT 1 FROM orders o
WHERE o.id = ol.order_id AND o.placed_at >= DATE '2024-01-01')
ORDER BY ol.popularity
LIMIT 100;
У меня подобный подход приводит к ~20% улучшения производительности.
А по каким критериям выбор пал на Avro, а не Protobuf?
Например, для нас решающим критерием оказалось то, что в gRPC Protobuf применять явно проще, чем Avro, а schema registry и сами схемы для Confluent и для gRPС могут быть одни и те же. Особенно для иерархических структур данных.
Странно то, что .NET вообще использует рефлексию в тех случаях, когда всё известно на этапе компиляции. Рефлексия нужна как раз в случаях, когда что-то выясняется только на этапе выполнения. Например, схема в топике Кафки из schema registry, которая может быть обновлена в любой момент времени.
Только сейчас заметил, что ссылка не прикрепилась. Пост тут.
Если кратко, то претензия к этому:
select *
from rate_plans rp
join dir_change_hist dch on rp.rtpl_id = dch.rtpl_rtpl_id
where dch.status = 'O' and dch.del_date is null
and dch.start_date <= current_timestamp
and dch.end_date >= current_timestamp
and rp.traffic_yn ='Y'
Планировщик в случае btree ничего не знает о диапазонах. Для него start_date и end_date никак логически не связаны и о том, что пересечения диапазонов недопустимы он тоже не знает. Но мы можем ему явно об этом сообщить, переписав запрос так:
SELECT *
FROM rate_plans RP
JOIN LATERAL (
SELECT *
FROM dir_change_hist D
WHERE D.rtpl_rtpl_id = RP.rtpl_id
AND D.status = 'O' AND D.del_date IS NULL
AND D.start_date <= CURRENT TIMESTAMP
ORDER BY D.start_date DESC
LIMIT 1
) DCH ON D.end_date > CURRENT TIMESTAMP
WHERE RP.traffic_yn = 'Y'
Вот тут показано, что подобный поход выигрывает по производительности у gist в пять(!) раз.
Спасибо. Как и подозревалось, речь о кривых запросах. При оптимизированных запросах btree показывает в разы лучшую производительность, чем gist. Я этот вопрос уже подробно рассматривал на Хабре тут.
На самом деле в документации написано правильно. Это лишь параметр для планировщика. Для примера, размер дискового кеша в VM или k8s может быть по факту как больше, так и меньше размера кеша файловой системы. То же самое относится и к СХД, у которого размер его кеша может быть сотни гигабайт.
Правильней считать, что effective_cache_size выражается в попугаях, которые в частном случае, на физическом сервере с программным RAID, действительно байты. И определяет этот параметр вероятность того, что ранее считанная страница БД доступна быстрее, чем ранее не считанная.
Сериализация и десериализация в JSON существенно медленней, чем, например, в protobuf. В первую очередь, из-за необходимости преобразования из двоичной системы исчисления в десятичную и обратно.
Sink для PostgreSQL очень неэффективен, что заставило нас написать собственное решение, использующее COPY FROM stdin binary. Если удаления и модификации записей не требуется, то сразу в целевую таблицу. В противном случае - в буферную нежурналируемую, что бы потом обновить целевую таблицу MERGE.
Самое главное. CH и JOIN плохо совместимы. Исключение составляют справочники, но это не таблицы и у них свои ограничения. Поэтому данные из разных БД всё равно приходится объединять в широкие таблицы, которые куда эффективней для колоночного хранения, чем JOIN в запросах. И подобные трансформации выполняются на PostgreSQL.
CH эффективно вставляет записи только крупными пакетами. Всё же каждая вставка для него - создание нового файла. И только потом он будет накопившиеся мелкие файлы объединять в один с дедупликацией. Поэтому в CH заливаем данные периодическим заданием. А отчёты используют данные и из CH, и из PostgreSQL. Из последнего берутся только те данные, которых еще нет в CH.
Самое непонятное, как же gist мог оказаться быстрей btree при работе с обычными диапазонами. Впрочем, так как в статье нет ни примера кода, ни результатов его модификации, ни бенчмарков, то речь может идти о каком-то хитром частном случае или кривых запросах из ORM.
ПИД-регулятор тут не при чём. Только пропорциональной составляющей эту проблему не решить. Такие задачи решаются рампой разгона и торможения в дополнение к ПИД-регулятору.
Исходя из того, что как межмолекулярное, так и внутримолекулярное взаимодействие есть взаимодействие электромагнитное, то вместо квантововой физики со стандартной моделью и фотоном, применять тут механику макромира выглядит несколько странным. Особенно с учётом того, что именно фотоны, порождаемые квантовым эффектом, позволяют читать это.
С C# на бэке в случае веб сервисов вообще без разницы комбинация на чём разрабатывать/на чём запускать.
Вообще-то разница существенная. Даже если не касаться более тонких различий, о которых Вы бы точно знали, если бы действительно занимались разработкой в Windows для k8s/Linux, только наличие чувствительности к регистру в файловых системах Linux и нечувствительности в Windows - уже более чем достаточно для того, что в продуктиве сервис повёл себя не так, как при отладке под Windows.
Ну то есть чем мне вообще поможет переход на Linux для разработки?
Не потребуется постоянно переключаться между Windows и Linux в VM/WSL2 в целях отладки.
Поэтому повторяю вопрос, который Вы почему-то проигнорировали. Чем в этом сценарии может помочь Windows? Не субъективно "мне так нравится/удобней/привычней", а объективно.
Вы упорно не видите разницу между "богатый" и "богаче, чем"
Конечно не вижу, так как "богатый" - понятие относительное. По сравнению с Мордашовым я нищий, по сравнению со большинством соседей в моей деревне - богатый.
я изначально подразумевал, ведь очевидно же,
И сразу же применили два ключевых признака демагогии? )))
Учиться я способен, но зачем мне признавать ошибку, когда я прав?
Кто это писал?
Покажите мне хоть одного учёного, разбогатевшего за счёт своей научной деятельности. (Эдисона не предлагать, он не подходит)
Сколько было в моём списке, в том числе тех, кто ну совершенно не были бизнесменами, как Генри Бессемер, Роберт Кернс или Чарльз Дарроу?
Да, общее состояние моего клана, пожалуй, даже превышает миллион баксов
Вас не смущает, что совместные накопления сообщества за десятки лет и премия одному имеют один и тот же порядок. Это, уж простите, не тушёнка.
Далее еще хуже - демагогия, так как резко подменяется тезис добавлением "хорошим". Любому, кто хоть немного знаком с теорией вероятности суть такой подмены тезиса сразу понятна. Эдисон так себе учёный, хоть и неплохой инженер. А Роберт Кернс вообще никакой бизнесмен. Впрочем, как и Чарльз Дарроу.
А в качестве вишенки на торт, Вы всё же подтвердили, что учиться уже не способны, так как признать свою ошибку не смогли )))
Только Вы как-то странно забыли, что подушка в виде жилья, какая-никакая, есть у любого москвича. Но её нет у приезжих. Не будет денег на съём квартиры на следующий месяц - уезжай обратно. Я по себе знаю, что это очень и очень стимулирует )
Ну а родители того Дайсона воще отправили в интернат.
Ну так это чуть ли на самый дорогостоящий подход, когда ребёнком занимаются вообще только наёмные специалисты.
А с подушкой стартовать легче.
Заниматься бизнесом с начальным капиталом - легче. В остальных случаях - не думаю. Например, средние зарплаты коренных москвичей заметно ниже, чем средние зарплаты приезжих. Подозреваю, потому что "подушка" расслабляет, а её отсутствие - стимулирует. Да я и сам видел это по студентам. Те, кому возвращаться некуда, очень боятся вылететь. А те, кого в любом случае примут и обеспечат - могут и бросить учёбу просто потому, что надоело.
Думаю, вы не можете не понимать разницу между учёным и бизнесменом.
Она очень условна, так как и учёный может заниматься бизнесом, и бизнесмен заниматься наукой. А вот то, что Вы не умеете учиться, так как не признаёте свои ошибки - это уже Ваша проблема ))
Нисколько. Да, общее состояние моего клана, пожалуй, даже превышает миллион баксов -- но мы ни разу не "богатые".
В таком случае это явное лицемерие, не считать богатством 11 миллионов шведских крон.
А почему бы не поступить так?
У меня подобный подход приводит к ~20% улучшения производительности.
Какой смысл сравнивать язык со сборщиком мусора и язык с прямым управлением памятью? У них же разные области применения!
А по каким критериям выбор пал на Avro, а не Protobuf?
Например, для нас решающим критерием оказалось то, что в gRPC Protobuf применять явно проще, чем Avro, а schema registry и сами схемы для Confluent и для gRPС могут быть одни и те же. Особенно для иерархических структур данных.
Странно то, что .NET вообще использует рефлексию в тех случаях, когда всё известно на этапе компиляции. Рефлексия нужна как раз в случаях, когда что-то выясняется только на этапе выполнения. Например, схема в топике Кафки из schema registry, которая может быть обновлена в любой момент времени.
Только сейчас заметил, что ссылка не прикрепилась. Пост тут.
Если кратко, то претензия к этому:
Планировщик в случае btree ничего не знает о диапазонах. Для него start_date и end_date никак логически не связаны и о том, что пересечения диапазонов недопустимы он тоже не знает. Но мы можем ему явно об этом сообщить, переписав запрос так:
Вот тут показано, что подобный поход выигрывает по производительности у gist в пять(!) раз.
Спасибо. Как и подозревалось, речь о кривых запросах. При оптимизированных запросах btree показывает в разы лучшую производительность, чем gist. Я этот вопрос уже подробно рассматривал на Хабре тут.
Так последняя фраза есть в условии:
Greenplum больше про MPP, что не всегда возможно.
Например, когда отчеты требуют использования перцентилей при агрегации по независимым аналитикам.
На самом деле в документации написано правильно. Это лишь параметр для планировщика. Для примера, размер дискового кеша в VM или k8s может быть по факту как больше, так и меньше размера кеша файловой системы. То же самое относится и к СХД, у которого размер его кеша может быть сотни гигабайт.
Правильней считать, что effective_cache_size выражается в попугаях, которые в частном случае, на физическом сервере с программным RAID, действительно байты. И определяет этот параметр вероятность того, что ранее считанная страница БД доступна быстрее, чем ранее не считанная.
На самом деле тут целый ряд опущенных проблем.
Сериализация и десериализация в JSON существенно медленней, чем, например, в protobuf. В первую очередь, из-за необходимости преобразования из двоичной системы исчисления в десятичную и обратно.
Sink для PostgreSQL очень неэффективен, что заставило нас написать собственное решение, использующее COPY FROM stdin binary. Если удаления и модификации записей не требуется, то сразу в целевую таблицу. В противном случае - в буферную нежурналируемую, что бы потом обновить целевую таблицу MERGE.
Самое главное. CH и JOIN плохо совместимы. Исключение составляют справочники, но это не таблицы и у них свои ограничения. Поэтому данные из разных БД всё равно приходится объединять в широкие таблицы, которые куда эффективней для колоночного хранения, чем JOIN в запросах. И подобные трансформации выполняются на PostgreSQL.
CH эффективно вставляет записи только крупными пакетами. Всё же каждая вставка для него - создание нового файла. И только потом он будет накопившиеся мелкие файлы объединять в один с дедупликацией. Поэтому в CH заливаем данные периодическим заданием. А отчёты используют данные и из CH, и из PostgreSQL. Из последнего берутся только те данные, которых еще нет в CH.
Самое непонятное, как же gist мог оказаться быстрей btree при работе с обычными диапазонами. Впрочем, так как в статье нет ни примера кода, ни результатов его модификации, ни бенчмарков, то речь может идти о каком-то хитром частном случае или кривых запросах из ORM.
ПИД управляет не двигателем непосредственно, а рампой. Про рампу написано было немало. Например, даже на Хабре https://habr.com/ru/articles/550942/
ПИД-регулятор тут не при чём. Только пропорциональной составляющей эту проблему не решить. Такие задачи решаются рампой разгона и торможения в дополнение к ПИД-регулятору.
Исходя из того, что как межмолекулярное, так и внутримолекулярное взаимодействие есть взаимодействие электромагнитное, то вместо квантововой физики со стандартной моделью и фотоном, применять тут механику макромира выглядит несколько странным. Особенно с учётом того, что именно фотоны, порождаемые квантовым эффектом, позволяют читать это.
Вообще-то разница существенная. Даже если не касаться более тонких различий, о которых Вы бы точно знали, если бы действительно занимались разработкой в Windows для k8s/Linux, только наличие чувствительности к регистру в файловых системах Linux и нечувствительности в Windows - уже более чем достаточно для того, что в продуктиве сервис повёл себя не так, как при отладке под Windows.
Не потребуется постоянно переключаться между Windows и Linux в VM/WSL2 в целях отладки.
Поэтому повторяю вопрос, который Вы почему-то проигнорировали. Чем в этом сценарии может помочь Windows? Не субъективно "мне так нравится/удобней/привычней", а объективно.
Конечно не вижу, так как "богатый" - понятие относительное. По сравнению с Мордашовым я нищий, по сравнению со большинством соседей в моей деревне - богатый.
И сразу же применили два ключевых признака демагогии? )))
Кто это писал?
Сколько было в моём списке, в том числе тех, кто ну совершенно не были бизнесменами, как Генри Бессемер, Роберт Кернс или Чарльз Дарроу?
Вот с этого:
Вас не смущает, что совместные накопления сообщества за десятки лет и премия одному имеют один и тот же порядок. Это, уж простите, не тушёнка.
Далее еще хуже - демагогия, так как резко подменяется тезис добавлением "хорошим". Любому, кто хоть немного знаком с теорией вероятности суть такой подмены тезиса сразу понятна. Эдисон так себе учёный, хоть и неплохой инженер. А Роберт Кернс вообще никакой бизнесмен. Впрочем, как и Чарльз Дарроу.
А в качестве вишенки на торт, Вы всё же подтвердили, что учиться уже не способны, так как признать свою ошибку не смогли )))
Только Вы как-то странно забыли, что подушка в виде жилья, какая-никакая, есть у любого москвича. Но её нет у приезжих. Не будет денег на съём квартиры на следующий месяц - уезжай обратно. Я по себе знаю, что это очень и очень стимулирует )
Ну так это чуть ли на самый дорогостоящий подход, когда ребёнком занимаются вообще только наёмные специалисты.
Заниматься бизнесом с начальным капиталом - легче. В остальных случаях - не думаю. Например, средние зарплаты коренных москвичей заметно ниже, чем средние зарплаты приезжих. Подозреваю, потому что "подушка" расслабляет, а её отсутствие - стимулирует. Да я и сам видел это по студентам. Те, кому возвращаться некуда, очень боятся вылететь. А те, кого в любом случае примут и обеспечат - могут и бросить учёбу просто потому, что надоело.
Она очень условна, так как и учёный может заниматься бизнесом, и бизнесмен заниматься наукой. А вот то, что Вы не умеете учиться, так как не признаёте свои ошибки - это уже Ваша проблема ))
В таком случае это явное лицемерие, не считать богатством 11 миллионов шведских крон.