📚 База по графовой СУБД Neo4j

Довольна старая статейка, но я специально ее придержал для студентов, которые планируют изучать графовые БД.

Как базовые туториал материал неплох, хотя в эпоху ИИ постигать популярные opensource инструменты в 100 раз проще. Хотя признаю, чтобы начать учиться нужно уметь задавать правильные вопросы. Если ты совсем не в теме, то ты даже вопросы сформулировать не сможешь. Про релевантные ответы и говорить не стоит.

В общем, ребята, начинайте изучение чего-то нового по туториалам на Хабре или Youtube, а уже потом идите к ИИ "засыпайте" её вопросами по пройденному материалу! 🕸 Вот тут ИИ раскрывается во всей красе! 👍

Если конечно ИИ не с галюционирует и не обманит вас 🤪

Чем-то ИИ мне напоминает студентов на экзамене, которые на "серьезных щах" придумывает такую чушь, что даже сами верят в неё! 😱

Эх, какие были времена!

С пятницей!

#mems

📚 Как CockroachDB и Spanner хранят ваши данные: от Pebble и RocksDB до первичного ключа

Я крайне редко натыкаюсь на статьи по проектированию распределенных схем баз данных и тут такой подарок. Конечно хотелось бы большего, но хоть что-то.

Я пропущу традиционное вступление о том, что CockroachDB выросла из Google Spanner и зарекомендовала себя на рынке, как сверхнадежная транзакционно-распределенная СУБД. Архитектурное описание тоже пропущу. Собственно про проектирование.

В распределённых базах типа CockroachDB данные живут на нескольких машинах.

Главный нюанс: PRIMARY KEY (PK) сильно влияет на то, где физически окажутся строки, а значит, будет ли всё быстро или начнутся походы по сети и "тормоза".

❇️ Что важно помнить

1️⃣PK задаёт раскладку данных
Первое поле в PK - это почти как "папка", по которой база группирует строки. Если выбрать неудачно, то ваши данные размажутся по кластеру и даже простой запрос приведет к опросу всех узлов.

2️⃣ Кладите рядом то, что читаешь вместе
Если у вас multi-tenant и запросы обычно "внутри клиента", то ставьте tenant_id первым в ключе (и часто в индексах тоже).
Так данные одного клиента чаще будут рядом → меньше сетевых скачков.

3️⃣ Монотонные ключи убивают производительность записи
Пример "как часто делают" для лого событий:

PRIMARY KEY (tenant_id, created_at)

Новые записи всегда самые свежие → они постоянно падают в одно и то же место → одна нода данных "перегревается".

Решение: добавить "распределитель", bucket. Это небольшое число, чтобы равномерно раскладывать новые записи:

PRIMARY KEY (tenant_id, bucket, created_at, id)

где bucket = hash(id) % 16 (например)

Теперь новые события распределяются по 16 "полкам", и база не упирается в одну горячую точку.

4️⃣ Индекс - это такая же таблица
Вторичный индекс в такой архитектуре - это просто другая сортировка тех же данных. Он живет своей жизнью и может находиться на других узлах.

Каждый новый индекс = дополнительная Raft-транзакция при записи. 5 индексов = 5 консенсусов.

Лайфхак: Делайте индексы покрывающими (include все нужные поля). Это позволит не ходить в основную таблицу, если она "далеко".

И да пребудет с вами tenant_id в начале каждого ключа 😇. Аминь 🙏

Я обычно так не делаю, но тут три новости отлично объединятся в одну 🚀

1️⃣ Базы данных для искусственного интеллекта: векторы, эмбеддинги и архитектура

2️⃣ Что происходит с базой данных, когда пользователь является ИИ-агентом

3️⃣ Базы данных не предназначены для разрастания агентов — SurrealDB хочет это исправить

Эти статьи появились примерно в одно время и пытаются ответить на вопрос:

Что меняется в мире СУБД и приходом ИИ-агентов (LLM) ?

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

❇️ Общий тренд: Мы переходим от эпохи «Базы Данных как хранилища» к эпохе «Базы данных как оперативной памяти ИИ».

Основные составляющие этого тренда:

