Разумно будет предпочесть hash, только если вы экономите место на диске - тут в лекции чуть подробнее. Во всех остальных случаях "умолчательный" btree будет не хуже.
Стандартная цитата разрабов и манагеров - "мы уперлись в СУБД". ... Почему, то считается, что если приложение тормозит надо портить нервы и стоять над душой у DBA ...
Это существующая, но порочная практика, увы.
"с СУБД аномалий нет , разбирайтесь с кривым приложением и проблемами инфраструктуры"
Это, правда, не менее порочная, с точки зрения бизнеса, которому важно "чтоб работало", а не "перевод стрелок".
Для исследования вопросов производительности приложения "в целом" правильно или команду специалистов собирать, или нужен "человек-оркестр"/performance engeneer, который проследит цепочку вызова от браузера через БЛ до БД и выявит конкретную проблему в конкретном месте.
В логах обновляемых данных нет, а в аналитике - есть.
"Золотой молоток"? Это пугает.
Мы не фанатики. Но сейчас у меня есть на руках инструмент для хорошего мониторинга/анализа работы PG, а для CH такого же по функционалу - нету. И усложнять клиентскую инфраструктуру для локального разворота нашего решения тоже не хочется.
В логах обновляемых данных нет, а в аналитике - есть.
"Золотой молоток"? Это пугает.
Мы не фанатики. Но сейчас у меня есть на руках инструмент для хорошего мониторинга/анализа работы PG, а для CH такого же по функционалу - нету. И усложнять клиентскую инфраструктуру для локального разворота нашего решения тоже не хочется.
У нас миллионы корпоративных аккаунтов. То есть потенциально неудачное решение может смасштабироваться на всех пользователей всех этих аккаунтов - тут за каждую миллисекунду имеет смысл биться, чтобы не завозить "железо" в ЦОД КАМАЗами.
удручающе низкий уровень разработки
Для его повышения я и пишу-пишу статьи - присоединяйтесь!
CH не особо заточен на обновляемые данных. У нас в общей инфраструктуре он тоже используется для некоторых задач, и у него есть и плюсы (я в курсе про *MergeTree-движки), и минусы, как и у любой СУБД.
Нам для анализа работы PG - пока не подошел. В том числе, и потому что наша собственная экспертиза в области PG, а не CH.
Тут нет параметра "бюджета" - в нашем случае это баланс между затратами на ФОТ разработки против затрат на оборудование.
Банальный пример: разработчик написал запрос к БД, но забыл сделать под него подходящий индекс. Это приводит к увеличению нагрузки по cpu, памяти, диску хоста, кол-ву вычитываемых/отфильтровываемых записей, вычитываемых страниц.
Можно вложить 100 рублей в выделение больших аппаратных ресурсов, а можно за 1 рубль заставить разработчика добавить индекс, после чего оценить изменение описанных выше метрик.
Если DBA - "хозяин" базы, то с него и спрос за ее работу в полном объеме. Иначе получается "к пуговицам претензии есть?"
Но это определяется разделением обязанностей в организации. Например, ответственным за тупящий запрос можно назначить написавшего его разработчика , которого DBA научит, как его переписать эффективнее. Можно - DBA, заставляя его самостоятельно придумывать подходящие для запросов индексы. А можно - и "железячников", заставляя выделять больше аппаратных ресурсов для БД.
Согласен, что снапшот-модель интервальных отчетов мало полезна. Но и анализ конкретных фактов с помощью матстата выглядит как-то не слишком оптимально.
Статью читал, но как применить к реальным условиям использования - не придумал. На мой взгляд, оно может быть полезно, если "везде все хорошо и вдруг где-то становится плохо". У нас же обычно можно взять любой хост и какую-нибудь неоптимальность да найти, а раз нашел - стоит устранить.
Хранение лога - второстепенная для нас задача, а основная - заранее известные выборки.
Мы пробовали использовать колоночные хранилища, например, citus. Получилось, что четко зная целевую выборку, можно написать запрос, работающий в 3-4 раза чем на citus.
Операционка. Полностью одновременно писать в один и тот же блок данных она все равно не позволит. В достаточно большой файл - да, в атомарный его блок - нет.
Если "нормальный" == "клиентоориентированный", то не далее как сегодня, загнав машину на замену масла, попросил заодно проверить ручник. И таки да, поменяли колодки, суппорт и подтянули ручник без вопросов.
Ведь меня как пользователя машины интересует ее полная исправность, а не то, что Вася - электрик, Петя - механик, и как они делят обязанности на современных электромобилях.
К сожалению (или к счастью), описываемые мной решения и методики - это наш собственный путь по реальным граблям в том числе и на продах - то есть никакого теоретизирования, сугубо практические выкладки, накопленные за последние 10-15 лет.
Например, вот тут я приводил примеры анализа ситуаций, которые требуют от DBA все-таки иметь кругозор и за пределами самой DB.
Поэтому взглянуть на принципиально другую методику будет весьма любопытно.
Если речь про DataFile* события ожидания, то проще говорить и о них как об ожидании доступа к заблокированному ресурсу. Не зря они в pg_locks отражаются.
определение производительности СУБД это среднее время отклика СУБД
Да, только лучше использовать не среднее, а процентили. А вот эффективность достижения одной и той же производительности может быть разной относительно использованных ресурсов.
На этом принципе реализована параллелизация выполнения в PG. Очевидно, что распределение работы по воркерам требует больше ресурсов, но дает меньшее время выполнения.
Открываем инцидент ?
Безусловно. Но не факт, что на работу СУБД. Это может быть ошибкой условия, сформированного разработчиком. В любом случае требует исследования.
примерно описать сценарий действий
Определяем проблемный хост. На нем находим подходящий шаблон запроса в конкретном методе, дальше по времени/хитмапу находим конкретный проблемный план.
Тут есть в докладе примерная логика как и почему мы пришли к таким моделям.
Если мы берем buffers.read и соотносим с io.read, то при достаточных величинах можем судить о скорости СХД "в моменте". И если эти значения каждый момент маловаты, то можем судить и о недостаточной пропускной способности дисковой подсистемы.
Понятно, что если на СХД max=10Kops положим нагрузку 15Kops, то увидим замедление каких-то из операций. Но это как раз и будет сигналом о недостаточной производительности.
По вашему производительность запроса это время выполнения запроса?
Производительность - это именно про время, а вот эффективность может определяться и объемом buffers, и их распределением по hit/read, и скоростью обмена с СХД, и размером возвращаемого resultset, которые прямо или косвенно влияют на это самое время.
Классический вопрос - если запрос выполняется дольше и возвращает больше строк - это деградация или нет?
Зачем сравнивать сладкое и теплое? Давайте лучше сравнивать в рамках одного критерия.
Если запрос хронически возвращает 1K записей, но внезапно возвращает 1M размером на несколько десятков MB - это может и не быть деградацией, но крайне подозрительно само по себе.
Если выполнялся по 10мс, а внезапно стало 1000мс - тоже подозрительно.
И далее - вы представляете размер лога при включённом auto_explain?
Есть реальные кейсы из промышленной эксплуатации ИС ?
У нас сейчас на мониторинге с включенным auto_explain ~3K инстансов PostgreSQL. Размер логов порядка 16TB за пару месяцев, дольше не храним.
Вот тут я рассказывал, как мы их собираем и храним.
auto_explain + track_io_timing + сбор и анализ всех планов = можно построить heatmap распределения времени выполнения запросов и наглядно отследить деградацию.
По крайней мере, "проблема в СХД" определяется на раз по I/O Timings.
Разумно будет предпочесть hash, только если вы экономите место на диске - тут в лекции чуть подробнее. Во всех остальных случаях "умолчательный" btree будет не хуже.
Это существующая, но порочная практика, увы.
Это, правда, не менее порочная, с точки зрения бизнеса, которому важно "чтоб работало", а не "перевод стрелок".
Для исследования вопросов производительности приложения "в целом" правильно или команду специалистов собирать, или нужен "человек-оркестр"/performance engeneer, который проследит цепочку вызова от браузера через БЛ до БД и выявит конкретную проблему в конкретном месте.
В логах обновляемых данных нет, а в аналитике - есть.
Мы не фанатики. Но сейчас у меня есть на руках инструмент для хорошего мониторинга/анализа работы PG, а для CH такого же по функционалу - нету. И усложнять клиентскую инфраструктуру для локального разворота нашего решения тоже не хочется.
В логах обновляемых данных нет, а в аналитике - есть.
Мы не фанатики. Но сейчас у меня есть на руках инструмент для хорошего мониторинга/анализа работы PG, а для CH такого же по функционалу - нету. И усложнять клиентскую инфраструктуру для локального разворота нашего решения тоже не хочется.
У нас миллионы корпоративных аккаунтов. То есть потенциально неудачное решение может смасштабироваться на всех пользователей всех этих аккаунтов - тут за каждую миллисекунду имеет смысл биться, чтобы не завозить "железо" в ЦОД КАМАЗами.
Для его повышения я и пишу-пишу статьи - присоединяйтесь!
CH не особо заточен на обновляемые данных. У нас в общей инфраструктуре он тоже используется для некоторых задач, и у него есть и плюсы (я в курсе про *MergeTree-движки), и минусы, как и у любой СУБД.
Нам для анализа работы PG - пока не подошел. В том числе, и потому что наша собственная экспертиза в области PG, а не CH.
Тут нет параметра "бюджета" - в нашем случае это баланс между затратами на ФОТ разработки против затрат на оборудование.
Банальный пример: разработчик написал запрос к БД, но забыл сделать под него подходящий индекс. Это приводит к увеличению нагрузки по cpu, памяти, диску хоста, кол-ву вычитываемых/отфильтровываемых записей, вычитываемых страниц.
Можно вложить 100 рублей в выделение больших аппаратных ресурсов, а можно за 1 рубль заставить разработчика добавить индекс, после чего оценить изменение описанных выше метрик.
Если DBA - "хозяин" базы, то с него и спрос за ее работу в полном объеме. Иначе получается "к пуговицам претензии есть?"
Но это определяется разделением обязанностей в организации. Например, ответственным за тупящий запрос можно назначить написавшего его разработчика , которого DBA научит, как его переписать эффективнее. Можно - DBA, заставляя его самостоятельно придумывать подходящие для запросов индексы. А можно - и "железячников", заставляя выделять больше аппаратных ресурсов для БД.
Согласен, что снапшот-модель интервальных отчетов мало полезна. Но и анализ конкретных фактов с помощью матстата выглядит как-то не слишком оптимально.
Статью читал, но как применить к реальным условиям использования - не придумал. На мой взгляд, оно может быть полезно, если "везде все хорошо и вдруг где-то становится плохо". У нас же обычно можно взять любой хост и какую-нибудь неоптимальность да найти, а раз нашел - стоит устранить.
Хранение лога - второстепенная для нас задача, а основная - заранее известные выборки.
Мы пробовали использовать колоночные хранилища, например, citus. Получилось, что четко зная целевую выборку, можно написать запрос, работающий в 3-4 раза чем на citus.
Операционка. Полностью одновременно писать в один и тот же блок данных она все равно не позволит. В достаточно большой файл - да, в атомарный его блок - нет.
Если "нормальный" == "клиентоориентированный", то не далее как сегодня, загнав машину на замену масла, попросил заодно проверить ручник. И таки да, поменяли колодки, суппорт и подтянули ручник без вопросов.
Ведь меня как пользователя машины интересует ее полная исправность, а не то, что Вася - электрик, Петя - механик, и как они делят обязанности на современных электромобилях.
К сожалению (или к счастью), описываемые мной решения и методики - это наш собственный путь по реальным граблям в том числе и на продах - то есть никакого теоретизирования, сугубо практические выкладки, накопленные за последние 10-15 лет.
Например, вот тут я приводил примеры анализа ситуаций, которые требуют от DBA все-таки иметь кругозор и за пределами самой DB.
Поэтому взглянуть на принципиально другую методику будет весьма любопытно.
СУБД использует СХД, поэтому причиной проблем первой могут быть проблемы второй. А могут и не быть. А может быть и наоборот.
Если у меня машина не едет нормально, то виноват некачественный бензин, проблемы с двигателем или я передачу не переключил?..
Если речь про DataFile* события ожидания, то проще говорить и о них как об ожидании доступа к заблокированному ресурсу. Не зря они в pg_locks отражаются.
Да, только лучше использовать не среднее, а процентили. А вот эффективность достижения одной и той же производительности может быть разной относительно использованных ресурсов.
На этом принципе реализована параллелизация выполнения в PG. Очевидно, что распределение работы по воркерам требует больше ресурсов, но дает меньшее время выполнения.
Безусловно. Но не факт, что на работу СУБД. Это может быть ошибкой условия, сформированного разработчиком. В любом случае требует исследования.
Определяем проблемный хост. На нем находим подходящий шаблон запроса в конкретном методе, дальше по времени/хитмапу находим конкретный проблемный план.
Тут есть в докладе примерная логика как и почему мы пришли к таким моделям.
Если мы берем buffers.read и соотносим с io.read, то при достаточных величинах можем судить о скорости СХД "в моменте". И если эти значения каждый момент маловаты, то можем судить и о недостаточной пропускной способности дисковой подсистемы.
Понятно, что если на СХД max=10Kops положим нагрузку 15Kops, то увидим замедление каких-то из операций. Но это как раз и будет сигналом о недостаточной производительности.
Ожидания и перехватываем из лога как следствие возникновения длительной блокировки.
Производительность - это именно про время, а вот эффективность может определяться и объемом buffers, и их распределением по hit/read, и скоростью обмена с СХД, и размером возвращаемого resultset, которые прямо или косвенно влияют на это самое время.
Можно вот типа таких картинок наблюдать по ходу дня.
Зачем сравнивать сладкое и теплое? Давайте лучше сравнивать в рамках одного критерия.
Если запрос хронически возвращает 1K записей, но внезапно возвращает 1M размером на несколько десятков MB - это может и не быть деградацией, но крайне подозрительно само по себе.
Если выполнялся по 10мс, а внезапно стало 1000мс - тоже подозрительно.
У нас сейчас на мониторинге с включенным auto_explain ~3K инстансов PostgreSQL. Размер логов порядка 16TB за пару месяцев, дольше не храним.
Вот тут я рассказывал, как мы их собираем и храним.
auto_explain + track_io_timing + сбор и анализ всех планов = можно построить heatmap распределения времени выполнения запросов и наглядно отследить деградацию.
По крайней мере, "проблема в СХД" определяется на раз по I/O Timings.