SQL *

Среди применяемых в PostgreSQL методов доступа к данным Index Only Scan стоит особняком, считаясь у многих разработчиков "волшебной пилюлей" для ускорения работы запроса - мол, "Index Scan - плохо, Index Only Scan - хорошо, как только получим его в плане - все станет замечательно".

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

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

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

Всем привет от команды ЮMoney ?

Делимся видеозаписями и главными мыслями митапа High SQL, который посвятили работе с данными в DWH на Microsoft SQL Server.

Кому советуем посмотреть доклады

◾️ Тем, кто планирует перебраться с Microsoft SQL в PostgreSQL, но всё ещё сомневается.

◾️ Тем, кто выбирает между ANTLR и DacFx и хочет научиться решать проблемы во время ревью TSQL-кода.

◾️ И тем, кто хочет узнать, зачем тестировать OLAP-кубы, что может пойти не так и какой результат дают автотесты силами разработчиков и тестировщиков.

В одной из моих предыдущих статей я рассказал о скрипте с названием GentleRebuild, который делал index rebuild в базах, работающих под нагрузкой 24/7, когда нет maintenance window, в Enterprise Edition. Там можно использовать опции ONLINE=ON и даже RESUMABLE=ON, вежливо уступая основной нагрузке базы.

А как же Standard Edition, где этого нет? Каюсь, раньше у меня в скрипте даже стояла проверка, и для Standard Edition скрипт сразу завершался. Но шеф меня попросил заняться и серверами со Standard Edition, и мне пришлось выжать из ситуации максимум.

Пример использования триггеров, при взаимном обновлении таблиц. При таких задачах возникает ошибка мутирования таблиц ORA-04091: table is mutating.

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

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

История более биографическая, чем техническая, с вкраплением мыслей о разработке в целом и небольшим обзором проекта который развивает наша команда. Если вы ждете техно-жесткача с фреймворками, конфигами и кусками кода, то дальше читать не надо - такого не будет. Продолжив вы узнаете про чужой опыт развития долгоживущего продукта, узнаете о еще одном отечественном open source проекте и просто увидите картинки с UI конструктором приложений.

Перед нашей командой была поставлена задача осуществить миграцию из Oracle в PostgreSQL большой (несколько десятков терабайт) работающей базы с нагрузкой порядка 20 миллионов dml-операций в час и генерацией 2ГБ редо-логов в минуту. Особенность задачи состояла в том, что миграция должна была происходить не один-в-один, а по частям в разные шарды. А какие данные в какие шарды и в каком порядке поедут, определялось бы в процессе самой миграции, по результатам этой миграции, в режиме, так сказать, ручного управления.

YQL — это SQL‑диалект, специфичный для базы данных YDB. YQL требует заранее объявлять имена и типы параметров запроса. Это обеспечивает высокую производительность и корректное поведение. В синтаксисе YQL параметры необходимо перечислять явно с помощью инструкции DECLARE. И этот нюанс YDB может быть неожиданным для пользователей традиционных баз данных. В статье раскрывается вспомогательный механизм, позволяющий писать привычные простые SQL‑запросы при работе с YDB.

В данной статье хочу поднять тему, которая представляет собой одну большую боль для администраторов, разработчиков и тестировщиков высоконагруженных (и не очень) систем под управлением PostgreSQL. Даже не «боль», а «БОЛЬ»!

Удивительно, что за почти 30 лет существования PostgreSQL не появилось нормальных инструментов для получения вменяемых счетчиков и трассировок. Все, кто работают с MS SQL Server используют профайлер. Это обязательный и привычный инструмент, который позволяет вылавливать запросы, интересные нам в рамках исследования. Вылавливать как все запросы без разбора, так и какие-то единичные запросы, которые удовлетворяют правилам отбора. Кроме того, можно настроить не одну трассу, а столько сколько нужно, с разными фильтрами. Эти трассы содержат очень богатый набор измерений для анализа: – Reads физические и логические; Writes; SPID, Процессорное время; план запроса (хэш плана), количество строк и т.д.

Многие компании стали всерьез рассматривать СУБД PostgreSQL как замену MSSQL и сталкиваются с тем, что возможностей для ее мониторинга просто нет – она как черный ящик, в котором наощупь вылавливаешь какую-ту информацию и пытаешься систематизировать ее хоть как-то.

