SQL *

Меня иногда спрашивают: «Если в таблице много индексов и SQL Server вынужден анализировать больше вариантов, то не замедлит ли это построение плана запроса?»

Что же, вполне может быть, но что действительно сбивает с толку оптимизатор, так это секционирование. Даже простейшие запросы к секционированным таблицам могут привести к значительному увеличению использования процессорного времени. Хуже того, как однажды сказал знаменитый философ: «Больше секционирования — больше проблем».

Итак, давайте возьмем какую-нибудь из баз данных Stack Overflow и создадим функцию секционирования, которая будет разбивать наши данные по дням:

У каждого из нас есть задача, над решением которой ты долго и безуспешно бьешься, которую изучил уже и вдоль и поперек, но все равно не можешь получить нужный результат. При этом одни уверены, что твоя задача в принципе не имеет решения, другие - что проблемы вообще нет. Такой задачей для меня было большое время выполнения любых запросов к хранилищу данных на Greenplum. И как же приятно наконец-то написать, что я эту проблему победил!

 IVI – кросс-платформенный сервис, а значит, мы должны анализировать метрики всюду: на вебе, телевизорах и мобильных приложениях. Продукт непрерывно развивается, чтобы стать максимально эффективным, удобным и повысить ценность и привлекательность подписки. Перед тем, как внедрить какую-то новую фичу, мы проводим a/b-тесты и исследуем, на сколько востребованным окажется нововведение и как оно повлияет на конверсию или смотрение. Одновременно у нас может проверяться до 70-ти гипотез, от которых непосредственно зависят планы по развитию продукта.

Для того, чтобы правильно оценить успешность или неуспешность теста, требовалось технологичное решение. Новая схема ETL позволила нам иметь хранилище, толерантное к дубликатам. При ошибке в коде мы всегда можем откатить consumer offset в kafka и обработать часть данных снова, не прилагая лишних усилий для движения данных. Хотим рассказать о том, как мы в IVI используем ClickHouse, чтобы посчитать метрики для решения разных продуктовых задач и понять, что мы действительно делаем продукт лучше, а не придумываем фичи, которыми никто не будет пользоваться.

Добрый день уважаемые читатели! О данном методе сегментации клиентов по давности покупок, частоте и сумме сделок написано довольно много материалов. На просторах Интернета вы без труда найдете публикации с описанием теории и практики rfm-анализа. Он может выполняться как на платформе табличного редактора (при небольшом количестве данных), так и с помощью sql-запросов или силами тематических библиотек Python/R. Методология всех примеров одна и та же, расхождение будет только в деталях. Например, порядок присвоения номеров сегментам или принцип деления на группы. Ввиду всего вышеизложенного мне будет трудно привнести новизну в эту тему. В статье я лишь постараюсь заострить ваше внимание на некоторых моментах, которые могут помочь начинающим аналитикам данных.

Всем привет.

Первые пять лет своей карьеры программиста, я работал над in-house проектом, следующие семь лет я работал в разных стартапах, с командой максимум из пяти разработчиков.

Сейчас я пару месяцев работаю над проектом где 20+ разработчиков, работа одновременно ведётся в примерно 30-ти ветках, имеется пять сред для отработки кода (драфт, дев, тестинг, хотфикс, прод), у каждой среды своя БД (перед выкаткой камита на стенд/среду, происходит проверочная выкатка с использованием отдельной БД, то есть на пять сред мы имеем 10 отдельных баз данных).

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

Есть большая проблема с тем как синхронизировать версию кода и версию схемы базы данных.

Ниже я расскажу о правилах которые я принял для себя и буду рад если вы поделитесь своими приёмами и техниками, которые помогают вам справиться с этой бедой.

Добрый день уважаемые читатели! Данная статья является продолжением публикации "Повторяем когортный анализ, выполненный в Power BI, силами Python" (ссылка). Настоятельно рекомендую познакомиться с ней хотя бы бегло, иначе последующее повествование будет вам малопонятным. С момента ее выхода на Хабр прошло достаточно времени. Я основательно пересмотрел методологию решения подобных задач. Первым желанием было просто переписать старый материал, но после недолгих размышлений я пришел к выводу, что более разумным шагом будет оформить наработки в новую рукопись.

Какова основная причина моего "недовольства" Python и Power BI? Язык Python/R c тематическими библиотеками и Power BI (Tableau, Qlik) могут на 70-80% закрыть потребности бизнеса в расчете сложных метрик и построении визуализаций. Но только если речь идет об обработке относительно небольших датасетов с уже агрегированными данными. Если мы говорим о предварительном манипулировании данными в промышленном масштабе, то здесь игра переходит на сторону сервера с БД и используется SQL. Данный момент я не осветил в предыдущей публикации, поэтому решил ликвидировать это упущение здесь.

