📚 Шардинг MongoDB: что нужно знать перед началом шардинга
Я немного соскучился по статьям про MongoDB 😚. Приятно снова почитать что-то из серии "перед тем как шардировать, остановись, подумай и сверься с ИИ" 😉
Каких-то откровений тут нет. Если вы уже сталкивались с шардингом, targeted vs scatter-gather и вечным вопросом выбора shard key (ключ локальности, на русском звучит забавно), то всё будет знакомо 🪧. Но в этом и плюс, автор не пытается изобрести что-то новое, а аккуратно напоминает про грабли: запросы без shard key превращаются в прогулку по всем шардам, монотонные ключи легко делают вам hot shard, а hashed/range - это компромисс, а не «правильный ответ».
Статья приятная визуально ☺️. Примеры и картинки реально помогают, а кейс с книжным магазином хорошо "прожёвывает" логику выбора ключа 🔑.
Материал местами слишком дружелюбный (не ИИшный ли часом? 🫤 ). Не хватает чувства боли 😖 от реальных проблем с прода (миграции, паттерны запросов, балансер, стоимость scatter-gather под нагрузкой), но как короткий чек-лист перед шардированием сгодится!
Я немного соскучился по статьям про MongoDB 😚. Приятно снова почитать что-то из серии "перед тем как шардировать, остановись, подумай и сверься с ИИ" 😉
Каких-то откровений тут нет. Если вы уже сталкивались с шардингом, targeted vs scatter-gather и вечным вопросом выбора shard key (ключ локальности, на русском звучит забавно), то всё будет знакомо 🪧. Но в этом и плюс, автор не пытается изобрести что-то новое, а аккуратно напоминает про грабли: запросы без shard key превращаются в прогулку по всем шардам, монотонные ключи легко делают вам hot shard, а hashed/range - это компромисс, а не «правильный ответ».
Статья приятная визуально ☺️. Примеры и картинки реально помогают, а кейс с книжным магазином хорошо "прожёвывает" логику выбора ключа 🔑.
Материал местами слишком дружелюбный (не ИИшный ли часом? 🫤 ). Не хватает чувства боли 😖 от реальных проблем с прода (миграции, паттерны запросов, балансер, стоимость scatter-gather под нагрузкой), но как короткий чек-лист перед шардированием сгодится!
Medium
MongoDB Sharding: What to Know Before You Shard
This article was written by Ricardo Mello, Senior Developer Advocate.
📚 Хроники Valkey: сайдкары, операторы и один очень упрямый кластер
В Авито один из самых крупных внедрений Redis'а на территории РФ 👍. С ними разве что-то Яндекс.Облако посоперничать, но от последних давно ничего не слышал.
Авитовцы наконец решились переехать на Valkey и уйти от Redis. Даже смена лицензии с Redis 8 обратно в opensource проект не остановило. Я думаю, что статья вышла довольно поздно. Мне кажется, что проект по миграции был сделан месяца за 3-4. По сути, чего там менять то? API полностью совместимы. И с точки зрения эксплуатации и мониторинга ничего не меняется. Даже чуть лучше становится.
Я думаю, что товарищей из Авито подкупила то, что Valkey будет активно прокачивать свой Valkey Cluster 😎. А в Авито это 400+ инсталяций!
Думаю, стоит ждать новых статей от ребят по Valkey. Хотя я больше надеюсь на их доклады 📇
А пока, записывайтесь на мой курс по Redis/Valkey! Старт чуть съехал на 1 неделю, поэтому начала 2 марта!
В Авито один из самых крупных внедрений Redis'а на территории РФ 👍. С ними разве что-то Яндекс.Облако посоперничать, но от последних давно ничего не слышал.
Авитовцы наконец решились переехать на Valkey и уйти от Redis. Даже смена лицензии с Redis 8 обратно в opensource проект не остановило. Я думаю, что статья вышла довольно поздно. Мне кажется, что проект по миграции был сделан месяца за 3-4. По сути, чего там менять то? API полностью совместимы. И с точки зрения эксплуатации и мониторинга ничего не меняется. Даже чуть лучше становится.
Я думаю, что товарищей из Авито подкупила то, что Valkey будет активно прокачивать свой Valkey Cluster 😎. А в Авито это 400+ инсталяций!
Думаю, стоит ждать новых статей от ребят по Valkey. Хотя я больше надеюсь на их доклады 📇
А пока, записывайтесь на мой курс по Redis/Valkey! Старт чуть съехал на 1 неделю, поэтому начала 2 марта!
Хабр
Хроники Valkey: сайдкары, операторы и один очень упрямый кластер
Привет! Меня зовут Никита Кречетов, я работаю в команде Datawave в юните DBA в Авито . В этой статье рассказываю, как мы перевели полторы тысячи инстансов Redis на Valkey за два месяца, как отказались...
🔥2
📚 Миссия выполнима: как мы добились актуальности двух тысяч кешей
Еще одна статья про Valkey 🙄. И про скрытаю миграцию. Как я понял, все уже было сделано, но нужно еще как-то "улучшить", возможно упростить 😅. Поэтому ребята с Redis и Memcashed переехали на Valkey.
В контексте этого проекта озоновцам был важен функционал Pub/Sub и Streams. После небольших доработок "напильником" 🛠(100 пудов они не чистый opensource задеплоили в кубик) все поставленные задачи были решены. Успех! 😎
Размеры данных потрясают! Вау! ☝️Я с таким объемом в проде дел не имел. БигТех всё-таки...
Очередное подтверждение того, что спустя 1.5 года существования Valkey он начинает набирать популярность и применимость в проде у серьезных ребят. Единственно, что смущает - это неизвестность в области доработок. Что они меняли "в коробке"? ❓ Очень интересно 🤔
Надеюсь, что ребята из Озон и Авито будут активно контребьютить в проект ☑️. Спрошу их об этом на конференциях в этом году. Пока на примете только DevOpsConf2026 в апреле и HighLoadSPB++ в июне.
Еще одна статья про Valkey 🙄. И про скрытаю миграцию. Как я понял, все уже было сделано, но нужно еще как-то "улучшить", возможно упростить 😅. Поэтому ребята с Redis и Memcashed переехали на Valkey.
В контексте этого проекта озоновцам был важен функционал Pub/Sub и Streams. После небольших доработок "напильником" 🛠(100 пудов они не чистый opensource задеплоили в кубик) все поставленные задачи были решены. Успех! 😎
Поскольку подов у нас 2000, а кешей в Valkey — 115 терабайт
Размеры данных потрясают! Вау! ☝️Я с таким объемом в проде дел не имел. БигТех всё-таки...
Очередное подтверждение того, что спустя 1.5 года существования Valkey он начинает набирать популярность и применимость в проде у серьезных ребят. Единственно, что смущает - это неизвестность в области доработок. Что они меняли "в коробке"? ❓ Очень интересно 🤔
Надеюсь, что ребята из Озон и Авито будут активно контребьютить в проект ☑️. Спрошу их об этом на конференциях в этом году. Пока на примете только DevOpsConf2026 в апреле и HighLoadSPB++ в июне.
🔥2
Всегда в коллективе найдется такой человек. Грустнее всего, что приходиться с ним работать всё равно 🥲.
С пятницей!
#mems
С пятницей!
#mems
😁5👍1
📚OpenEverest: платформа с открытым исходным кодом для автоматизации баз данных
Буквально недавно Percona объявила о том, что их продукт Percona Everest трансформируется в OpenEverest и становится opensource.
К сожалению, в моей среде обитания кубера нет, поэтому мне тяжело рассуждать насколько этот проект будет полезен современным DevOps специалистам. Это прекрасная тема для разработки НИР 😏
Помню с 2020-2023 на кафедре было много тем про Кубнетес. Каждый третий студент искал возможности его "улучшить". Думаю пришла пора вернуть подобные темы в список для защиты 😈
Буквально недавно Percona объявила о том, что их продукт Percona Everest трансформируется в OpenEverest и становится opensource.
OpenEverest — новый открытый проект от Percona, который представляет собой базу управления базами данных на Kubernetes. В ней объясняется, что OpenEverest — это модульная платформа для автоматического развёртывания, масштабирования, резервного копирования и восстановления кластеров БД (PostgreSQL, MySQL, MongoDB и др.) на Kubernetes-инфраструктуре, будь то облако или собственный сервер. Он использует Kubernetes-операторы и CRD, чтобы операции с базами выглядели как обычные, декларативные ресурсы Kubernetes, и цель проекта — уменьшить зависимость от проприетарных баз данных в облаке и упростить DBaaS-опыт
К сожалению, в моей среде обитания кубера нет, поэтому мне тяжело рассуждать насколько этот проект будет полезен современным DevOps специалистам. Это прекрасная тема для разработки НИР 😏
Помню с 2020-2023 на кафедре было много тем про Кубнетес. Каждый третий студент искал возможности его "улучшить". Думаю пришла пора вернуть подобные темы в список для защиты 😈
InfoQ
OpenEverest: Open Source Platform for Database Automation
Percona recently announced OpenEverest, an open-source platform for automated database provisioning and management that supports multiple database technologies. Launched initially as Percona Everest, OpenEverest can be hosted on any Kubernetes infrastructure…
❤1🔥1
📚 Разница между шардингом и секционированием
Опять, клик-бейтное же название статьи, согласитесь? Очень интересно было бы прочесть. Открываю, листаю и на лице... 😐
Хочется почитать про какие-то откровения что ли. А тут, ИИ бы написал интереснее 🤖.
Как пример:
На практике я не видел одновременное использование секционирования и шардирования. Возможно у меня малая насмотренность 👀. Буду повышать уровень 📈
Опять, клик-бейтное же название статьи, согласитесь? Очень интересно было бы прочесть. Открываю, листаю и на лице... 😐
Хочется почитать про какие-то откровения что ли. А тут, ИИ бы написал интереснее 🤖.
Как пример:
Секционирование (partitioning) — это когда у тебя одна база, но ты аккуратно разложил данные по ящикам. Быстрее искать, проще убирать старьё, меньше бардака. Всё по-прежнему живёт на одном сервере, транзакции и JOIN работают как раньше, просто база начинает «дышать свободнее», т.к. при выполнении запросов не надо проверять все ящики.
Шардинг (sharding) — это когда одного шкафа уже мало, и ты начинаешь расставлять ящики по разным комнатам. Даёт настоящее горизонтальное масштабирование и спасает при высоких нагрузках, но появляется новая боль: маршрутизация, кросс-шардовые запросы и вечный вопрос «а куда теперь переехали эти данные?».
Итого: секционирование — это уборка и организация, шардинг — переезд на новую квартиру. Обычно сначала наводят порядок, и только потом начинают "ломать стены".
На практике я не видел одновременное использование секционирования и шардирования. Возможно у меня малая насмотренность 👀. Буду повышать уровень 📈
Астрологи обьявили неделю Redis на этом канале
Почему Redis, а не Valkey, ведь это drop-in клон? Valkey мы очень любим, но кое-чего в Valkey нет. Верятностные структуры — про это мы начинаем серию образовательных постов. Автор серии - Константин Ратвин (МФТИ).
Часть #1. Введение в вероятностные структуры Redis
По мере развития проекта растет не только нагрузка, но и функциональность: появляются рекомендации, промо-механики, антифрод и новые требования к наблюдаемости. Вместе с этим увеличивается поток событий и измерений: значительную его часть начинают занимать клики, оформления заказов, метрики задержек.
И разработчикам, и аналитикам все чаще становятся нужны ответы «прямо сейчас»:
🤩 сколько было уникальных посетителей сегодня?
🤩 что стало трендом за последние минуты?
🤩 не пришло ли событие повторно?
🤩 какой p95/p99 у времени ответа или у времени оформления заказа?
Ответить на эти вопросы, не перегружая систему, позволяет класс техник, который называют вероятностными структурами данных. Они дают быстрый отклик и требуют мало памяти, но допускают небольшую и заранее предсказуемую погрешность.
В больших системах такие расчеты часто выносят в отдельный контур обработки, и это может сильно снижать оперативность как получения данных, так и внесения изменений. Однако Redis позволяет избежать этого усложнения, предлагая решение подобных задач прямо "из коробки”.
Так появились вероятностные структуры (их еще называют sketch-структурами) появились как ответ на практическую проблему: потоки данных растут быстрее, чем бюджет на память и хранение. Решение в том, чтобы хранить не исходные элементы, а их компактное представление, под которым обычно понимают:
🤩 Хеш-отпечатки и битовые/регистровые массивы
Элементы превращаются в несколько хеш-значений и «отмечаются» в битовой матрице/регистрах.
Пример: Bloom filter отмечает позиции битов, HyperLogLog обновляет регистры по «разрядам» хеша.
🤩 Сжатую статистику вместо сырого потока
Хранится не каждое значение, а агрегированное статистическое представление.
Пример: t-digest сохраняет сжатое приближение распределения, чтобы быстро отвечать на запросы вида p95/p99.
Вопросы, на которые способны ответить вероятностные структуры:
🤩 Сколько уникальных? → HyperLogLog
🤩 Видели ли мы это? → Bloom / Cuckoo
🤩 Что в топе? → Top-K
🤩 Сколько раз встречалось? → Count-Min Sketch
🤩 Какие p95/p99? → t-digest
5 разных структур данных - и все доступны в Redis из коробки. В следующих постах разберём каждый из них подробнее.
А всем, кому интересно изучить Redis на практике с автором этого поста, приходите на курс Devhands: Redis и Valkey, от основ к хайлоаду. Старт 10 марта, 6 недель: все необходимые структуры данных, масштабирование c Sentinel, кластерные возможности и многое другое.
🔥 уже используем возможности Redis для observability/аналитики
👍 спасибо, подучил
Почему Redis, а не Valkey, ведь это drop-in клон? Valkey мы очень любим, но кое-чего в Valkey нет. Верятностные структуры — про это мы начинаем серию образовательных постов. Автор серии - Константин Ратвин (МФТИ).
Часть #1. Введение в вероятностные структуры Redis
По мере развития проекта растет не только нагрузка, но и функциональность: появляются рекомендации, промо-механики, антифрод и новые требования к наблюдаемости. Вместе с этим увеличивается поток событий и измерений: значительную его часть начинают занимать клики, оформления заказов, метрики задержек.
И разработчикам, и аналитикам все чаще становятся нужны ответы «прямо сейчас»:
Ответить на эти вопросы, не перегружая систему, позволяет класс техник, который называют вероятностными структурами данных. Они дают быстрый отклик и требуют мало памяти, но допускают небольшую и заранее предсказуемую погрешность.
В больших системах такие расчеты часто выносят в отдельный контур обработки, и это может сильно снижать оперативность как получения данных, так и внесения изменений. Однако Redis позволяет избежать этого усложнения, предлагая решение подобных задач прямо "из коробки”.
Так появились вероятностные структуры (их еще называют sketch-структурами) появились как ответ на практическую проблему: потоки данных растут быстрее, чем бюджет на память и хранение. Решение в том, чтобы хранить не исходные элементы, а их компактное представление, под которым обычно понимают:
Элементы превращаются в несколько хеш-значений и «отмечаются» в битовой матрице/регистрах.
Пример: Bloom filter отмечает позиции битов, HyperLogLog обновляет регистры по «разрядам» хеша.
Хранится не каждое значение, а агрегированное статистическое представление.
Пример: t-digest сохраняет сжатое приближение распределения, чтобы быстро отвечать на запросы вида p95/p99.
Вопросы, на которые способны ответить вероятностные структуры:
5 разных структур данных - и все доступны в Redis из коробки. В следующих постах разберём каждый из них подробнее.
А всем, кому интересно изучить Redis на практике с автором этого поста, приходите на курс Devhands: Redis и Valkey, от основ к хайлоаду. Старт 10 марта, 6 недель: все необходимые структуры данных, масштабирование c Sentinel, кластерные возможности и многое другое.
🔥 уже используем возможности Redis для observability/аналитики
👍 спасибо, подучил
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4👀3
Украл текст из "соседней беседки". Автор мне разрешил 🤝
Делюсь с вами! 🖐 🍧
Делюсь с вами! 🖐 🍧
Эволюция PostgreSQL: 1986–2025
От исследовательской базы данных до корпоративной и готовой к ИИ платформе
Путь PostgreSQL — одна из самых выдающихся историй успеха в истории баз данных.
Изначально разработанная Майклом Стоунбрейкером в рамках проекта POSTGRES в 1986 году, она развилась из более ранней системы баз данных Ingres в Калифорнийском университете в Беркли. То, что начиналось как академическая исследовательская инициатива, превратилось в одну из самых мощных, расширяемых и готовых для корпоративных открытых баз данных в мире.
Вот краткий обзор его основных этапов:
1986 — Начало проекта POSTGRES (UC Berkeley)
1994 – POSTGRES95 – добавлена поддержка SQL
1996 – версия 6.0 – Переименована в PostgreSQL и Глобальная группа разработки PostgreSQL (PGDG)
2000 – версия 7.0 – улучшения MVCC и WAL
2005 – версия 8.0 – поддержка Windows, PITR, Tablespaces
2008 – версия 8.3 – Полнотекстовый поиск, интегрированный в ядро
2010 – версия 9.0 – Потоковое воспроизведение
2011 – версия 9.1 – Синхронная репликация
2013 – версия 9.3 – Материализированные просмотры, JSON
2016 – версия 9.6 – Параллельный запрос
2017 – версия 10 – Логическая репликация, декларативное разбиение
2018 – версия 11 – Улучшенное разбиение и параллелизм
2019 – версия 12 – Сгенерированные столбцы, РЕИНДЕКС ОДНОВРЕМЕННО
2020 – версия 13 – дедупликация B-дерева, прирост производительности VACUUM
2021 – версия 14 – Параллелизм и улучшения индексации
2022 – версия 15 – команда MERGE, улучшения логической репликации
2023 – версия 16 – Улучшения производительности, мониторинг, логическое декодирование в режиме ожидания
2024 – версия 17 – Высокая доступность, производительность и улучшения VACUUM
2025 – версия 18 – Улучшенная логическая репликация, зрелость экосистемы векторного поиска, ИИ и корпоративный фокус
От академических исследований до поддержки финансовых систем, SaaS-платформ, правительств и рабочих нагрузок, управляемых искусственным интеллектом — PostgreSQL продолжает доказать, почему его часто называют:
«Самая продвинутая в мире реляционная база данных с открытым исходным кодом.»
Как DBA и разработчики, мы стали свидетелями того, как PostgreSQL стал полнофункциональной альтернативой настоящей корпоративной, облачной и поддержкой искусственного интеллекта платформы.
Эволюция продолжается.
❤4
📚 Сообщество MySQL призывает к обсуждению будущего экосистемы
Если кратко, то сообщество MySQL обзавидоволось PostgeSQL 🥲 и хочется так же бурно развиваться как последние. Но... Oracle вставляет палки в колеса и не дает расти🤬. Товарищи предложили создать независимый некоммерческий фонд развития MySQL и передать этому фонду все права на MySQL. Это даст возможность забустить 100500 доработок в проект и потеснить PostgreSQL на пьедестале самого динамично развивающейся OSS СУБД 🥋.
Срок ответа 31 марта. Осталось недолго ждать финальной развязки ✌️.
Если кратко, то сообщество MySQL обзавидоволось PostgeSQL 🥲 и хочется так же бурно развиваться как последние. Но... Oracle вставляет палки в колеса и не дает расти🤬. Товарищи предложили создать независимый некоммерческий фонд развития MySQL и передать этому фонду все права на MySQL. Это даст возможность забустить 100500 доработок в проект и потеснить PostgreSQL на пьедестале самого динамично развивающейся OSS СУБД 🥋.
Срок ответа 31 марта. Осталось недолго ждать финальной развязки ✌️.
BetaNews
MySQL community calls for discussions on the future of the ecosystem
Earlier this month Oracle put out a blog post on how it plans to expand the community edition of MySQL. In response the MySQL community has now published an
😱3
Forwarded from Архитектор Данных
Data Engineer не нужен
А вот правда. Он не приносит видимого результата, единственная его ценность в том что 10 аналитикам комфортнее, если у них есть 1 инженер.
И если раньше это соотношение было 3-5 к 1, то уже сейчас стремится к 10 аналитиков на одного инженера данных.
Появление фреймворков вроде dbt, sql mesh и такого скила как analytics engineer этому способствует. Следующий шаг - распространение класса решений для быстрой GUI-AI наладке ETL и модели данных.
И если до Low-Code пока что далековато, то Low-DE аналитика уже вполне реальность.
А вот правда. Он не приносит видимого результата, единственная его ценность в том что 10 аналитикам комфортнее, если у них есть 1 инженер.
И если раньше это соотношение было 3-5 к 1, то уже сейчас стремится к 10 аналитиков на одного инженера данных.
Появление фреймворков вроде dbt, sql mesh и такого скила как analytics engineer этому способствует. Следующий шаг - распространение класса решений для быстрой GUI-AI наладке ETL и модели данных.
И если до Low-Code пока что далековато, то Low-DE аналитика уже вполне реальность.
Я очень жду профессию из разряда ИИ-психолог. Человек, который на "серьезных щах" будет копаться в обученных моделях и корректировать их поведение. А может такие специалисты уже есть?
С пятницей!
#mems
С пятницей!
#mems
😁8❤1
Наткнулся на статью по проектированию реляционных баз данных, а затем на его видеоролик на ютубе 🎦 .
Весь курс по сути пересказ книги: "Grokking Relational Database Design".
Удовольствие на 6 часов🥱. Нууу, дай думаю всё-таки посмотрю и послушаю 👂. Вдруг что-то интересное скажут. Интересно, чему учат иностранцы других иностранцев 🤺.
В целом, материал хороший, но всё это уже было рассказано 100500 раз. Никаких откровений или нового взгляда. Почему-то автор даже JSON игнорирует в своем курсе 🤔.
Получается, что с одно стороны - это хороший базовый, вводный учебник по проектированию. А с другой, он оторвал от современных реалий 🤯.
Я бы в книгах/курсах по проектированию хотел бы видеть такие темы:
Тогда бы курс выглядел более практичным и полезным .
А как вы думайте❔
Весь курс по сути пересказ книги: "Grokking Relational Database Design".
Удовольствие на 6 часов🥱. Нууу, дай думаю всё-таки посмотрю и послушаю 👂. Вдруг что-то интересное скажут. Интересно, чему учат иностранцы других иностранцев 🤺.
В целом, материал хороший, но всё это уже было рассказано 100500 раз. Никаких откровений или нового взгляда. Почему-то автор даже JSON игнорирует в своем курсе 🤔.
Получается, что с одно стороны - это хороший базовый, вводный учебник по проектированию. А с другой, он оторвал от современных реалий 🤯.
Я бы в книгах/курсах по проектированию хотел бы видеть такие темы:
1. Партиционирование, шардинг
2. Влияние репликаций на модель данных
3. Правила эволюции схемы данных
4. Полуструктурные данные (JSON/XML), гибридное моделирование "в реляционное" vs "в документ".
5. Хотя бы кратенько про моделирование схем для OLAP нагрузок(dimensional modeling: star/snowflake, SCD, витрины/слои)
6. Практики по безопасности/комплаенса на уровне схемы: (row-level security аудит, политики хранения/удаления)
7. Правила проектирования распределенных схем данных
Тогда бы курс выглядел более практичным и полезным .
А как вы думайте❔
freeCodeCamp.org
Learn Relational Database Design
Relational databases are used in many different types of software. We just posted a course on the freeCodeCamp.org YouTube channel that will help you learn relational database design from the ground up. This course covers SQL fundamentals, entity-rel...
❤1👍1
🚶♂️➡️В продолжении темы проектирования схем баз данных.
Недавно была статья на Хабре
25 железных правил проектирования баз данных в PostgreSQL
Она собрала более 95+ лайков и свыше 190 комментов.
На мой взгляд - это успех автора 😎! Если учесть, что это "из песочницы", то еще больший успех 🎰!
Однако, во всех чатах, где я состою, статью откровенно "зас***и" 💩.
Комментарии довольно жесткие 👊.
Примечательно, что опровержения или развернутого комментария "почему какое-то правило не работает" никто не дал 🫤. Ответ на претензию "почему" ответ такой:
Очередной раз ловлю себя на мысли, что надо написать статью или серию статей по проектированию схем данных для современных систем 📝. Причем видимо надо вводить какую-то классификацию этих систем и набор правил под каждую.
Повод посидеть, подумать на тему кому бы делегировать эту задачу? 😎
Есть желающие? 😉
Недавно была статья на Хабре
25 железных правил проектирования баз данных в PostgreSQL
Она собрала более 95+ лайков и свыше 190 комментов.
На мой взгляд - это успех автора 😎! Если учесть, что это "из песочницы", то еще больший успех 🎰!
Однако, во всех чатах, где я состою, статью откровенно "зас***и" 💩.
Написал сплошной бред, который почти никогда не бьется с продакшн системами. Все эти правила валидны для "школьной скамьи" и т.п.
Комментарии довольно жесткие 👊.
Примечательно, что опровержения или развернутого комментария "почему какое-то правило не работает" никто не дал 🫤. Ответ на претензию "почему" ответ такой:
"лень писать", "эти знания за которые люди платят деньги на мастер-классах/воркшопах".Получается забавная проблема 🙁. "Кривая" и откровенно ложная статья набирает огромную популярность у сообщества, а потом мы на проде ловим такое 🔥... от чего челюсть не может встать на место несколько часов 😱.
Очередной раз ловлю себя на мысли, что надо написать статью или серию статей по проектированию схем данных для современных систем 📝. Причем видимо надо вводить какую-то классификацию этих систем и набор правил под каждую.
Повод посидеть, подумать на тему кому бы делегировать эту задачу? 😎
Есть желающие? 😉
❤4
📚Хочу поделиться образовательным сайтом от коллеги, Александра Поломодова.
Довольно интересная история создания этого сайта 😊
Если не вдаваться в подробности, то это электронная вариация его потенциальной книги, которую он прогнал через сервис lovable и в итоге получился сайт.
Для меня и для вас самым интересным и полезным должен стать раздел 8 Базы Данных.
🚧 p.s. всё информация о базах данных там должна подвергаться сомнению!🫤 Автор книги "Путеводитель по базам данных" в комментариях к посту уже изложил своё мнение.
Довольно интересная история создания этого сайта 😊
Если не вдаваться в подробности, то это электронная вариация его потенциальной книги, которую он прогнал через сервис lovable и в итоге получился сайт.
Для меня и для вас самым интересным и полезным должен стать раздел 8 Базы Данных.
🚧 p.s. всё информация о базах данных там должна подвергаться сомнению!🫤 Автор книги "Путеводитель по базам данных" в комментариях к посту уже изложил своё мнение.
System Design Space
System Design Space — Главная, граф знаний, треки и материалы
Главная страница System Design Space: быстрый старт, граф знаний, библиотека материалов, персональные треки и трекинг прогресса.
🔥8❤1
Я часто вижу непонимание в глазах слушателей, когда речь заходит о терминах «структура», «полуструктура» и «неструктурированные данные». Поэтому решил написать короткий пост
Представьте: База данных - это огромный ресторан, а мы - повара, которым нужно быстро находить ингредиенты.
🍏 Структурированные данные — «идеальный холодильник»
Всё разложено по полкам и контейнерам, у каждого продукта своя ячейка и подпись. Нужно "все огурцы за вчера" - открыли нужную полку (таблицу) и мгновенно нашли.
🤔 SQL (PostgreSQL, MySQL и т.д.)
➕ быстрый поиск, строгая логика
➖ менять схему больнее, т.к. нужно перестраивать полки
🍕 Полуструктурированные данные — «коробка с заказом»
Вы заказали пиццу. В коробке лежит сама пицца, пакетик с соусом, перец, салфетки и рекламка. Есть общая логика и ярлыки, но набор и форма могут меняться. Сегодня есть оливки - завтра нет.
Это как JSON/XML, ключи есть, но структура может быть какой угодно.
🤔 NoSQL, JSON/XML/YAML
➕ легко добавлять новые поля
➖ без дисциплины начинается хаос 🪬
📦 Неструктурированные данные — «склад с коробками без подписей»
Это когда на складе ресторана стоит гора коробок и пакетов без нормальных наклеек и сортировки. Внутри может быть что угодно: мешок специй, куча чеков от поставщиков, распечатки меню, записки от шефа, фото блюда, инструкции к оборудованию. Хранилище знает только внешнее (размер/дата), а смысл приходится "доставать" отдельно (поиск, разметка, ML/LLM).
🤔 Data Lakes, облачные хранилища, векторные БД
➕ можно хранить всё
➖ чтобы найти смысл, нужно отдельно индексировать/анализировать
Архитектурные "премудрости" 🧙♂️:
Структура - это дорого строить, но дешево искать.
Неструктура - дешево хранить, но дорого понимать 😏.
Представьте: База данных - это огромный ресторан, а мы - повара, которым нужно быстро находить ингредиенты.
🍏 Структурированные данные — «идеальный холодильник»
Всё разложено по полкам и контейнерам, у каждого продукта своя ячейка и подпись. Нужно "все огурцы за вчера" - открыли нужную полку (таблицу) и мгновенно нашли.
🤔 SQL (PostgreSQL, MySQL и т.д.)
➕ быстрый поиск, строгая логика
➖ менять схему больнее, т.к. нужно перестраивать полки
🍕 Полуструктурированные данные — «коробка с заказом»
Вы заказали пиццу. В коробке лежит сама пицца, пакетик с соусом, перец, салфетки и рекламка. Есть общая логика и ярлыки, но набор и форма могут меняться. Сегодня есть оливки - завтра нет.
Это как JSON/XML, ключи есть, но структура может быть какой угодно.
🤔 NoSQL, JSON/XML/YAML
➕ легко добавлять новые поля
➖ без дисциплины начинается хаос 🪬
📦 Неструктурированные данные — «склад с коробками без подписей»
Это когда на складе ресторана стоит гора коробок и пакетов без нормальных наклеек и сортировки. Внутри может быть что угодно: мешок специй, куча чеков от поставщиков, распечатки меню, записки от шефа, фото блюда, инструкции к оборудованию. Хранилище знает только внешнее (размер/дата), а смысл приходится "доставать" отдельно (поиск, разметка, ML/LLM).
🤔 Data Lakes, облачные хранилища, векторные БД
➕ можно хранить всё
➖ чтобы найти смысл, нужно отдельно индексировать/анализировать
Архитектурные "премудрости" 🧙♂️:
Структура - это дорого строить, но дешево искать.
Неструктура - дешево хранить, но дорого понимать 😏.
🔥12❤7🍾3
Видео вчерашнего стрима с Никитой Кречетовым, Avito:
https://www.youtube.com/watch?v=bJnDkDAoOUw
Некоторое «мясо» по темам интервью (в видео на самом деле ещё больше инсайтов).
Масштаб: ~2700 хранилищ Redis, среди них сотни шардированных инсталляций. Это “внутреннее облако”: продуктовые команды не думают про жизненный цикл БД (создание, окружения, секреты, аккаунты, доступы) — это делает платформенная команда.
Почему исторически не Redis Cluster. Присматривались к Redis Cluster пробовали с Redis 5 → 7, но считали технологию незрелой для больших масштабов, требовалось перепилить компоненты платформы, клиентские библиотеки созрели не сразу.
Выбор Valkey vs KeyDB vs Dragonfly
• Лицензию Redis “закрыли” в марте 2024.
• Valkey: первый стабильный релиз — апрель 2024; форк Redis, бинарно близкий, но вначале было неясно, “взлетит ли” комьюнити.
• Dragonfly не тестировали: не подошла лицензия.
• KeyDB рассматривали всерьёз (развивался с 2019, поддержка/участие Snapchat), интересен master-master / active replication (идея распределять write-нагрузку без шардирования данных) + честная “многопоточность” через несколько event loop (условно “несколько Redis в потоках”), давала выигрыш на 3–4 потоках.
• Но в процессе выяснилось, что KeyDB фактически не поддерживается/не развивается, и примерно в 2025 приняли окончательное решение перейти на Valkey.
Производительность: конкретные цифры
• Оптимальная конфигурация по тестам: 3–4 потока.
• На тестах Valkey 8.x давал: до +50% к максимальному RPS/пропускной способности относительно Redis 7.2.8 (при одинаковом CPU-лимите, “CPU под завязку”), относительно KeyDB — ещё несколько процентов выигрыша.
• Узкое место часто было не CPU, а количество соединений и “пиковые” коннекты: Valkey 8.x держал их более линейно и предсказуемо (за счёт переработки многопоточности).
“Неожиданность” с обновлением версий
• Тестировали на 8.0.2 (стабильно, хороший выигрыш).
• Попробовали обновить часть кластеров на 8.1.0: на синтетике “норм”, но на реальных данных хуже latency (в среднем до ~1.5×), быстро откатились обратно на 8.0.2.
• Реальные паттерны нагрузки сложно воспроизвести на стенде, часть проблем проявляется только в проде.
Почему поверх Cluster построили ещё один “кластер” (sidecar + Raft)
Valkey/Redis Cluster “умный”, но для платформы не хватает критичных функций:
• Авто-учётки/доступы, интеграции с безопасностью.
• Автоматический решардинг при изменении топологии (добавление/удаление узлов).
• Умная поддержка зон доступности (AZ): важно равномерно держать master-ноды по зонам, кластер не умеет “умный фейловер” с учётом AZ.
🔥 спасибо за интересный платформенный кейс
👍 из полей доноситсяналей valkey!
—
Обучение Devhands Redis/Valkey: https://devhands.io/rv
Канал Алексея Рыбака: https://t.me/rybakalexey
Канал Avito Tech: https://t.me/avitotech
Канал Avito Data Tech: https://t.me/avitotech
https://www.youtube.com/watch?v=bJnDkDAoOUw
Некоторое «мясо» по темам интервью (в видео на самом деле ещё больше инсайтов).
Масштаб: ~2700 хранилищ Redis, среди них сотни шардированных инсталляций. Это “внутреннее облако”: продуктовые команды не думают про жизненный цикл БД (создание, окружения, секреты, аккаунты, доступы) — это делает платформенная команда.
Почему исторически не Redis Cluster. Присматривались к Redis Cluster пробовали с Redis 5 → 7, но считали технологию незрелой для больших масштабов, требовалось перепилить компоненты платформы, клиентские библиотеки созрели не сразу.
Выбор Valkey vs KeyDB vs Dragonfly
• Лицензию Redis “закрыли” в марте 2024.
• Valkey: первый стабильный релиз — апрель 2024; форк Redis, бинарно близкий, но вначале было неясно, “взлетит ли” комьюнити.
• Dragonfly не тестировали: не подошла лицензия.
• KeyDB рассматривали всерьёз (развивался с 2019, поддержка/участие Snapchat), интересен master-master / active replication (идея распределять write-нагрузку без шардирования данных) + честная “многопоточность” через несколько event loop (условно “несколько Redis в потоках”), давала выигрыш на 3–4 потоках.
• Но в процессе выяснилось, что KeyDB фактически не поддерживается/не развивается, и примерно в 2025 приняли окончательное решение перейти на Valkey.
Производительность: конкретные цифры
• Оптимальная конфигурация по тестам: 3–4 потока.
• На тестах Valkey 8.x давал: до +50% к максимальному RPS/пропускной способности относительно Redis 7.2.8 (при одинаковом CPU-лимите, “CPU под завязку”), относительно KeyDB — ещё несколько процентов выигрыша.
• Узкое место часто было не CPU, а количество соединений и “пиковые” коннекты: Valkey 8.x держал их более линейно и предсказуемо (за счёт переработки многопоточности).
“Неожиданность” с обновлением версий
• Тестировали на 8.0.2 (стабильно, хороший выигрыш).
• Попробовали обновить часть кластеров на 8.1.0: на синтетике “норм”, но на реальных данных хуже latency (в среднем до ~1.5×), быстро откатились обратно на 8.0.2.
• Реальные паттерны нагрузки сложно воспроизвести на стенде, часть проблем проявляется только в проде.
Почему поверх Cluster построили ещё один “кластер” (sidecar + Raft)
Valkey/Redis Cluster “умный”, но для платформы не хватает критичных функций:
• Авто-учётки/доступы, интеграции с безопасностью.
• Автоматический решардинг при изменении топологии (добавление/удаление узлов).
• Умная поддержка зон доступности (AZ): важно равномерно держать master-ноды по зонам, кластер не умеет “умный фейловер” с учётом AZ.
🔥 спасибо за интересный платформенный кейс
👍 из полей доносится
—
Обучение Devhands Redis/Valkey: https://devhands.io/rv
Канал Алексея Рыбака: https://t.me/rybakalexey
Канал Avito Tech: https://t.me/avitotech
Канал Avito Data Tech: https://t.me/avitotech
👍1🔥1
Книга: «Архитектуры данных: современные решения для любых задач»
Свежий перевод западной литературу Orelly от нашего издательства Питер.
Примечательно, что книгу рецензировали в клубе рецензентов ИТ-литературы ReadITClub.
Судя по сайту данный клуб принадлежи КРОКу и получает дополнительную поддержку от российских издательств технической литературы.
Здорово, что у нас существует подобный клуб 💪! Я до того, как открыл книгу ничего об этом не знал.
❇️ Коротко про книгу.
В ней 288 страниц — надеюсь, прочитаю быстро 😁
Состоит из 4-х частей:
Сегодня — Часть I, в ней 3 главы и 3 ключевые мысли:
1️⃣ Ценность важнее “объёмов”.
Big Data — это не “очень много данных”, а любые данные, которые дают эффект. Автор объясняет 6V: Volume, Variety, Velocity, Veracity, Variability и главное — Value. Остальные V важны ровно настолько, насколько помогают (или мешают) получить ценность.
2️⃣ Универсальной архитектуры нет.
Показывается “ландшафт” подходов: RDW → Data Lake → MDW → Fabric / Lakehouse / Mesh. Выбор зависит от нагрузок, типов данных, SLA, безопасности, доступности и того, как данные будут потребляться (в т.ч. self-service).
3️⃣ Выбор архитектуры — это процесс.
Предлагается ADS (architecture design session): собрать бизнес + ИТ и зафиксировать цели/ограничения (latency, объёмы, HA/DR, источники, ML и т.д.). По опыту: без практики и фасилитатора/ментора такую сессию легко "запороть". Было бы интересно на таких сессиях поприсутвовать...
❇️ Итоговая мысль
Сначала формулируем какую ценность хотим получить и фиксируем реальные требования/ограничения. Затем проводим дизайн-сессию со стейкхолдерами, чтобы осознанно выбрать архитектурный подход согласно задаче.
⚠️ Забавный исторический факт.
Data Lake появились в 2010-х годах. Самые яркие представители это Hadoop, Cloudera, Hortonworks и MapR. Однако, все эти решения (кроме Hadoop) провались в коммерческом плане. Причина банальная, неудобный и сложный инструментарий для извлечения данных (создание отчетов). Последним гвоздем стало то, что все любят SQL, транзакции и так нужный в корпоративной среде аудит.
В 2020-х случился "Ренессанс" с пришествием табличных форматов/транзакционными слоями вроде Delta Lake (и аналогов Iceberg/Hudi). Были добавлены transaction log, операции MERGE/UPDATE/DELETE, контроль схемы и версионирование (time travel). Таким образом, озеро стали гораздо ближе к требованиям BI и аналитики.
Очередное подтверждение того, что от SQL и реляционной теории нам не избавиться никогда 😈😈😈
Свежий перевод западной литературу Orelly от нашего издательства Питер.
Примечательно, что книгу рецензировали в клубе рецензентов ИТ-литературы ReadITClub.
Судя по сайту данный клуб принадлежи КРОКу и получает дополнительную поддержку от российских издательств технической литературы.
Здорово, что у нас существует подобный клуб 💪! Я до того, как открыл книгу ничего об этом не знал.
❇️ Коротко про книгу.
В ней 288 страниц — надеюсь, прочитаю быстро 😁
Состоит из 4-х частей:
Часть I. Основные понятия
Часть II. Общие понятия архитектуры данных
Часть III. Архитектуры данных
Часть IV. Люди, процессы и технологии
Сегодня — Часть I, в ней 3 главы и 3 ключевые мысли:
1️⃣ Ценность важнее “объёмов”.
Big Data — это не “очень много данных”, а любые данные, которые дают эффект. Автор объясняет 6V: Volume, Variety, Velocity, Veracity, Variability и главное — Value. Остальные V важны ровно настолько, насколько помогают (или мешают) получить ценность.
2️⃣ Универсальной архитектуры нет.
Показывается “ландшафт” подходов: RDW → Data Lake → MDW → Fabric / Lakehouse / Mesh. Выбор зависит от нагрузок, типов данных, SLA, безопасности, доступности и того, как данные будут потребляться (в т.ч. self-service).
3️⃣ Выбор архитектуры — это процесс.
Предлагается ADS (architecture design session): собрать бизнес + ИТ и зафиксировать цели/ограничения (latency, объёмы, HA/DR, источники, ML и т.д.). По опыту: без практики и фасилитатора/ментора такую сессию легко "запороть". Было бы интересно на таких сессиях поприсутвовать...
❇️ Итоговая мысль
Сначала формулируем какую ценность хотим получить и фиксируем реальные требования/ограничения. Затем проводим дизайн-сессию со стейкхолдерами, чтобы осознанно выбрать архитектурный подход согласно задаче.
⚠️ Забавный исторический факт.
Data Lake появились в 2010-х годах. Самые яркие представители это Hadoop, Cloudera, Hortonworks и MapR. Однако, все эти решения (кроме Hadoop) провались в коммерческом плане. Причина банальная, неудобный и сложный инструментарий для извлечения данных (создание отчетов). Последним гвоздем стало то, что все любят SQL, транзакции и так нужный в корпоративной среде аудит.
В 2020-х случился "Ренессанс" с пришествием табличных форматов/транзакционными слоями вроде Delta Lake (и аналогов Iceberg/Hudi). Были добавлены transaction log, операции MERGE/UPDATE/DELETE, контроль схемы и версионирование (time travel). Таким образом, озеро стали гораздо ближе к требованиям BI и аналитики.
Очередное подтверждение того, что от SQL и реляционной теории нам не избавиться никогда 😈😈😈
🔥4