SQL *

Особо углубляться в описание малинового продукта нет необходимости. Глобальная сеть пестрит статьями с описанием как самого микрокомпьютера, так и проектов на нем.

Не буду лукавить и приводить кучу доказательств и обоснований того почему сделано так как сделано (а с учетом ценников на пром автоматику, система получилась копеечная, <150$ против самой дешевой дельты с ограниченным функционалом за 300$), так как давным-давно меня заинтересовал симбиоз RasberyPi и программного комплекса промышленной автоматизации Codesys и хотелось проверить на реально необходимом проекте. И только поэтому был выбран данный «Hardware», хоть и сомнение в стабильной работе не покидали до последнего момента.

Сегодня я расскажу о том, как использовать функцию `UNNEST` в Google BigQuery для анализа параметров событий и свойств пользователей, которые вы получаете вместе с данными Google Analytics.

Привет, Хабр! Меня зовут Артемий Козырь.

За последние годы у меня накопился довольно обширный опыт работы с данными и тем, что сейчас называют Big Data.

Не так давно также разгорелся интерес к сфере интернет-маркетинга и Сквозной Аналитики, и не на пустом месте. Мой друг из действующего агентства снабдил меня данными и кейсами реальных клиентов, и тут засквозило понеслось.
Получается довольно интересно: Azure SQL + dbt + Github Actions + Metabase.

GET /api/products?page=10
{"items": [...100 products]}

GET /api/products?page=11
{"items": [...another 100 products]}

Для многих систем характерен паттерн постоянного накопления данных с течением времени. Причем основная их масса больше никогда не изменяется - то есть они пишутся в режиме append-only.

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

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

Транзация — это набор операций по работе с базой данных, объединенных в одну атомарную пачку.

Транзакционные базы данных (базы, работающие через транзакции) выполняют требования ACID, которые обеспечивают безопасность данных. В том числе финансовых данных ? Поэтому разработчики их и выбирают.

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

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

Бессерверный SQL — это инструмент распределенных вычислений, который позволяет обрабатывать распределенные данные с помощью языка SQL без необходимости администрировать серверы баз данных. Если у нас есть данные, или даже "большие данные", в одном из наших озер или хранилищ, например AWS S3 или хранилище BLOB-объектов Azure, мы сможем выполнить запрос SQL на этих данных без необходимости создавать конвейер или импортировать данные в распределенные базы данных, например в Cassandra или MongoDB.

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

Подробности под катом!

Одним из наиболее частых требований-"хотелок" бизнеса является построение всяких разных рейтингов - "самые оборотистые клиенты", "самые продаваемые позиции", "самые активные сотрудники", … - любимая тема разных дашбордов.

Традиционно, есть два подхода к этой задаче: запрос по требованию по "сырым" данным или предварительная агрегация. И если "просто посчитать" такой отчет по первичке - упражнение для SQL-новичка, но очень "тяжелое" для производительности СУБД, то вариант сделать так, чтобы он строился практически мгновенно при большом количестве активных аккаунтов независимых бизнесов, как у нас в СБИС, без необходимости пересчитывать агрегированную статистику каждый день судорожно по всем клиентам - интересная задача.

Я – выскочка. По крайней мере, так я себя иногда ощущаю. Закончив второй курс политологии и журналистики в университете, я увидел американский рейтинг профессий по уровню оплаты труда. Журналист в этом рейтинге был на последнем месте, а на первых местах были data scientists и data engineers (политолога в этом списке, почему-то, не было). Я не знал, кто составлял этот список, и понятия не имел, кто такие эти data-челы с первых строк, но он меня впечатлил. Я бросил пить и начал проходить курсы на Coursera, а потом каким-то чудом заполучил студенческую подработку в стартапе. Так я сделал своё «войти в IT».

Когда человек, не имеющий университетской подготовки, пытается начать программировать, то он чувствует себя несчастным, который, увидев из окна солнце, вышел на улицу и попал под неожиданный в столь прекрасный день град: шаблоны проектирования, функции, классы, ООП, инкапсуляция, протоколы, потоки, ACID… Хочется прокричать, как Виктор Фёдорович в своё время:

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

Тем не менее, в связи с ростом популярности аджайл методологии в последние годы и востребованностью непрерывной интеграции и развертывания, мы больше не можем ограничивать применение CI/CD только к коду приложения, оставив SQL позади.

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

Ниже будут рассмотрены сходства и различия ныне хорошо известных продуктов Flyway и Liquibase.

• устройство кластера логов, который позволяет нам понимать, что происходит с платежами и транзакциями (а также в целом с компонентами и сервисами);
• работу дата-инженеров в машинном обучении;
• внедрение и трансформацию CI/CD.

Разрабатывая модуль для OpenCart, возникла необходимость сделать произвольное поле в карточке товара, которое должно быть видно только в админке. Это должно быть поле с логическим значением "маркирован товар или нет".

CREATE TABLE task AS
SELECT
  id
, (random() * 100)::integer person -- всего 100 сотрудников
, least(trunc(-ln(random()) / ln(2)), 10)::integer priority -- каждый следующий приоритет в 2 раза менее вероятен
FROM
  generate_series(1, 1e5) id; -- 100K задач
CREATE INDEX ON task(person, priority);

SELECT
  *
FROM
  generate_series(0, 99) pid
WHERE
  EXISTS(
    SELECT
      NULL
    FROM
      task
    WHERE
      person = pid AND
      priority = 10
  );

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

EXPLAIN <-> SQL

Приглашаем на мастер-классы «Тюнинг и масштабирование проекта на MySQL» 15—17 декабря 2020. Расскажем, что именно настроить, чтобы база не тормозила и не падала, а данные не терялись. Поможем найти медленные запросы и сделать их быстрыми.

Мастер-классы ведет Владимир Федорков, специалист по настройке и эксплуатации СУБД MySQL, эксперт в сфере производительности MySQL, постоянный спикер конференций в России, Европе и США.

Недавно мы с коллегой по профессии обсуждали в Интернете (точнее в ЛС на Хабре) архитектуру некоторой системы, и у нас возник спор по одному вопросу.

Имеется склад, где хранятся разные материалы, имеются документы прихода и расхода материалов, в документах есть записи с информацией "материал, количество", связь один-ко-многим. В базе данных есть таблица с информацией о текущем наличии материалов на складе, есть таблица для документов и таблица для их позиций. Назовем их "current_stocks", "documents", "document_positions".

Считать ли таблицу "current_stocks" денормализацией данных?