👉 Конец «базового разврата» (Database Exhaustion)
Какой прикольный термин "базовый разврат". Надо будет обязательно его на лекции использовать.

Последние 10 лет девизом было Polyglot Persistence: "используй отдельную БД для каждой задачи" (Redis для кеша, Postgres для таблиц, Neo4j для графов, Pinecone для векторов).

Для ИИ-агентства эта модель - тупик 🚫. Агенту нужно всё и сразу в одном контекстном окне. Перекачка данных между пятью базами создает задержки (latency), которые убивают логику агента.

❇️ Тренд: Возврат к мультимодельным системам, которые объединяют векторы, графы и транзакции "под одним капотом".

👉 Смена «главного пользователя»

Раньше базы данных проектировались под запросы человека (через SQL) или бэкенд-приложения. Теперь главным потребителем данных становится LLM/Агент. У него другие паттерны. Он делает тысячи микро-запросов, ему нужна идеальная семантическая точность.

👉 Появление Agent-Native Infrastructure. База данных перестает быть пассивным архивом и становится активным участником процесса, который сам умеет запускать логику (через WASM или плагины, как в SurrealDB 3.0).

✅ Данные - это теперь "Контекст", а не просто "Строки"
Статьи подчеркивают, что для ИИ-агента данные бесполезны без связей. Просто найти похожий вектор (RAG) уже мало. Агенту нужно понимать иерархию и зависимости (графы).

👉Слияние Vector Search и Graph Relations. Будущее за системами, которые позволяют ИИ-агенту «рассуждать» прямо над структурой данных, не выходя за пределы БД.

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

Мы входим в эру консолидации🪬. Разработчики устали от сложности "зоопарка" баз данных. Победят те решения, которые предложат ИИ-агентам единую, быструю и "умную" среду обитания, где память, логика и данные не разделены сетевыми барьерами.

Иными словами, разгоняем хайп AI-native баз данных по полной!

Когда прокачал свои навыки на максимум! Но есть нюанс...

С 1-ым апреля!

"В каждой шутке есть доля... " (с)

#mems

В одной статье про "Перспективы развития баз данных в 2026 году" меня зацепила не AI-native часть (она ожидаемая 😁), а блок про надёжность: автор пишет, что reliability в 2026 измеряется observability-driven engineering", и как базовую практику внезапно достаёт из широких штанин правило "3-2-1".

Кратко напомню о чем оно:
👉 3 копии данных. «Две - это одна, а одна - это ноль» (с). Если у вас всего две копии и одна ломается в процессе восстановления (что бывает часто из-за нагрузки на диск), вы теряете всё.
👉 2 разных носителя. Если хранить всё на двух одинаковых жестких дисках из одной партии, есть риск, что они оба умрут от одного и того же заводского брака в один день.
👉 1 копия вне дома. Чтобы пожар или кража не уничтожили и оригинал навсегда.

Правило 3-2-1 - это не стандарт из лаборатории IBM. Это мем из мира фотографов. Его популяризировал Питер Крог, формулируя простую "памятку выживания" для цифровых архивов в The DAM Book (середина 2000-х).

То есть оригинальная модель защищала в первую очередь от случайных фейлов инфраструктуры. И как "база" она до сих пор красивая 🥹😍.

Но эпоху постоянных хакерских атак, вирусов-вымогателей и активным развитием ИИ-агентов оно начинает "трещать по швам".

👉 Во второй части разберем почему 3-2-1 сегодня не закрывает главный класс угроз, и почему нормой становится 3-2-1-1-0.

Не прошло и трех лет и наконец-то:

С 7 апреля PostgresPRO запускает профессиональную сертификацию по PostgreSQL 16.

До этого народ сертифицировался только по PostgreSQL 13. Да, был еще курс повышения квалификации с 13 до 16, но это другое.

В общем, обещание сделать сертификацию по 16 версии я слышал еще с 2023 года. Ребята шли к этому событию три года! Причем следует учесть, что над этим проектом задействовано более 10+ человек. Интересно было бы послушать о причинах такой задержки, но это не столь важно сейчас.

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

Весенее обострение начинается...

