Базы данных *

Каждое Android-приложение, которое хранит данные на устройстве, рано или поздно сталкивается с базой данных. Встроенная SQLite — надёжное решение, но работа с ней через SQLiteOpenHelper требует написания SQL-запросов вручную, преобразования курсоров в объекты и постоянного контроля за закрытием соединений. Это отнимает время и довольно часто вызывает ошибки.

Google предложил библиотеку Room, которая является оберткой над SQLite и реализует паттерн ORM (Object-Relational Mapping). В этой статье мы на конкретном примере сравним, как выглядят операции добавления и чтения данных на чистом SQLite и на Room. Вы увидите, почему Room избавляет от «шаблонного кода» и делает работу с БД простой и безопасной.

JSON в PostgreSQL давно перестал быть экзотикой, но работать с ним по-реляционному до сих пор приходилось не самым изящным способом: jsonb_array_elements, LATERAL, ручные касты, обработка ошибок на честном слове. В PostgreSQL 17 появился JSON_TABLE — стандартный SQL/JSON-механизм, который превращает JSON-документ в табличное представление одним выражением. В статье разберём, как он работает, чем отличается от привычного подхода, где действительно упрощает запросы и какие ограничения по производительности и применению у него остаются.

С тех пор как мы представили инструмент резервного копирования в Manticore Search 6, создавать резервные копии данных стало заметно проще. Но мы постоянно слышали один и тот же вопрос: "А как насчёт облачного хранилища?" Сегодня мы рады объявить, что manticore-backup теперь поддерживает S3-совместимое хранилище с потоковой загрузкой — без промежуточных файлов, без проблем с местом на локальном диске, только бэкапы напрямую в облако.

В предыдущей статье о Vinyl я рассказывал об архитектуре LSM-движка Tarantool. Восемь лет, прошедшие с момента с написания статьи, показали, что Vinyl сразу получился идеальным и менять его не нужно :). Если серьёзно, сегодня я расскажу о тех изменениях, которые мы внесли в алгоритм в форке Tarantool от Picodata, и неизбежно коснусь более глубокой проблематики работы LSM-деревьев, а конкретнее – работы планировщика слияний (compaction scheduler).

До недавнего времени для реализации сложной многошаговой логики в экосистеме Apache Spark разработчикам приходилось выходить за рамки декларативного SQL. Оркестрация последовательных вызовов, вычисление промежуточных переменных и ветвление логики требовали привлечения внешних языков программирования, таких как Python (PySpark) или Scala и дополнительных инструментов.

Spark SQL Scripting, который стал доступен, начиная с 4-й версии, кардинально меняет этот подход, представляя собой процедурное расширение классического Spark SQL. Теперь разработчики могут писать полноценные многошаговые сценарии непосредственно на уровне SQL-артефактов, внедряя в них управляющую логику.

В данной публикации мы, команда вендора Data Sapience, разберем возможности Spark scripting на практике.

При работе с данными в SQL рано или поздно возникает задача ранжирования: топ-5 продуктов по продажам, рейтинг сотрудников по KPI, распределение клиентов по категориям.

На первый взгляд RANK() и DENSE_RANK() делают почти одно и то же. На тестовых данных разница может быть вообще незаметна. Но в проде именно здесь часто начинаются ошибки: — топ-3 внезапно возвращает 5 строк; — дашборд "врёт"; — backend-логика начинает вести себя не так, как ожидалось; — запрос, который вчера работал быстро, сегодня уходит в disk spill.

Две самые популярные функции для ранжирования — RANK() и DENSE_RANK(). Ниже разберём, чем они отличаются, где именно ошибаются разработчики и аналитики, и что важно понимать: не только что делает оконная функция, но и сколько она стоит на больших объёмах данных.

Представьте, что вы создаёте мощное поисковое приложение. Пользователи вводят ключевые слова, а ваш бэкенд должен выполнять запрос к базе данных Manticore Search, чтобы найти подходящие результаты. Распространённый (и соблазнительный!) подход — напрямую вставлять ввод пользователя в SQL‑запросы. Например, вы можете фильтровать по числовому полю, такому как категория или идентификатор записи. Если пользователь передаёт обычное значение, например 5, запрос будет SELECT FROM products WHERE id=5. А что, если он передаст 1 OR 1=1? Запрос станет SELECT FROM products WHERE id=1 OR 1=1 — условие всегда истинно, поэтому запрос вернёт все строки вместо одной. Это SQL‑инъекция.

