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" денормализацией данных?

• почти 9000 баз общим объемом 1PB
• свыше 200TB данных клиентов
• 1500 разработчиков работают с БД

• Анализ запросов
  Наглядно демонстрируем все тайны EXPLAIN [ANALYZE].
• SQL Antipatterns и оптимизация SQL
  Понимаем как [не] надо решать те или иные задачи в PostgreSQL и почему.
• SQL HowTo
  Пробуем подходы к реализации сложных алгоритмов на SQL для развлечения и с пользой.
• DBA
  Присматриваем за базой, чтобы ей легко дышалось.
• Прикладные решения
  Решаем с помощью PostgreSQL конкретные бизнес-задачи.

Всем привет, последние 2-3 года у меня было интересное хобби, интересное для меня - предоставление аналитических услуг компаниям в Канаде и США. В этой статья я хочу поделиться опытом по созданию консалтинг-компании в области аналитики. Могу сразу сказать, что идея провалилась, если оценивать денежную составляющую идеи, но зато я смог получить полезный опыт и расширить кругозор.

В этой статье я расскажу, в чем состоит проблема N + 1 запросов при использовании JPA и Hibernate, и как ее лучше всего исправить. 

Проблема N + 1 не специфична для JPA и Hibernate, с ней вы можете столкнуться и при использовании других технологий доступа к данным.

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

• Дело о непростом пути вверх
  Разберем в live-видео на реальном примере некоторые из способов улучшения производительности иерархического запроса.
• Дело о худеющем запросе
  Увидим, как можно запрос упростить и ускорить в несколько раз, пошагово применяя стандартные методики.
• Дело о развесистой клюкве
  Восстановим структуру БД на основании единственного запроса с 11 JOIN и предложим альтернативный вариант решения на ней той же задачи.