Возможно ли применить статический анализ структуры базы данных к реальным проектам, которые используют PostgeSQL, какой будет результат? Давайте применим и посмотрим что получится. В качестве реальных проектов возьмем инструменты с открытым кодом, которыми многие пользуются ежедневно - GitLab и Redmine.
Быстрое развитие проекта несет в себе множество сложностей: большая вероятность сломать старый функционал или привнести новые баги. Одним из способов поддержания качества кода в хорошем состоянии – это покрытие кода Unit тестами. Но следствием увеличения количества Unit тестов, является увеличение времени исполнения. Попробуем достигнуть максимума – скомбинируем параллельно выполняющиеся UnitTest’ы таким образом, чтобы достигнуть наибольшего быстродействия.
Привет, меня зовут Владимир Сердюк. Я основатель компании Софтпоинт и этой статьей хочу открыть цикл, посвященный распределенным кластерам СУБД с возможностью равномерного распределения нагрузки по всем его серверам.
Идеи создания распределенного вычислительного кластера СУБД (далее РВК) посещали меня достаточно давно. Если упрощенно описать, то программное обеспечение РВК позволяет объединить множество серверов в один суперсервер (кластер), осуществляющий равномерную балансировку всех запросов между отдельными серверами. При этом для приложения, которое работает на РВК все будет выглядеть как будто оно работает с одним сервером и одной базой данных (далее БД), это будут не разрозненные базы данных на распределенных серверах, а как будто одна виртуальная. Все сетевые протоколы, репликационные обмены, прокси-перенаправления будут скрыты внутри РВК. При этом будут эффективно и равномерно использоваться все ресурсы распределенных серверов, в частности, оперативная память и процессорное время.
Популярным языком запросов от Microsoft является DAX. В отличие от диалектов SQL, DAX позволяет аналитикам сфокусироваться на решении задач бизнес-аналитики, вместо того, чтобы заниматься рутинными техническими задачами (например, вопросами производительности).
Безусловно, DAX не является панацеей для решения любых задач, но, если честно, ознакомление с этим функциональным языком может быть своего рода открытием, что создать единый язык для всех SQL диалектов - это вообще "doable", причем поддерживаются практически все имеющиеся базы данных многих видов (например, реляционные, колоночные), а также обеспечивается высокая производительность запросов.
В этой статье рассматриваются преимущества DAX на конкретных примерах, таким образом, если Вам интересен Business Intelligence на DAX - добро пожаловать :)
Сегодня я продолжу знакомить вас с нестандартными задачами, которые появляются в моей работе, и способами их решения.
За информацию из этой статьи, я был готов заплатить деньги, убить или сходить на концерт Шамана.
Уверен, что мой рассказ будет полезен не только пользователям Superset, но и всем аналитикам, которые используют SQL в своей работе и учёбе.
Не буду рассказывать про базовое построение таблиц на BI системе Superset, с этим прекрасно справятся тонны видео на ютубе и бесполезные курсы (про которые я писал ранее). Но сразу скажу, что суперсет в отличие от некоторых других BI систем начинает раскрываться только если ты знаешь SQL, так что хотим мы этого или нет – погружаться в тонкости языка придётся.
Больше двух недель на поиск оптимального решения, ошибки, костыли и элегантный финал.
Итак, Что такое «Вес в приросте» и чем он отличается от обычного «Прироста», и в чем собственно говоря — сложность?
Разберёмся на примере:
Привет, Хабр!
Меня зовут Петр. Я работаю инженером по данным в Okko и обожаю ClickHouse.
Примерно в середине прошлого года мы начали переезжать с PostgreSQL на ClickHouse. Одной из главных причин переезда была низкая производительность: среднее время аналитического запроса составляло около минуты. Сейчас, после переезда, среднее время запроса в аналитическом кластере — около 2 с. И это не предел.
Я расскажу, как мы пришли к текущему состоянию хранилища данных, какие ошибки совершили, какие шишки набили, и о каких фишках кликхауса предпочли бы знать заранее.
Статья в основном для тех, кто только начинает свой путь работы с кликхаусом: мы посмотрим, как делать не надо, и как можно сделать лучше.
В этой статье не будет объяснений почему для переезда мы выбрали именно этот инструмент. Не будет и глубокой теории о его внутреннем устройстве. Отметим лишь: в правильных руках ClickHouse — одна из самых быстрых колоночных СУБД для OLAP запросов.
В предыдущих сериях (FAQ • 1 • 2 • 3 • 4 • 5 • 6 ) мы весьма подробно рассмотрели, как написать на Java собственный интерпретатор объектно-ориентированного диалекта SQL поверх Spark RDD API, заточенный на задачи подготовки и трансформации наборов данных.
В данной части поговорим о том, как добавить в собственный диалект SQL поддержку процедур. Например,
-- library.tdl
CREATE PROCEDURE dwellTimeByMode(@signals, @target, @outPrefix,
@modes = ['pedestrian', 'non_pedestrian', 'car', 'bike'],
@groupid='cell10') AS BEGIN
LOOP $mode IN $modes BEGIN
SELECT * FROM $signals INTO "{$signals}/{$mode}" WHERE mode=$mode;
CALL dwellTime(@signals_userid_attr=userid,
@target_userid_attr=userid,
@target_grouping_attr=$groupid
) INPUT signals FROM "{$signals}/{$mode}", target FROM $target
OUTPUT INTO "{$outPrefix}/{$mode}";
ANALYZE "{$signals}/{$mode}";
ANALYZE "{$outPrefix}/{$mode}";
END;
END;
--- ... --- ... --- ... ---
-- script.tdl
CALL dwellTimeByMode(@signals=$this_month, @target=$population, @outPrefix=$this_month);Нафига это надо?
Ну, допустим, у нас уже есть некоторое количество SQL ETL кода, наработанного за время эксплуатации инструмента в продакшене, и становится заметно, что значительная часть скриптов на разных проектах совпадает, и из раза в раз повторяется. Логично было бы вынести все эти совпадающие куски в библиотеку, чтобы держать в одном месте, да и вызывать с какими надо параметрами, когда надо. Вот прям как на примере выше.
Unit of Work отслеживает все объекты, которые были загружены в память и изменены в ходе выполнения программы. Он управляет их состояниями и сохраняет изменения в базе данных в конце транзакции. Это делается с использованием сессий, которые действуют как контейнеры для всех изменений.
Когда работа завершена, Unit of Work выполняет commit для всех изменений, сохраняя их в базе данных. Если что-то пошло не так, выполняется rollback, и база данных возвращается в состояние до начала транзакции.
В данной статье рассмотрим, как реализовать паттерн Unit of Work с использованием SQLAlchemy.
В SQL server есть замечательная технология - AlwaysOn. Она используется для DR (disaster recovery, асинхронная репликация данных), HA (high availability, часто с automatic failover, что возможно при синхронной репликации), и для того, что мы обсудим в статье: readonly replica для DWH/OLAP/Reporting workload.
Ничто не совершенно (хотя я восхищаюсь простотой установки некоторых решений в MS SQL по сравнению с Postgre и Oracle. Хотя бы бэкапы... А AlwaysOn для маленьких баз заводится буквально в пару кликов).
Cегодня мы рассмотрим проблемы при использовании AlwaysOn для DWH/OLAP/Reporting.
Когда вы анализируете данные, базовых функций SQL часто недостаточно, особенно когда дело касается сложных запросов и обработки больших объемов информации. В таких случаях на помощь приходят функции для работы с массивами в ClickHouse. Однако, многие пользователи не знают о их существовании или не используют их в полной мере.
Эта статья — небольшой гид по функциям работы с массивами в ClickHouse. Мы рассмотрим самые полезные и мощные инструменты, такие как arrayJoin, arrayMap, arrayFilter, и другие. Разберём, как их использовать для решения повседневных задач аналитики данных, на конкретных примерах.
Почему это важно? Потому что умение грамотно работать с массивами позволяет сократить и упростить код, делая его более читаемым и поддерживаемым. Это ключевой навык для тех, кто хочет писать оптимальные запросы.
Вам могут пригодиться array функции, когда стандартные SQL-запросы становятся сложными и трудными для понимания. Например, вместо использования множества подзапросов и объединений для отслеживания последовательности действий пользователя, вы можете использовать функции работы с массивами. Кроме того, использование функций позволяет фильтровать элементы внутри массива, избавляя от необходимости написания сложных условий в подзапросах. Функции работы с массивами в ClickHouse помогут сократить количество кода и упростить запросы, заменяя многократные подзапросы на более элегантные и читабельные решения.
Думаю, вы знаете, что поиск эффективных решений – это половина успеха. Я сам прошел через все эти тернии, когда работа с данными казалась слишком сложной и запутанной. И именно тогда я открыл для себя потрясающие возможности PostgreSQL, которые значительно упростили мою жизнь.
Сегодня я хочу поговорить о трех фичах PostgreSQL, которые помогут сделать работу более продуктивной и вдохновить на создание более сложных и интересных проектов.
Эти фичи уже не раз выручали меня в сложных проектах, и я уверен, что они станут надежными помощниками и в вашей разработке.
В этой статье я не намерен обидеть DBA-разработчиков, но хочу рассмотреть корректность использования хранимых процедур с точки зрения .NET Backend-разработчика. При работе с ними часто возникает невообразимая боль. Причина этого в том, что в какой-то момент казалось отличной идеей поместить всю бизнес-логику нашего приложения в хранимые процедуры и вызывать их из различных сервисов. Однако с течением времени это решение стало неподдерживаемым и проблемным.
На Хабре я часто вижу статьи о реализации тех или иных фич на Python-фреймворках. Я объединил все эти фичи в реальный проект с открытым исходным кодом, чтобы у вас сложилась целостная картина. Мы с вами создадим UX/UI на Figma, напишем фронтенд на HTML, CSS, SASS, Bootstrap и JavaScript, создадим ER-диаграмму в MySQL Workbench, напишем бекэнд на Flask, создадим регистрацию через социальные сети OAuth 2.0 в один клик, используем брокер сообщений и асинхронную очередь Celery для отправки писем на электронную почту, сделаем WYSIWYG-редактор, реализуем полнотекстовый поиск Elasticsearch, закешируем Redis, покроем тестами pytest и запустим в Docker-контейнерах, поговорим о многопроцессности для WSGI-шлюза Gunicorn.
В мире программирования чит-листы — это секретное оружие каждого разработчика. От новичков до опытных программистов, эти чит-листы помогают быстро найти нужную информацию и повысить продуктивность. Сегодня я собрал для вас лучший набор чит-листов по различным языкам программирования и инструментам, от Python до Docker.
Обязательно сохраняйте в закладки!
В данной статье планирую поделиться с вами своей наработкой, которая позволяет создавать меню и кнопки вашего Telegram бота на основе данных хранящихся в БД.
Реализовывать все это будем на Python и нам потребуются библиотеки.
Всем привет!
В прошлой статье мы с вами разобрались, как устроена MPP-архитектура Greenplum. Сегодня мы в сотрудничестве с @imzorin углубимся и разберемся, что представляет из себя DDL в этом хранилище. Также постараемся выделить основные моменты, на которые стоит обращать внимание при выборе типа таблиц, дистрибуции и прочего.
Написание запросов для решения аналитических задач — это основное занятие тех, кто работает с данными Pinterest. Но подбор подходящих данных и преобразование описания проблемы в корректный и эффективный SQL‑код могут оказаться непростыми делами. Ведь речь идёт о среде, которая быстро меняется, и о значительных объёмах данных, разбросанных по разным местам.
Недавно возникла потребность переместить данные из Bubble в Heroku, так как Bubble начал требовать много денег за хранение и доступ к большому кол-ву данных, поэтому было решено переместить данные проекта в Heroku.
В статье рассказано, как вам может помочь утка при работе с данными, с OLAP-нагрузкой и как она может плавать в вашем Data Lake. Вы узнаете всё самое важное про DuckDB и сможете попрактиковаться в работе с DuckDB.