Используете?
Anonymous Poll
30%
Использую wildcards
41%
Стараюсь избегать wildcards
30%
Просто посмотреть результаты
Завтра провожу вебинар по Java “от Junior до Middle”.
О чем буду рассказывать:
- что необходимо знать об архитектуре, чтобы пройти собеседование на Middle-позицию
- как прокачать софт скилы перед собеседованием
- как знание Docker, Kafka и K8S влияет на твое конкурентное преимущества
- как продать себя на более высокую должность
Участие бесплатное, регистрируйтесь по ссылке: https://cutt.ly/ST3yKQr
О чем буду рассказывать:
- что необходимо знать об архитектуре, чтобы пройти собеседование на Middle-позицию
- как прокачать софт скилы перед собеседованием
- как знание Docker, Kafka и K8S влияет на твое конкурентное преимущества
- как продать себя на более высокую должность
Участие бесплатное, регистрируйтесь по ссылке: https://cutt.ly/ST3yKQr
Снова об оптимизации баз данных
Один из часто используемых инструментов для мониторинга состояния БД остается slow queries log - это лог куда СУБД складирует запросы, которые медленнее установленной величины n. Туда попадают и неверно написанные запросы, однако это редко приводит к снижениям нагрузки на БД и главная причина в том, что чаще основную нагрузку генерируют не низкочастотные неоптимизированные запросы, а высокочастотные быстрые.
Предположим, есть два запроса. Первый выполняется 30 секунд, но раз в час. Второй выполняется за 100 мс, но "бомбит" БД 10 раз в секунду. Первый генерирует нагрузку ~1% времени потока, а второй занимает ровно 100%. Оптимизация второго запроса даст в ~100 раз больше профита.
Правда мониторить такие запросы сложнее, но на рынке присутствует много средств мониторинга и профилирования - okmeter, datadog и т.д. Если используете другие - поделитесь в комментариях.
Один из часто используемых инструментов для мониторинга состояния БД остается slow queries log - это лог куда СУБД складирует запросы, которые медленнее установленной величины n. Туда попадают и неверно написанные запросы, однако это редко приводит к снижениям нагрузки на БД и главная причина в том, что чаще основную нагрузку генерируют не низкочастотные неоптимизированные запросы, а высокочастотные быстрые.
Предположим, есть два запроса. Первый выполняется 30 секунд, но раз в час. Второй выполняется за 100 мс, но "бомбит" БД 10 раз в секунду. Первый генерирует нагрузку ~1% времени потока, а второй занимает ровно 100%. Оптимизация второго запроса даст в ~100 раз больше профита.
Правда мониторить такие запросы сложнее, но на рынке присутствует много средств мониторинга и профилирования - okmeter, datadog и т.д. Если используете другие - поделитесь в комментариях.
#повседневное
Вчерашний запрос, "заморозивший" миграцию на три часа:
можно было бы написать сильно оптимальнее вот так:
При сильно похожих WHERE в таких конструкциях, удобнее схлопнуть UNION и "на лету" подставлять в SELECT нужное значение через if.
Вчерашний запрос, "заморозивший" миграцию на три часа:
SELECT entity_id, MAX(start_date), MAX(end_date)
FROM (
SELECT entity_id, MAX(start_date) start_date, NULL AS end_date FROM audit_log
WHERE attr = 'reviewed' AND newValue = 'true'
GROUP BY entity_id
UNION ALL
SELECT entity_id, NULL AS start_date, MAX(end_date) end_date FROM audit_log
WHERE attr = 'overriden' AND newValue = 'true'
GROUP BY entity_id
) a GROUP BY entity_id;
можно было бы написать сильно оптимальнее вот так:
SELECT entity_id,
MAX(if(attr = 'reviewed', NULL, start_date)) AS start_date,
MAX(if(attr = 'reviewed', end_date, NULL)) end_date
FROM audit_log
WHERE (attr = 'reviewed' OR attr='overriden') AND newValue = 'true'
GROUP BY entity_id;
При сильно похожих WHERE в таких конструкциях, удобнее схлопнуть UNION и "на лету" подставлять в SELECT нужное значение через if.
В последнее время периодически раздумываю запустить какой-нибудь проект типа “Контрольный собес”. Знаете - как “Контрольная закупка”, только о собеседованиях на разработчиков в IT-компании.
Так уж сложилось что я подготовил многих людей к собеседованиям, и сам часто проводил собеседования, и проходил их соискатель, в том числе в европейские и азиатские компании. Так вот - определить набор критериев и оценивать компании с точки зрения того, как у них устроен процесс найма IT-шников.
Как думаете - зашло бы такое?
Так уж сложилось что я подготовил многих людей к собеседованиям, и сам часто проводил собеседования, и проходил их соискатель, в том числе в европейские и азиатские компании. Так вот - определить набор критериев и оценивать компании с точки зрения того, как у них устроен процесс найма IT-шников.
Как думаете - зашло бы такое?
Я знаю что это не по теме, и я никогда не хотел тут писать на темы, слабо связанные с IT. Но если честно у меня ощущение, что у нас всех, в том числе айтишников, отбирают будущее. Если еще вчера казалось, что, если что, всегда можно улететь, спрятать голову в песок и т.д., то уже сегодня перспектива не улететь стала реальностью. Реальностью стало и то, что будучи программистом, можно будет не найти работу через месяц. Потому что отрезанный от глобального рынка локальный - не вывезет то количество айтишников и программистов которые на него придут, после разрыва отношений с западными заказчиками.
Но больше всего меня пугает последние дни не сам рынок и его перспективы, а то, что где-то там гибнут родственники моих знакомых и друзей. Все это по той причине, что Путин начал полномасштабную войну против Украины - мирного европейского государства. Нам всем стало в одночастье жить хуже, у всех нас отбирают будущее, у кого-то отобрали и прямо сейчас отбирают настоящее. Я знаю что у меня не большая аудитория - всего 500 человек (и, возможно, станет меньше после этого поста), но это для начала то немногое что я могу сделать и призвать вас подписать открытое письмо российских IT-специалистов:
https://docs.google.com/forms/d/e/1FAIpQLScEsxsoXl_7R4aD5F8-B7fCCBVwU_BXBaOVJsKszbFyRHRkkw/viewform
Но больше всего меня пугает последние дни не сам рынок и его перспективы, а то, что где-то там гибнут родственники моих знакомых и друзей. Все это по той причине, что Путин начал полномасштабную войну против Украины - мирного европейского государства. Нам всем стало в одночастье жить хуже, у всех нас отбирают будущее, у кого-то отобрали и прямо сейчас отбирают настоящее. Я знаю что у меня не большая аудитория - всего 500 человек (и, возможно, станет меньше после этого поста), но это для начала то немногое что я могу сделать и призвать вас подписать открытое письмо российских IT-специалистов:
https://docs.google.com/forms/d/e/1FAIpQLScEsxsoXl_7R4aD5F8-B7fCCBVwU_BXBaOVJsKszbFyRHRkkw/viewform
Google Docs
Оставить подпись под открытым письмом представителей российской ИТ-индустрии по поводу военной операции на территории Украины
Открытое письмо представителей российской ИТ-индустрии против военной операции на территории Украины
Мы, работники российской ИТ-индустрии, категорически против военных действий на территории Украины, начатых вооруженными силами Российской Федерации.
Мы…
Мы, работники российской ИТ-индустрии, категорически против военных действий на территории Украины, начатых вооруженными силами Российской Федерации.
Мы…
Планирую выступать на JPoint в июне. Опять с своей любимой многопоточностью.
Ссылка: https://jpoint.ru/talks/82e4c9067a0fae2844e9d6dbc47023f1/
если вдруг кто будет из подписчиков там - буду рад любому фидбеку ну и вопросам, а если вдруг есть идеи/вопросы заранее - буду рад если зададите, а я смогу доработать доклад чтоб было интереснее и мне и вам.
Ссылка: https://jpoint.ru/talks/82e4c9067a0fae2844e9d6dbc47023f1/
если вдруг кто будет из подписчиков там - буду рад любому фидбеку ну и вопросам, а если вдруг есть идеи/вопросы заранее - буду рад если зададите, а я смогу доработать доклад чтоб было интереснее и мне и вам.
JPoint 2022. Международная Java‑конференция
Многопоточный конвейер в Java — JPoint 2022. Международная Java‑конференция
Андрей разберет эволюцию процесса обработки данных от простого однопоточного Java-приложения до того момента, когда ему уже требуются мощные внешние стриминговые инструменты.
И вместе с тем ответит на вопрос: сколько же потоков требуется многопоточному приложению.
И вместе с тем ответит на вопрос: сколько же потоков требуется многопоточному приложению.
все еще не чувствую себя на 100% комфортно, когда пишу даже короткие приглашения на английском. Поэтому загоняю их иногда в гугл транслейт и проверяю, что все правильно написано, переводя тексты туда-сюда.
Сегодняшний перевод выглядит так:
Я приглашаю вас на запланированную встречу в Zoom.
Я хочу показать вам способы ускорения длительных процессов на примере того, как работает развертывание наших бамбуковых спецификаций.
Насколько правильно использовать ExecutorServices/ThreadPools и сколько реально потоков нужно в вашем коде.
Хотели бы послушать про бамбуковые спецификации? 😏
Сегодняшний перевод выглядит так:
Я приглашаю вас на запланированную встречу в Zoom.
Я хочу показать вам способы ускорения длительных процессов на примере того, как работает развертывание наших бамбуковых спецификаций.
Насколько правильно использовать ExecutorServices/ThreadPools и сколько реально потоков нужно в вашем коде.
Хотели бы послушать про бамбуковые спецификации? 😏
Упали тесты после замены
private static final
на
private static final
угадаете в чем разница?
private static final
Map<String, Validator>
VALIDATORS =
new HashMap<>();
static {
VALIDATORS.put(
"US",
new StatesUSCodeValidator());
}
на
private static final
Map<String, Validator>
VALIDATORS = Map.
of(
"US",
new StatesUSCodeValidator()
);
угадаете в чем разница?
Ребята, а есть кто-то с очень хорошим английским?
У меня уже полгода в полунаписанном состоянии несколько статей и я все боюсь их опубликовать т.к. боюсь что они выглядят неграмотно с точки зрения языка.
Так вот. Я ищу человека который поможет мне в редактировании статей о программировании и дизайне на английском. Нужно будет отредачить (совместно со мной) и высказать свое мнение/критику. Желательно джуновый или мидловый уровень в айти.
С меня - менторинг / подготовка к IT собесам / алгоритмы / ну или просто деньги ^^ кто заинтересон напишите пожалуйста в пм или комменты ваш уровень инглиша / IT и чего бы хотелось получить взамен.
У меня уже полгода в полунаписанном состоянии несколько статей и я все боюсь их опубликовать т.к. боюсь что они выглядят неграмотно с точки зрения языка.
Так вот. Я ищу человека который поможет мне в редактировании статей о программировании и дизайне на английском. Нужно будет отредачить (совместно со мной) и высказать свое мнение/критику. Желательно джуновый или мидловый уровень в айти.
С меня - менторинг / подготовка к IT собесам / алгоритмы / ну или просто деньги ^^ кто заинтересон напишите пожалуйста в пм или комменты ваш уровень инглиша / IT и чего бы хотелось получить взамен.
Опубликовал небольшую заметку о том, как проектировать бд с OLTP-подходом. Наверное следующая будет о том, когда и зачем нужна денормализация.
https://hackernoon.com/principles-of-a-clean-relational-database
https://hackernoon.com/principles-of-a-clean-relational-database
Hackernoon
Principles of a Clean Relational Database | HackerNoon
The article describes how a relational database should be designed to properly work in OLTP mode.
Пару недель назад вышел подкаст со мной на Javaswag. Бегом бронировать полтора часа на послушать разговор за Java, Clean code и собеседования 😏
Forwarded from javaswag
https://soundcloud.com/javaswag/e34
В 34 выпуске подкаста Javaswag поговорили с Андреем Сундуковым о переходе c PHP на Java, чистом коде и о собеседованиях
00:00:09 Инженер дата-центра
00:02:54 Из PHP в Java
00:08:16 Что хорошего в Java с точки зрения PHP
00:11:58 PHP же тоже можно писать читаемый код
00:17:15 Зачем писать чистый код
00:33:39 Clean Code 2.0
00:42:04 Простая 300 строчная функция против чистого кода
00:49:03 Договорились писать "чистый код", что дальше?
00:58:28 Спринг мотивируют писать чистый код
01:04:13 Собеседования, курс From Junior to Middle https://education.dhabits.ru/
01:07:48 Что должно быть в резюме
01:18:29 Что спрашивают Сеньоров?
01:27:04 Систем дизайн интервью
01:32:38 Канал https://t.me/developers_mind
Ссылки от гостя:
Разбор резюме на позицию Java Dev https://www.youtube.com/watch?v=nDRXq21B4PI
Гость - https://t.me/Hcd5opza9bdcjid26fg
Кип сейф! 🖖
В 34 выпуске подкаста Javaswag поговорили с Андреем Сундуковым о переходе c PHP на Java, чистом коде и о собеседованиях
00:00:09 Инженер дата-центра
00:02:54 Из PHP в Java
00:08:16 Что хорошего в Java с точки зрения PHP
00:11:58 PHP же тоже можно писать читаемый код
00:17:15 Зачем писать чистый код
00:33:39 Clean Code 2.0
00:42:04 Простая 300 строчная функция против чистого кода
00:49:03 Договорились писать "чистый код", что дальше?
00:58:28 Спринг мотивируют писать чистый код
01:04:13 Собеседования, курс From Junior to Middle https://education.dhabits.ru/
01:07:48 Что должно быть в резюме
01:18:29 Что спрашивают Сеньоров?
01:27:04 Систем дизайн интервью
01:32:38 Канал https://t.me/developers_mind
Ссылки от гостя:
Разбор резюме на позицию Java Dev https://www.youtube.com/watch?v=nDRXq21B4PI
Гость - https://t.me/Hcd5opza9bdcjid26fg
Кип сейф! 🖖
SoundCloud
Hear the world’s sounds
Explore the largest community of artists, bands, podcasters and creators of music & audio
Вчера был мой 4ый рабочий день на новой работе. Вкратце как проходит онбординг:
день 1 - вводный колл с тиммейтом, получение ноута в середине рабочего дня, небольшая настройка
день 2 - еще пара коллов на полтора часа по онбордингу, изучение всяких онборд доков и настройка доступов, в конце дня получил ключик к репозиторию, стянул основную репу, поковырялся в ней
день 3 - прошел несколько онборд тренингов, получил первую таску (причем по фронтенду, с которым я никогда не работал). стянул фроненд репу, тиммейт помог быстро его запустить, начал разбираться и шерстить как это сделать
день 4 - закончил онборд тренинги, доразбирался с таской, тиммейт помог поправить пару косяков, создал PR, прошел ревью, нажал merge, через полчаса таска уже в продакшене.
Да да, на 4ый день я уже принес пользу и выложил свое поделие в продакшн. Первый раз настолько быстрый и эффективный онбординг и отлично работающие CI/CD, простой понятный код (даже на незнакомых технологиях), отсутствие танцев с бубном для запуска сервисов. Немного даже в шоке 🙂
день 1 - вводный колл с тиммейтом, получение ноута в середине рабочего дня, небольшая настройка
день 2 - еще пара коллов на полтора часа по онбордингу, изучение всяких онборд доков и настройка доступов, в конце дня получил ключик к репозиторию, стянул основную репу, поковырялся в ней
день 3 - прошел несколько онборд тренингов, получил первую таску (причем по фронтенду, с которым я никогда не работал). стянул фроненд репу, тиммейт помог быстро его запустить, начал разбираться и шерстить как это сделать
день 4 - закончил онборд тренинги, доразбирался с таской, тиммейт помог поправить пару косяков, создал PR, прошел ревью, нажал merge, через полчаса таска уже в продакшене.
Да да, на 4ый день я уже принес пользу и выложил свое поделие в продакшн. Первый раз настолько быстрый и эффективный онбординг и отлично работающие CI/CD, простой понятный код (даже на незнакомых технологиях), отсутствие танцев с бубном для запуска сервисов. Немного даже в шоке 🙂
Как быстро на последнем месте работы ваш код впервые попал в продакшн?
Anonymous Poll
18%
до 7 дней
16%
7-20 дней
15%
3-8 недель
7%
2-4 месяца
12%
4+ месяцев
32%
посмотреть результаты
В прошлую субботу выступал в качестве спикера в Белграде на IT-митапе по софт скилам (@belgradeitmeetups). Тема: "behavior собеседования на западном рынке".
Основные тезисы:
1. CV - упор на Achievements вместо Responsibilities
2. English - основная причина провала технарей из СНГ на собеседованиях в иностранные компании
3. Необходимо мыслить с точки зрения вашего value для компании, а не с точки зрения какой вы классный или классная и сколько задачек вы успеваете делать.
По-моему эти три пункта отвечают за 20% усилий и 80% успеха с точки зрения поведенческой оценки кандидата с рынка СНГ для западных компаний. Более того - вчерашнее обсуждение этой темы с моим проджект менеджером из США подтвердило эти тезисы.
В следующих постах раскрою подробнее каждый пункт.
Основные тезисы:
1. CV - упор на Achievements вместо Responsibilities
2. English - основная причина провала технарей из СНГ на собеседованиях в иностранные компании
3. Необходимо мыслить с точки зрения вашего value для компании, а не с точки зрения какой вы классный или классная и сколько задачек вы успеваете делать.
По-моему эти три пункта отвечают за 20% усилий и 80% успеха с точки зрения поведенческой оценки кандидата с рынка СНГ для западных компаний. Более того - вчерашнее обсуждение этой темы с моим проджект менеджером из США подтвердило эти тезисы.
В следующих постах раскрою подробнее каждый пункт.
CV - Responsibilities vs Achievements
Какое же основное отличие резюме для западного рынка и резюме с рынка СНГ? Из моего опыта - это упор на достижения вместо описания зоны ответственности. Особенно удручающе выглядят фразы типа “написание кода”, “исправление багов”, “проведение код ревью” - это похоже на “ответсвенный, коммуникабельный стрессоустойчивый, легкообучаемый” что, конечно, является огромным клише. Итак, вместо “разработка функционала” лучше написать “реализовал рекоммендательную систему, которая увеличила прибыль на 40%”. Вместо “оптимизация кода” лучше написать “оптимзировал главную страницу на 200 мс, что улучшило конверсию на 30% и сэкономило на оборудовании 20%”. Вместо “проведение код ревью” лучше написать “внедрил автоматический процесс проверки качества кода который экономит 20 человекочасов разработчиков IT-департамента еженедельно”. Так уж сложилось что на западном рынке не смотрят на, что специалист делал ежедневно, Намного важнее, чего он достиг и как он поможет бизнесу зарабатывать больше денег. В конце концов зарабатывать деньги - и есть цель любого бизнеса.
Бонусом же к такому подходу в составлении CV будет и то, что и на рынке СНГ такое CV не выглядит чужим. Оно выглядит нормально для западных компаний и свежо для компаний рынка СНГ.
Какое же основное отличие резюме для западного рынка и резюме с рынка СНГ? Из моего опыта - это упор на достижения вместо описания зоны ответственности. Особенно удручающе выглядят фразы типа “написание кода”, “исправление багов”, “проведение код ревью” - это похоже на “ответсвенный, коммуникабельный стрессоустойчивый, легкообучаемый” что, конечно, является огромным клише. Итак, вместо “разработка функционала” лучше написать “реализовал рекоммендательную систему, которая увеличила прибыль на 40%”. Вместо “оптимизация кода” лучше написать “оптимзировал главную страницу на 200 мс, что улучшило конверсию на 30% и сэкономило на оборудовании 20%”. Вместо “проведение код ревью” лучше написать “внедрил автоматический процесс проверки качества кода который экономит 20 человекочасов разработчиков IT-департамента еженедельно”. Так уж сложилось что на западном рынке не смотрят на, что специалист делал ежедневно, Намного важнее, чего он достиг и как он поможет бизнесу зарабатывать больше денег. В конце концов зарабатывать деньги - и есть цель любого бизнеса.
Бонусом же к такому подходу в составлении CV будет и то, что и на рынке СНГ такое CV не выглядит чужим. Оно выглядит нормально для западных компаний и свежо для компаний рынка СНГ.
English
Много раз собеседовался в иностранные компании и получил несколько инсайдов из западных же компаний по поводу главных причин отказа ребятам из России. Несложно догадаться - это уровень английского. Большинству технически сильных кандидатов отказывают из-за низкого уровня коммуникации - для мидловых, а особенно сеньорных ролей, это критически важный момент. Причем такой фидбек и дают: "кандидат технически крутой, но коммуникация это труба, как потом с ним взаимодействовать?". С кандидатами из других стран это проблема намного менее ярко выражена.
Причина? Так уж исторически сложилось, что в русскоговорящем сегменте было много проектов нацеленных на внутренний рынок и много своих кандидатов, потому что русскоговорящий рынок это 250 миллионов культурно похожих и близко проживающих людей. Т.е. всегда можно найти что-то на своем рынке и нет необходимости учить язык. Европейские страны такого свойства были лишены поэтому там уровень знания английского сильно выше.
Что делать, если хотите работать на западном рынке? Учите английский.
Много раз собеседовался в иностранные компании и получил несколько инсайдов из западных же компаний по поводу главных причин отказа ребятам из России. Несложно догадаться - это уровень английского. Большинству технически сильных кандидатов отказывают из-за низкого уровня коммуникации - для мидловых, а особенно сеньорных ролей, это критически важный момент. Причем такой фидбек и дают: "кандидат технически крутой, но коммуникация это труба, как потом с ним взаимодействовать?". С кандидатами из других стран это проблема намного менее ярко выражена.
Причина? Так уж исторически сложилось, что в русскоговорящем сегменте было много проектов нацеленных на внутренний рынок и много своих кандидатов, потому что русскоговорящий рынок это 250 миллионов культурно похожих и близко проживающих людей. Т.е. всегда можно найти что-то на своем рынке и нет необходимости учить язык. Европейские страны такого свойства были лишены поэтому там уровень знания английского сильно выше.
Что делать, если хотите работать на западном рынке? Учите английский.
В новой компании в слаке есть канал #insights куда падают feature-реквесты от пользователей и куда кидают результаты опроса-фидбека по поводу причин почему пользователь начал или прекратил пользоваться услугами компании.
Очень нравится быть намного ближе к пользователям и возможность тут же обсудить их идеи с коллегами, а может и забрать что-то в беклок. Сразу начинаешь и по своим небольшим задачам понимать необходимсть / пользу / критичность.
Очень нравится быть намного ближе к пользователям и возможность тут же обсудить их идеи с коллегами, а может и забрать что-то в беклок. Сразу начинаешь и по своим небольшим задачам понимать необходимсть / пользу / критичность.
Value
И наконец, третье отличие рекрутингового процесса на западе и СНГ-рынка - это ориентация на ценности (или value). По сути эта ориентация в процессе интервью позволит не просто пройти интервью, но и получить позитивную, а зачастую и восторженную, обратную связь от менеджеров. В самом примитивном варианте value - количество заработанных для компании денег, т.е. в процессе интервью показывайте сколько денег сэкономлено или заработано в прошлых компаниях и сколько заработаете для этой. Более продвинутый вариант - это почитать на сайте о ценностях компании и излагать опыт и умения с точки зрения ценностей для конкретной компании. Но последним мерилом ценности и полезности все равно являются деньги, поэтому деньги - универсальная метрика, которая помогает компании оценивать профессионалов. Если доказать, что будете приносить компании $30к, то можно легко просить обоснованную зарплату в $10к.
И наконец, третье отличие рекрутингового процесса на западе и СНГ-рынка - это ориентация на ценности (или value). По сути эта ориентация в процессе интервью позволит не просто пройти интервью, но и получить позитивную, а зачастую и восторженную, обратную связь от менеджеров. В самом примитивном варианте value - количество заработанных для компании денег, т.е. в процессе интервью показывайте сколько денег сэкономлено или заработано в прошлых компаниях и сколько заработаете для этой. Более продвинутый вариант - это почитать на сайте о ценностях компании и излагать опыт и умения с точки зрения ценностей для конкретной компании. Но последним мерилом ценности и полезности все равно являются деньги, поэтому деньги - универсальная метрика, которая помогает компании оценивать профессионалов. Если доказать, что будете приносить компании $30к, то можно легко просить обоснованную зарплату в $10к.
Запостил новую статью про то как делать какие-то прикидки насколько быстро или долго может выполняться тот или иной запрос:
https://hackernoon.com/how-to-make-rough-estimates-of-sql-queries
Но конечно все равно такие вещи сводятся к мониманию архитектуры баз данных, а еще глубже - к знанию как работает железо.
https://hackernoon.com/how-to-make-rough-estimates-of-sql-queries
Но конечно все равно такие вещи сводятся к мониманию архитектуры баз данных, а еще глубже - к знанию как работает железо.
Hackernoon
How to Make Rough Estimates of SQL Queries | HackerNoon
To do estimates of SQL queries we need to understand how DB works with queries. Let's find out what exactly the db do with queries.