NoSQL *

Сразу оговорюсь: я из команды LibreDB Studio, и статья — про наши собственные грабли. LibreDB Studio — это self-hosted IDE для СУБД, работающая в браузере: один инстанс разворачивается рядом с базами, а не устанавливается на ноутбук каждого разработчика. Команда открывает URL — и почти сразу упирается в вопрос, который сожрал у нас не один спринт: как показать результат из четырнадцати принципиально разных движков в одной таблице и при этом не начать выдавать пользователю выдумки за реальные данные.

Объектное хранилище с типами, деревьями и настоящим SQL прямо в вашей PostgreSQL/MS SQL/SQLite. FK на объекты, EF и Dapper рядом. redb против Mongo и Raven.

Чтобы хранить объекты, графы и деревья с типами, индексами и полноценными запросами, вам не нужна ещё одна база данных. Нужна та, что у вас уже есть.

redb превращает PostgreSQL, MS SQL или SQLite в типизированное объектное хранилище, не отнимая ни SQL, ни EF Core, ни Dapper. Это принципиально другой разговор, чем «MongoDB против RavenDB»: там вы выбираете отдельный движок и живёте с ним отдельно; здесь объекты ложатся в базу, которая у вас уже крутится в проде. Ниже чем это выигрывает у документных баз, с кодом, и где у redb честные границы.

Чтобы не спорить с чучелами: MongoDB  зрелая серверная документная база с горизонтальным масштабированием и огромной экосистемой, и мультидокументные ACID-транзакции у неё есть с версии 4.0 (2018). RavenDB  .NET-native документная база, полностью ACID, с типизированным LINQ и автоиндексами. Обе хорошие продукты. redb просто играет на другом поле и на этом поле у него сильные карты.

И учить, по сути ...

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

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

Внутри: почему спор «отказ - статус или событие» решил один запрос к проду, три мины Mongoose, найденные на ревью, и регрессия, прилетевшая через двадцать часов после релиза.

Однажды я решил проверить на практике байку, которую слышал на десятке собеседований: “у нас на проде было такое-то место продано дважды, потому что…”. Оказалось, воспроизвести это не просто легко — это воспроизводится настолько надёжно и настолько наглядно, что грех было не довести дело до конца: взять систему бронирования мест, специально сломать её, замерить, насколько плохо, а потом последовательно починить тремя разными способами — и честно сравнить, что каждый из них стоит по производительности.

Спойлер: один из результатов оказался прямо противоположным тому, что я ожидал увидеть.

Привет, Хабр! Меня зовут Роман Ананьев из команды DBA в Авито. В этой статье я расскажу о поиске альтернативы для многошардовых инсталляций MongoDB. Основная цель исследования — найти базу данных с поддержкой автошардирования, которая упростит эксплуатацию и лучше утилизирует ресурсы.

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

Это текст не про то, что MongoDB плохая, она — прекрасный стандарт рынка, в топ-5 движков БД. Я расскажу про то, что происходит, когда у стандартной технологии заканчивается запас прочности на нужном масштабе, и про то, как мы в Авито перебрали множество NoSQL и NewSQL кандидатов, чтобы найти одного подходящего.

В статье я разберу результаты технического исследования, проведённого командой DBA. Мы сравнили производительность, утилизацию ресурсов и архитектурные грабли Cassandra 5, FoundationDB и других БД. Также объясню, почему погоня за низкой latency в случае с FDB обернулась трёхкратным перерасходом дискового пространства.

Valkey (форк Redis под крылом Linux Foundation) в релизном цикле 9.1 отдал ИИ-агентам рутину мейнтенанса: бэкпорт-агент сам раскатывает фиксы по веткам 7.2/8.0/8.1/9.0, отдельный агент сканирует provenance кода на конфликт с нынешней лицензией Redis (чтобы в форк случайно не затёк несовместимый код родителя), а агентский поиск багов наткнулся на ещё закрытую CVE. Разбираю не «ИИ заменяет мейнтейнеров», а как это сделали по уму: по словам Мэделин Олсон из AWS, агентов посадили на ограниченный, проверяемый слой (CI + ревью + человек на мерже) — «using AI agents without losing control». Главный вывод для своих проектов: сажать агентов на toil, а не на дизайн.

Дисклаймер: вся статья это мнение автора, если вы не согласны или готовы предложить что-то, то прошу в комментарии.

IT охватывают огромный простор навыков и идей, многие из них специфичны и предназчена для узкого круга профессий. При этом существуют навыки, которые или универсальны для всех, или не будут лишними точно. В данной статье пойдет речь про Git, SQL и NoSQL, Linux, базовый азы алгоритмов и структур данных и о английском языке. Дополнительно поставил себе задачу, добавить как можно больше бесплатных или квази-бесплатных ресурсов.

Всем привет!

Наверняка большинство инженеров, работающих с высоконагруженными системами, слышали о Aerospike.

Для тех, кто всё ещё не знает, что это, приведу короткую цитату из документации:

Привет, Хабр! На связи системный аналитик Илья Глазунов и разработчик Захар Корсаков. Мы работаем с платформой карточного хранилища Т-Банка.

Когда данных становится много, а архитектура обязана оставаться простой, классические решения начинают упираться в ограничения стека. В нашем случае нужно было организовать асинхронную доставку событий из Cassandra, но без CDC, без отдельного брокера и без разрастания зоопарка технологий. Так мы пришли к Non-transactional Outbox — схеме, которая по духу напоминает Kafka Inside the Database, но живет в рамках наших ограничений и требований к отказоустойчивости.

