Провокационная статья: Elasticsearch был великолепен, но за векторными базами данных будущее

Поисковые СУБД и векторные прекрасно справляются с задачами семантического поиска. Вопрос, какая лучше?

Так как статья написана Jiang Chen (руководителем платформы разработки ИИ в компании Zilliz (разработчик векторных СУБД), поэтому о безусловном доверии речи быть не может. Однако, это прекрасно тема для научной работы. Она может звучать так: "Сравнение поисковых и векторных СУБД в задачах семантического поиска".

Думаю студентам МФТИ вполне по силам раскрыть эту тему! 😈

Продолжение постов 1 и 2.

Книга "Путеводитель по базам данных". — М.: ДМК-Пресс, 2024. — 520 с. ISBN 978-5-93700-287-7

🚀 Часть 3. Архитектура СУБД 🚀

Благо часть не особо большая, но полезной части весьма много.


❇️Общее впечатление.
Всё начинается с рассказа о транзакциях. Вводится терминология ACID. Последнюю букву "D" автор раскрывает целым разделом о журналировании. Если начался разговор про транзакции, то и про блокировки нельзя забывать. Логическим завершением рассказа о транзакция является тема с версионированием данных и технологией MVCC. Очень здорово, что автор описывает разницу в реализациях MVCC в зависимости от СУБД.

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

Экземпляр (instance) — набор ресурсов операционной системы, выделенных
для работы с общими данными в памяти и на диске. Экземпляр состоит из процессов и области памяти, общей для всех процессов.

База данных (database) — это набор логически связанной информации, хранимой в электронном виде. В подавляющем большинстве случаев это означает набор файлов, однако иногда это могут быть данные на «сырых» устройствах или
набор произвольных объектов в объектном хранилище S3.

Разница:

Один экземпляр может обслуживать несколько баз данных, и наоборот —
несколько экземпляров могут обслуживать одну и ту же базу

Темы ACID и MVCC очень интересные, важные и даже необходимые для понимания работы СУБД. Транзакции есть в подавляющем числе СУБД. В каждой из них разработчики реализовывают их по своему вкусу. Если есть желание поглубже копнуть, то можно начать со списка литературы, который приведен к каждой главе. Затем почитать книжки по конкретной СУБД и для со всем хардкорщиков есть официальная документация! 😜

Продолжение постов 1, 2 и 3.

Книга "Путеводитель по базам данных". — М.: ДМК-Пресс, 2024. — 520 с. ISBN 978-5-93700-287-7

🚀 Часть 4. Распределённые базы данных 🚀

❇️Общее впечатление.
Традиционно всё начинается с изучения CAP-теоремы и PACELC (читается как "pass-elk", "пропусти-лося" 🫎 ). Если кто-то подзабыл, что это такое, что обязательно освежите в памяти. Затем автор согласно классификации разбирает каждый отдельный класс распределенных систем. Отдельно хочу выделить подробный обзор класса CA-систем. Прочие авторы незаслужено пропускают объяснение этого класса, а тут выделено целых 10 страниц! Обязательно включу эту информацию в свой курс!

Если пошла тема про распределенные системы, то обязательно надо рассказать про протоколы консенсуса.

Paxos. Multi-Paxos. Raft. Zookeper Atomic Broadcast.

Затем автор переходит к небольшому (на мой взгляд) обзору распределенных транзакций. Вводится понятия согласованности, кворума и версионирования. В заключение этой части автор приводит список систем, где разработаны свои уникальные механизмы функционирования на основе разобранных подходов.

Начав читать главу "Изменение данных в распределённых системах" меня посетила мысль, что полезной информации тут так много, а выделенного академического времени так мало 🥲. Надо обязательно написать факультатив на будущий год "Распределенные СУБД" 🫨. Целую дисциплину посвятить распределенным СУБД 😵‍💫. Сделать теоретический обзор, рассказать об области применения и разработать классный практикум по созданию кластеров и генерации соответствующей нагрузки. Сейчас я уделяю слишком мало времени этому направлению. Хотя в этом учебному году во втором семестре мой курс будет с упором на распределенные СУБД. Я и мои коллеги расскажем про СУБД Pangolin, СУБД Shardman, СУБД YDB 🧨🚀. Думаю это станет прекрасной основой для выделения этих знаний в новую дисциплину для тех кто желает еще глубже погрузится в мир распределенных систем. 💪

Приём зачетов/экзаменов для кого-то та еще пытка...

С пятницей!

#mems

Продолжение постов 1, 2, 3 и 4.

Книга "Путеводитель по базам данных". — М.: ДМК-Пресс, 2024. — 520 с. ISBN 978-5-93700-287-7

🚀 Часть 5. Восстановление при сбоях 🚀

❇️Общее впечатление.
Пора объемных глав прошла и осталось совсем чуть-чуть 😊

Тема крайне болезненная для всех инженеров поддержки и администраторов баз данных. Разработчики могут смело скипать этот раздел 😉

На всего 30 страницах автор рассказал все виды репликаций, которые существуют в мире СУБД. Блочная, физическая, логическая и прочие модификации. В качестве основных знаний это более чем достаточно. Конечно, мир репликаций гораздо разнообразнее. Есть двунаправленная репликация, есть так всеми любимый "мастер-мастер" репликации. Но это уже более сложные понятия. Если кто-то хочет погрузиться в эту тему, то есть неплохой доклад с PGConf.2023. Из книжек я нашел только такую Database Replication A Complete Guide.

После погружения в репликацию данных пора позаботиться и о резервном копировании. Благо тут особо ничего нового не изобрели. Есть стандартные 3 вида резервного копирования:
👉 Full backup (Полный бэкап)
👉 Differential backups (Дифференцированный бэкап)
👉 Incremental backup (Инкрементальный бэкап)

Из интересного хотел бы отметить стратегию "вечного инкремента". DBA один раз сделал полную копию базы, а затем выполняет только инкрементальные бэкапы. Если честно, я такое никогда не встречал. Но идея забавная.

Про холодное и горячее копирование данных особо и говорить нечего. Я признаться честно не любил запариваться с функцией бэкапа. Просто выключал экземпляр и копировал всю базу целиков на отдельный диск. Мне казалось это самое простое и быстрое решение. В компании меня за этого никто не бил 💪🥴 Всё норм 🤓

📚 Database Trends and Applications Magazine: October/November 2024 Issue

Традиционно пропускаю статьи про ИИ 🤖

➡️ RECOGNIZING THE POWER OF GRAPH DATABASES AND KNOWLEDGE GRAPHS By Joe McKendrick

Пройдусь по интересным фактам:

👉 По оценкам Adroit Research, объем глобального рынка баз данных graph в 2022 году составил 2,12 миллиарда долларов и, как ожидается, вырастет до 10,3 миллиарда долларов в 2032 году

👉 Графовые БД позволяют выполнять семантический
поиск, участвуют в работе рекомендательных систем.

👉 Графовые БД превосходно справляются с иерархическими и взаимосвязанными данными — социальными сетями, цепочками поставок,
приложениями для совместного использования поездок - особенно там, где взаимосвязи являются ключевой частью системы.

👉 Графики знаний “включают
семантику и контекст, что делает их
незаменимыми для искусственного интеллекта и LLM

👉 Графовые БД прекрасно себе показывают в задачах определение личности пользователя и обнаружение мошенничества.

👉 Графическая модель данных и
языки запросов, такие как Gremlin или Cypher, более выразительны, наглядны и интуитивно
понятны, чем стандартные реляционные таблицы и
SQL

👉 Понимание контекста и взаимосвязей важно для получения точных ответов

👉 Одной из проблем графовых БД - это наличие "суперузла". Когда один узел в
графе связан со многими другими узлами. Например,
пользователь с миллионами подписчиков
в социальной сети или популярный
продукт в каталоге. Запрос к суперузлу
или его соседним узлам может быть ресурсоемким
и приводить к проблемам масштабируемости, поскольку
база данных должна обрабатывать большое количество данных.

👉 РСУБД могут быть более
подходящими, особенно когда данные
менее взаимосвязаны или когда
согласованность транзакций имеет приоритет над изучением взаимосвязей между точками данных

👉Графовые БД + LLM = Graph RAG.

👉Новый тренд - Graph RAG. Технология улучшения качества ответов для ИИ.

В настоящее время 72% средств, выделяемых на ИТ, направляется на базовые техническое обслуживание вместо инноваций, согласно исследованию 2020 года.

➡️ Five Critical Qualities for DBAs

Статья из разряда: "Приколы нашего Городка" (с)

Какие же пять важнейших качеств ДБА ???? Мммм, интрига, интрига... А вот они:

1. Общительность (быть в команде)
2. Документирование своих знаний (ведение ВИКИ)
3. Автоматизация рутиных задачки
4. Распространять знания
5. Стрессоустойчивость

О, Хосподи!!! 🎉 Как я жил до этого без этих знаний!!! Автор открыл мне глаза!!! Спасибо! Низкий поклон!🧨

Если чуть серьезнее, то эти"важнейшие качества" подходят ЛЮБОЙ профессии. Как автору не стыдно такое писать, я не понимаю... 🙈

Поздравляю всех с Наступающим Новым Годом!

Желаю всем читателям в новом году большого счастья, крепкого здоровья, успешно защищенных НИР, любви, радости, красных дипломов, новый знаний и успеха во всех рабочих начинаниях!

А теперь, прыгаем под ёлку и открываем подарки!

p.s. можете написать в комментах как вы встречаете НГ...

Продолжение постов 1, 2, 3, 4 и 5.

Книга "Путеводитель по базам данных". — М.: ДМК-Пресс, 2024. — 520 с. ISBN 978-5-93700-287-7

🚀 Часть 6. Эксплуатация баз данных 🚀

❇️Общее впечатление.

Единственная часть книги с тремя главами 🙃!

Первая глава посвящена теме мониторинга СУБД. Рассказывается об основных параметрах БД за которыми нужно следить и т.п. Глава довольно интересная и даёт необходимое представление. Однако, как и тема с репликацией она крайне сложная при более серьезным погружении. Буквально недавно вышла книга "Мониторинг PostgreSQL" от Лесовского А. В. 2024 год. Целая книга рассказывающая о том, как правильно нужно следить на состоянием БД.

Во второй главе рассказывается про выбор оборудования на котором должна работать СУБД. Рассказывается и про сервера, системы хранения данных (СХД), NAS, SAN, RAID и прочие системы по хранению и передачи информации. Очень здорово, что автор рассказывает про такие вещи. Оборудование тесно связано с работой СУБД. Не просто так разработчики СУБД тесно работать с производителями оборудования для улучшения производительности БД. Даже есть целые программного-аппаратные комплексы (ПАК), которые объединяют в себе хорошо настроенное железо и специально оптимизированную СУБД по него. Пример, Скала-Р и Tantor.

Третья глава поднимает важный вопрос выбора СУБД для проекта. Какая СУБД нужна именно вам? Как это определить? Как проходит тендор на выбор вендора? На все эти вопросы в краткой форме отвечает это глава. По сути, все сводится к весовым коэфициентам. Выбор между качеством, стоимостью и временем внедрения. Конечно же количество этих коэффициентов меняется от проекта к проекту. Глава даёт понимание как проходит GAP-анализ во время тендера.

Продолжение постов 1, 2, 3, 4, 5 и 6.

Книга "Путеводитель по базам данных". — М.: ДМК-Пресс, 2024. — 520 с. ISBN 978-5-93700-287-7

🚀 Часть 7. Безопасность баз данных 🚀

❇️Общее впечатление.

Ролевая модель, полномочия, права доступа... Это с одной стороны довольно интересно, но очень часто инженерны и разработчики воспринимают это как вставку "палок в колеса". Инженеры поддержки и специалисты по внедрению очень часто сталкиваются с огромным числом барьеров во время развертывания новых сервисов в организации. Чтобы пройти все барьеры, уходит далеко не один день. Однако, приходиться с этим мириться.

Так плавно мы подходим к проблеме внутренних угроз безопасности. Составление модели угроз и принятия мер по метизации различных рисков. Самой большой дырой в безопасности всегда будет человек. Даже четкое выполнение инструкции может привести к росту возникновения инцидентов.

Приведу такой пример из жизни. Все мы сталкивались с сертификатами. Сертификат для пользователя или для сервиса (HTTPS).

Стандартное правило гласит, что все сертификаты выдаются ровно на 1 год и затем их нужно продлевать.

Я всю жизнь как думал, подходит срок, значит мне надо выполнить следующие шаги:
1. Сгенерить новую ключевую пару
2. Создать запрос на сертификат с указанием всех необходимых полей.
3.Получить от удостоверяющего центра (УЦ) новый сертификат.
4.Конец.

Вроде бы всё банально. Однако, некоторые специалисты исполняют всё дословно. В правиле есть слово "продлевать". Получается достаточно просто перевыпустить сертификат. Ключевую пару менять не надо! Тогда количество шагов сокращается.
1.Создаем новый запрос на сертификат (используя текущую ключевую пару)
2.Получаем от УЦ новый сертификат.
3.Конец.

В итоге, мы четко выполнили инструкцию, но почему-то чувства защищенности у меня не возникает.

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

Эххх...закончилась это чудесно путешествие. На сердце осталось много приятных впечатлений. Был бы у меня такой учебник в мои годы учебы...уххх, возможно карьера бы сложилась иначе. Если мир баз данных вам интересен и вы хотели бы узнать о нем побольше, то эта книга прекрасное начало великого пути!

Новогодние праздники подошли к концу... Да здравствуют новые начинания! 🍻

С пятницей

#mems

📻NoSQLFM

Один знакомый:
Я обсуждал как-то ИИ с руководителем оптимизатора в Teradata. Он сказал: "...тебе никто не скажет спасибо, если твоя новая версия оптимизатора принесет 10-20% ускорения. Но когда ты замедлишь их ключевые запросы - они будут звонить твоему CEO"

По общению с народом, у кого нагруженная аналитика на системах за большие 💰💰 - их очень парит стабильность и предсказуемость, и всякие умные фичи они сразу отключают. И некоторые помнят опыт LEO Optimizer от IBM.

По хорошему нужно провести соответствующее исследование для подтверждения или опровержения данных слов.

📚 Основы проектирования баз данных (Database Design Solutions, 2nd Edition)
Род Стивенс

Как и в прошлый раз буду разбирать книгу по частям.

🚀Часть 1. Введение в базы данных и их проектирование🚀 

👉 Глава 1. Цели проектирования баз данных
👉 Глава 2. Обзор реляционных баз данных
👉 Глава 3. Обзор NoSQL

Дочитав эту часть до конца у меня осталось послевкусие старых-старых книг из начала 2000-х. Может это из-за слога автора, не знаю. Примеров и информации из мира NoSQL достаточно (это 2009 год), но кажется, что автор далее 2011 года не заглядывал. Книга переводная и оригинал вышел 2023 году. Это не так уж давно.

Странно, что в книге NewSQL направление отведено всего 2 абзаца!😕 Про распределенные системы и говорить нечего. Даже хайповый тренд блокчейн СУБД в 2020-х годах тоже не упоминается. Как и во всех книжках про СУБД реляционной модели уделяется больше всего текста.

➕ Положительные моменты 📈
Теория - вещь важная и перечитывать её в очередной раз становится довольно скучно. Однако, автор часто проводит хорошие примеры из своей практики в качестве дополнения. Эти примеры довольно интересные и жизненные. Благодаря им я не терял интереса к дальнейшему чтению.

➖ Отрицательные моменты 📉
Меня немного разочаровала глава про NoSQL. Вроде отведено ей 35 страниц, но почему-то всё написано очень поверхностно. Мне не хватило информации. Почему-то кажется, что дальше в книге всё проектирование баз данных будут завязано на РСУБД. Надеюсь, я не прав.

Хочу добавить пару слов про упражнения после каждой главы. Они весьма интересные и позволяют повспоминать прочитанный материал. Считаю идею добавления упражнений и заданий в книгах очень хорошей идеей. Все упражнения являются открытыми вопросами. Слава богу в книге есть ответы с рассуждением 🙏 😉

Старый Новый Год прошёл, но мемы из прошлого актуальны как никогда!

С пятницей!

#mems

📚 Основы проектирования баз данных (Database Design Solutions, 2nd Edition)
Род Стивенс

Продолжение поста 1.

🚀Часть 2. Процесс и методы проектирования баз данных🚀

👉 Глава 4 - 10.

Если вы только постигаете основы СУБД и учитесь в ВУЗе (колледже), где преподают дисциплину "Базы данных", то это часть настоящий клондайк полезной информации. Если у вас возникают вопросы в понимании нормальных форм (НФ), в построении реляционных отношений, о том с чего вообще начинается проектирование и какой прикладной характер имеет, то вам очень повезло. Жаль в 2006 году не было такой книги на русском языке. Однако, есть некоторые НО...

Здорово, что автор так подробно и доходчиво преподносит информации, но ценности ей в 2024/25 году не много. Всё это уже известно и переписано в сотни других книг. Проектирование в NoSQL парадигме автор избегает по максимум. Даже те крупицы текста в основном говорят лишь о графовой модели (иерархической как частный случай), либо про существования JSON данных. Ничего конкретного и полезного. Я в очередной раз убеждаюсь, что это книга являются небольшим обновлением книги начала 2000-х. Самого-самого начала. Слишком старые и банальные принципы изложены. Даже "примеры из жизни" попахивают нафталином.

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

Но это не повод не читать дальше...вдруг книга раскроется. Как Starfield (c)

📚 Основы проектирования баз данных (Database Design Solutions, 2nd Edition)
Род Стивенс

Продолжение поста 1 и 2.

Не вижу смысла делить далее книгу по частям, т.к. основная информация уже прошла. Остались финальные штрихи.

🚀Часть 3. Подробный анализ конкретного примера🚀
👉 Глава 11 - 14.

По сути, просто рассказ о проекте с нотками юмора. Вроде интересно, но меня уже такие вещи не цепляют. Чем больше я читаю, тем больше понимаю, что такие вещи, как проектирование базы данных, выполняются целой командой! Учебные проекты можно в одно лицо запроектировать, но БД для проекта - это совсем другая история. Мне кажется лучше 1-2 раза поучаствовать в таком проекте, чем читать подобные истории. Реальность может оказаться совсем другой. Скорей всего даже проще, чем в книжках 😉

🚀Часть 5. Примеры программ🚀
👉 Глава 15 - 25.

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

🚀Часть 6. Темы для углубленного изучения🚀
👉 Глава 26 - 29.

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

❇️ По итогу
Плюсы
- Очень подробный гайд по проектированию баз данных. Для студентов настоящая бомба при выполнении лабораторных работ.
- Упражнения в конце каждой главы. Держит читателя в тонусе и проверяет полученные знаний. Здорово, что есть ответы.
- Современные примеры программ на популярных языках программирования по общению с СУБД
- Русский язык. Однозначный плюс
Минусы
- Лично у меня стойкий запах нафталина от книги. Вроде книга интересная, но почему-то окунает меня в прошлое 2006 года. Никаких новых откровений.
- Почти никак не освещено проектирование NoSQL баз данных. Лишь общие слова и не более.
- Мелкий текст в книге. Читать не удобно.

На очередном совещании:

Руководитель: Смотрю, задача наконец решена! Здорово! Как ты этого добился?

ГУРУ: Я просто всех за*бал!

ГУРУ: Вот, Коля приехал! Теперь я могу его за*бывать прямо через стол.

Руководитель: Понятно...

ГУРУ: Поэтому сотрудников поддержки никто не любит.

С пятницей!
#mems

📚 Статья: Итоги года от Энди Павло из CMU.

Традиционная статья от Энди Павло по всем значимым события (для него конечно) в мире СУБД за прошедший 2024 год.

❇️Моё мнение:
Как ни странно, но многие события о которых пишет Энди я никак в своем канале не освещал. Я писал про некоторые громкие новости по закрытию GreenPlum и переходу Redis на более строгую лицензию, но я и не думал, что изменений лицензий и в целом, перестройка некоторых opensource продуктов, настолько глобальна!
Базы данных - это большие деньги! Владельцы кода хотят ограничить круг компаний, которые обогащаются на их продукте ничего не давая взамен. Облачные провайдеры должны вкладываться в продукты, которые используют. Либо деньгами, либо интеллектуальным трудом помогая последнему развиваться. Наш рынок СУБД в РФ очень "молод" в этом плане. Поэтому "взрослые" решения принимаются крайне редко. Одна ситуация с разделением сообщества GreenPlum чего стоит.

Интересный раздел про инвестиции (и покупки) в компании, которые разрабатывают СУБД и экосистему к ней. Здорово было бы сделать подобный анализ по рынку РФ. Кто бы взялся... 🤔

В целом, отличная статья. Заставляет задуматься "о вечном"... точнее, сравнить, а что же происходило в РФ в 2024 году? Какие самые знаковые события? Если руки дойдут, то постараюсь написать своё мнение.

Выделю некоторые моменты из статьи:

👉 Elasticsearch вернулся в "лоно природы" и поменял лицензию на AGPL

👉 Я даже не знал, что существуют расширения для PostgreSQL, которые интегрируют поддержку DuckDB. Их оказываются уже 4 штуки вышло. Надо подтянуть свои знания.

👉 Позабавила идея сделать 30% скидку от облачных провайдеров для клиентов при переходе с Redis на Valkey.

👉 Интересно, что Энди хвалит DragonFly. Хотя за 2024 год об этой СУБД я почти ничего не слышал от российских разработчиков. У них есть и opensouce продукт и коммерческая версия. Почему-то в РФ все выбрали ValKey. Хмммм

👉 Список СУБД, которые родились в 2024 году.

👉 Лари Элисону исполнилось уже 80 лет! Как и за любым безумного богатым человеком СМИ следят 24/7/365. Знают, что он купил за 12 миллионов квотербек для Мичигана и то, что он женился в шестой раз!

🎥 Saint Highload++ 2024 и GolangConf 2024

Неожиданный подарок с небес 🧖 от компании Онтико! Они выложили в свой ютуб канал HighLoad++ видео с Санкт-Петербурской конференции 2024 года. Еще и с GolangConf видео за 2024 год. Щедрость невиданного размера 💸

В общем, всем советую посмотреть 👀 Подсвечу самые интересные доклады по теме "базы данных".

👉 Геораспределенные системы / Евгений Кузовлев (Т-Банк)
👉 Переосмысление Picodata как cluster-first-СУБД / Ярослав Дынников (Picodata)
👉 Redis — такой простой и такой сложный! / Андрей Комягин (STM Labs)
👉 Про UUID v.7 / Андрей Бородин (Yandex Cloud)
👉 Балансировка нагрузки шардированного PostgreSQL не своими руками / Денис Волков (Yandex Cloud)
👉 Как мы шли к 5000 RPS на запись / Ян Силов (Ozon)
👉 О распределённых транзакциях / Владимир Комаров (СберТех)
👉 Кластеризация с помощью etcd / Петр Растегаев (AGIMA)
👉 Как научить MongoDB делать горячие физические бэкапы / Юрий Фролов (Yandex Cloud)

📻 Многие знают, что последние несколько лет, я стал очень часто ходить в качестве слушателя на всяческие конференции, митапы, форумы, подкасты... За 2024 год я посетил более 30 мероприятий, а прослушал онлайн еще больше! Пора что-то менять 🪬

В этом году я наконец-то решил начать публично выступать на внешних конференциях 🤯 Думаю мне есть чем поделиться с сообществом!

❇️ 25 января прошла XVII международная научно-практическая конференция «ШАМОВСКИЕ ЧТЕНИЯ».
Выступал в секции 1: "Безопасная школа в условиях информатизации".
Тема: "Влияние кражи персональных данных на репутацию образовательной организации"

❗️Презентация

Выступление было онлайн в домашней обстановке. Это явно уменьшало уровень стресса, но сердечный ритм всё-таки ускорился 💓 мероприятия волнительное 🎊

✴️Немного о самом докладе
Утечки персональных и конфиденциальных данных в РФ происходит довольно часто. Причем из любых отраслей будь то финансовый сектор, телекоммуникации или игровая индустрия.

Если утечка замечена, то для компании-жертвы это всегда финансовый и репутационные потери 📉. Если про "деньги" всё более-менее понятно, то как это сказывается на репутации? 🤔

По факту, репутация - это мнение людей о компании. А мнение скалывается из нескольких составляющих, таких, как: СМИ, SMM и т.п.

В умных книгах выделяют 4 репутационных риска:
*️⃣ Негативное освещение в СМИ и социальных сетях
*️⃣ Утрата доверия клиентов
*️⃣ Проблемы с партнёрами и инвесторами
*️⃣ Потери на рынке труда

В итоге, утечка данных компании приводит к краткосрочным репутационным потерям.

Затем я сформулировал антитезис:
"Утечка данных в конечном счете может оказать положительное влияние на репутацию компании" 🤯💥

Казалось бы, ситуация парадоксальная! 😨 Но, давайте разберем возможные шаги по достижению этого:
1️⃣ Демонстрация ответственности
2️⃣ Улучшение стандартов безопасности
3️⃣ Привлечение внимания к продуктам или услугам
4️⃣ Быть примером для остальных! («голос разума»)

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

Конец! 🔚

p.s. сейчас пара докладов у меня на рассмотрении на других конференциях, которые всё-таки ближе к тематике СУБД. Как-то только их утвердят, то я обязательно сообщу!

Вангую... Проекты миграции на отечественное ПО будут актуальный и в этом году!

С пятницей!

#mems