Иногда при анализе производительности запроса на предмет "куда ушло все время" возникает стойкое ощущение deja vu, что вот ровно этот же кусок плана ты уже где-то раньше видел...
Пролистываешь выше - и таки-да, вот он рядом - но почему он там оказался, и как выйти из Матрицы самому и помочь коллегам?
Многие не знают, что некоторые сложные для написания и неэффективные для выполнения SQL-запросы можно легко выразить и эффективно выполнить в графовой базе данных. Это справедливо даже для тех, кто уже знает, что графовые алгоритмы являются наиболее эффективным, а иногда и единственным решением для сложных бизнес-задач, таких как кластеризация пользователей (с использованием Лувенского алгоритма), поиск инфлюенсеров - людей или компаний (алгоритмом PageRank) или прогнозирование поведения пользователей для персональных рекомендаций (алгоритмом label propagation).
В этой статье мы опишем SQL запрос с 24 JOIN в корпоративный knowledge graph и покажем, что задачу можно решить в графовой базе данных - и это будет понятней, более легко поддерживаться и эффективно выполняться. Пример взят из проблемы, описанной в сообществе: https://community.tigergraph.com/
Достаточно часто при работе с вводимыми пользователем адресными данными возникает необходимость сначала подсказать ему, как правильно свой адрес указать, а потом - полученную строку адреса привести в некоторый машинно-читаемый вид.
Таким видом у нас в стране можно считать код по справочникам КЛАДР или ФИАС.
Первый из них уже несколько лет считается устаревающим, но отличается более простой структурой и исторически продолжает использоваться во множестве систем, поскольку вполне подходит для большинства задач.
Давайте научимся разбирать строку адреса "туда и обратно", а заодно познакомимся с некоторыми алгоритмическими подходами и их реализацией на SQL.
Иногда мы пишем SQL-запросы, мало задумываясь над тем фактом, что сначала они должны быть по сети как-то доставлены до сервера, а затем их результат - обратно в клиентское приложение. Если при этом на пути до сервера присутствует еще и пулер соединений типа pgbouncer, дополнительно "перекладывающий" байты между входящими и исходящими коннектами, ситуация становится еще тяжелее...
Поэтому сегодня рассмотрим некоторые типичные ситуации, в которых разработчики иногда принимают не самые оптимальные решения, гоняя по сети мегабайты трафика при общении с сервером PostgreSQL - а заодно посмотрим, как можно увидеть такую ситуацию в плане с помощью explain.tensor.ru и подумаем над вариантами, как сделать подобное взаимодействие более эффективным.
Всем привет. Некоторое время назад пришлось разбираться в ФИАСе, хочу поделиться своими наработками. Эта статья расскажет о том как базу развернуть, как её обновлять и как ей пользоваться.
К счастью мне не пришлось во всём разбираться самому, потому что на Хабре есть хорошая серия статей о ФИАС (Адреса ФИАС в среде PostgreSQL), и у этих статей не менее ценные коменты. На их основе у меня получилось написать скрипты и написать Докер образ, всё опубликовано на ГитХабе.
Как работать с образом описано в README.md, здесь я распишу всё тоже самое но более подробно.
SQL – это нескучно. С современными инструментами возможности языка кратно возросли. Мультитул для моделирования данных dbt, современные колоночные аналитические СУБД позволяют буквально творить с данными чудеса.
Меня зовут Артемий и я Analytics Engineer в компании Wheely. И сегодня я подготовил небольшой экскурс в реальные и интересные сценарии использования гибридного SQL
– Операции Pivot и Unpivot для табличных данных
– Генерирование суррогатного ключа и ключа конкатенации
– Гибкая фильтрация записей из таблиц-источников
– Автоматизация экспорта данных из Хранилища в S3
– Валютные курсы, Continuous Integration, Data Quality
Инструкция SET STATISTICS TIME ON позволяет нам легко получить информацию о времени выполнения запроса. В этой статье посмотрим подробнее, какую именно, и что она означает.
Всем привет. "Не возвращаясь" к нашим баранам из предыдущей статьи "И снова про MS Excel", хочу показать, что же все-таки у меня получилось для работы со скриптами First Response Kit (sp_Blitz) от Brent Ozar и компании. Нравится данный набор и для анализа загруженности SQL Server-а и оптимизации запросов на оном. Причем сам Brent предлагает нечто подобное за денюжку. Для тех кто пользовался, пользуется или думает пользоваться - предлагаю взглянуть на то что у меня получилось.
SELECT version(); version
------------------------------------------------------------
PostgreSQL 15devel on x86_64-pc-linux-gnu, compiled by gcc
(Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0, 64-bit
От корректного функционирования базы данных (БД) может зависеть не только скорость, но и надежность приложения. Для глубокого погружения в задачи специалисту, как правило, нужно освоить работу с транзакциями – об этом и пойдет речь ниже. Рассмотрим виды и свойства транзакций, а также постараемся понять, как устроен этот механизм. Надеемся, что статья может быть полезна начинающим разработчикам и всем, кто хочет лучше разобраться в теме.
В X5 Group активно развивают цифровые продукты, построенные на основе больших данных, использующие сложную аналитику и машинное обучение, такие как прогнозирование спроса, управление ассортиментной матрицей магазинов, предсказание отсутствия товаров на полках, динамическое ценообразования и т.п.
Для разработки продуктов формируются автономные, кросс-функциональные команды, которые имеют минимум внешних зависимостей и могут двигаться вперед с максимальной скоростью. Одной из ключевых ролей в таких командах является роль Data Engineer.
В реляционных базах данных внешние ключи (foreign key) используются для обеспечения целостности связей между таблицами. Простыми словами, внешний ключ — это столбец (или несколько столбцов), ссылающийся на первичный ключ другой таблицы. Таблица с внешним ключом называется дочерней, а с первичным — родительской. При вставке строки в дочернюю таблицу проверяется наличие значения внешнего ключа в родительской таблице. Эти дополнительные операции иногда могут вызывать проблемы с блокировками и приводить к взаимоблокировкам. В этой статье мы изучим, почему это происходит, и как решать подобные проблемы.
Полезная библиотека Pebble Templates и как с ней готовить.
Привет! Рассказываем о том, что мы сделали в DataGrip за четыре месяца. Если вы пользуетесь другими IDE от JetBrains и работаете в них с базами данных, то этот пост для вас тоже.
В этой статье обсудим одну проблему производительности SQL Server, с которой можно столкнуться при вставке большого количества данных.
Иногда необходимо сделать быструю выгрузку данных в интерфейсе Formspider при нажатии на кнопку "Export to XLS", к примеру. Для этого в Formspider создаётся объект ACTION в котором указывается пакет и его процедура, скачивающая нужные данные.
В теле процедуры объявлена переменная формата BLOB, которой присваивается значение, возвращаемое функцией, которой я и хочу поделиться с общественностью (выгрузка из PL/SQL делается при помощи пакетов DBMS_SQL и AS_XLSX).
Когда-то давно, в 2015 году, я опубликовал на Хабре статью, если вкратце "Как я на коленке сделал свое 1С:Предприятие, с блек-джеком и шлюхами".
Но это была, во-первых, двухзвенка, а во-вторых, потребовала от меня столько лапшекода, что после кодирования я надолго погрузился в депрессию. Теперь е я готов представить вам вариант производственного процесса, который не отпугнет перебежчика с 1С на Java.
У вас бывают в разработке такие периоды, когда что-то в коде идет не так, ты ищешь баг, а потом оказывается, что за ним стоял еще один баг? Мне нравится искать баги. Это создает ощущение словно ты Шерлок Холмс и являешься главным героем в детективе, где кто-то из обширного списка на вид безобидных классов и функций вызывает неожиданное и даже неопределенное поведение программы, а ты своим зорким взглядом и экспериментами пытаешься вычислить этого мерзавца в кратчайшие сроки.
Можно выделить несколько стадий поиска бага:
• удивление (не знаю как вы, но я каждый раз как в первый раз удивляюсь когда что-то вдруг в моем коде работает не так, как ожидается);
• обвинение всех кругом в баге (коллег по проекту, github, сторонние либы, компилятор), но только не себя;
• смирение с тем, что возможно баг появился из-за меня и поиск бага: анализ выдаваемого результата, локализация ошибки, эксперименты с входными данными; в общем, все, что делает нормальный детектив, только в сфере программирования;
• если причина бага найдена быстро, то я хвалю себя за то, что нашел баг, при этом, я не напоминаю себе, что причиной бага стал тоже я, а не коллеги по проекту, не github, не сторонние либы и не компилятор;
• если причина бага все время ускользает, то приятное ощущение того, что ты суперпупердетектив сменяется глупой злостью, и чем дольше я не могу найти причину бага, тем больше я злюсь. И вот такие истории почему-то всегда запоминаются больше всех. Об одной такой истории я вам как раз хочу поведать.
Добрый день, уважаемые читатели! Данная публикация посвящена Databricks и она получилась не совсем обычный по двум причинам.
Во-первых, в ней не будут обсуждаться типичные вопросы: целесообразность перевода всех сервисов и служб компаний в облако, возможные ошибки при такой миграции, стоимость использования сервиса, правовые аспекты хранения данных не на территории РФ. Это темы сложные, дискуссионные и без указания конкретных цифр и бизнес-факторов их сложно полноценно раскрыть в статье. Поэтому я решил посмотреть на Databricks под другим углом и заострить внимание читателей на таком аспекте: что может дать изучение инструмента аналитику данных.
Во-вторых, чтобы обзор продукта был максимально комплексным и технически взвешенным я с самого начала планировал написать материал в соавторстве с инженером данных и специалистом в сфере data science. В таком случае была бы возможность донести до читателей концепцию Delta Lake и рассказать о нюансах машинного обучения. Но предложение не нашло отклика в сердцах коллег по цеху, поэтому итоговый результат получился в стиле: “Я художник - я так вижу!”) Это была преамбула, а теперь настало время познакомиться поближе с Databricks.
Работа аналитика требует постоянного пополнения своих знаний - новые инструменты, обновления и методы создаются, как горячие пирожочки. Но перерабатывать такие объемы информации просто нереально, а узнавать что-то новенькое и полезное хочется. И что делать?
Можно, конечно, подписаться на «стоковые» группы и каналы, которые каждый день публикуют по 10-20 постов с «полезным» материалом. Но, признайтесь, это просто самообман: во-первых, столько информации в день просто невозможно пропустить через себя - это только и надо, что статьи читать, а есть же еще работа/учеба. Во-вторых, «полезность» этих статей сомнительна - не каждый пост от умного индуса можно считать полезным, увы :(
Так как же быть? Ответ прост - читать авторские каналы, где реальные специалисты делятся информацией, которую они для себя считают полезной!
Итак, мы собрали для Вас большую подборку телеграм-каналов на любой вкус - каждый найдет для себя что-то интересное. Здесь и BI, и продуктовая аналитика, и программирование, и дашборды, и хранилища данных - одним словом, есть где разгуляться аналитической душе!
Сохраняйте себе и подписывайтесь на ребят - они это точно заслужили! :)