SQL *

Если при работе с SQLite вам встречалась ситуация, когда не нашлось нужного функционала, то добро пожаловать под кат. И нет, хранимые процедуры добавить нельзя.

Пятница — самое время занимательных историй. Сегодня предлагаем вам послушать доклады DevOps и SQL-направления с конференции ЮMoneyDay. Специалисты расскажут про:

• устройство кластера логов, который позволяет нам понимать, что происходит с платежами и транзакциями (а также в целом с компонентами и сервисами);
• работу дата-инженеров в машинном обучении;
• внедрение и трансформацию CI/CD.

Делимся ценным опытом, чтобы вы не совершали наших ошибок. Надеемся, будет полезно!

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

Но, поскольку люди — не компьютеры, то и ищут они примерно как "что-то там такое было от Иванова или от Ивановского… нет, не то, раньше, еще раньше… вот оно!"

То есть технически верное решение — это префиксный полнотекстовый поиск с ранжированием результатов по дате.

Но разработчику это грозит жуткими проблемами — ведь для FTS-поиска в PostgreSQL используются «пространственные» типы индексов GIN и GiST, которые не предусматривают «подсовывания» дополнительных данных, кроме текстового вектора.

Остается только грустно вычитывать все записи по совпадению префикса (тысячи их!) и сортировать или, наоборот, идти по индексу даты и фильтровать все встречающиеся записи на совпадение префикса, пока не найдем подходящие (как скоро найдется «абракадабра»?..).

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

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

Как можно управлять сложностью проекта по разработке ETL-трансформаций на Spark?

Тут все не так просто.

Как это выглядит в жизни? Заказчик предлагает создать приложение, собирающее витрину. Вроде бы надо выполнить через Spark SQL код и сохранить результат. В ходе разработки выясняется, что для сборки этой витрины требуется 20 источников данных, из которых 15 похожи, остальные нет. Эти источники надо объединить. Далее выясняется, что для половины из них надо писать собственные процедуры сборки, очистки, нормализации.

И простая витрина после детального описания начинает выглядеть примерно так:



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

Перевод статьи подготовлен в преддверии старта курса «MS SQL Server Developer».

---

Может ли запрос, выполняющийся параллельно, использовать меньше CPU и выполняться быстрее, чем такой же запрос, выполняющийся последовательно?

Да! Для демонстрации я буду использовать две таблицы с одной колонкой типа integer.


Примечание — TSQL скрипт в виде текста находится в конце статьи.

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

Поэтому, когда на каком-то из тысяч подконтрольных серверов случается аномальное потребление ресурсов (CPU, памяти, диска, сети, ...), возникает потребность разобраться «кто виноват, и что делать».


Для оперативного мониторинга использования ресурсов Linux-сервера «в моменте» существует утилита pidstat. То есть если пики нагрузки периодичны — их можно «высидеть» прямо в консоли. Но мы-то хотим эти данные анализировать постфактум, пытаясь найти процесс, создавший максимальную нагрузку на ресурсы.

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



В этой статье рассмотрим, как все это можно экономично расположить в БД, и как максимально эффективно собрать по этим данным отчет с помощью оконных функций и GROUPING SETS.

Для тех, кто не знает, SNAFU — персонаж военных патриотических мультфильмов, созданных американцами во время войны. Этот раздолбай, ввиду природного идиотизма, все время попадает в катастрофические ситуации и, как правило, гибнет в конце серии. Правда, в следующей серии он снова оказывается живым — в этом смысле, его можно считать далеким прародителем Кенни из Южного Парка.

При наборе людей на позицию SQL server developer, я часто был покорен тем, как они отвечали на вопросы. Я готов был сказать им ДА, если бы меня не спасала небольшая задача в одну строчку, которую предложил мой коллега. Удивительно, сколько всего может дать эта задача в одну строку SQL. И вот уже кандидат уже с упоением ходит по граблям. А грабель, как вы увидите, там много. Конечно, ни один человек не собрал ВСЕ возможные грабли. Но, чтобы их все показать, мне и понадобился SNAFU.

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

Наиболее «жизненный» пример — вывести 20 самых старых задач, числящихся на списке сотрудников (например, в рамках одного подразделения). Для различных управленческих «дашбордов» с краткими выжимками по участкам работы похожая тема требуется достаточно часто.



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

Продолжаем серию статей, посвященных исследованию малоизвестных способов улучшения производительности «вроде бы простых» запросов на PostgreSQL:

• редкая запись долетит до середины JOIN
• сизифов JOIN массивов
• вредные JOIN и OR
• CTE JOIN CTE

Не подумайте, что я так сильно не люблю JOIN… :)

Но зачастую без него запрос получается ощутимо производительнее, чем с ним. Поэтому сегодня попробуем вообще избавиться от ресурсоемкого JOIN — с помощью словаря.

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

Пойдем «от обратного» и посмотрим, как делать не стоит, почему, и как можно сделать лучше.

По роду деятельности приходится сталкиваться с ситуациями, когда разработчик пишет запрос и думает "база умная, сама со всем справится!"