С пятницей!

#mems

❗️Почему 3-2-1 уже мало?

В прошлом посте мы вспомнили классику от Питера Крога. Но если вы строите защиту компании только на ней, то вы в зоне риска.

В чем проблема? Классика 3-2-1 защищает от техногенных катастроф (пожар, сбой железа), но она бессильна против хакеров. Современные вирусы-вымогатели (Ransomware) первым делом ищут бэкапы в сети и удаляют их, прежде чем зашифровать рабочую базу.

Как пишут ребята из «Киберпротекта» и авторы на Хабре, современная норма - это 3-2-1-1-0.

Разбираем «добавки»:

🟢 +1 (Immutable копия): Это «защита от дурака» и хакера. Неизменяемая копия, которую физически нельзя удалить или зашифровать даже с правами админа (технология S3 Object Lock).

🟢 +0 (Zero errors): Бэкап не считается существующим, если он не прошел автоматическую проверку. Ноль ошибок при тестовом восстановлении!

А что сам Питер Крог? Он является активным деятелем, однако менять термин 3-2-1 он не хочет. Он бережет бренд 😎. "3-2-1" - это уже легендарный мем🐉 в мире ИТ. Проще расширять его толкование, чем придумывать новый номер телефона 📱. В его нынешних лекциях «единица» (offsite) всё чаще подразумевает именно неизменяемое облачное хранилище.

Как итог защищаться только от пожаров и игнорировать хакеров в 2026 году - это как поставить бронированную дверь 🦾, но оставить ключ под ковриком 🔑.

Есть ли у вас та самая «неизменяемая» копия и автоматический тест восстановления? 😈

Кому сегодня скучно, то можно глянуть трансляцию ArenaDaY

Конечно ребята делают всё очень пафосно!

Докладов мало, но с другой стороны это же конфа про коммерческие продукты. Это вам не опенсорс.

Надеюсь будет интересно 😎

🎥 Как работает Search Engine под капотом: ранжирование и релевантность | Рауф Алиев #74

Рауф Алиев - человек, который варится в поиске уже четверть века. Он начинал с самописного inverted index в начале 2000-х, когда всё приходилось изобретать руками, и дошёл до современных гибридных систем — с векторным поиском, трансформерами и рекомендациями поверх всего этого.

Хороший подкаст. Видно, что герой очень мощный специалист своего дела. Мне слушать его было приятно и весьма познавательно. Вообще, темы довольно технические и явно не для всех, поэтому выпишу буквально несколько тезисов, которые тронули моё сердечко ♥️

👉 Разные точки зрения о качестве поиска. Со стороны пользователя он работает чаще всего плохо, а со стороны бизнеса - хорошо.

👉 Автор приводит в пример сайт Amazon. Пользователи часто ругают их систему поиска 🤬. Но ИТ-команда, которая занимается поисков в Амазон одна из самых сильных в индустрии! 💪

👉 Поиск нужен пользователям, но он не нужен бизнесу.
На поиске сложно заработать и уж тем более доказать бизнесу, что многомиллионные инвестиции в это направление действительно нужны порой очень сложно 💸.

👉 Поиск очень близок к рекомендациям.
Мне даже добавить нечего.

👉 Хорошие рекомендации "очень дорого стоят". Пользователь не будет ждать так долго.
Опять выбор, либо качественно, но долго, либо быстро, но кое-как. Разработчикам приходится как-то изворачиваться, что сделать всем хорошо!

Очень неплохая картинка, которая объясняет концепцию LSM деревьев. Это довольно нужная вещь для понимания работы множества СУБД.

📚 LSM деревья - описание структуры данных, которая лежит в основе баз данных NoSQL.

Я в своих лекциях очень мало времени уделяю описанию LSM деревьев и прочих интересных инженерных решений в современных СУБД, поэтому решил чуть-чуть закрыть этот пробел своим постом. Тем более вышла соответствующая статья по LSM.

🧠 LSM-деревья: почему NoSQL пишет быстрее, чем вы читаете?
Это структура данных, превращающая хаотичную запись в стройную очередь. Именно на ней "едут" Cassandra, RocksDB, ScyllaDB и даже движки в MongoDB (WiredTiger) и MySQL (MyRocks).

