❗️Почему 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 году - это как поставить бронированную дверь 🦾, но оставить ключ под ковриком 🔑.
Есть ли у вас та самая «неизменяемая» копия и автоматический тест восстановления? 😈
В прошлом посте мы вспомнили классику от Питера Крога. Но если вы строите защиту компании только на ней, то вы в зоне риска.
В чем проблема? Классика 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 году - это как поставить бронированную дверь 🦾, но оставить ключ под ковриком 🔑.
Есть ли у вас та самая «неизменяемая» копия и автоматический тест восстановления? 😈
Киберпротект
От «3-2-1» к «3-2-1-1-0»: современная стратегия резервного копирования
Разбираемся, почему правила «3-2-1» недостаточно для полной уверенности в сохранности информации и что такое современная стратегия «3-2-1-1-0»
👍2🔥2
Кому сегодня скучно, то можно глянуть трансляцию ArenaDaY
Конечно ребята делают всё очень пафосно!
Докладов мало, но с другой стороны это же конфа про коммерческие продукты. Это вам не опенсорс.
Надеюсь будет интересно 😎
Конечно ребята делают всё очень пафосно!
Докладов мало, но с другой стороны это же конфа про коммерческие продукты. Это вам не опенсорс.
Надеюсь будет интересно 😎
🎥 Как работает Search Engine под капотом: ранжирование и релевантность | Рауф Алиев #74
Хороший подкаст. Видно, что герой очень мощный специалист своего дела. Мне слушать его было приятно и весьма познавательно. Вообще, темы довольно технические и явно не для всех, поэтому выпишу буквально несколько тезисов, которые тронули моё сердечко ♥️
👉 Разные точки зрения о качестве поиска. Со стороны пользователя он работает чаще всего плохо, а со стороны бизнеса - хорошо.
👉 Автор приводит в пример сайт Amazon. Пользователи часто ругают их систему поиска 🤬. Но ИТ-команда, которая занимается поисков в Амазон одна из самых сильных в индустрии! 💪
👉 Поиск нужен пользователям, но он не нужен бизнесу.
На поиске сложно заработать и уж тем более доказать бизнесу, что многомиллионные инвестиции в это направление действительно нужны порой очень сложно 💸.
👉 Поиск очень близок к рекомендациям.
Мне даже добавить нечего.
👉 Хорошие рекомендации "очень дорого стоят". Пользователь не будет ждать так долго.
Опять выбор, либо качественно, но долго, либо быстро, но кое-как. Разработчикам приходится как-то изворачиваться, что сделать всем хорошо!
Рауф Алиев - человек, который варится в поиске уже четверть века. Он начинал с самописного inverted index в начале 2000-х, когда всё приходилось изобретать руками, и дошёл до современных гибридных систем — с векторным поиском, трансформерами и рекомендациями поверх всего этого.
Хороший подкаст. Видно, что герой очень мощный специалист своего дела. Мне слушать его было приятно и весьма познавательно. Вообще, темы довольно технические и явно не для всех, поэтому выпишу буквально несколько тезисов, которые тронули моё сердечко ♥️
👉 Разные точки зрения о качестве поиска. Со стороны пользователя он работает чаще всего плохо, а со стороны бизнеса - хорошо.
👉 Автор приводит в пример сайт Amazon. Пользователи часто ругают их систему поиска 🤬. Но ИТ-команда, которая занимается поисков в Амазон одна из самых сильных в индустрии! 💪
👉 Поиск нужен пользователям, но он не нужен бизнесу.
На поиске сложно заработать и уж тем более доказать бизнесу, что многомиллионные инвестиции в это направление действительно нужны порой очень сложно 💸.
👉 Поиск очень близок к рекомендациям.
Мне даже добавить нечего.
👉 Хорошие рекомендации "очень дорого стоят". Пользователь не будет ждать так долго.
Опять выбор, либо качественно, но долго, либо быстро, но кое-как. Разработчикам приходится как-то изворачиваться, что сделать всем хорошо!
YouTube
Как работает Search Engine под капотом: ранжирование и релевантность | Рауф Алиев #74
Сегодня у меня в гостях Рауф Алиев — человек, который варится в поиске уже четверть века. Он начинал с самописного inverted index в начале 2000-х, когда всё приходилось изобретать руками, и дошёл до современных гибридных систем — с векторным поиском, трансформерами…
❤4
📚 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 - это осознанный обмен скорости чтения и места на диске на феноменальную пропускную способность записи.
Я в своих лекциях очень мало времени уделяю описанию 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 - это осознанный обмен скорости чтения и места на диске на феноменальную пропускную способность записи.
Medium
LSM Trees — Understanding the Data Structure that powers NoSQL databases
While we all know what data structures are used in relational databases (B trees), the implementation of a NoSQL database like Apache…
🔥5❤1
🎊 11 и 12 марта прошла конференция Monster SCALE Summit 2026 в режиме онлайн.
О том, как устроена конференция я писал ранее. Сейчас немного поговорим о докладах.
Я отсмотрел более 70% видео. Вроде бы они интересные, но какие-то скучные 😞. Может просто спикер не запал в мое сердечко, не знаю )) бывает 😁.
Расскажу про видео, которые мне откликнулись.
❇️Monster SCALE Summit 2026 | Designing Data-Intensive Applications Second Edition by Martin and Chris
По сути это небольшое интервью с авторами книги "Кабанчик 2.0". Да, да, оно уже вышло и его заказал. Когда придет, не знаю )
В целом, интервью откровенное слабое. Как журналист ведущий очень слаб. Пару тезисов я всё-таки выцепил
❇️Monster SCALE Summit 2026 | Fast and Simple Analytics on MongoDB with DuckDB by Stephanie Wang
Доклад вроде бы банальный, но меня привлекло то, что пытаются скрестить с DuckDB не РСУБД в виде PostgerSQL, а MongoDB.
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
Доклад креативный, но визуально скудный. Не хочу его пересказывать, поэтому сведу одну общую мысль:
Лучший доклад всей конференции!💪 Кайфанул очень сильно! 🔥
Сделаю отдельный разбор доклада в следующем посте! 😎
p.s. Из каждого угла сайта конференции активно пиарится книга
Database Performance at Scale: A Practical Guide. Дойдут руки, почитаю её.
О том, как устроена конференция я писал ранее. Сейчас немного поговорим о докладах.
Я отсмотрел более 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. Дойдут руки, почитаю её.
ScyllaDB
Monster Scale Summit On Demand
Monster Scale Summit Extreme scale engineering Discover the latest trends and best practices impacting data-intensive applications. Register for access to all 60+ sessions available on demand. Featured Sessions All Sessions
❤2
🎦 You Can’t Scale When You’re Dead
Лучший доклад всей конференции по моему мнению! 💪Я слушал, смотрел видео и кайфовал! 😌
Очень много прикольный цитат. Очень здорово сделана презентация и видеоряд 🎥. Мне очень понравилось! Супер! 💥
Автор доклада - Joran Greef, Creator, Tigerbeetle.
В целом, он мне продал свою базу данных 💰. Была бы возможность, то сразу же запросил прайслист и дистриб на тестирование.
Начнем...
🛡 Масштабируемость - это не скорость. Это выживаемость
Многие думают, что масштаб - это про миллионы RPS и бесконечные кластеры. Но на самом деле масштаб - это способность системы не умереть окончательно, когда всё летит в тартарары.
Автор Tiger Beetle (БД для финтеха на языке Zig) выкатил мощный манифест о том, как пережить 1 триллион транзакций.
Вот краткая выжимка того, почему текущий стек может быть "слишком большим, чтобы выжить":
❌ Где все ошибаются?
1️⃣Шардирование (Horizontal Scaling): Оно убивает локальность кэша. Ваша CPU тратит время на ожидание сети, а не на вычисления.
2️⃣Разделение хранения и вычислений (Decoupling): Круто для аналитики, но слишком медленно для транзакций (OLTP) из-за задержек объектных хранилищ (типа S3).
3️⃣Смертельная спираль: Если база на 100 ТБ, то восстанавливается она дольше, чем падает следующий узел. Система ломается быстрее, чем чинится.
7 стадий эволюции баз данных
✅ Решение: "Диагональное масштабирование"
Вместо того чтобы просто добавлять узлы, Tiger Beetle предлагает гибрид: RSM + LSM + Object Storage.
RSM (Replicated State Machine): Обеспечивает отказоустойчивость и строгую последовательность (Strict Serializability).
LSM-деревья: Эффективно работают с иерархией памяти (кэш -> RAM -> NVMe).
Облачное хранилище: Для бесконечного и дешевого хранения исторических данных.
🚀 Результаты Tiger Beetle
800,000 транзакций в секунду на обычном кластере из 3-х узлов.
В демо-ролике система обрабатывает 800,000 транзакций в секунду (TPS) на кластере из 3 узлов (очень красивое видео).
Итог: проектируйте систему не "для работы", а "для восстановления". Если вы научите базу "оживать" за минуты при любом объеме данных, то масштаб станет бесплатным побочным эффектом.
P.s.я понимаю, что в докладе очень много маркетинга, но как же это красиво! ☺️
Лучший доклад всей конференции по моему мнению! 💪Я слушал, смотрел видео и кайфовал! 😌
Очень много прикольный цитат. Очень здорово сделана презентация и видеоряд 🎥. Мне очень понравилось! Супер! 💥
Автор доклада - Joran Greef, Creator, Tigerbeetle.
В целом, он мне продал свою базу данных 💰. Была бы возможность, то сразу же запросил прайслист и дистриб на тестирование.
Начнем...
🛡 Масштабируемость - это не скорость. Это выживаемость
Многие думают, что масштаб - это про миллионы RPS и бесконечные кластеры. Но на самом деле масштаб - это способность системы не умереть окончательно, когда всё летит в тартарары.
Автор Tiger Beetle (БД для финтеха на языке Zig) выкатил мощный манифест о том, как пережить 1 триллион транзакций.
Вот краткая выжимка того, почему текущий стек может быть "слишком большим, чтобы выжить":
❌ Где все ошибаются?
1️⃣Шардирование (Horizontal Scaling): Оно убивает локальность кэша. Ваша CPU тратит время на ожидание сети, а не на вычисления.
2️⃣Разделение хранения и вычислений (Decoupling): Круто для аналитики, но слишком медленно для транзакций (OLTP) из-за задержек объектных хранилищ (типа S3).
3️⃣Смертельная спираль: Если база на 100 ТБ, то восстанавливается она дольше, чем падает следующий узел. Система ломается быстрее, чем чинится.
➖ MTTR > MTBF➖ Масштабировать систему сложно, потому что трудно обеспечить живучесть.➖ Вы больше не являетесь владельцем Системы, Система владеет Вами
7 стадий эволюции баз данных
1. log, журнал
2. Снапшоты
3. LSM-Tree
4. Репликация машины состояние (1988, основа Ver, за 1 год до Рафта)
5. Горизонтальное масштабирование (часть состояния машины)
6. Разделись всё. Отдельно сторадж и отдельно вычисления. Айсберг
7. (диагональное масштабирование (Diagonal Scaling) RSM + LSM + Object Storage
✅ Решение: "Диагональное масштабирование"
Вместо того чтобы просто добавлять узлы, Tiger Beetle предлагает гибрид: RSM + LSM + Object Storage.
RSM (Replicated State Machine): Обеспечивает отказоустойчивость и строгую последовательность (Strict Serializability).
LSM-деревья: Эффективно работают с иерархией памяти (кэш -> RAM -> NVMe).
Облачное хранилище: Для бесконечного и дешевого хранения исторических данных.
🚀 Результаты Tiger Beetle
800,000 транзакций в секунду на обычном кластере из 3-х узлов.
В демо-ролике система обрабатывает 800,000 транзакций в секунду (TPS) на кластере из 3 узлов (очень красивое видео).
Итог: проектируйте систему не "для работы", а "для восстановления". Если вы научите базу "оживать" за минуты при любом объеме данных, то масштаб станет бесплатным побочным эффектом.
P.s.я понимаю, что в докладе очень много маркетинга, но как же это красиво! ☺️
Please open Telegram to view this post
VIEW IN TELEGRAM
ScyllaDB
You Can't Scale When You're Dead - ScyllaDB
Scale is about survivability, not just performance: a system that can't stay alive when things break can't scale at all. This talk examines the limits holding back most OLTP systems, traces database architecture through seven stages of survivability, and…
❤6🤩2🔥1
📚Почему 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 дает предсказуемую и бешеную производительность💪
Люблю такие статейки про 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 дает предсказуемую и бешеную производительность💪
Medium
Redis Is Single-Threaded… So Why Is It So Fast?
Understanding Redis Internals: From Event Loops to I/O Threading
🤪3👍1
📚 Database Trends and Applications Magazine: February/March 2026
❗️Тема номера: Кто присматривает за СУБД? Как меняются роли DBA и специалистов по данным.
Дисклеймер: традиционно разбираю только небольшой набор статей.
➡️SURVEY: DATA INFRASTRUCTURE IS NOT READY FOR THE AI AGE
Традиционно 1-ая статья про ИИ. Забавно, что в этот раз она основана не на опросе компаний, а на результатах исследования компании Cockroach Labs, которое выявило серьезный разрыв между амбициями компаний в сфере ИИ и готовностью их ИТ-инфраструктуры.
1️⃣ Разрыв между амбициями и реальностью. Бизнес находится в состоянии эйфории от возможностей ИИ, но технические специалисты не могут заставить его работать 😏. Классическая ситуация, когда софт (модели ИИ) на десятилетие опередил железо и методы управления данными.
2️⃣ База данных - новое "узкое горлышко". Традиционные архитектуры просто не рассчитаны на ту интенсивность и непредсказуемость, которую создают автономные ИИ-агенты. Это всё к тому, что зарождается маркетинговый термин AI-native базы данных.
3️⃣ Управленческая слепота: Компании инвестируют в ИИ, но не получают отдачи, так как система постоянно "падает" или тормозит под нагрузкой 😞.
Мы сами сейчас внедряем свой "карманный" ИИ и сталкиваюсь с описанными проблемами. Тормозит жестко...
4️⃣ Необходимость новой архитектуры. Авторы подводят к мысли, что для эпохи ИИ нужны принципиально другие системы, например, облачно-ориентированные, способные к мгновенному масштабированию и сверхбыстрой обработке транзакций.
Кто бы сомневался 🤔 Опять облака всех спасут💭 . Ну-ну... я вижу как страны персидского залива кайфуют после выхода из строя уже двух ЦОД Amazon😶🌫️ .
➡️ Who’s Minding the Database? The Changing Role of DBAs and Data Professionals
❗️Главная статья номера.
Это явно продолжение статьи из прошлого номера.
Фу...😠 Наймите вы отдельных людей для этого. Почему все мучают бедных DBA? Не понятно... 😔
В крупных компаниях часто я слышу в адрес коллег такое:
И очень часто народ тупит над этим вопрос😵💫. Мне кажется это проверка на ЧСВ 🤴. Надо растить это чувство, чтобы народ понимал, что ты самый ох**нный специалист на свете 💪!
➡️Harnessing the Potential of CXL for Cloud-Native Databases
Статья и новой технологии CXL (Compute Express Link).
Главная идея статьи - переход от традиционного разделения ресурсов к дизагрегации памяти, что позволяет базам данных работать быстрее, надежнее и дешевле.
RDMA для disaggregated memory уже недостаточно хороша для будущих cloud-native БД, а CXL может дать более тонкий доступ к памяти, лучшую когерентность, более быстрое recovery и лучшую экономику инфраструктуры.
Технология решает главную проблему облачных БД — неэффективное использование дорогой оперативной памяти и долгие простои при сбоях.
❗️Тема номера: Кто присматривает за СУБД? Как меняются роли DBA и специалистов по данным.
Дисклеймер: традиционно разбираю только небольшой набор статей.
➡️SURVEY: DATA INFRASTRUCTURE IS NOT READY FOR THE AI AGE
Традиционно 1-ая статья про ИИ. Забавно, что в этот раз она основана не на опросе компаний, а на результатах исследования компании Cockroach Labs, которое выявило серьезный разрыв между амбициями компаний в сфере ИИ и готовностью их ИТ-инфраструктуры.
Мы сами сейчас внедряем свой "карманный" ИИ и сталкиваюсь с описанными проблемами. Тормозит жестко...
Кто бы сомневался 🤔 Опять облака всех спасут
➡️ Who’s Minding the Database? The Changing Role of DBAs and Data Professionals
❗️Главная статья номера.
Это явно продолжение статьи из прошлого номера.
Современный DBA перестает быть просто "хранителем2 серверов и становится стратегическим партнером бизнеса.
Фу...😠 Наймите вы отдельных людей для этого. Почему все мучают бедных DBA? Не понятно... 😔
DBA как «Стюард платформы данных»
Вместо того чтобы быть изолированным «контролером» (gatekeeper), специалист по данным теперь:
👉Определяет правила и стандарты (governance), по которым разработчики могут сами изменять схемы данных.
👉Отвечает за надежность и скорость данных, которые питают аналитику и ИИ.
👉Управляет стоимостью облачных ресурсов и соблюдением законодательных норм.
Роль администратора баз данных не исчезает, но радикально меняется. Она становится менее технически-рутинной и более стратегической, интересной и влиятельной для успеха всей организации. Это переход от "обслуживания инфраструктуры" к "управлению интеллектуальным капиталом компании".
В крупных компаниях часто я слышу в адрес коллег такое:
"Как твоя работа влияет на наш Бизнес? Как ты приносишь деньги?"
И очень часто народ тупит над этим вопрос😵💫. Мне кажется это проверка на ЧСВ 🤴. Надо растить это чувство, чтобы народ понимал, что ты самый ох**нный специалист на свете 💪!
➡️Harnessing the Potential of CXL for Cloud-Native Databases
Статья и новой технологии CXL (Compute Express Link).
CXL - это высокоскоростной открытый стандарт интерконнекта для когерентной связи CPU-устройств (например, ускорителей, GPU, SSD) и CPU-памяти (позволяя процессору использовать память устройств как свою собственную и наоборот).
Главная идея статьи - переход от традиционного разделения ресурсов к дизагрегации памяти, что позволяет базам данных работать быстрее, надежнее и дешевле.
RDMA для disaggregated memory уже недостаточно хороша для будущих cloud-native БД, а CXL может дать более тонкий доступ к памяти, лучшую когерентность, более быстрое recovery и лучшую экономику инфраструктуры.
Технология решает главную проблему облачных БД — неэффективное использование дорогой оперативной памяти и долгие простои при сбоях.
Lifelong Learners
...
In short, the great DBA of 2026 is a hybrid: part technologist, part strategist, part businessperson, part diplomat. They’re not just managing databases, they’re managing complexity, risk, and opportunity.
Please open Telegram to view this post
VIEW IN TELEGRAM
Database Trends and Applications
Database Trends and Applications Magazine: February/March 2026 Issue
The February/March issue of Database Trends and Applications magazine includes a special MultiValue database technology report.
📚 "дезинтермедиации" (disintermediation) баз данных
Пора почитать блоги других исследователей в области ИТ-технологий 🔎.
И так, товарищ из аналитической компании RedMonk написал статью о том, что эпоха «баз-посредников» подходит к концу. Наступает дезинтермедиация.
😵💫 Что происходит?
👉 Хранение ушло в свободное плавание. Раньше данные принадлежали базе. Теперь они лежат в дешевых облаках и открытых форматах типа Apache Iceberg, что позволяет придать «бесформенным» блобам свойства таблиц (схемы, ACID-транзакции). Это отделяет логику хранения данных от вычислительных движков.
👉 Движки запросов стали расходным материалом. Инструменты для выполнения запросов (query engines) становятся отделяемыми от уровня хранения. Это означает, что "сложность их переноса" больше не является таким серьезным барьером для смены технологий, как раньше. Привязка к вендору (Vendor Lock-in) ломается прямо на глазах.
👉 ИИ крадет интерфейс (AI-native). Зачем учить диалекты SQL, если можно спросить ИИ-агента человеческим языком? База данных превращается в «черный ящик» где-то глубоко под капотом, до которого пользователю нет дела.
👉 Стирание границ между транзакциями (OLTP) и аналитикой (OLAP). HTAP в кадым дом! Транзакционные базы (например, PostgreSQL) все чаще используются для аналитики. OLAP и OLTP системы движутся к друг другу
Конечно, старый добрый PostgreSQL не умрет завтра, можете расслабиться (он переживет нас всех). Но для новых проектов база перестает быть "священным граалем"🏆. Теперь это просто конструктор: здесь храним, там считаем, а ИИ объясняет, почему всё тормозит 🤗.
Зановес
Пора почитать блоги других исследователей в области ИТ-технологий 🔎.
База Данных традиционно является центром притяжения для ИТ-архитектуры. Мы выбирали СУБД как спутника жизни, один раз, по любви или расчету, и на всю жизнь! ❤️💋
И так, товарищ из аналитической компании RedMonk написал статью о том, что эпоха «баз-посредников» подходит к концу. Наступает дезинтермедиация.
😵💫 Что происходит?
👉 Хранение ушло в свободное плавание. Раньше данные принадлежали базе. Теперь они лежат в дешевых облаках и открытых форматах типа Apache Iceberg, что позволяет придать «бесформенным» блобам свойства таблиц (схемы, ACID-транзакции). Это отделяет логику хранения данных от вычислительных движков.
👉 Движки запросов стали расходным материалом. Инструменты для выполнения запросов (query engines) становятся отделяемыми от уровня хранения. Это означает, что "сложность их переноса" больше не является таким серьезным барьером для смены технологий, как раньше. Привязка к вендору (Vendor Lock-in) ломается прямо на глазах.
👉 ИИ крадет интерфейс (AI-native). Зачем учить диалекты SQL, если можно спросить ИИ-агента человеческим языком? База данных превращается в «черный ящик» где-то глубоко под капотом, до которого пользователю нет дела.
👉 Стирание границ между транзакциями (OLTP) и аналитикой (OLAP). HTAP в кадым дом! Транзакционные базы (например, PostgreSQL) все чаще используются для аналитики. OLAP и OLTP системы движутся к друг другу
Конечно, старый добрый PostgreSQL не умрет завтра, можете расслабиться (он переживет нас всех). Но для новых проектов база перестает быть "священным граалем"🏆. Теперь это просто конструктор: здесь храним, там считаем, а ИИ объясняет, почему всё тормозит 🤗.
Зановес
Alt + E S V
The Disintermediation of Databases
The database has been the center of gravity in data architecture for decades. It owned the storage, the query layer, and the interface. That center of gravity is changing. We’re seeing this structural erosion happening from multiple directions at once: cheaper…
🎦 The End of Eventual Consistency | CockroachDB
Кликбейтное название + тайминг в 6:28 = секрет успешного видео! Люблю такое!😍
Понятное дело, что строгая согласованность лучше согласованности в конечном счета. Это понятно 👌
В целом, автор видео это наглядно нам продемонстрировал.
Меня в этом видео зацепил сам эксперимент.
Автор взял кластер из трех нод CockroachDB (3 мастера) и RDS for PostgreSQL (1 мастер + 2 реплика. Причем не понятно, репликация синхронная или асинхронная)
Затем смоделировал нагрузку, а-ля, e-commerce-сценарий в котором агенты (или пользователи) создают и забирают ваучеры.
Тест запускался параллельно для 10 агентов, где каждый создавал по 100 ваучеров.
Результаты очевидны:
В целом, ничего удивительного. Но мне захотелось воспроизвести этот сценарий тестирования. Надо бы написать подобный скрипт с нагрузкой и проверить его на Постгресе с двумя синхронными репликами. Еще можно собрать мастер-мастер кластер из трех нод на PostgresPro дистрибутиве . Мне кажется результаты будут другие.
В общем, отличная тема для открытого урока!
Возьму на заметку 📝
Кликбейтное название + тайминг в 6:28 = секрет успешного видео! Люблю такое!
Понятное дело, что строгая согласованность лучше согласованности в конечном счета. Это понятно 👌
В целом, автор видео это наглядно нам продемонстрировал.
Меня в этом видео зацепил сам эксперимент.
Автор взял кластер из трех нод CockroachDB (3 мастера) и RDS for PostgreSQL (1 мастер + 2 реплика. Причем не понятно, репликация синхронная или асинхронная)
Затем смоделировал нагрузку, а-ля, e-commerce-сценарий в котором агенты (или пользователи) создают и забирают ваучеры.
Тест запускался параллельно для 10 агентов, где каждый создавал по 100 ваучеров.
Результаты очевидны:
🪳 CockroachDB
все ваучеры созданы и захвачены корректно, без дублирования (Strong Consistance всё-таки)🐘 RDS PostgreSQL
В "вежливом" режиме, 36 случаев двойного захвата одного ваучера. В "невежливом" режиме. появились случаи тройного захвата. Причина в том, что агент проверяет статус ваучера на реплике, где данные ещё не обновились, и повторно захватывает уже занятый ресурс.
В целом, ничего удивительного. Но мне захотелось воспроизвести этот сценарий тестирования. Надо бы написать подобный скрипт с нагрузкой и проверить его на Постгресе с двумя синхронными репликами. Еще можно собрать мастер-мастер кластер из трех нод на PostgresPro дистрибутиве . Мне кажется результаты будут другие.
В общем, отличная тема для открытого урока!
Возьму на заметку 📝
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
The End of Eventual Consistency | CockroachDB
This video demonstrates why eventual consistency in databases is becoming increasingly problematic with the rise of AI agents. Rob Reid explains why choosing a database built for strong consistency reduces the complexity and potential for error in rapidly…
📚Introducing Valkey Admin: Visual Cluster Management for Valkey 2026-02-25 · Allen Helton, Arseny Kostenko
Какая классная тема! Первая opensource GUI для Valkey! Проект пока на очень ранее стадии, но надеюсь они доведут его до ума. Я обожаю всяческие графические управляшки. Супер! Буду обязательно следить за проектом.
Написан на TypeScript + JavaScript
Текущие особенности:
👉 Визуализация топологии кластера
👉 Мониторинг узлов
👉 Управление ключами (просмотр, редактирование, удаление)
👉 Диагностика производительности
👉 Встроенный CLI
В будущем планируется веб-версия. RedisInsight подвинься...
Valkey Admin - новый инструмент с графическим интерфейсом для визуального управления кластерами Valkey.
Какая классная тема! Первая opensource GUI для Valkey! Проект пока на очень ранее стадии, но надеюсь они доведут его до ума. Я обожаю всяческие графические управляшки. Супер! Буду обязательно следить за проектом.
Написан на TypeScript + JavaScript
Текущие особенности:
👉 Визуализация топологии кластера
👉 Мониторинг узлов
👉 Управление ключами (просмотр, редактирование, удаление)
👉 Диагностика производительности
👉 Встроенный CLI
В будущем планируется веб-версия. RedisInsight подвинься...
valkey.io
Valkey: Introducing Valkey Admin: Visual Cluster Management for Valkey
Valkey Admin is an open-source desktop application that provides visual cluster topology, hot key detection, performance diagnostics, and interactive key management for Valkey clusters without piecing together CLI commands. Now in preview!
❤1
📚Open Source, Community, and Consequence: The Story of MongoDB
Конечно она далеко не полная, но кое-какие вызовы подсвечивает.
Я попытался разбить текст статьи на исторические вехи
🚀 Этап 1: Рождение из боли (2007–2009)
👉 Основатели работают в DoubleClick (рекламный гигант). Реляционные базы не справляются с веб нагрузками.
👉 Идея: Хватит пытаться втиснуть объекты из кода в таблицы. Сделаем «документную модель» — JSON-подобные структуры, которые понятны разработчику.
🔥 В результате появилась MongoDB.
🌪 Этап 2: Хайп и «Web-Scale» (2010–2014)
Взрыв популярности. Весь мир строит приложения на «MERN/MEAN» стеке.
Ложка дегтя. Появляются мемы про потерю данных и плохую консистентность. Критики разносят базу за отсутствие транзакций и слабую надежность. Однако Команда признает ошибки, активно слушает сообщество и исправляет баги и пилит фичи.
🛠 Этап 3: Техническое взросление (2015–2018)
⚡️Покупка движка WiredTiger. MongoDB полностью переписывает систему хранения.
👉Появление ACID-транзакций. База перестает быть «игрушкой для стартапов» и заходит в банки и энтерпрайз. Я бы еще добавил, отказ от BASE и добавлением необходимых "корпоративных" фич.
☁️ Этап 4: Облачные войны и Atlas (2019–2023)
🧨 Бизнес-бомба: Ввод лицензии SSPL. Запрет использования облачным провайдерам кода MongoDB без дополнительной платы.
👉 Релиза своего облачного сервиса Mongo Atlas.
🤖 Этап 5: Платформа данных (Сегодня)
🤘 Это уже не просто NoSQL. Теперь это «Developer Data Platform».
👉 Векторный поиск для ИИ, полнотекстовый поиск, аналитика в реальном времени.
Как итог я бы сказал, что сообщество - ключ к успеху. Надо делать всё возможное, чтобы привлекать народ к своему продукту. Реклама, маркетинг, бренд маскот и т.п.
Я ScyllaDB полюбил как вендора только благодаря маскоту. Хотя сам я эту СУБД нигде не использую. Но отношение к ней максимально положительное 🤪
История эволюции MongoDB от простой нишевой документоориентированной БД до полнофункциональной платформы данных..
Конечно она далеко не полная, но кое-какие вызовы подсвечивает.
"нереляционных" данных не существует. Любые данные имеют связи. Разница лишь в том, как мы их моделируем.
Я попытался разбить текст статьи на исторические вехи
🚀 Этап 1: Рождение из боли (2007–2009)
👉 Основатели работают в DoubleClick (рекламный гигант). Реляционные базы не справляются с веб нагрузками.
👉 Идея: Хватит пытаться втиснуть объекты из кода в таблицы. Сделаем «документную модель» — JSON-подобные структуры, которые понятны разработчику.
🔥 В результате появилась MongoDB.
🌪 Этап 2: Хайп и «Web-Scale» (2010–2014)
Взрыв популярности. Весь мир строит приложения на «MERN/MEAN» стеке.
Ложка дегтя. Появляются мемы про потерю данных и плохую консистентность. Критики разносят базу за отсутствие транзакций и слабую надежность. Однако Команда признает ошибки, активно слушает сообщество и исправляет баги и пилит фичи.
🛠 Этап 3: Техническое взросление (2015–2018)
⚡️Покупка движка WiredTiger. MongoDB полностью переписывает систему хранения.
👉Появление ACID-транзакций. База перестает быть «игрушкой для стартапов» и заходит в банки и энтерпрайз. Я бы еще добавил, отказ от BASE и добавлением необходимых "корпоративных" фич.
☁️ Этап 4: Облачные войны и Atlas (2019–2023)
🧨 Бизнес-бомба: Ввод лицензии SSPL. Запрет использования облачным провайдерам кода MongoDB без дополнительной платы.
👉 Релиза своего облачного сервиса Mongo Atlas.
🤖 Этап 5: Платформа данных (Сегодня)
👉 Векторный поиск для ИИ, полнотекстовый поиск, аналитика в реальном времени.
Как итог я бы сказал, что сообщество - ключ к успеху. Надо делать всё возможное, чтобы привлекать народ к своему продукту. Реклама, маркетинг, бренд маскот и т.п.
Я ScyllaDB полюбил как вендора только благодаря маскоту. Хотя сам я эту СУБД нигде не использую. Но отношение к ней максимально положительное 🤪
Please open Telegram to view this post
VIEW IN TELEGRAM
InfoQ
Open Source, Community, and Consequence: the Story of MongoDB
Andrew Davidson and Akshat Vig discuss the journey of disrupting the transactional database market. They explain why the document model became the "Buckminster Fuller" moment for modern apps and share lessons on scaling from "web-scale" memes to mission-critical…
❤2
📚 ClickHouse не тормозит, но заставляет глаз дергаться. Materialized Views
Не буду обозревать эту статью. Она на 4 минутки и так можно прочесть 😎.
По сути автор жалуется, что материализованные представления в РСУБД и они же в Кликхаусе работают совершенно по другому 😲. Нужно отдельно про них читать и вникать в нюансы. Это прекрасно подчеркнуто в комментарии:
Мне даже добавить нечего. Всё, что вы знаете по РСУБД справедливо только для РСУБД. Представления, констрейнты, индексы и триггеры в других СУБД могут работать совсем не так, как вы ожидаете. Будьте к этому готовы 😉
Не буду обозревать эту статью. Она на 4 минутки и так можно прочесть 😎.
По сути автор жалуется, что материализованные представления в РСУБД и они же в Кликхаусе работают совершенно по другому 😲. Нужно отдельно про них читать и вникать в нюансы. Это прекрасно подчеркнуто в комментарии:
Когда вы имеете дело с продуктом, который на первый взгляд выглядит как типичная реляционная СУБД, но у которого, внезапно, первичный ключ не предполагает уникальности, вы не только вправе, но даже обязаны ожидать от него чего угодно.
Мне даже добавить нечего. Всё, что вы знаете по РСУБД справедливо только для РСУБД. Представления, констрейнты, индексы и триггеры в других СУБД могут работать совсем не так, как вы ожидаете. Будьте к этому готовы 😉
Хабр
ClickHouse не тормозит, но заставляет глаз дергаться. Materialized Views
Вы пришли из мира PostgreSQL, Oracle или MSSQL. Вы знаете: материализованное представление — это «замороженный» результат запроса. Удобно. Предсказуемо. Вы открываете документацию ClickHouse. Видите...
👍4
📚 Почему "достаточно хорошие2 облачные базы данных становятся риском для бизнеса?
В последнее время часто встречаются статьи исследований, которые делают аналитические и RnD агенства по заказу компаний разработчиков СУБД. Что CockroachLab, что Scylla сейчас. Почему в РФ нет такой практики? Такое ощущение, что люди сами себе аналитики и не хотят платить за исследования. Хотя по DevOps регулярно проводятся разные опросы и исследования.
Подниму этот вопрос на каких-нибудь конференциях и спрошу народ... Если не забуду 😊
Вернемся к статье. Главные тезис:
По сути это классическая ловушка. Система сейчас работает и всё ОК, но что будет через год-два, когда данных станет больше? Как поведет себя система? Спрогнозировать тяжело. Хотя вру, не тяжело. Дорого 💰 Попробуй выбить у руководство бюджет на подобные тесты 😊
Я сам переживал только последний вариант. Реально, пришел новый СТО и сказал всем перейти с БД Oracle. Это было давно, но всё-таки. Мы все массово всем банком пошли в новое будущее....
Никогда не видел, чтобы меняли СУБД исходя из каких-то технических ограничений или ошибок и т.д.
СУБД меняют только тогда, когда компания-разработчик "умерла" или ушла с рынка. Всё.
Довольно забавный вывод из статьи. Действительно проблема на лицо. Сейчас на хайпе PostgreSQL. Найти спеца по это СУБД очень легко. Понятное дело, что есть нюансы, но по крайне мере выбор есть. Найти специалиста по Valkey или MongoDB или YDB даже по Tarantool, а? Реально на рынке? Особенно если он не бывший сотрудник Яндекса или VK. Проблема в обучение специалистов технологиями 2-ого или 3-ого эшелона на лицо.
Как итог можно сказать следующее, что это статья не про базы данных, а про поведение компаний в разных ситуациях. Все архитектурные решения откладываются до тех пор, пока система не начинает приносить убытки.
В исследовании Futurum Group, выполненное по заказу ScyllaDB, рассматриваются расходы на облачные базы данных, проблемы с производительностью и причины миграции на другие системы.
В последнее время часто встречаются статьи исследований, которые делают аналитические и RnD агенства по заказу компаний разработчиков СУБД. Что CockroachLab, что Scylla сейчас. Почему в РФ нет такой практики? Такое ощущение, что люди сами себе аналитики и не хотят платить за исследования. Хотя по DevOps регулярно проводятся разные опросы и исследования.
Подниму этот вопрос на каких-нибудь конференциях и спрошу народ... Если не забуду 😊
Вернемся к статье. Главные тезис:
У многих команд с текущей облачной БД всё "вроде бы нормально", но уверенности в будущем нет. 33% респондентов довольны текущей конфигурацией, но при этом 38% опасаются, что их нынешняя база не справится с будущими техническими требованиями, включая рост данных, AI/ML-нагрузки и новые требования по соответствию. То есть сегодня система ещё устраивает, а завтра уже может стать проблемой.
По сути это классическая ловушка. Система сейчас работает и всё ОК, но что будет через год-два, когда данных станет больше? Как поведет себя система? Спрогнозировать тяжело. Хотя вру, не тяжело. Дорого 💰 Попробуй выбить у руководство бюджет на подобные тесты 😊
Решение о смене БД редко принимается “рационально”.
Обычно это:
👉 не меняем ➡️ потому что работает
👉 терпим ➡️ потому что высокая цена миграции
👉 меняем ➡️ когда пришёл новый CTO
Я сам переживал только последний вариант. Реально, пришел новый СТО и сказал всем перейти с БД Oracle. Это было давно, но всё-таки. Мы все массово всем банком пошли в новое будущее....
Никогда не видел, чтобы меняли СУБД исходя из каких-то технических ограничений или ошибок и т.д.
СУБД меняют только тогда, когда компания-разработчик "умерла" или ушла с рынка. Всё.
Замкнутый круг
экономим ресурсы ➡️падает производительность
➡️ не хватает экспертизы ➡️ не можем оптимизировать
➡️ система кажется плохой ➡️ но менять дорого ➡️ работаем с тем, что есть
Довольно забавный вывод из статьи. Действительно проблема на лицо. Сейчас на хайпе PostgreSQL. Найти спеца по это СУБД очень легко. Понятное дело, что есть нюансы, но по крайне мере выбор есть. Найти специалиста по Valkey или MongoDB или YDB даже по Tarantool, а? Реально на рынке? Особенно если он не бывший сотрудник Яндекса или VK. Проблема в обучение специалистов технологиями 2-ого или 3-ого эшелона на лицо.
Как итог можно сказать следующее, что это статья не про базы данных, а про поведение компаний в разных ситуациях. Все архитектурные решения откладываются до тех пор, пока система не начинает приносить убытки.
The New Stack
Why “good enough” cloud databases are becoming a business risk
Research finds 38% of tech leaders doubt their database can handle future AI workloads, yet most wait for a crisis before migrating.
❤1
📚 DuckDB использует реляционную базу данных для решения классической проблемы «небольших изменений» в системах хранения данных.
DuckDB предлагает неожиданный поворот в архитектуре lakehouse.
Вкратце, они решили вернуть в lakehouse… классическую реляционную базу данных. Но используют её не для хранения данных, а для хранения метаданных и обработки мелких изменений .
Казалось, а зачем? Проблема современных lakehouse (Iceberg, Delta и др.) в том, что они плохо справляются с маленькими изменениями. Добавили пару строк - получили новый файл или обновили метаданные - сделали лишние операции с хранилищем.
❌В итоге:
👉 много мелких файлов
👉 лишние IO
👉 падение производительности
DuckDB предлагает следующее:
1️⃣ сначала писать изменения в обычную SQL-БД
2️⃣ накапливать их
3️⃣ и только потом батчами выгружать в Parquet
✅Что это даёт:
👉 меньше файлов
👉 меньше накладных расходов
👉 данные записываются быстрее
По сути, это попытка сбалансировать два мира:
гибкость lakehouse + строгость и эффективность классических СУБД
Мне кажется это никак не революция, а какой-то шаг назад, чтобы чуть подумать и потом сделать более осознанный шаг вперед. Это промежуточная конструкция.
Данный "костыль" поднимает новые вопросы
🤔 не станет ли RDBMS новым узким местом?
🤔 не усложняется ли архитектура?
🤔 не теряется ли идея serverless?
DuckDB аккуратно подталкивает индустрию к мысли, что будущее не в чистом lakehouse, а в гибридных решениях.
DuckDB предлагает неожиданный поворот в архитектуре lakehouse.
Вкратце, они решили вернуть в lakehouse… классическую реляционную базу данных. Но используют её не для хранения данных, а для хранения метаданных и обработки мелких изменений .
Казалось, а зачем? Проблема современных lakehouse (Iceberg, Delta и др.) в том, что они плохо справляются с маленькими изменениями. Добавили пару строк - получили новый файл или обновили метаданные - сделали лишние операции с хранилищем.
❌В итоге:
👉 много мелких файлов
👉 лишние IO
👉 падение производительности
DuckDB предлагает следующее:
1️⃣ сначала писать изменения в обычную SQL-БД
2️⃣ накапливать их
3️⃣ и только потом батчами выгружать в Parquet
✅Что это даёт:
👉 меньше файлов
👉 меньше накладных расходов
👉 данные записываются быстрее
По сути, это попытка сбалансировать два мира:
гибкость lakehouse + строгость и эффективность классических СУБД
мы слишком увлеклись “файловой” архитектурой lakehouse и забыли, что у СУБД уже давно есть решения для транзакций, метаданных и мелких операций.
Мне кажется это никак не революция, а какой-то шаг назад, чтобы чуть подумать и потом сделать более осознанный шаг вперед. Это промежуточная конструкция.
Данный "костыль" поднимает новые вопросы
🤔 не станет ли RDBMS новым узким местом?
🤔 не усложняется ли архитектура?
🤔 не теряется ли идея serverless?
DuckDB аккуратно подталкивает индустрию к мысли, что будущее не в чистом lakehouse, а в гибридных решениях.
The Register
DuckDB uses RDBMS to attack classic 'small changes' problem in lakehouses
: Batching teensy changes in chunks creates massive performance boost, DuckDB Labs team claims
❤2
📚 Как Redis Auto Failover повышает отказоустойчивость наших БД
Классная статья про адаптацию опенсор версии Redis под требования реального мира. Кластер Redis является хорошим решением, но не идеальным. Если у вас одномоментно выходит из строя кворум мастеров, то кластер считается разваленным, даже если реплики с нужными данными живы.
Ребята из WB прикрутили свой дополнительный механизм Auto Failover поверх Redis Cluster. Он очень похож на слой координации, аналогичный DCS (Distributed Configuration Store).
Идея хорошая. Я о подобном писал недавно.
Надеюсь, что WB выложат свой доработку в opensource.
Классная статья про адаптацию опенсор версии Redis под требования реального мира. Кластер Redis является хорошим решением, но не идеальным. Если у вас одномоментно выходит из строя кворум мастеров, то кластер считается разваленным, даже если реплики с нужными данными живы.
Ребята из WB прикрутили свой дополнительный механизм Auto Failover поверх Redis Cluster. Он очень похож на слой координации, аналогичный DCS (Distributed Configuration Store).
Идея хорошая. Я о подобном писал недавно.
Надеюсь, что WB выложат свой доработку в opensource.
Хабр
Как Redis Auto Failover повышает отказоустойчивость наших БД
Введение Привет! Меня зовут Иван Откидач, я DevOps-инженер в команде DBA. Моя основная специализация — NoSQL-базы данных, в частности Redis и MongoDB. С каждым месяцем количество Redis, находящихся на...
👍3