SQL *

Привет, Хабр! Это Ахмед Шериев, сооснователь стартапа VoxOps, а сегодня — еще и гостевой автор блога Friflex. Моя статья — про опыт разработки офлайн-приложений. 

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

Здесь постараюсь поделиться, как не зарыться в тонну инфраструктурного кода и избежать некоторых других ошибок.    

Я внедрял поддержку offline как в роли разработчика, так и в роли руководителя и директора по разработке. Поэтому тема мне хорошо знакома с обеих сторон. Кто помнит, с ней я выступал на CrossConf.

В статье рассматривается использование теста TPC-H с PostgreSQL и проблемы, связанные с запросами Q17-Q20 теста.

Введение

Вместе с PostgreSQL поставляется утилит pg_bench с "TPC-B like" тестом. Кроме этого теста были созданы тесты TPC-R для отчётов, TPC-D для OLAP, TPC-W для заказов в веб-магазине, которые не получили распространения. На основе TPC-D был создан более удачный тест TPC-H для хранилищ данных и аналитических запросов ("OLAP нагрузка"). В тесте используется 8 таблиц и 17 ограничений целостности. В TPC-H выделены номинации по размерам обрабатываемых данных от "до 100Гб" до  30-100Тб. Тест TPC-H предназначен для хранилищ данных, включает в себя 22 запроса, которые называют Q1 ... Q22.

Запросы теста TPC-H не меняют данные в таблицах, а значит, для повторных тестирований не нужно пересоздавать или вакуумировать таблицы. В тестах TPC-B, TPC-C, TPC-E запросы довольно простые. В реальных приложениях запросы более сложные, чем в этих тестах. Поэтому для тестирования того, как СУБД выполняет запросы, которые могут встретиться в реальных приложениях, можно использовать все или отдельные запросы из теста TPC-H. Для быстрого аудита производительности различных СУБД используют вариант с 1Гб данных. В этом варианте запросы выполняются быстро, не нужно много памяти под экземпляр СУБД и много места на диске. Можно найти программы или скрипты для большинства СУБД, например, для PostgreSQL, Oracle Database, MySQL. После теста TPC-H появился тест TPC-DS с 99 запросами, но он менее популярен.

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

Сегодня рассмотрим, как на голом SQL построить полноценный когортный анализ: определим дату первой покупки, сгруппируем пользователей по когортам, посчитаем удержание (retention), оценим LTV по месяцам жизни и сделаем RFM-сегментацию.

Я уже не раз поднимал в статьях тему [не]эффективной работы с json[b] в PostgreSQL — и как его лучше превращать в выборку, и как можно «транспонировать». Сегодня же рассмотрим некоторые возможности по его генерации на стороне базы.

В моей предыдущей статье я отображал метрики из записанного SQL profiler trace на листинг stored процедуры. Это идеально подходит к тестовым окружениям, но в production надо быть осторожным, и запись "частых" событий могут увеличивать CPU сервера и замедлять его работу.

@speshuric предложил использовать данные из Query Store. Там, правда, нет номеров строк. Но можно выкрутиться, так как есть смещения и можно посчитать количество переводов строки до смещения. Итак, сказано - сделано!

Привет! Меня зовут Андрей Дорожкин, и я руковожу командой администрации баз данных в Hybrid. В этом материале я поделюсь опытом работы с ClickHouse — колоночной БД, разработанной специально для аналитических запросов, которая позволяет получать результаты в разы быстрее традиционных решений. Также я подсвечу, как устроен этот продукт, чем он отличается от реляционных баз данных, и в каких сценариях его использование может дать бизнесу реальное преимущество.

Пара слов о компании Hybrid. Мы — независимая AdTech-экосистема с собственным стеком технологий и решений для любых рекламных целей. Развиваем собственные технологии благодаря in-house отделу разработки, который каждый день работает над их улучшением. ClickHouse — инструмент, который мы выбираем для хранения данных за высокую скорость обработки запросов, эффективное сжатие данных и масштабируемость.

Выбор облачного хранилища данных — задача не из простых: десятки решений, каждая со своими плюсами и подводными камнями. В этой статье — результаты масштабного практического исследования, в ходе которого команда Agritask сравнила производительность, масштабируемость, стоимость и совместимость SQL ведущих платформ: от ClickHouse и BigQuery до Druid и Firebolt. Без маркетинговых обещаний — только реальные тесты, живые выводы и нюансы, которые неочевидны до момента внедрения.

Вам интересно, какие индексы используются больше или меньше? Какие не используются вовсе? Какие таблицы и индексы самые большие? Очень легко создать такие диаграммы. Это и красиво, и полезно.

Привет, Хабр! Когда-то я проверяла завещания и готовила доверенности, а теперь проверяю витрины данных, ищу дубли и считаю доходность по инвестиционным инструментам. Меня зовут Арина Шахтарина, и я — Data Quality-инженер в Сбере. Это история о том, как любовь к данным и таблицам превратилась в новую профессию, и почему SQL — лучший универсальный язык после русского. Тут будет про карьерные повороты, боли с форматами данных, проверки данных и немного про мечты, которые сбываются (даже если ты не в отпуске).

В этой челлендж-серии статей попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2024.

Возможно, SQL не самый подходящий для этого язык, зато мы рассмотрим его различные возможности, о которых вы могли и не подозревать.

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