К счастью, существует более безопасный и эффективный способ: prepared statements. По сути, prepared statements отделяют ваш SQL‑код от передаваемых данных. Вместо того чтобы каждый раз собирать всю строку запроса, вы один раз задаёте структуру запроса с маркерами параметров, а затем отдельно передаёте поисковые термины. Подробнее о концепции можно узнать на Wikipedia .

Manticore Search поддерживает prepared statements через стандартный протокол MySQL, предоставляя мощный инструмент для создания безопасных поисковых приложений. Используя prepared statements, вы не только значительно снизите риск SQL‑инъекций, но и улучшите читаемость вашего кода.

prepared statements — это не просто функция; иногда они являются обязательными. Например, библиотека Rust sqlx работает с MySQL-эндпоинтом, используя исключительно prepared statements. Кроме того, некоторые OLE DB‑коннекторы, позволяющие MS SQL работать с сервером MySQL, тоже используют prepared statements внутри.

Привет.

В этой технической статье мы на практике разберёмся, что такое RAG, распарсим MDN Web Docs, научимся готовить эмбеддинги, заполним ими векторную базу данных и напишем свой MCP сервер с гибридным векторным и полнотекстовым поиском. Зальём всё получившееся добро на HuggingFace, GitHub и NPM, и настроим автоматическое обновление данных.

Внутри будет много пошаговых инструкций и примеров кода на Bun + TypeScript.

Привет, Хабр!

Запрос работает 30 секунд. Вы смотрите на него, всё вроде ок: JOIN по индексированным полям, WHERE по дате, LIMIT 100. Должен летать, но что-то не летает. Добавляете индекс наугад — не помогает. Переписываете подзапрос в CTE и стало ещё хуже.

Проблема не в запросе, а в в том, что вы не смотрели в план выполнения. EXPLAIN ANALYZE показывает не что вы написали, а что PostgreSQL делает: какие индексы использует (и использует ли вообще), в каком порядке соединяет таблицы, где тратит время, сколько строк ожидал и сколько получил.

Представьте: вы заходите в репозиторий, открываете папку schemas и через пять минут понимаете, как устроена база во всём проекте, со всеми связями. Никаких устаревших диаграмм в Confluence, никаких гаданий по коду миграций. Схема базы данных становится частью кодовой базы — её можно версионировать, рецензировать и тестировать. Модель в формате ArchDB становится единым источником истины, из которого автоматически генерируются документация, DDL-скрипты и даже ORM-сущности. Звучит как мечта? Для нас с командой это стало реальностью, когда мы перешли на ArchDB.

Все началось с обычного тикета в Jira, из тех, которые выглядят безобидно и даже немного скучно. «Нужно протестировать новый личный кабинет. Разверни тестовую базу». Через несколько месяцев этот тикет аукнулся сорванным релизом, сгоревшим маркетинговым бюджетом и отложенным запуском важнейшего сервиса. А Олег, как всегда, остался крайним.

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

На связи Денис Волков из команды платформы данных в Yandex Cloud. В предыдущей статье мы рассказали, как устроен SPQR (Stateless Postgres Query Router): архитектура, компоненты и принципы. Красивая теория. Эта статья — про то, что происходит, когда теорию начинаешь применять к живому продакшену с десятками таблиц, набором микросервисов и новогодней нагрузкой. Про грабли, решения и конечно же проблемы.

Вы слышали, что Manticore Search быстрый. Вы слышали, что он объединяет полнотекстовый, векторный и нечеткий поиск в одном движке. Но когда вы начинаете реально работать с ним, вы сидите перед документацией, угадываете синтаксис SQL и надеетесь, что CREATE TABLE не выдаст непонятную ошибку.

MCP-Manticore меняет правила игры.

Это сервер Model Context Protocol (MCP), который подключает Cursor, Claude Code, Codex CLI или любой другой MCP-совместимый AI-ассистент напрямую к вашему экземпляру Manticore. AI может:

Помните те времена, когда мы сидели в три часа ночи, пытаясь свести VLOOKUP‑ами три кривых CSV‑файла, выгруженных из разных CRM, а питоновский скрипт падал из‑за одной запятой не в той кодировке? Кажется, это было в прошлой жизни...

На дворе апрель 2026 года. Нейросетевой анализ данных — это уже не игрушка для гиков и не R&D‑эксперимент с непредсказуемым бюджетом. Это суровая, ежедневная необходимость. Если вы сегодня не используете ИИ для очистки, обогащения и анализа датасетов, вы всё равно что копаете котлован чайной ложкой, пока соседи работают экскаватором.

