SQL *

В эпоху урбанизации, когда мегаполисы и региональные центры России растут как на дрожжах, вопрос доступности социальной инфраструктуры выходит на первый план. Родители, ищущие ближайший детский сад для своего малыша, урбанисты, планирующие новые жилые кварталы, или городские власти, стремящиеся оптимизировать транспортную сеть, — все они сталкиваются с одной и той же проблемой: как быстро и точно оценить, насколько "дружественен" город к пешеходам? Сколько минут пешком до ближайшей школы? А до игровой площадки? Эти вопросы, кажущиеся простыми, на деле требуют сложных расчетов, анализа геоданных и визуализации, которая была бы интуитивно понятной.

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

Города растут, районы меняются, а людям по-прежнему нужно простое и честное понимание: удобно здесь жить или нет?

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

Кому это нужно?

Привет! Меня зовут Дима Кривопальцев, я тимлид бэкенд‑команды Яндекс Диска (Яндекс 360). Уже больше семи лет я занимаюсь разработкой высоконагруженных распределённых систем — и в статье расскажу об одной из них.

В Яндекс 360 есть сервисы с очень большими нагрузками — и по RPS, и по объёму хранимых данных, и по числу обрабатываемых асинхронных задач. Именно последняя часть — асинхронная обработка — будет в центре этого рассказа.

Тема может показаться немного провокационной: речь пойдёт об очередях поверх SQL‑баз, а в сообществе такое решение принято считать антипаттерном — и на это есть основания. На конференциях и в статьях обычно можно услышать скепсис: «Очередь на PostgreSQL? Не стоит даже пытаться». Действительно, подобных попыток было много, и почти все сталкивались с типовыми проблемами — от блокировок до деградации производительности.

Тем не менее, в реальности у многих крупных компаний всё равно есть свои очереди, построенные поверх SQL‑баз — как PostgreSQL, так и MySQL. Это решение встречается и в российских, и в зарубежных командах. Яндекс Диск здесь не исключение — у нас тоже есть своя реализация, о которой сегодня и пойдёт речь.

Осторожно, спойлеры! Не читайте, пока хотите решить задачу самостоятельно.

В этой челлендж-серии статей, начатой с прошлогоднего эвента, попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2025.

Возможно, SQL не самый подходящий для этого язык, зато мы рассмотрим его различные возможности, о которых вы могли и не подозревать.

Сколько я пользуюсь SQL, столько же он меня бесит. Сегодня хочу рассказать про свой прототип языка для создания больших и сложных аналитических запросов, который компилируется в SQL. Он будет опираться на структуру конкретной БД, и даже больше — он будет опираться на логику данных.

Осторожно, спойлеры! Не читайте, пока хотите решить задачу самостоятельно.

В этой челлендж-серии статей, начатой с прошлогоднего эвента, попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2025.

Возможно, SQL не самый подходящий для этого язык, зато мы рассмотрим его различные возможности, о которых вы могли и не подозревать.

Привет! Хочу рассказать о своей новой библиотеке context-async-sqlalchemy, которая помогает очень просто работать с sqlalchemy в async python приложениях. Минимум кода для простых сценариев, но и максимум свободы для сложных.

Осторожно, спойлеры! Не читайте, пока хотите решить задачу самостоятельно.

В этой челлендж-серии статей, начатой с прошлогоднего эвента, попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2025.

Возможно, SQL не самый подходящий для этого язык, зато мы рассмотрим его различные возможности, о которых вы могли и не подозревать.

Сегодня стартовал Advent of Code 2025!

Осторожно, спойлеры! Не читайте, пока хотите решить задачу самостоятельно.

В этой челлендж-серии статей, начатой с прошлогоднего эвента, попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2025.

Возможно, SQL не самый подходящий для этого язык, зато мы рассмотрим его различные возможности, о которых вы могли и не подозревать.

Привет, Хабр! Меня зовут Сергей Сорокин, я .NET-разработчик с 12-летним стажем. Занимаюсь бэкендом, архитектурой и высокими нагрузками.

Знаю, о чем вы подумали, прочитав заголовок: "О боже, еще одна ORM? В 2025 году? Зачем, если есть Dapper и EF Core?".

Я тоже так думал. Но когда ты работаешь в Enterprise-системах, где производительность критична, а база данных — это не просто хранилище, а мощный инструмент обработки данных, стандартные решения начинают показывать свои слабые места.

Сегодня я хочу рассказать о Visor — ORM, которую мы создали, чтобы превратить работу с базой данных в вызов типизированного API, убрать оверхед рефлексии и решить извечную боль с передачей списков (TVP) в SQL Server. А заодно показать, как Source Generators позволяют писать код, который работает быстрее, чем то, что вы пишете руками.

Для чего существуют принципы ACID? Можно ответить по бумажке, сказать, что это нужно для того, чтобы каждая транзакция обрабатывалась надежно, данные оставались в безопасности и системы работали предсказуемо.

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

В этой статье вы узнаете, почему так важны принципы ACID и что это за принципы. Оставайтесь со мной, если интересно!

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