Бум No-code начался в 2022 году, и сейчас многие компании стараются так или иначе внедрить функционал «low-code» в свои продукты. У участников IT-индустрии пока нет согласия о границах применимости технологий «без кода», хотя адепты этих технологий обещают, что они позволят создавать практически любые приложения.

В этой заметке мы рассмотрим один из основных аспектов создания приложений – его масштабируемость в средней и дальней перспективе. Для этого сам продукт под капотом должен быть построен на чем-то более мощном, чем MS Excel, Airtable, Notion и Make, и такие продукты уже есть на рынке.

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

Выбор облачного хранилища данных — задача не из тривиальных, особенно когда речь идёт о миллиардах полуструктурированных записей, геоаналитике и требованиях к отклику в доли секунды. В Agritask мы провели масштабное исследование: протестировали популярные DWH-платформы на реальных кейсах, сравнили производительность, параллелизм и затраты. В первой части делимся подходом к оценке, техническими требованиями и тем, почему PostgreSQL и Snowflake перестали справляться с нашими задачами.

Предлагаю вашему вниманию немного дополненный доклад, который я делал на конференции PGConf.СПб 2024. В нем я рассказываю о том, как появились первые реляционные системы, как возник и всех победил язык SQL.

Приветствую всех хаброжителей и тех, кто читает мою статью. Меня зовут Александр, я являюсь ИТ директором с более 15-летним стажем, начинал в 2002 году обычным программистом в международной FMCG компании, что сильно повлияло на меня как человека и как ИТ специалиста.

Но статья не об этом, повествование пойдет о другом, об 1С и SQL, а именно о том, как быть если нужно выгружать данные из этой самой 1С, да еще, когда она не одна, да и в разных городах и странах. Трудился я в международной алкогольной компании и достался мне «зоопарк» ИТ систем (думаю, что многим понятно и известно, о чем я говорю). Среди этих систем была самописная ERP система с подчиненными базами (больше 100 штук) на базе СУБД Firebird и клиенты, написанные на Delphi и Microsoft С#, годами пока это все развивалось и росло, появились запросы и потребность в анализе данных и стали реализовываться различные выгрузки данных. Получаемые данные как тогда водилось стали выгружать в MS SQL в специально созданную базу (DWH) используя MS SSIS и потом трансформировались в OLAP кубы в MS SSAS. Еще была систем именуемая как «Бизнес-процессы» на базе 1С Бухгалтерия 1.6, с последующим обновлением и совместимостью, чтобы запустится на платформе 1С 8.3, на обычных формах с многокилометровыми модулями кода. Обшито все это было микросервисами (как сейчас это принято называть) и обменивалось между собой как-то, никому 100% не известно как.

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

В этой статье поговорим про MERGE в MS SQL Server. Не просто MERGE, а MERGE с OUTPUT — как обновлять данные, вставлять новые и одновременно логировать изменения.

Оператор MERGE позволяет объединить INSERT, UPDATE и DELETE. Клаузу OUTPUT можно прикрутить, чтобы получить, что именно поменялось — с деталями: было, стало, когда, зачем и кто виноват.

Привет!

Все мы слышали, что сегодня данные - это новая нефть. Но вот вопрос: а как мне их использовать? Ты видишь цифры, графики, метрики, а прибыль всё равно стоит на месте. Я когда-то думал, что данные — это просто отчеты для начальства. Пока не понял: данные — это истории. Истории о том, как ваши пользователи радуются, злятся, теряются или готовы платить. И если их «услышать», они принесут реальные деньги. Давайте разберемся, как это сделать — без магии, только логика и немного цифр.

Индексы – это «ускорители» доступа к данным в базах данных. Правильно выбранные индексы могут многократно ускорить запросы, что особенно критично в highload-системах с большими объёмами данных и большим числом запросов. Однако за ускорение чтения приходится платить усложнением записи и дополнительным расходом памяти. В этой статье мы подробно рассмотрим, как работают разные типы индексов в реляционных СУБД, как выбирать индекс под конкретный запрос, обсудим подводные камни (например, блоат, переиндексация, избыточные индексы) и затронем индексацию в NoSQL (MongoDB, Cassandra). Завершим чеклистом, который поможет выбрать оптимальный индекс под вашу задачу.

Привет, Хабр! Меня зовут Александр Овсов, я RnD-разработчик в компании Just AI и занимаюсь продуктом Jay Knowledge Hub. Это умная платформа для поиска по неразмеченным корпоративным данным, созданная на базе RAG и AI-агентов.

Одним из типичных юзкейсов для наших пользователей является аналитика сложных данных хранящихся в CSV-таблицах (финансовые отчеты, продуктовая аналитика и т.д.). Работать с такими данными при помощи классических методов RAG сложно из-за структуры этих данных. Чтобы решить эту проблему, мы решили использовать агентский подход — набирающий популярность метод, который позволяет LLM выполнять сложные задачи, например, отправлять SQL-запросы к таблицам. О реализации такого подхода на примере CSV таблиц я сейчас и расскажу.

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

В этой челлендж-серии статей попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2024.

Возможно, SQL не самый подходящий для этого язык, зато мы рассмотрим его различные возможности, о которых вы могли и не подозревать.

Рекурсивно вычисляем логические выражения и разбираем устройство двоичного сумматора.