🚫 Проблема B-деревьев (классика SQL)
В PostgreSQL или MySQL изменение даже 1 байта заставляет движок перезаписывать целую страницу (8 КБ) на диске. Это порождает Random I/O и Write Amplification (усиление записи) - под большой нагрузкой диск начинает "захлебываться".

✅ Как работают LSM: Магия Append-only
Здесь ничего не перезаписывается "на месте". Путь данных выглядит так:
👉 WAL (Write Ahead Log): Сначала пишем в лог на диске. Это максимально быстро (просто допись в конец файла), зато гарантирует сохранность при сбое.
👉 MemTable (RAM): Данные попадают в память, где они сортируются.
👉SSTable (Disk): Когда память заполнена, данные сбрасываются на диск одним большим последовательным куском. Эти файлы неизменяемы (immutable).

👀 Чтение: Иголка в стоге сена
Читать из LSM сложнее, чем из B-tree. Нужно проверить память, а потом идти по файлам от новых к старым. Чтобы не «шуршать» диском зря, в RAM держат Фильтры Блума. Они мгновенно говорят: «этого ключа тут точно нет» (пропускаем файл) или "возможно, есть" (лезем на диск).

🗑 Удаление и "надгробия" 🪦
Удалить запись в LSM - значит записать её заново, но с пометкой Tombstone ("надгробие"). Старые данные физически удаляются только во время компакции — фонового слияния файлов.

🛠 Инженерные нюансы:
SSD-friendly: LSM пишет последовательно, что бережет ресурс SSD и идеально ложится на их внутреннюю архитектуру.

👉 Write Amplification никуда не делся: Он просто переехал из синхронного процесса записи в фоновый процесс компакции.

👉 Read Amplification: Чтение - "ахиллесова пята" LSM. Без фильтров Блума и правильной стратегии компакции (Leveled vs Size-Tiered) чтение может превратиться в кошмар.

👉 Tombstones могут "тормозить": Если вы удалили миллион записей, а потом делаете Scan, системе придется продраться через все эти "трупы", прежде чем она найдет живые данные.

Как итог: LSM - это осознанный обмен скорости чтения и места на диске на феноменальную пропускную способность записи.

Актуально как никогда!

С пятницей!

#mems

🎊 11 и 12 марта прошла конференция Monster SCALE Summit 2026 в режиме онлайн.

О том, как устроена конференция я писал ранее. Сейчас немного поговорим о докладах.

Я отсмотрел более 70% видео. Вроде бы они интересные, но какие-то скучные 😞. Может просто спикер не запал в мое сердечко, не знаю )) бывает 😁.

Расскажу про видео, которые мне откликнулись.

❇️Monster SCALE Summit 2026 | Designing Data-Intensive Applications Second Edition by Martin and Chris

По сути это небольшое интервью с авторами книги "Кабанчик 2.0". Да, да, оно уже вышло и его заказал. Когда придет, не знаю )

В целом, интервью откровенное слабое. Как журналист ведущий очень слаб. Пару тезисов я всё-таки выцепил

👉300 000+ проданных экземпляров первого издания! Для технической книги это очень много.

👉Мартин ушел с головой в академическую деятельность и немного подотстал от техничего прогресса. Наверстать ему помог Крис. Так и получилось 2-ое издание.

👉ИИ меняет мир, но мы пока не понимаем как. То, что сегодня кажется оптимальным решением. Через полгода может стать не актуальным.

👉Мартин: Не позволяйте своим инженерам писать книги. Иначе они могут уйти!

❇️Monster SCALE Summit 2026 | Fast and Simple Analytics on MongoDB with DuckDB by Stephanie Wang

Доклад вроде бы банальный, но меня привлекло то, что пытаются скрестить с DuckDB не РСУБД в виде PostgerSQL, а MongoDB.

👉 Многие компании начинают строить аналитику с огромных стеков: ETL-процессы, хранилища (DWH) и распределенные движки. Это оправдывают «масштабируемостью» и «будущим ростом».