В некоторых случаях (частично от незнания возможностей БД, частично от преждевременных оптимизаций) такой подход приводит к появлению «франкенштейнов».

Доброго дня.

Сегодня хочу рассказать про ORM SQLAlchemy. Поговорим о том, что это, про его возможности и гибкость, а также рассмотрим случаи, которые не всегда понятно описаны.

Данная ORM имеет порог вхождения выше среднего, поэтому я попытаюсь объяснить всё простым языком и с примерами. Статья будет полезна тем, кто уже работает с sqlalchemy и хочет прокачать свои навыки или только знакомится с этой библиотекой.

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

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

Эпиграф:
«Когда у тебя в руках молоток, всё вокруг кажется гвоздями».

Как-то давным-давно, кажется – в прошлую пятницу, обходя окрестности офиса, озаботилось окаянное начальство тем, что я провожу время в праздности и созерцании котиков и кошечек.

— А не загрузить ли тебе ФИАС, друг ситный! – сказало начальство. – Ибо процесс его загрузки что-то не нравится нашим бизнес-подразделениям. Долго, говорят грузится, грузит продуктовый сервер, да и чувак, который писал процесс загрузки, намедни уволился, года как три уже.
К тому же, все там давно нужно переделать, так что ты возьми, создай себе базу и обеспечь периодическую заливку ФИАСА. Всё, как говорится, не задерживаю!

Тут надо сказать, что к программированию я имею отдаленное отношение, т.к. являюсь, скорее, DBA. Хотя, с другой то стороны, загрузка больших массивов предварительно отпрепарированной информации – как раз задача DBA, nest pa?

— Да ладно… Щас сделаем – сказал я начальству, и ринулся на сайт ФИАСА, засучив рукава.

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

Как искать по исходникам? Где список файлов? Как найти таблицу? Ответы на эти вопросы — в нашем сегодняшнем видео.

Недавно с некоторым удивлением узнал, что в одном из департментов огромной фирмы, где я работаю, запрещен запуск SQL profiler в business hours.

В моей любимой компьютерной игре Quest for Glory 2: Trial by Fire, когда мир в очередной раз оказывается в опасности, главный герой попадает в Университет волшебников. После успешного прохождения вступительных испытаний бородатые мудрые волшебники предлагают поступить в этот Университет, потому что, окончив его, мы разберемся во всех тонкостях магии, изучим все заклинания и тогда уже точно спасем своих друзей и победим мировое зло. Проблема только в том, что учиться предстоит 15-20 лет, а за это время силы зла успеют победить и не один раз.

Я каждый раз невольно вспоминаю этот эпизод, когда передо мной оказывается очередная интересная книга или кипа технической документации. Про тайм-менеджмент написана куча книг, но для меня это сводится к простой формуле: разобрался в основах, разобрал примеры – дальше только автоматизация!

Теперь, когда мы примерно представляем, как работают инъекции, так почему бы не попробовать упростить себе жизнь и еще раз разобрать какой-нибудь прошлый пример, но уже с помощью дополнительного программного обеспечения. Нам потребуется два инструмента:
Sqlmap – инструмент, которой позволяет автоматизировать поиск и эксплуатацию уязвимостей в SQL и ZAP Proxy – локальный прокси-сервер, который нужен для анализа трафика между браузером в веб-сервером.

Опять нужно упомянуть, что это не единственные подобные инструменты, и наверняка в соседнем блоге вам убедительно докажут, что вместо sqlmap нужно разобраться с sqlninja, а на ZAP тратить время не нужно, когда есть Burp. Спорить ни с кем не стану.

Облегчать жизнь мы себе начнем с перехвата трафика между клиентом и веб-сервером. Полученные данные будут использованы в качестве параметров для sqlmap. По большому счету, в качестве такого параметра может выступать и URL уязвимого приложения, но сейчас данные с прокси будут для нас нагляднее.

Работать будем всё с тем же примером из A1, который мы разбирали в предыдущей статье («SQLi – Extract Data» > «User Info (SQL)»).

Предисловие

Приветствую вновь тебя, уважаемый читатель Хабра!

Когда свои реализованные идеи, опыт, а также всю ту информацию, что не дает покоя, оформляешь в публикации, рано или поздно приходит логическая точка всему ранее написанному потоку информации. Эта статья будет отличаться от всех ранее опубликованных мною своей нестрогостью и более свободным стилем изложения текста, а также она завершит изложение всего моего накопленного опыта по MS SQL Server.

Данная статья является дополнением к статье Исследуем базы данных с помощью T-SQL, а также вкратце рассказывает о созданной базе данных по администрированию SRV и о проектах-утилитах, которые предназначены помочь в работе DBA MS SQL Server.

Введение

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

Но обычные синтаксические анализаторы (ANTLR, например) могут столкнуться с ошибками разбора скриптов, каждый диалект SQL имеет свои собственные особенности. Время анализа тоже может быть существенным на больших БД.

Я хочу показать намного более простой способ: RegEx + небольшой трюк,
итак…