Ну этот подход тоже не работает. Вот есть аналитик, у него есть отдельная БД аналитики (sqlite, pg, mysql, vertica, clickhouse или еще что-то), ему надо вытащить данные, он пишет запрос, запускает и внезапно понимает, что прошло уже 20 минут, а сервер думает. Было бы неплохо, если бы этот аналитик умел сам переделать запрос, чтобы запрос данные таки вывел. Каждый запрос к программистам не набегаешься же. Но это точно не про джуна (да он бы хоть какой-то запрос написал) и точно не решающий вопрос на собеседовании.
Какой-то винегрет из неудачных вопросов, не очень корректных ответов и почти случайных (опять же не всегда корректных) фактов непонятно про какую СУБД.
Очень странный в принципе вопрос аналитику на собеседовании про оптимизацию запросов (ну ок, наверное можно его задать, если кандидат явно на несколько ступеней оверквал - но это всё равно дичь).
Очень странные "способы оптимизации". Не основанные ни на анализе планов, ни на анализе ресурсов, ни на анализе хотя бы времени выполнения. Ладно, первый способ я еще могу представить на собеседовании аналитика, но второй и третий вызывают у меня вопросы к квалификации интервьюера. Про вторую оптимизацию. Просто из любопытства - попробуйте сделать такое заполнение секционированной таблицы из примера и запрос к ней, в которой секционирование будет стабильно лучше любого индекса, приведите пример с временем, io и планом. Если получилось, то скорее всего вы создали неудачный индекс. Про нормализацию отметили выше, что обычно она понижает скорость выборки, а не ускоряет.
В разделе про джойны:
Фильтр по orders.order_id IS NULL позволяет идентифицировать клиентов без заказов.
Так делать иногда можно, но по умолчанию лучше использовать exists.
В разделе про оконные функции в запросе со скользящим средним может быть очень неожиданным, если поле order_date неуникально. Но это уже мелкая придирка.
CTE. В postgresql, например, CTE имеют тенденцию к материализации. До версии 12 с этим было вообще плохо, сейчас получше, но всё равно можно выстрелить себе в ногу. Тут уж в статье надо было выбрать - либо удобство аналитика, либо акцент на оптимизации.
Но это всё были цветочки, если бы вся статья была этого уровня, я бы не стал комментировать. Но когда я добрался до задач, то увидел
HAVING SUM(CASE WHEN impression = 'Bored' THEN 1 ELSE 0 END) = 0
За 25 лет работы с БД я, конечно, встречал такой код. И даже смогу вспомнить сколько-то раз, когда это не приводило к ухудшению плана запроса. И даже, наверное, вспомню пару раз, когда это решение было хорошим. Но не в этот раз. Не делайте так. Просуммировать выражение с CASE от поля только чтобы убедиться что таких значений нет - очень плохая идея. После этого ситуацию уже индексами, например, исправить нельзя.
То ли я чего-то не понимаю, то ли китайцы хитрят. В MSI 1P17 мне непонятно зачем 2 x 2.5 GbE LAN - с указанными процами там же с трудом и 1 такой порт прогрузить.
Хм. А интересно, можно ли передавать данные через "ШИМ"? Ну то есть кодировать данные временем между пакетами, да хоть бы той же морзянкой (понятно, что надёжность и скорость невысоки).
А если numpy или подобные либы есть, то можно не класс создавать, а матрицей прикинуться:
import numpy as np
def magic(x: int, y: int, z: int) -> int:
a = 10000000000000000000000
b = 20000000000000000000000
c = 30000000000000000000000
return a * x + b * y + c * z
X = np.array([[1, 0, 0]])
Y = np.array([[0, 1, 0]])
Z = np.array([[0, 0, 1]])
print(magic(X, Y, Z))
Ну это не так. Мне даже коммент на хабре проще на ПК писать, потому что тут клавиатура есть. Вот на днях жена кучку заявлений на госуслугах и mos.ru делала - тоже через ноутбук, а не планшетотелефон. Мой отец (72 года) фотографии редактирует и печатает на ПК. Чёрт, да даже старший сын ютуб смотрит на ПК, потому что с плагином в браузере можно скорость выше 2 ставить.
Подход с GG и пробными запросами понятен - это очень разумный подход, но я всё равно не смогу поверить, что все баги чинились незаметно. Мне при обсуждениях переезда с СУБД на другую на лету всегда вспоминается очень старый ролик EDS "Airplane". Спасибо за подробную статью.
Во-первых, не приплетайте здесь парадокс Рассела, он ни чём, а во-вторых, у меня другие формулировки. Усложнить систему, т.е. сделать сложной, то есть состоящей из большого числа элементов и связей, причём скорее всего с циклами обратной связи, т.е. нелинейной - просто. "Просто" в данном случае больше отражает объём усилий. Про то что сделать систему простой, т.е. выделить только существенные элементы и взаимосвязи, написано не "сложно", а "нужно приложить усилия". Сама такая деятельность, как правильно заметил @Ndochp не является системой, к ней не применима метрика сложности системы.
Сжатие на уровне строк полезно по факту только если много числовых (numeric) полей с нулями или небольшими значениями (при больших допустимых). Тогда все эти нули будут храниться компактно. Другие выгодные варианты придумать можно, конечно, но базовый, наверное, такой.
Сжатие на уровне страниц - если есть много повторяющихся (но не длинных строковых/бинарных) значений. Повторения могут быть частичными. Способ сжатия описан тут. Доступ к таким данным на чтение и запись дороже по CPU, но для таблиц с кучей похожих чисел и ссылками на другие записи (всеми типовыми способами: уидами, строками, числами, бинарными) жмутся очень хорошо и это часто даёт такой выигрыш при чтении/записи с диска, что становится оправданным. Даже для неплохих систем хранения.
Сжатие бэкапов явно алгоритм не описан, но судя по появлению в 2022 выбора между MS_XPRESS (по умолчанию) and QAT_DEFLATE (для аппаратного ускорения) и по некоторым другим признакам - штатный алгоритм сильно похож на обычный deflate - умеренно хорошо подходит для любых избыточных потоков.
Отсюда уже можно сделать все выводы данной статьи, но по другим соображениям :) Плюс есть всякие хитрозадые опции хранения типа sparse columns, column sets, columnstore indexes и другие. Плюс есть еще соображения разницы между Standard/Enterprise.
И есть еще куча граничных случаев. Так, например "таблица-лог" с большими сообщениями не будет нормально сжиматься ни rows, ни page, зато может в десяток раз сжаться в бэкапе. Таблица с большим количеством низкоселективных ссылочных полей будет отлично жаться в page, зато потом плохо в бэкапе. А может для конкретно случая лучше подойдёт columnstore.
Так что всё равно придётся смотреть по месту, экспериментировать и замерять.
Ну этот подход тоже не работает. Вот есть аналитик, у него есть отдельная БД аналитики (sqlite, pg, mysql, vertica, clickhouse или еще что-то), ему надо вытащить данные, он пишет запрос, запускает и внезапно понимает, что прошло уже 20 минут, а сервер думает. Было бы неплохо, если бы этот аналитик умел сам переделать запрос, чтобы запрос данные таки вывел. Каждый запрос к программистам не набегаешься же.
Но это точно не про джуна (да он бы хоть какой-то запрос написал) и точно не решающий вопрос на собеседовании.
Статья очень плохая.
Какой-то винегрет из неудачных вопросов, не очень корректных ответов и почти случайных (опять же не всегда корректных) фактов непонятно про какую СУБД.
Очень странный в принципе вопрос аналитику на собеседовании про оптимизацию запросов (ну ок, наверное можно его задать, если кандидат явно на несколько ступеней оверквал - но это всё равно дичь).
Очень странные "способы оптимизации". Не основанные ни на анализе планов, ни на анализе ресурсов, ни на анализе хотя бы времени выполнения. Ладно, первый способ я еще могу представить на собеседовании аналитика, но второй и третий вызывают у меня вопросы к квалификации интервьюера.
Про вторую оптимизацию. Просто из любопытства - попробуйте сделать такое заполнение секционированной таблицы из примера и запрос к ней, в которой секционирование будет стабильно лучше любого индекса, приведите пример с временем, io и планом. Если получилось, то скорее всего вы создали неудачный индекс.
Про нормализацию отметили выше, что обычно она понижает скорость выборки, а не ускоряет.
В разделе про джойны:
Так делать иногда можно, но по умолчанию лучше использовать
exists.В разделе про оконные функции в запросе со скользящим средним может быть очень неожиданным, если поле
order_dateнеуникально. Но это уже мелкая придирка.CTE. В postgresql, например, CTE имеют тенденцию к материализации. До версии 12 с этим было вообще плохо, сейчас получше, но всё равно можно выстрелить себе в ногу. Тут уж в статье надо было выбрать - либо удобство аналитика, либо акцент на оптимизации.
Но это всё были цветочки, если бы вся статья была этого уровня, я бы не стал комментировать. Но когда я добрался до задач, то увидел
За 25 лет работы с БД я, конечно, встречал такой код. И даже смогу вспомнить сколько-то раз, когда это не приводило к ухудшению плана запроса. И даже, наверное, вспомню пару раз, когда это решение было хорошим. Но не в этот раз. Не делайте так. Просуммировать выражение с CASE от поля только чтобы убедиться что таких значений нет - очень плохая идея. После этого ситуацию уже индексами, например, исправить нельзя.
То ли я чего-то не понимаю, то ли китайцы хитрят. В MSI 1P17 мне непонятно зачем 2 x 2.5 GbE LAN - с указанными процами там же с трудом и 1 такой порт прогрузить.
Хм. А интересно, можно ли передавать данные через "ШИМ"? Ну то есть кодировать данные временем между пакетами, да хоть бы той же морзянкой (понятно, что надёжность и скорость невысоки).
Странно. Обычно минут через 10 уже бросают трубку.
А если
numpyили подобные либы есть, то можно не класс создавать, а матрицей прикинуться:На скорости 2,5-3 чаще всего какой-нибудь длинный видос про майнкрафт. Учебный материал 1,5-2.
Ну это не так. Мне даже коммент на хабре проще на ПК писать, потому что тут клавиатура есть. Вот на днях жена кучку заявлений на госуслугах и mos.ru делала - тоже через ноутбук, а не планшетотелефон. Мой отец (72 года) фотографии редактирует и печатает на ПК. Чёрт, да даже старший сын ютуб смотрит на ПК, потому что с плагином в браузере можно скорость выше 2 ставить.
Подход с GG и пробными запросами понятен - это очень разумный подход, но я всё равно не смогу поверить, что все баги чинились незаметно. Мне при обсуждениях переезда с СУБД на другую на лету всегда вспоминается очень старый ролик EDS "Airplane".
Спасибо за подробную статью.
Ха-ха. Вам показалось :)
Список - вся "внутренность", накопленная за ~25 лет.
Ну да, ну да. Сначала "дай носик отсканировать", а потом всё это превращается в "почему в jira время не оттрекано".
Пока приложение однопоточное - может быть. Как только приложение многопоточное - появляются весьма интересные способы выстрелить себе в ногу.
Так есть шанс депремировать каждый квартал новую команду.
Во-первых, не приплетайте здесь парадокс Рассела, он ни чём, а во-вторых, у меня другие формулировки.
Усложнить систему, т.е. сделать сложной, то есть состоящей из большого числа элементов и связей, причём скорее всего с циклами обратной связи, т.е. нелинейной - просто. "Просто" в данном случае больше отражает объём усилий.
Про то что сделать систему простой, т.е. выделить только существенные элементы и взаимосвязи, написано не "сложно", а "нужно приложить усилия". Сама такая деятельность, как правильно заметил @Ndochp не является системой, к ней не применима метрика сложности системы.
Усложнить систему - просто. А сделать простой - нужно приложить усилия.
Эх, были же времена, когда это считалось хорошей рабочей станцией! :)
И для ARM.
Сжатие на уровне строк полезно по факту только если много числовых (numeric) полей с нулями или небольшими значениями (при больших допустимых). Тогда все эти нули будут храниться компактно. Другие выгодные варианты придумать можно, конечно, но базовый, наверное, такой.
Сжатие на уровне страниц - если есть много повторяющихся (но не длинных строковых/бинарных) значений. Повторения могут быть частичными. Способ сжатия описан тут. Доступ к таким данным на чтение и запись дороже по CPU, но для таблиц с кучей похожих чисел и ссылками на другие записи (всеми типовыми способами: уидами, строками, числами, бинарными) жмутся очень хорошо и это часто даёт такой выигрыш при чтении/записи с диска, что становится оправданным. Даже для неплохих систем хранения.
Сжатие бэкапов явно алгоритм не описан, но судя по появлению в 2022 выбора между MS_XPRESS (по умолчанию) and QAT_DEFLATE (для аппаратного ускорения) и по некоторым другим признакам - штатный алгоритм сильно похож на обычный deflate - умеренно хорошо подходит для любых избыточных потоков.
Отсюда уже можно сделать все выводы данной статьи, но по другим соображениям :) Плюс есть всякие хитрозадые опции хранения типа sparse columns, column sets, columnstore indexes и другие. Плюс есть еще соображения разницы между Standard/Enterprise.
И есть еще куча граничных случаев. Так, например "таблица-лог" с большими сообщениями не будет нормально сжиматься ни rows, ни page, зато может в десяток раз сжаться в бэкапе. Таблица с большим количеством низкоселективных ссылочных полей будет отлично жаться в page, зато потом плохо в бэкапе. А может для конкретно случая лучше подойдёт columnstore.
Так что всё равно придётся смотреть по месту, экспериментировать и замерять.
Может быть закрывать лучше в обратном порядке?