👉 Однако исследования (например, данные AWS Redshift) показывают, что 99% аналитических запросов на самом деле небольшие (сканируют менее 10 ГБ данных).

Как это работает технологически:

1️⃣Вы пишете обычный SQL-запрос в DuckDB.

2️⃣Расширение (extension) для MongoDB «пробрасывает» фильтры и проекции в саму базу (Projection/Filter Pushdown).

3️⃣Из MongoDB извлекаются только нужные данные и передаются в DuckDB.

4️⃣DuckDB выполняет сложные джойны (joins), агрегации и оконные функции локально в памяти, используя векторный движок.

Финальный посыл: используйте подход «Local-first analytics». Начинайте с простого - используйте мощь современных локальных систем и добавляйте сложность (распределенность) только тогда, когда нагрузка этого действительно требует.

❇️Monster SCALE Summit 2026 | The Future of Data Consistency in ScyllaDB by Alex Dathskovsky

ScyllaDB явно движется к унификации вокруг Raft. Раньше для разных задач у них был “зоопарк” механизмов: gossip для cluster state, Paxos для LWT, отдельные схемы репликации и repair. Сейчас Raft уже используется для schema/topology metadata, а дальше, похоже, курс взят на более широкую strong consistency там, где она действительно нужна.

На этом фоне интересно смотреть на Redis/Valkey Cluster. Там gossip отвечает не только за membership, но и за ping/pong, обнаружение узлов, failure suspicion и распространение служебных cluster-сообщений.

Мне кажется, если Redis/Valkey когда-нибудь и пойдут в сторону Raft, то первым шагом будет “не сделать CP-систему”, а перевести на Raft control plane: membership, topology, failover decisions, config metadata. Это дало бы более детерминированное управление кластером, более предсказуемые topology changes и менее двусмысленный failover. А пользовательские данные при этом могли бы ещё долго жить в старой async-модели. Это долгий путь - и не факт, что он вообще нужен. Но как направление эволюции control plane идея выглядит вполне разумной.

❇️What Speedrunning Can Teach Us
Доклад креативный, но визуально скудный. Не хочу его пересказывать, поэтому сведу одну общую мысль:

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

❇️You Can’t Scale When You’re Dead
Лучший доклад всей конференции!💪 Кайфанул очень сильно! 🔥
Сделаю отдельный разбор доклада в следующем посте! 😎

p.s. Из каждого угла сайта конференции активно пиарится книга
Database Performance at Scale: A Practical Guide. Дойдут руки, почитаю её.

📚Почему Redis такой быстрый на одном потоке?

Люблю такие статейки про Redis. Вдруг там что-то интересное написано? Или хотя бы подача креативная? 😏

Статья длинная и мне кажется не очень понятная. Думаю стоит её чуть оживить. Краткое "самари" по ней:

Redis быстрей не только потому-то он in-memory, но потому, что он "дружит" с ядром ОС.

1️⃣. I/O Multiplexing (epoll)
Redis не ждет данных от каждого клиента. Он использует системный вызов epoll: ядро само сигнализирует, когда в сокете появились байты. Это позволяет одному потоку обслуживать тысячи соединений без переключения контекста.

2️⃣. Никаких блокировок (Locks)
В многопоточных БД потоки часто стоят в очереди за доступом к данным (lock contention). В Redis один поток, а следовательно, ноль конкуренции, ноль мьютексов, максимальная скорость CPU.

3️⃣. Но он не совсем однопоточный

👉 До v6.0: Вспомогательные потоки (BIO) уже тогда фоном чистили память и сбрасывали логи на диск.

👉 После v6.0: Появились I/O Threads. Они парсят сетевые пакеты параллельно, но команды по-прежнему выполняет только один главный поток, сохраняя атомарность.

⚠️ Нюанс:
В однопоточной среде любая команда O(n) (например, KEYS *) — это приговор. Она блокирует весь сервер для всех клиентов, пока не выполнится.

Redis - это пример того, как отказ от сложности (многопоточности) в пользу умного I/O дает предсказуемую и бешеную производительность💪

Старый мем, но всё-таки такой родной...

С пятницей!

#mems