Перед НГ увидел рекламу этого кресла и аж загорелся. Объездил полгорода, в итоге всё-таки нашёл где оно есть выставленное в зале, посидел и это, правда, восторг для спины. Но для меня оказался очень неудобным подголовник. Мой рост под два метра и подголовник упирается и давит куда-то в шею в макстимальном верхнем положении. От покупки пока отказался. Может ещё выпустят версию для людей повыше.
Ведь априори, если уменьшая фрагментацию, мы увеличиваем плотность данных на страницах
Это ложное утверждение. C fill factor < 100 вы скорее её уменьшаете, но поскольку не отслеживаете - подтвердить или опровергнуть это не получится. Однако люди, которые запустят ваши скрипты, могут сильно удивиться, что индексы выросли, и памяти теперь нужно больше, чем до дефрагментации.
suggested_fillfactor позволяет найти компромисс от полного заполнения станиц и как следствие каждодневное повышение фрагментации и сохранить плотность на должном уровне
А кем он suggested? Зачем он безльтернативно suggested для всех таблиц с фрагментацией больше 5%? А если это историческая таблица с индексом по дате, в которой все изменения происходят в последнем месяце?
А как ваш скрипт учитывает плотность страниц, о которой вы пишете в тексте? Ну, не считая того, что уменьшает её, уменьшая для всех таблиц fill factor?
Результат в примере с подзапросами может отличаться от оптимизированного варианта с джойнами, если у клиента не было заказов.
Пример с процедурой выглядит максимально странно:
вложенные циклы - это прям не круто, особенно для такой задачи (вот бы посмотреть на sql-запрос, может он и не такой уж сложный)?
может "терять" данные, если SUM(Quantity) будет одинаковым для 2 и более продуктов, сортировки в запросе нет, на каждый вызов, теоретически, может возвращаться разный продукт;
"сбрасывается" только одна переменнаяv_max_quantity , проверок никаких нет, а что произойдёт, если в предыдущей итерации у clinet_id = 123 был заказ, а у следующего клиента client_id = 124 заказов не было?
При чтении с диска производительность точно (на самом деле уже не точно) упадёт, и не факт, что снижение производительности при чтении фрагментированного индекса будет заметно меньше, чем при чтении нефрагментированного. А если данные уже в памяти - будет ли разница?
Разница может быть заметна в случае, если на страницах много свободного места, но это обычно не то, что понимают под фрагментацией. В статье тоже акцент на порядке страниц, а не их содержимом.
В какой ситуации фрагментация индекса повлияет на этот запрос? Насколько сильно?
SELECT * FROM MyTable WHERE ID = 12345
В случае, когда ID не уникальны? В случае, когда было много удалений и в индексе "образовался" "лишний" уровень?
Вообще, было бы здорово, если бы в примерах были не просто примеры запросов, а рельная статистика выполнения - с фрагментированным индексом и с дефрагментированным.
как предлагаете аттестовывать специалистов по ним?
Если вы прочтёте мой комментарий, то увидите, что я ничего не предлагаю. Всего лишь говорю, что ваше сравнение оценки программистов с методами нацистов - это абсурд.
Сертификации придумали не вчера, наверное, у любого крупного вендора этих сертификаций навалом.
Я абсолютно не сторонник "проф стандартов", но ваше утверждение (предположение?) - это абсурд. Экзамены в школе и ВУЗе ничего не напоминают? Разряды/категории у рабочих профессий (сварщики, электрики)?
with x (id, smth) as (select 1, 'smth' union all select 2, 'smth else' union all select 3, 'anthr')
, y (id) as (select 1 union all select 2 union all select 1)
select *
from x
where id in (select id from y);
Статья в блоге банка, значит, видимо, банк разделяет описанные принципы ведения переговоров. Это, кстати, вполне согласуется с тем, что Альфа - это пока единственный банк, в котором менеджер мне соврал в ответ на прямой вопрос.
Действительно, как правило схема на PROD стабильна, за исключением релизов. Но увы, есть системы, где это не так.
Сталкивался с системой, где пользователи "обновляли" данные с помощью truncate + insert, на реплику смотрел SSRS, который рассылал миллиарды тяжёлых отчётов.
С тех пор сильно недолюбливаю truncate (особенно в связке с AlwaysOn) и триггерюсь каждый раз, когда вижу как кто-то пишет, что это очень лёгкая и приятная замена для delete.
Это перевод статьи (которой уже больше 10 лет к тому же), поэтому добавлять что-то сюда считаю неправильным. Но вы вполне можете сами сделать и опубликовать расширенную версию :)
Следующим шагом, видимо, будет выход на рынок с "межоператорным шлюзом"?
Вообще, "шина данных" для ЭДО кажется хорошей идеей, даже для не-холдингов, если она берёт на себя работу со множеством операторов, потому что держать зоопарк коннекторов - это и правда боль. И делигировать эту боль кому-то было бы очень приятно:)
Кажется, что к выводам неплохо было бы добавить и регулярные проверки целостности. Старый полный бэкап + цепочка бэкапов ЖТ (при своевременном обнаружении) могли бы полностью решить проблему в примере 4.
Truncate– это команда DDL, она используется для удаления всех строк из таблицы и освобождения пространства, содержащего таблицу. Его нельзя откатить назад.
Можно откатить в MS SQL, PostgreSQL и, наверняка, в подавляющем большинстве РСУБД. В каких именно нельзя?
Drop– это команда DDL, она удаляет полные данные вместе со структурой таблицы (в отличие от команды truncate, которая удаляет только строки). Все строки, индексы и привилегии таблиц также будут удалены.
А Drop можно откатить? А в каких СУБД? А есть СУБД, где можно откатить Drop, но нельзя Truncate? Почему-то не указано...
А почему в обзоре pg_trgm индексов нигде не написано, что и обычные like/ilike он очень даже весомо ускоряет? Я практически уверен, что в 99% случаев их используют именно для ускорения запросов с like/ilke.
И в контексте использования для ускорения с like'ми было бы интересно узнать про выбор типа индекса gin/gist - в каком случае какой больше подходит.
dba -> разработчик БД
Лет семь уже, как бывший
Перед НГ увидел рекламу этого кресла и аж загорелся. Объездил полгорода, в итоге всё-таки нашёл где оно есть выставленное в зале, посидел и это, правда, восторг для спины. Но для меня оказался очень неудобным подголовник. Мой рост под два метра и подголовник упирается и давит куда-то в шею в макстимальном верхнем положении. От покупки пока отказался. Может ещё выпустят версию для людей повыше.
Это ложное утверждение. C fill factor < 100 вы скорее её уменьшаете, но поскольку не отслеживаете - подтвердить или опровергнуть это не получится. Однако люди, которые запустят ваши скрипты, могут сильно удивиться, что индексы выросли, и памяти теперь нужно больше, чем до дефрагментации.
А кем он suggested? Зачем он безльтернативно suggested для всех таблиц с фрагментацией больше 5%? А если это историческая таблица с индексом по дате, в которой все изменения происходят в последнем месяце?
А как ваш скрипт учитывает плотность страниц, о которой вы пишете в тексте? Ну, не считая того, что уменьшает её, уменьшая для всех таблиц fill factor?
Результат в примере с подзапросами может отличаться от оптимизированного варианта с джойнами, если у клиента не было заказов.
Пример с процедурой выглядит максимально странно:
вложенные циклы - это прям не круто, особенно для такой задачи (вот бы посмотреть на sql-запрос, может он и не такой уж сложный)?
может "терять" данные, если
SUM(Quantity)будет одинаковым для 2 и более продуктов, сортировки в запросе нет, на каждый вызов, теоретически, может возвращаться разный продукт;"сбрасывается" только одна переменная
v_max_quantity, проверок никаких нет, а что произойдёт, если в предыдущей итерации у clinet_id = 123 был заказ, а у следующего клиента client_id = 124 заказов не было?Есть примеры с замерами?
При чтении с диска производительность точно (на самом деле уже не точно) упадёт, и не факт, что снижение производительности при чтении фрагментированного индекса будет заметно меньше, чем при чтении нефрагментированного. А если данные уже в памяти - будет ли разница?
Разница может быть заметна в случае, если на страницах много свободного места, но это обычно не то, что понимают под фрагментацией. В статье тоже акцент на порядке страниц, а не их содержимом.
В какой ситуации фрагментация индекса повлияет на этот запрос? Насколько сильно?
В случае, когда ID не уникальны? В случае, когда было много удалений и в индексе "образовался" "лишний" уровень?
Вообще, было бы здорово, если бы в примерах были не просто примеры запросов, а рельная статистика выполнения - с фрагментированным индексом и с дефрагментированным.
Если вы прочтёте мой комментарий, то увидите, что я ничего не предлагаю. Всего лишь говорю, что ваше сравнение оценки программистов с методами нацистов - это абсурд.
Сертификации придумали не вчера, наверное, у любого крупного вендора этих сертификаций навалом.
Я абсолютно не сторонник "проф стандартов", но ваше утверждение (предположение?) - это абсурд. Экзамены в школе и ВУЗе ничего не напоминают? Разряды/категории у рабочих профессий (сварщики, электрики)?
Зачем там вообще distinct, в любом месте?
И зачем вообще вариант с IN, если есть с EXISTS.
Статья в блоге банка, значит, видимо, банк разделяет описанные принципы ведения переговоров. Это, кстати, вполне согласуется с тем, что Альфа - это пока единственный банк, в котором менеджер мне соврал в ответ на прямой вопрос.
На этот вопрос вы не ответили. Почему бы не использовать lateral?
Сталкивался с системой, где пользователи "обновляли" данные с помощью truncate + insert, на реплику смотрел SSRS, который рассылал миллиарды тяжёлых отчётов.
С тех пор сильно недолюбливаю truncate (особенно в связке с AlwaysOn) и триггерюсь каждый раз, когда вижу как кто-то пишет, что это очень лёгкая и приятная замена для delete.
т.е. выражение вида where not (smth = null) даст true (будет истинным)?
Это перевод статьи (которой уже больше 10 лет к тому же), поэтому добавлять что-то сюда считаю неправильным. Но вы вполне можете сами сделать и опубликовать расширенную версию :)
Следующим шагом, видимо, будет выход на рынок с "межоператорным шлюзом"?
Вообще, "шина данных" для ЭДО кажется хорошей идеей, даже для не-холдингов, если она берёт на себя работу со множеством операторов, потому что держать зоопарк коннекторов - это и правда боль. И делигировать эту боль кому-то было бы очень приятно:)
Спасибо за пост.
Кажется, что к выводам неплохо было бы добавить и регулярные проверки целостности. Старый полный бэкап + цепочка бэкапов ЖТ (при своевременном обнаружении) могли бы полностью решить проблему в примере 4.
Можно откатить в MS SQL, PostgreSQL и, наверняка, в подавляющем большинстве РСУБД. В каких именно нельзя?
А Drop можно откатить? А в каких СУБД? А есть СУБД, где можно откатить Drop, но нельзя Truncate? Почему-то не указано...
А почему в обзоре pg_trgm индексов нигде не написано, что и обычные like/ilike он очень даже весомо ускоряет? Я практически уверен, что в 99% случаев их используют именно для ускорения запросов с like/ilke.
И в контексте использования для ускорения с like'ми было бы интересно узнать про выбор типа индекса gin/gist - в каком случае какой больше подходит.