Хотя библиотека с открытым исходным кодом QRCode4CS, использованная в статье "Генерация двумерных штрих-кодов QR Code® в отчете SSRS", позволяет отображать QR-коды в отчетах SSRS, оказалось, что она поддерживает только стандарт Micro QR Code, который ограничивает строку ввода до 34 символов.

В отличие от этого, библиотека QRCoder с открытым исходным кодом может поддерживать строку ввода до 2952 символов.

Я довольно долгое время работала аналитиком в Яндекс.Метрике - системе web аналитики. Такие системы помогают сайтам собирать и анализировать поведение пользователей на их сайтах.

Естественно, в таких продуктах как аналитические системы, данные - это главная ценность. Поэтому одна из моих задач как аналитика был мониторинг того, что с данными всё ок.

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

Привет, Хабр! Меня зовут Игорь, я занимаюсь разработкой серверной части в команде RuBackup.

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

Наверняка многие из вас знают, что валидирование пользовательского ввода — краеугольный камень процесса безопасной разработки. С одной стороны, нам как разработчикам не хочется ограничивать пользователей в наборе таких входных данных, как символы и выражения, которые они могут использовать в работе, например, в паролях. С другой стороны, нельзя допустить выполнения в СУБД вредоносного кода, который приводит к SQL-инъекциям. А такие случаи время от времени происходят и становятся достоянием гласности. PostgreSQL дает разработчику возможность решить эту проблему экранированием потенциально опасных символов, превращая их в безопасные. Таким образом, для PostgreSQL будет вполне безвредно, если пользователь в качестве пароля использует строку "password' OR 1=1".

Для защиты от SQL-инъекций в прикладных библиотеках PostgreSQL libpq и libpqxx применяется техника «эскейпинг» или экранирование строки. Она заключается в том, чтобы убрать лишние символы разрыва строк в строках, содержащих специальные символы. С помощью этой функций символы удваиваются и более не считаются окончанием строки, а интерпретируются как обычные символы. Я буду рассматривать только библиотеку libpqxx, так как она, по сути, является С++ оберткой над более низкоуровневой С библиотекой libpq, где и реализованы все функции, о которых далее пойдет речь.

В шахматы меня когда-то легко обыгрывал восьмибитный компьютер, а действующего чемпиона мира IBM-овский Deep Blue одолел уже в 1997 году. Но игра Го держалась значительно дольше: победить обладателя девятого дана Ли Седоля удалось только в 2016 году компании Гугл с машиной AlphaGo. В Го простые правила, которые, однако, приводят к очень сложным стратегическим построениям. Ровно то, что нужно: простое условие, не дающее намека на то, как справиться с задачей одним SQL-запросом. Тема Го и легла в основу задач финала олимпиады, про которую я уже начал рассказывать в прошлый раз.

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

Привет, Хабр!

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

Данная информация предполагает знание основ языка запросов и я надеюсь, она окажется полезной для разработчиков, которые сейчас активно ищут работу а также, что ты прочитаешь этот текст до конца и добавишь свой вопрос к перечню (ну или поправишь неточности в существующих)

Автор статьи: Артем Михайлов

Недавно во время обсуждения по решению проблем, связанных с таймаутами запросов в Azure SQL Database, я подумала — интересно, можете ли вы найти запросы, время ожидания которых истекло, в Query Store (хранилище запросов)?

Оказывается, можно.

Привет! Меня зовут Михаил, я Java Backend Developer в Simbirsoft. В этой статье хочу поделиться своим опытом создания миграций файлов с большим списком данных при помощи Liquibase. Cтолкнувшись с такой задачей на проекте, я был сильно удивлен тому, как мало материалов написано по этой теме, даже на английском. Поэтому описал то, что удалось собрать и проверить на собственном опыте.

Аналитические системы должны эффективно обрабатывать сложные пользовательские запросы к десяткам и сотням терабайт данных (пета-?). Продвинутый оптимизатор запросов является важнейшим компонентом любого big data движка. В данной статье мы рассмотрим, как устроен оптимизатор запросов в массивно-параллельном аналитическом SQL-движке Trino.