Добрый день, сегодня я хотел бы поделится с Вами проблемами и их необычными решениями, которые встретились при написании небольших IT проектов. Сразу скажу, что статья для тех, кто хоть немного разбирается в разработке телеграмм ботов, баз данных, SQL и в языке программировании python.

Весь проект выложен на github, ссылка будет в конце статьи.

Основная проблема

Изначально я хотел для себя написать простенького телеграмм бота счетчика калорий, который получает число от пользователя и возвращает сколько калорий осталось до нормы на день. То есть нужно хранить грубо говоря пару переменных для каждого пользователя.

В данной статье мы разберемся с эксплуатацией некоторых WEB-узвимостей на примере прохождения варгейма Natas. Каждый уровень имеет доступ к паролю следующего уровня. Все пароли также хранятся в файлах /etc/natas_webpass/. Например, пароль для natas5 хранится в файле /etc/natas_webpass/natas5 и доступен для чтения только для пользователей natas4 и natas5.

Прошлые части: часть 1, часть 2 и часть 3.

Иногда медленные запросы можно исправить, немного изменив запрос. Один из таких примеров может быть проиллюстрирован, когда несколько значений сравниваются в предложении WHERE с помощью оператора OR или IN. Часто OR может вызывать сканирование индекса или таблицы, которая может не быть предпочтительным планом выполнения с точки зрения потребления ввода-вывода или общей скорости запросов.

Многие переменные вступают в игру, когда оптимизатор запросов создает план выполнения. Эти переменные включают в себя множество характеристик оборудования, настроек экземпляра, настроек базы данных, статистики (таблица, индекс, auto-generated), а также способ написания запроса. Здесь мы меняем способ написания запроса. Каким бы неожиданным это ни казалось, даже если два разных запроса могут возвращать одни и те же результаты, путь, по которому они идут, может быть совершенно разным в зависимости от формата запроса.

Привет, читатель!

Меня зовут Артём Сайгин, я веду телеграм-канал Growth Lab, в котором делюсь опытом роста IT-продуктов.

В сети много статей по веб-аналитике, но найти действительно стоящие и последовательно сгруппированные материалы нелегко.

Поэтому сделал для вас большую подборку материалов для самостоятельного изучения.
Эта статья легко заменит курсы по веб-аналитике.
Добавляйте в закладки, чтобы не потерять.



Отмечу, что список материалов будет пополняться.

Если я не добавил стоящий материал, свяжитесь со мной — добавлю.

Приступим!

Введение в веб-аналитику

Что такое веб-аналитика и зачем она вам нужна?
Подробное руководство по аналитике веб-трафика
Какие бывают источники трафика
Какие ошибки возникают при работе с Google Analytics и как с ними бороться
Как настраивать представления в Google Analytics — подробное руководство
18 метрик и KPI интернет-маркетинга, которые вы должны знать
Основные термины в веб-аналитике
Что такое UTM-метки и как их применять
Глоссарий: базовые понятия веб-аналитики
Что такое ROI и какие нюансы следует учитывать при его расчете
Модели атрибуции — подробный обзор и сравнение
Модели атрибуции от Google
Что такое A/A тестирование, и как его провести
6 советов начинающему веб-аналитику

Запись об этом появилась в блоге AWS в начале августа. Эталонная реализация выложена на GitHub.

Почему это важно?

ПО поедает мир, а облака начинают поедать ПО. Перенос все большей части инфраструктуры клиента в облако — в интересах и поставщика облачных сервисов, и самого клиента. Первый заинтересован по финансовым соображениям, второй — для обеспечения возможности интеграции своих данных. Здесь, как говорится, если коготок увяз, то всей птичке пропасть.

В прошлый раз мы говорили о блокировках на уровне объектов, в частности — о блокировках отношений. Сегодня посмотрим, как в PostgreSQL устроены блокировки строк и как они используются вместе с блокировками объектов, поговорим про очереди ожидания и про тех, кто лезет без очереди.

Блокировки строк

Устройство

Напомню несколько важных выводов из прошлой статьи.

• Блокировка должна существовать где-то в разделяемой памяти сервера.
• Чем выше гранулярность блокировок, тем меньше конкуренция (contention) среди одновременно работающих процессов.
• С другой стороны, чем выше гранулярность, тем больше места в памяти занимают блокировки.

Нам безусловно хочется, чтобы изменение одной строки не приводило к блокировке других строк той же таблицы. Но и заводить на каждую строку по собственной блокировке мы не можем себе позволить.

Есть разные пути решения этой проблемы. В некоторых СУБД происходит повышение уровня блокировки: если блокировок уровня строк становится слишком много, они заменяются одной более общей блокировкой (например, уровня страницы или всей таблицы).

Как мы увидим позже, в PostgreSQL такой механизм тоже применяется, но только для предикатных блокировок. С блокировками строк дело обстоит иначе.

Домашний роутер (в данном случае FritzBox) умеет многое регистрировать: сколько трафика когда ходит, кто с какой скоростью подключён и т.п. Узнать, что скрывается под непонятными адресатами, мне помог сервер доменных имён (DNS) в локальной сети.