Тема "распухания" таблиц и индексов из-за реализации MVCC - больная для пользователей и администраторов PostgreSQL.

Однажды я уже поднимал ее в статье "DBA: когда пасует VACUUM — чистим таблицу вручную", разобрав на конкретных примерах, насколько драматический эффект для производительности запросов может оказывать невовремя проведенный или бесполезно отработавший из-за конкурентных транзакций VACUUM.

Но, помимо влияния на скорость, есть еще и факт влияния на занятое место. Наверное, вы сильно удивитесь, если таблица с единственной "живой" записью после успешного прохода autovacuum продолжит занимать гигабайты пространства на дорогих SSD.

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

На днях смотрел вебинар OWOX, где Андрей Осипов (веб-аналитик, автор блога web-analytics.me и лектор Школы веб-аналитики Андрея Осипова) рассказал о своем опыте использования dbt. Говорил о том, кому будет полезен инструмент и какие проблемы решает, а самое главное — как не свихнуться со сложной иерархией таблиц и быть уверенным, что все данные считаются корректно. Я решил расшифровать вебинар в статью, потому что так удобнее возвращаться к информации, а она тут, поверьте, того стоит.

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

Как же совершать их, если вы пишите backend на Node.js + Nest.js?

Привет, Хабр! У кого из вас black belt на sql-ex.ru, признавайтесь? На заре своей карьеры я немало времени провел на этом сайте, практикуясь и оттачивая навыки. Должен отметить, что это было увлекательное и вознаграждающее путешествие. Пришло время воздать должное.

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

Как то мы уже обращались к теме превосходства объектного/типизированного представления в реализации моделей предметной области в сравнении с SQL. И верность тех доводов и фактов на на йоту не уменьшилась. Казалось бы, зачем отступать и обсуждать технологии, которые глобально низвергают абстракции обратно в дообъектную и дотипизированную эпоху? Зачем провоцировать рост спагетти-кода, непроверяемых ошибок и упование на виртуозное мастерство разработчика?

Есть несколько соображений о том, почему стоит поговорить про обмен данными через API на основе SQL/REST/GraphQL, в противовес представлению их в виде типов/объектов:

В основном я предпочитаю использовать реляционные базы данных (SQL), поскольку они предоставляют несколько возможностей, которые весьма полезны при работе с данными. SQLite - отличный выбор, так как база данных там представляет собой единый файл, что упрощает обмен данными. Несмотря на то, что это единый файл, SQLite может обрабатывать до 281 терабайта данных. SQLite также поставляется с клиентом командной строки sqlite3, который отлично подходит для быстрого прототипирования.

Примечание: В других базах данных есть транзакции, языки запросов и схемы. Однако базы данных на основе SQL имеют тенденцию быть более развитыми испытанными временем, а сам SQL стандартизирован.

После перевода статьи Oracle: разница между deterministic и result_cache от Steven Feuerstein, хотелось бы дополнить ее действительно важными деталями их устройства. У меня есть серия статей на эти темы, но тут я хотел бы просто все резюмировать и оставить самое важное.

Мы заканчиваем мини-серию статей о работе с агрегатами в PostgreSQL:

- зачем, как, а стоит ли?

- эффективная обработка потока «фактов»

- многомерные суперагрегаты

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

• Могут ли диапазоны содержать пропуски значений?
• Зачем нужна индексная нотация типу json?
• Может ли индекс при частых обновлениях разрастаться меньше, чем таблица? А вообще не разрастаться?
• Сколько времени простаивали сеансы в idle_in_transaction?
• Как построить ER-диаграмму для таблиц системного каталога?

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

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

От переводчика: свой путь на habr я решил начать не с попытки написать какой-то уникальный текст с нуля, а с перевода относительно свежей (от 17.08.2020) статьи классика PL/SQL-разработки Стивена Фойерштайна, в которой он достаточно подробно рассматривает разницу между двумя основными вариантами кэша результатов выполнения PL/SQL функций. Надеюсь, что этот перевод будет полезен для многих разработчиков, начинающих работу с технологиями Oracle.

В этой статье будут рассмотрены две возможности Oracle Database - создание детерминированных функций (deterministic) и функций, использующий общий кэш результатов исполнения (result_cache). Будут показаны основные сценарии использование каждого из этих видов функций, требования к ним и основные сценарии использования.