А что на счет самих данных, если мы их рассматриваем как продукт? Как будем оценивать их ценность, как будем планировать их развитие?

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

Всем привет! С пылу с жару: мы только что вернулись с одного из главных митапов n8n в Сан-Франциско, где выступали сами основатели.

Внутри статьи: 3 инсайда о будущем n8n (новые фичи, ИИ-интеграции) и наш эксклюзивный бонус. Спойлер: Мы вывезли 1000 премиум-доступов к n8n, которые они выдали эксклюзивно для вас. Эти ключи очень ценны, и мы готовы подарить их нашим читателям.

В Ruby‑разработке ActiveRecord давно стал стандартом: он интуитивно понятен, встроен в Rails и позволяет быстро проводить CRUD‑операции. По мере роста проекта его «удобство» нередко начинает оборачиваться скрытыми проблемами.

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

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

Привет, Хабр! Некоторые функции DAX из Power BI могут выглядеть интуитивно понятными, но при детальном рассмотрении ведут себя не совсем ожидаемо. Например, SUMMARIZE не агрегирует «сразу», в месте использования, но SUMMARIZE реализуется через «виртуальную», «отложенную» агрегацию за счет сохранения состояния. Для суммы, т.е. SUM, промежуточное состояние и есть сумма и особенности SUMMARIZE не проявляются, но для любой другой агрегации (например, среднего AVERAGE) становится понятно, что в Power BI уже учитывается так называемое состояние для корректного расчета SUMMARIZE, т.е. данные по всем записям сохраняются в состоянии. В других СУБД единственный аналог — только State и Merge комбинаторы из ClickHouse, поэтому для иллюстрации состояний будет рассмотрен пример из ClickHouse, соответствующий DAX с SUMMARIZE и AVERAGE. Интересующимся особенностями SUMMARIZE в Power BI — добро пожаловать под кат :)

Иногда в архиве нашего сервиса анализа планов запросов к PostgreSQL встречаются примеры не очень эффективных, мягко говоря, запросов.

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

Всем привет!

Я Senior Java Developer в банке, и за эти годы мне довелось пройти немало собеседований. Где-то было спокойно, где-то — как в допросной, с каверзными вопросами, странными задачами и вечным «а почему так, а не иначе?». В процессе я собрал целую коллекцию тем, которые всплывают снова и снова, особенно когда дело касается баз данных.

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

При разборе продакшн heap dump я обнаружил странность: Hibernate Query Plan Cache занимал почти треть памяти. Обычный IN (:ids) внезапно генерировал тысячи SQL-планов и раздувал heap.

Почему так происходит и как полностью решить проблему с помощью ANY(:ids) — разбираю пошагово на реальном примере

Статья — практическое руководство по управлению привилегиями в StarRocks: объектная модель (SYSTEM, CATALOG, DATABASE, TABLE, VIEW, MATERIALIZED VIEW, FUNCTION и др.), перечень привилегий для каждого типа сущности и соответствующие операции. Разбираем роль‑based доступ (RBAC): встроенные роли (root, cluster_admin, db_admin, user_admin, public), создание собственных ролей и выдачу прав через GRANT/REVOKE с наглядными SQL‑примерами. Отдельный блок — особенности StarRocks: ограничение ресурсов на пользователя (max_user_connections), роли по умолчанию и их активация при входе, массовая выдача прав через public, выполнение от имени другого пользователя (IMPERSONATE/EXECUTE AS). Материал полезен инженерам данных, DBA и разработчикам, работающим с OLAP/MPP‑СУБД и хранилищами данных, а также тем, кто внедряет контроль доступа в аналитических кластерах. Дополнительно освещены создание пользователей с разными методами аутентификации (включая LDAP), управление RESOURCE/RESOURCE GROUP, GLOBAL FUNCTION и STORAGE VOLUME, а также практики безопасной раздачи прав по ролям.

Вот уже который год я потихоньку разрабатываю SQL-ный движок на основе Apache Spark, специализированный под задачи ETL. И хотя диалект языка изначально называется «Transform Definition Language», писать трансформации данных непосредственно на нём самом было до сих пор невозможно. Вместо этого на фазе Transform предполагалось использовать подключаемые модули, которые рантайм интерпретатора предоставляет из Java classpath.

Это очень эффективный с точки зрения производительности, но довольно долгий с точки зрения внедрения, и дорогой в разработке способ. Сначала трансформацию надо описать формально в виде статьи-whitepaper'а (это делает data scientist), потом написать прототип на Python (ответственность data analyst), отладиться на сэмпле реальных данных (тоже аналитик), и тогда уже делать и оптимизировать финальную имплементацию на Java с использованием низкоуровневого API Spark (собственно, задача разработчика). Неудобно.

Нельзя ли его как-нибудь сократить? Например, дать аналитикам инструмент для написания трансформаций непосредственно в самом SQL, вынеся некоторую часть функциональности MapReduce как разновидность итерирующих функций? Можно, конечно!