В целом, DNS оказал положительное влияние на домашнюю сеть: добавил скорость, устойчивость и управляемость.

Ниже приведена диаграмма, которая вызвала вопросы и необходимость разбираться в происходящем. В результатах уже отфильтрованы известные и рабочие запросы к серверам доменных имён.

По какой причине каждый день опрашиваются 60 непонятных доменов во время, когда все ещё спят?

Каждый день опрашиваются 440 неизвестных доменов в активное время. Кто это такие и что они делают?

Анализируя статистику сайта, мы получаем представление о том, что происходит с ним. Результаты мы сопоставляем с другими знаниями о продукте или сервисе и этим улучшаем наш опыт.

Когда анализ первых результатов завершён, прошло осмысление информации и сделаны выводы, начинается следующий этап. Возникают идеи: а что будет, если посмотреть на данные с другой стороны?

На этом этапе есть ограничения инструментов анализа. Это одна из причин, почему мне было недостаточно инструмента Google Analytics, а именно, из-за ограниченной возможности видеть свои данные и манипулировать ими.

Всегда хотелось быстро загрузить базовые данные (мастер-данные), добавить другой уровень агрегации или иначе интерпретировать имеющиеся значения.

Это легко сделать в своём маленьком хранилище на основе файла access.log и для этого достаточно языка SQL.

Без преувеличения можно сказать, что SQL — один из самых распространенных в мире языков. Информационные системы могут быть написаны на Java, Python, JavaScript, C#, PHP и десятке других языков, но SQL база в том или ином виде будет в абсолютном большинстве таких систем. Среди бизнес-приложений процент систем, использующих SQL, вообще стремится к 100%.

При этом большинство существующих материалов о SQL на хабре и других ресурсах сводятся к простым вопросам, вроде: «какие типы соединений бывают», «чем левое соединение отличается от правого», «что такое триггеры» и так далее. Более того, в этих материалах практически ничего не говорится о проблемах SQL (и его реализациях), которых на самом деле очень и очень немало. Поэтому мы решили восполнить оба этих пробела: с одной стороны рассказать, как многие вещи в SQL работают изнутри, а с другой стороны — почему они работают не так как нужно / хотелось бы.

При этом речь в статье пойдет не о «вкусах и цветах фломастеров». Все затрагиваемые проблемы носят фундаментальный характер: присутствуют при разработке практически любой информационной системы и не ограничиваются «красотой кода», а в той или иной степени приводят либо к критическому падению производительности, либо к существенному росту порога вхождения, либо к значительным трудозатратам со стороны разработчика.

Два предыдущих цикла статей были посвящены изоляции и многоверсионности и журналированию.

В этом цикле мы поговорим о блокировках (locks). Я буду придерживаться этого термина, но в литературе может встретиться и другой: замóк.

Цикл будет состоять из четырех частей:

1. Блокировки отношений (эта статья);
2. Блокировки строк;
3. Блокировки других объектов и предикатные блокировки;
4. Блокировки в оперативной памяти.

Материал всех статей основан на учебных курсах по администрированию, которые делаем мы с Павлом pluzanov, но не повторяет их дословно и предназначен для вдумчивого чтения и самостоятельного экспериментирования.

Читайте и другие серии.

Индексы:

1. Механизм индексирования;
2. Интерфейс метода доступа, классы и семейства операторов;
3. Hash;
4. B-tree;
5. GiST;
6. SP-GiST;
7. GIN;
8. RUM;
9. BRIN;
10. Bloom.

Изоляция и многоверсионность:

1. Изоляция, как ее понимают стандарт и PostgreSQL;
2. Слои, файлы, страницы — что творится на физическом уровне;
3. Версии строк, виртуальные и вложенные транзакции;
4. Снимки данных и видимость версий строк, горизонт событий;
5. Внутристраничная очистка и HOT-обновления;
6. Обычная очистка (vacuum);
7. Автоматическая очистка (autovacuum);
8. Переполнение счетчика транзакций и заморозка.

Журналирование:

1. Буферный кеш;
2. Журнал предзаписи — как устроен и как используется при восстановлении;
3. Контрольная точка и фоновая запись — зачем нужны и как настраиваются;
4. Настройка журнала — уровни и решаемые задачи, надежность и производительность.

Современные информационные системы достаточно сложны. Не в последнюю очередь их сложность обусловлена сложностью обрабатываемых в них данных. Сложность же данных зачастую заключается в многообразии используемых моделей данных. Так, например, когда данные становятся «большими», одной из доставляющих неудобства характеристик считается не только их объем («volume»), но и их разнообразие («variety»).

Если вы пока не находите изъяна в рассуждениях, то читайте дальше.

Утилита Webalizer и инструмент Google Analytics помогали мне много лет получать представление о том, что происходит на веб сайтах. Сейчас я понимаю, что они дают очень мало полезной информации. Имея доступ к своему файлу access.log, разобраться со статистикой очень просто и для реализации достаточно элементарных инструментов, таких как sqlite, html, языка sql и любого скриптового языка программирования.

Источником данных для Webalizer является файл access.log сервера. Так выглядят его столбики и цифры, из которых понятен лишь общий объём трафика:

Вы любите из раза в раз повторять рутинные операции? Вот и я нет. Но каждый раз в SQL-клиенте при работе с хранилищем Ростелекома приходилось прописывать все джойны между таблицами ручками. И это притом, что в 90% случаев поля и условия соединения таблиц совпадали от запроса к запросу! Казалось бы, любой SQL-клиент имеет функции автозаполнения, но для хранилищ оно не всегда работает: в них редко заводятся unique constraint и foreign key в целях повышения производительности, а без этого программе не узнать, как между собой связаны сущности и что она может тебе предложить.



Пройдя через отрицание, гнев, торг, депрессию и приближаясь к принятию, я решил — а почему бы самому не попробовать реализовать автозаполнение с блекджеком и как положено? Я пользуюсь клиентом dbeaver, написанным на java, у него есть комьюнити версия с открытым исходным кодом. Созрел нехитрый план:

Настройка производительности базы данных — разработчики обычно либо любят это, либо ненавидят. Я получаю удовольствие от этого и хочу поделиться некоторыми методами, которые я использовал в последнее время для настройки плохо выполняющихся запросов в PostgreSQL. Мои методы не является исчерпывающими, скорее учебником для тех, кто просто тащится от тюнинга.

Поиск медленных запросов

Первый очевидный способ начать тюнинг — это найти конкретные операторы, которые работают плохо.

pg_stats_statements

Модуль pg_stats_statements — отличное место для начала. Он просто отслеживает статистику выполнения операторов SQL и может быть простым способом поиска неэффективных запросов.

Как только вы установили этот модуль, системное представление с именем pg_stat_statements будет доступно со всеми своими свойствами. Как только у него будет возможность собрать достаточный объем данных, ищите запросы, которые имеют относительно высокое значение total_time. Сначала сфокусируйтесь на этих операторах.

SELECT *
FROM
  pg_stat_statements
ORDER BY
  total_time DESC;

Как известно индексы играют важную роль в СУБД, предоставляя быстрый поиск к нужным записям. Потому так важно их своевременно обслуживать. Об анализе и оптимизации написано достаточно много материала, в том числе и в Интернете. Например, недавно делался обзор данной темы в этой публикации.

Существует множество как платных, так и бесплатных решений для этого. Например, есть готовое решение, основанное на адаптивном методе оптимизации индексов.

Далее рассмотрим бесплатную утилиту SQLIndexManager, автором которой является AlanDenton.

Как вырасти в 10 раз под количеству запросов к БД не переезжая на более производительный сервер и сохранить работоспособность системы? Я расскажу, как мы боролись с падением производительности нашей базы данных, как оптимизировали SQL запросы, чтобы обслуживать как можно больше пользователей и не повышать расходы на вычислительные ресурсы.

Прочитав сегодняшний топик «SQL. Занимательные задачки», я вспомнил, что давно хотел порекомендовать отличную книгу для продвинутого уровня Oracle SQL от нашего отличного специалиста по Oracle, Алекса Репринцева — «The Power of Oracle SQL». Мало того, что она сама по себе чрезвычайно полезная для тех, кто хочет знать Oracle SQL на высоком уровне, так она еще и бесплатная! Кроме того, есть версии и на русском, и на английском.

В общем, ссылки на саму книгу.

И на обсуждение самой книги с автором.

Привет! Рассказываем о том, что мы сделали в DataGrip за четыре месяца. Если вы используете поддержку баз данных в других наших IDE, этот пост для вас тоже.

Сбор, хранение, преобразование и презентация данных — основные задачи, стоящие перед инженерами данных (англ. data engineer). Отдел Business Intelligence Badoo в сутки принимает и обрабатывает больше 20 млрд событий, отправляемых с пользовательских устройств, или 2 Тб входящих данных.

Исследование и интерпретация всех этих данных — не всегда тривиальные задачи, иногда возникает необходимость выйти за рамки возможностей готовых баз данных. И если вы набрались смелости и решили делать что-то новое, то следует сначала ознакомиться с принципами работы существующих решений.

Словом, любопытствующим и сильным духом разработчикам и адресована эта статья. В ней вы найдёте описание традиционной модели исполнения запросов в реляционных базах данных на примере демонстрационного языка PigletQL.

Здравствуй, Хабр!

Вот уже более 3-х лет я преподаю SQL в разных тренинг центрах, и одним из моих наблюдений является то, что студенты осваивают и понимают SQL лучше, если ставить перед ними задачу, а не просто рассказывать о возможностях и теоретических основах.

В этой статье я поделюсь с вами своим списком задач, которые я даю студентам в качестве домашнего задания и над которыми мы проводим разного рода брейнстормы, что приводит к глубокому и четкому пониманию SQL.



SQL (ˈɛsˈkjuˈɛl; англ. structured query language — «язык структурированных запросов») — декларативный язык программирования, применяемый для создания, модификации и управления данными в реляционной базе данных, управляемой соответствующей системой управления базами данных. Подробнее…

Почитать об SQL можно из разных источников.
Данная статья не преследует цели обучить вас SQL с нуля.