По данным исследований Стокгольмского института окружающей среды, современные LLM достигают 85–90% точности по сравнению с ручной разметкой и анализом даже в таких субъективных вещах, как оценка политических и климатических документов. А в жесткой математике и структурированных таблицах этот процент стремится к абсолютным 100%.

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

Пристегните скафандры, мы погружаемся. И начинаем с абсолютного геймчейнджера.

Привет, Хабр!

PostgreSQL умеет блокировать строки (SELECT ... FOR UPDATE) и таблицы (LOCK TABLE). Об этом знают все. Но есть третий тип блокировок, который решает задачи, с которыми row-level и table-level locks не справляются: advisory locks. Консультативные блокировки — механизм, где PostgreSQL предоставляет инфраструктуру (атомарные блокировки с очередями ожидания), а семантику определяет приложение.

Это значит: вы берёте блокировку по произвольному числовому ключу, и PostgreSQL гарантирует, что никто другой не возьмёт блокировку с тем же ключом одновременно. Никаких таблиц, строк или ресурсов БД не блокируется — это чисто логическая блокировка, видимая только тем, кто её проверяет.

Звучит как-то абстрактно. Посмотрим на конкретные задачи, где advisory locks незаменимы.

Каждый, кто приходит в ClickHouse из мира классических OLTP-баз, несет с собой багаж священных знаний. Один из таких «священных граалей» — Common Table Expressions (CTE).

Казалось бы, что в ClickHouse может пойти не так? Ведь там тоже есть WITH! Любой нормальный человек просто возьмет и начнет использовать, казалось бы, привычный функционал. Но в итоге останется у разбитого корыта.

В этой статье мы разберем главные грабли: почему WITH в ClickHouse — это не оптимизация, а макрос для парсера и выстрел себе в ногу, если этого не знать.

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

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

Почему поиск виноватых не работает

В ИТ есть старая поговорка: «Быстро поднятое не считается упавшим». Почти каждый инженер слышал её ещё в начале карьеры. В этой фразе есть важный инженерный принцип: в момент инцидента главная задача — не выяснять, кто виноват, а максимально быстро восстановить систему.

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

Команда экспертов Postgres Professional — Павел Лузанов, Егор Рогов и Игорь Лёвшин — представила обновлённое 12-е издание своего бестселлера «Postgres. Первое знакомство». Главная новость: книга актуализирована под возможности новейшей 18-й версии PostgreSQL.

Это небольшое, но ёмкое руководство призвано максимально быстро и комфортно погрузить читателя в работу с самой продвинутой СУБД с открытым кодом.

Поиск редко сводится к одному универсальному сценарию. Пользователь, вводящий "cheap running shoes", хочет точных совпадений по ключевым словам, а пользователь, задающий "comfortable footwear for jogging", выражает то же намерение другими словами. Традиционный полнотекстовый поиск хорошо справляется с первым случаем. Векторный поиск решает второй. Гибридный поиск объединяет оба в одном запросе, так что вам не приходится выбирать.

В современных поисковых системах это часто описывается как комбинирование лексического (разреженного) поиска с семантическим (плотным) поиском. Разные термины, одна идея: точное совпадение плюс смысл.

Я думаю многие согласятся, что Spring Data JDBC — это ORM, который занимает конкретную нишу: он предоставляет более легковесный репозиторный слой доступа к данным поверх реляционной БД без persistence context, без lazy loading, без dirty checking и т.д.

Иными словами, Spring Data JDBC реализует принцип "what you see is what you get" — каждое обращение к репозиторию означает конкретный SQL-запрос в БД, который просто достаёт дерево Aggregate. Это и преимущество, и, тем не менее, иногда это источник потенциальных проблем с производительностью.

В этой статье я разберу ключевые подходы к оптимизации запросов в Spring Data JDBC: от дизайна агрегатов и Single Query Loading, до Stream в качестве возвращаемого значения и @Modifying запросов. Разберём всё с кодом и на примерах.

Только один момент - в этой статье я не затрагиваю Spring Data открытые/закрытые Projection-ы и т.п, так как я предполагаю, что пользователи Spring Data знают, что это и в каких ситуациях их стоит использовать. Эти вещи не специфичны для Spring Data JDBC, я же буду говорить про вещи более специфичные для Spring Data JDBC.