В статье покажем, что такое Outbox, с чем его едят и как готовят. Расскажем допущения по реализации в нашем случае, вытекающие из отличий от классического паттерна Outbox. Обрисуем ту реализацию, которую сделали своими руками, и покажем бенчмарки нагрузочного тестирования. В конце поделимся списком вопросов, которые возникали чаще всего при обсуждении решения внутри банковского сообщества Apache Cassandra.

Мне пришла задача на исследование — выбрать хранилище для промышленной телеметрии. Я раньше с таким вообще не работал. Ни с временными рядами, ни с реактивным программированием, ни с WebSocket. Работал только с Postgres.

Слышал про Redis, но не применял. На выбор — SQLite или Redis, надо исследовать что лучше. Пошёл читать. Нашёл TimescaleDB и ещё кучу вариантов — у каждого свои плюсы.

Основной плюс SQLite — там можно писать запросы, SQL знакомый, Spring интеграция есть. Скорость записи меня вообще удивила — и у Redis, и у SQLite. Я не ожидал таких цифр.

Долго не мог понять зачем вообще Redis, если там нет нормального поиска. Просто хэши ключ-значение. Хочешь найти все датчики по типу объекта — не работает. Я такой: ладно, Redis минус, берём SQLite.

Сделал прототипы. Потестировал один поток — SQLite летит, 370 000 вставок в секунду. Redis ещё быстрее — 650 000. Нашёл RediSearch с поиском по индексам — оч круто, но скорость падает до 150 000. SQLite снова выглядит выигрышнее.

И вот я запускаю 100 потоков на SQLite.

В логах появляется:

Когда классические SQL‑базы падают под аналитической нагрузкой, а Hadoop‑кластер напоминает чемодан без ручки — пора искать новое решение.

В этой статье разбираем, как ClickHouse в связке с NoSQL‑экосистемой закрывает бреши в высоконагруженных проектах. Разберём архитектурные ловушки, Best Practices и честно оценим, где этот инструмент экономит миллионы, а где может создать проблемы.

Многие из нас любят NoSQL. И MongoDB среди них является одним из топ-любимчиков. Очень часто мы выбираем нашу «Монгу» за гибкость и скорость. И это вполне логично, ведь MongoDB почти никогда не подводит... сразу. Неприхотливая, шустрая, удобная - она ведет себя как идеальный помощник: не требует лишнего, принимает любые данные, не задаёт неудобных вопросов про схему и с готовностью отвечает на каждый запрос за считанные миллисекунды.

Но потом ты начинаешь подозревать что-то неладное. И, что самое главное, происходит это не сразу, а постепенно. Сначала один запрос начинает задерживаться немного дольше обычного, потом еще один. Там, где раньше было 10-20 миллисекунд, становится 100. Ты замечаешь, что графики ведут себя странно. И начинаешь искать причину: грешишь то на версию софта, то на железо, то думаешь, что сама MongoDB какая-то не такая.

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

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

Привет! Меня зовут Иван Откидач, я DevOps-инженер в команде DBA. Моя основная специализация — NoSQL-базы данных, в частности Redis и MongoDB. С каждым месяцем количество Redis, находящихся на нашей поддержке, растёт, поэтому обеспечение их стабильной и надёжной работы — один из приоритетов нашего подразделения. В этой статье мы разберем, как устроен механизм отказоустойчивости в Redis Cluster и почему он может давать сбои в multi-AZ-инфраструктуре. Также покажем один из практических подходов к решению этой проблемы.

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

В конце января компания OpenAI порадовала статьёй про то, как у них устроен backend, вот её перевод на русский. Хороший материал для размышлений о system design и, в частности, для поиска ответов на два вопроса: стоит ли идти таким путём начинающему стартапу? стоило ли OpenAI так делать?

Многие опытные разработчики недооценивают мощь инструментария БД при работе с микросервисами. По каким-то причинам в IT-сообществе приняты эмпирические правила - сервис маленький, значит и база маленькая. Но это не совсем так.

Скорее всего, при проектировании архитектуры у нас в голове чаще всего возникает паттерн database-per-service. И когда мы начинаем рисовать схемы, то возникает соблазн покрутить кирпичики модулей так, чтобы красиво их соединить стрелочками с цилиндриками, обозначающими БД.

С другой стороны, все знают, что много микросервисов, взаимодействующих через одну общую монструозную базу как Oracle, ElasticSearch и другие - это антипаттерн.

Поэтому выбирают маленькие(!) Postgres или MySQL.

При работе с Yandex Database (YDB) часто возникает потребность в удобном визуальном инструменте для работы с данными. AWS NoSQL Workbench — популярное приложение для моделирования и тестирования NoSQL баз можно использовать и с YDB благодаря DynamoDB-совместимому Document API.

Решил собрать нюансы создания резервных копий и восстановления таблиц в YDB. Это не замена документации, а раскрытие деталей, которые не очевидны для тех, кто начинает работать с этой базой данных.

Всем привет!

Идея LensDB родилась с простого поста моего друга. он делился своим опытом создания Shared Memory кэша для своего пет-проекта на C#. В этом посте он написал:

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

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

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