Привет, Хабр! Хочу поделиться самодельной питонской библиотекой, существенно упрощающей взаимодествие с базами данных.
«Написать свой собственный ORM» – неплохая задачка для тех, кто решил поглубже изучить некоторые языковые особенности Питона, но в данном случае задача была другая – написать не ORM, а не-ORM. Механизм, упорядочивающий и облегчающий доступ к базам данных, но который сам по себе ни в коей мере не является ORM-ом.
Недавно появились мысли походить на собеседования чем я успешно занялся. Если конкретно - смотрел лидовскую/сеньерскую позиции на Python и Golang(но статья может пригодиться backend разработчикам в целом). Не ставлю целью статьи объять все не объятное и дать какие-то гарантии. Я лишь зафиксирую данные для себя на будущее.
Вообще ходить на собеседования неплохой навык - в моем случае удается неплохо прокачать технические скилы и узнать запросы рынка на текущий момент(ведь может случиться так, что твои навыки перестанут быть актуальными).
Сразу сделаю пометку, что некоторые навыки/ресурсы специфичны(по типу нарешивания Leetcode), но отталкиваемся от текущих реалий рынка.
Иногда типичная IT-инфраструктура крупной компании выгляд так: PostgreSQL для аналитики, и Oracle для корпоративных данных, и MySQL для каких-нибудь микросервисов. В таких условиях взаимодействие между различными системами становится настоящим мастхевом. И тут может помочь герой нашей статьи - dblink.
dblink позволяет нам безболезненно дергать данные из одной базы в другую, будь то PostgreSQL или что-то вроде Oracle или MySQL.
Привет! Меня зовут Никита Грибков, я Flutter-разработчик в AGIMA. В сети море статей о различиях между SQL и NoSQL, но в большинстве из них много теории и почти совсем нет прикладных советов. Я пошел другим путем: ниже постараюсь внятно объяснить, какую систему и в каком случае выбирать. Спойлер: всё зависит от проекта и амбиций заказчика. Конечно, сосредоточусь на мобильной разработке, но основные принципы подойдут и в вебе.
Привет, Хабр!
Представьте себе, вы приходите домой после долгого рабочего дня, и вас встречает пушистый котик. Вы знаете, что он ждет вас, чтобы вы рассказали ему о своих подвигах на работе. И вот, вы начинаете свой рассказ, а он, этот милый мурлыка, вдруг спрашивает: "А как там у тебя с оптимизацией запросов в PostgreSQL?"
Вы, конечно, удивлены: "Откуда у кота такие знания?" Но котик смотрит на вас с понимающим видом и говорит: "Ведь хороший запрос должен быть как прыжок кошки - быстрым, точным и грациозным..."
В 2024 году вопросы и тестовые задания на собеседованиях не потеряли своей актуальности и продолжают вызывать огромный интерес у соискателей. Если вы сейчас погружены в процесс прохождения интервью, то наверняка сталкиваетесь с множеством непростых, но захватывающих задач.
Давайте вместе рассмотрим некоторые из новых вопросов и задач, которые реально задаются на собеседованиях в различных командах. Эти примеры основаны на моем собственном опыте и актуальны на сегодняшний день. Новые вопросы и задачи будут публиковаться по мере их поступления и прохождения собеседований.
Привет, Хабр!
Хеш-индексы в PostgreSQL — это хороший инструмент для ускорения выполнения запросов.
В основе хеш-индекса лежит хеш-функция. Хеш-функция — это алгоритм, который преобразует входные данные (или ключ) в число фиксированного размера, называемое хеш-значением. В PostgreSQL хеш-функция всегда возвращает значение типа integer, что составляет примерно 4 миллиарда возможных значений.
Всем привет! Меня зовут Виктор, я работаю в Компании БФТ-Холдинг руководителем группы разработки. Продолжаю цикл статей по работе с Greenplum. В этом материале хочу рассказать, как СУБД Greenplum строит планы и выбирает самый оптимальный, а также разберу типовые проблемы, которые влияют на выбор плана запроса. Статья будет полезна разработчикам Greenplum, которые пока не имеют достаточного опыта «чтения» плана запроса.
Поговорим о блокировках в 1С:Предприятие. Идея написать эту статью появилась «по просьбам слушателей». Постараюсь максимально простым языком, без зауми рассказать о природе блокировок и что с ними делать. В один пост весь материал помещать не буду — громоздко, поэтому сегодня речь пойдет о логических блокировках сервера СУБД.
С точки зрения конечного пользователя проблема избыточных блокировок выглядит почти одинаково — замедление при выполнении операций и/или ошибка. Но природа блокировок бывает разной и решения тоже разные.
Вдохновившись прошлогодним опытом, мы продолжили начинание и снова проводим конкурс по SQL на международной олимпиаде «IT-Планета».
Конкурс состоит из трех этапов. Заочный теоретический тест собрал почти 3000 человек, из которых на следующий этап мы отобрали примерно 200. Вопросы для этого этапа были подготовлены моим коллегой, Евгением Давыдовым.
Второй этап — также заочный. Здесь участником было предложено подумать над пятью задачами моего авторства, о которых я сегодня и хочу рассказать.
Третий — очный — этап пройдет в конце мая; постараюсь не затягивать с отчетом, но пока храню интригующее молчание.
Поскольку все вводные слова про мотивацию я уже сказал в прошлый раз, сразу приступим к делу.
Привет, Хабр!
Меня зовут Денис, я Ведущий Продуктовый Аналитик из МТС. Давайте сегодня поговорим про грейды в аналитике. Чем они отличаются? Расскажу, как можно быстро повышать свой грейд.
В целом, в разных компаниях разное понимание того, чем должен обладать тот или иной грейд. Однако, есть основные пункты, которые повторяются во многих командах, про них мы сегодня и поговорим.
Для аналитиков, владение 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
