Привет, Хабр!
Меня зовут Денис, я Ведущий Продуктовый Аналитик из МТС. Давайте сегодня поговорим про грейды в аналитике. Чем они отличаются? Расскажу, как можно быстро повышать свой грейд.
В целом, в разных компаниях разное понимание того, чем должен обладать тот или иной грейд. Однако, есть основные пункты, которые повторяются во многих командах, про них мы сегодня и поговорим.
Для аналитиков, владение SQL — это база. И от познаний в SQL зачастую зависит, отправит ли вам компания, где вы собеседуетесь — оффер.
В статье мы обсудим четыре области вопросов, которые могут встретиться на собеседованиях по SQL. А в конце рассмотрим три задачки.
Различные СУБД предлагают широкий набор разновидностей операторов JOIN для таблиц. Если Вам встретилась проблема с производительностью CROSS JOIN, - например, декартово произведение таблицы с миллионом записей самой на себя, - добро пожаловать, в этой статье перечислены простейшие способы избавиться от CROSS JOIN.
Конечно, можно пересмотреть и упростить саму бизнес-логику или способы расчетов, в данной статье рассмотрены некоторые базовые случаи, про которые не стоит забывать и имеет смысл проверять первыми. Надеюсь, они окажутся релевантными или смогут помочь найти другие SQL оптимизации.
Примеры в статье рассматриваются на основе CROSS JOIN из ClickHouse. Текущая версия ClickHouse не оптимизирует CROSS JOIN автоматически. Также стоит отметить, что поскольку часто SQL запросы не пишутся вручную, а, например, собираются по частям программно, то перечисленные далее случаи вполне реальны.
GTT – global temporary tables, таблицы которые наполняются и очищаются в рамках ABAP-сессии (application session), но находятся при этом на уровне БД (то есть данные не передаются между Database и Application).
GTT могут помочь сделать код по выборке из БД более удобочитаемым, а также сократить количество передаваемых данных между DataBase и Application.
Многие Golang-разработчики пробовали работать с БД в Go, и у каждого — свои боли. В этой статье разберём библиотеку database/sql как безотносительно конкретной СУБД, так и применительно к YDB. Рассмотрим трудности эксплуатации при использовании драйвера database/sql на проде. А также рассмотрим, что мы делали для решения проблем.
Меня зовут Алексей Мясников, я — руководитель Application Team в команде разработки YDB. Я очень люблю git blame за то, что с его помощью можно проследить, как развивалась инженерная мысль с течением времени и немножко побыть в шкуре разработчика той или иной классной штуки. В статье я расскажу, как реализовать драйвер database/sql для распределённой базы данных, какие проблемы при этом придётся преодолеть и как менялся подход с выходом новых версий Go.
Hola, Amigos! Меня зовут Евгений Шмулевский, я backend-разработчик на Laravel в агентстве продуктовой разработки Amiga. В статье описываю организацию поиска через Meilisearch и нюансы использования в связке с Laravel.
Как реализовать хранение и работу каталога папок в PostgreSQL? Есть большое количество вариантов. Но хочется, чтобы реализация выглядела лаконично, не нарушала прозрачность выполняемых операций, не вызывала блокировок, не требовала большого вовлечения клиента в специфику работы и т.д. Потому сегодня попробуем реализовать хранение древовидных структур и работу с ними без использования триггеров, блокировок, дополнительных таблиц (представлений) и внешних инструментов в SQL.
Данный материал позволит вам подготовиться к собеседованию, освежить знания или познакомиться с такими терминами как транзакции, ACID и уровни изоляции.
Важно отметить, что речь пойдет о реляционных базах данных, которые наилучшим образом подходят для транзакций и соответствуют критериям ACID.
Всем привет!
Как вы знаете, многие поставщики ПО ушли с российского рынка ввиду введённых санкций и многие компании столкнулись с необходимость заняться импортозамещением в кратчайшие сроки. Не стал исключением и наш заказчик. Целевой системой, на которое было принято решение мигрировать старое хранилище, стал Greenplum (далее GP) от компании Arenadata.
Этой статьей мы запускаем цикл материалов посвященных Greenplum. В рамках цикла мы разберем, как вообще устроен GP и как выглядит его архитектура. Постараемся выделить must have практики при работе с данным продуктом, а также обсудим, как можно спроектировать хранилище на GP, осуществлять мониторинг эффективности работы и многое другое. Данный цикл статей будет полезен как разработчикам БД, так и аналитикам.
Сначала запрос адаптирован для работы в PostgreSQL 15.6.
Затем работа запроса проверена на достаточно объемной иерархии - в качестве источника данных использована структура архива jdk-master.zip из OpenJDK 22
Продолжение статьи, в которой предложено решение задачи визуализации иерархической структуры средствами SQL запросов, на примере MySQL и SQLite
В этой части производится доработка запросов для отображения части иерархии, начиная с конкретных узлов, и анализируются возможные связанные ошибки
В процессе тестирования одного курса по SQL на stepik.org встретилась задача, из которой сочинилась другая, более интересная:
Необходимо с помощью одного SQL запроса с использованием обобщенных табличных выражений отобразить иерархию, в соответствии с иллюстрацией выше
Yandex Query Language (YQL) — универсальный декларативный язык запросов к системам хранения и обработки данных, разработанный в Яндексе. А ещё это один из самых нагруженных сервисов: YQL ежедневно обрабатывает около 800 петабайт данных и 600 000 SQL-запросов, и эти показатели постоянно растут.
Изначально YQL основывался на операциях MapReduce, которые эффективны для больших данных. Но для средних объёмов данных (до 50 Гб, которые составляют около 60% запросов) этот подход оказался неоптимальным, потому что нужно было обмениваться данными между операциями через диск. Поэтому разработчики создали новый более гибкий стриминговый движок, который значительно ускоряет обработку данных за счёт выполнения всех вычислений в памяти.
В этой статье я хочу рассказать о подходах и технологиях в разработке систем для обработки данных на примере YQL. Основное внимание я уделил переходу от MapReduce к стриминговому движку, который обеспечивает более эффективную обработку данных, вмещающихся в память, и который доступен в опенсорсе.
Нежданно ни гадано, затеяли значит высшие "итишные" силы включить новые заморские очереди Кафка в уже выполненный на 4/3 проект и слава богу, что только для внешних взаимодействий и передачи всякой информации туды-сюды. Главный архитектор дал благословение и понеслось, да не туда, так как нести то некому это невиданное заморское чудо. Что делать, в обозримые сроки не впихнуть и перед боярами чин и обязательства не сдержать. Посидел РП, погоревал, да сдул пыль со знаний древних и ранее опробованных и тут понеслось.
Недавно мы столкнулись с необходимостью найти библиотеку для удобной работы с базами данных. В проекте было принято решение не использовать ORM, а вместо этого применить миграции. Так как я работал только с ORM, мне, как и автору статьи, было мало знакомо понятие миграций баз данных. В поисках информации о миграциях и популярных решениях, я наткнулся на эту статью. Перевод статьи я оставил ниже. Возможно, она будет вам полезна. Буду признателен, если вы сможете поделиться библиотеками, которые используете.
В предыдущих сериях (FAQ • 1 • 2 • 3 • 4 • 5 ) мы весьма подробно рассмотрели, как написать на Java собственный интерпретатор объектно-ориентированного диалекта SQL поверх Spark RDD API, заточенный на задачи подготовки и трансформации наборов данных.
В данной части поговорим о том, как добавить в выражения SQL поддержку функций. Например,
SELECT
MAX(score1, score2, score3, score4, score5) AS max_score,
MIN(score1, score2, score3, score4, score5) AS min_score,
MEDIAN(score1, score2, score3, score4, score5) AS median_score,
score1 + score2 + score3 + score4 + score5 AS score_sum
FROM raw_scores INTO final_scores
WHERE ABS(score1 + score2 + score3 + score4 + score5) > $score_margin;— тут у нас функции MAX, MIN и MEDIAN принимают любое количество аргументов типа Double и возвращают Double, а ABS только один такой аргумент.
Вообще, кроме общей математики, в любом уважающем себя диалекте SQL как минимум должны быть функции для манипуляций с датой/временем, работы со строками и массивами. Их мы тоже обязательно добавим. В classpath, чтобы движок мог их оттуда подгружать. До кучи, ещё и операторы типа >= или LIKE, которые у нас уже были реализованы, но хардкодом, сделаем такими же подключаемыми.
Уровень сложности данной серии статей в целом высокий. Базовые понятия в тексте совсем не объясняются, да и продвинутые далеко не все. Однако, эта часть несколько проще для ознакомления, чем предыдущие. Но всё равно, понимать её будет легче, если вы уже пробежались по остальным хотя бы по диагонали.
Иван Якунин, продуктовый аналитик команды Fintech Marketplace, рассказал про то, как в Авито работают с Vertica, и на примерах объяснил, что такое проекции, и когда их стоит использовать.
В данной публикации я поделюсь двумя основными причинами, по которым я предпочитаю избегать использования автоинкрементных полей в PostgreSQL и MySQL в будущих проектах. Вместо этого я предпочитаю использовать UUID-поля, за исключением случаев, когда есть очень веские аргументы против этого подхода.
Всем привет!
В этой статье возьмем за основу пару таблиц и пройдемся по планам запросов по нарастающей: от обычного селекта до джойнов, оконок и репартиционирования. Посмотрим, чем отличаются виды планов друг от друга, что в них изменяется от запроса к запросу и разберем каждую строчку на примере партиционированной и непартиционированной таблицы.
В статье рассматриваются назначение, основные особенности и возможности Фреймворка “DBGridChart” и OLAP – приложения “Экспресс_обработка.exe” (разработчик – Плещев В.В., http://vipuskniki.usue.ru/Docum.html - DLL, исходные тексты, описание и демонстрационные примеры).
Фреймворк ориентирован на автоматизацию разработки программ на C# по формированию входных табличных и ленточных документов для ведения баз данных c СУБД SQL Server, PostgeSQL, MySQL, Access в режиме непостоянного соединения ADO .NET и немедленного (без промежуточного накопления изменений) добавления, удаления или изменения записей с соблюдением целостности базы данных, а также для формирования заранее нерегламентированных аналитических таблиц и диаграмм для анализа данных, по унифицированной технологии (с использованием управляющих элементов dataGridView и Chart в C#) с много функциональным, унифицированным, адаптивным и комфортным для пользователей готовым интерфейсом.
OLAP-приложение “Экспресс_обработка.exe” позволяет: вынести описания запросов Select из исходных текстов программ в отдельный текстовый файл, что исключает необходимость в разработке оригинальных программ для ведения баз данных с различными СУБД и формирования аналитических таблиц и диаграмм. Для формирования запросов разработан специальный визуальный конструктор.
Информация о таблицах, запросах Select и их полях берется автоматически конструктором из базы данных. Не выходя из приложения, пользователь может оперативно визуальным конструктором запросов формировать, сохранять и использовать запросы для анализа данных и ведения базы данных. Само приложение реализовано средствами Фреймворка “DBGridChart”.