Приколы версионирования продуктов!

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

🔥3 декабря закончилось двух дневное приключение по конференции HighLoad++ в Москве.

Уже скоро на Habr'е появится мнение коллег и журналистов о прошедшем событий. Пока поделюсь своими впечатлениями.

❇️ В очередной раз я заявляю, что это лучшая конференция в году для ИТ-специалистов в Москве🥇🏆! Все остальные мероприятия меркнут на общем фоне. Огромное количество людей! Спонсоры, спикеры и просто обычные посетители (готовые отвались 100к рублей за билет 💰). Более 13 треков с докладами на любой вкус!😋 Сумашествие по количеству информации. 🤯 Чтобы у народа не пухла голова присутствую десятки компаний со стендами и активностями на них. Можно отдохнуть и расслабиться по полной.

Я большой фанат различного мерча, но в этом году как-то скудненько вышло.🥺 Из крутого я выиграл огромного плюшевого питона, колонку SberBoomHome и всё на этом. Остальное мелочевка. Меня в самое сердце убил стенд Сбера 💔. В этом году они полностью отказались от мерча и просто сделали 5 настольных игр для посетителей. Работники стенда во время игр рассказывали как круто работать в Сбере... Жесть. 😨

Слава богу Gitverse и SberDevice меня искренне порадовали и огромный респект компании Островок за питона.

Самое ужасное (для меня лично), что было много докладов без записи! 📹🚫Если тебе повезло попасть на доклад, супер! Если нет, то извини...🤷‍♂️ Это конечно сильно напрягает. Я только на второй день конференции догадался диктофон включить💡. Самое главное, что контакты нужных спикеров я взял. Осталось только "обогатить" мои курсы их актуальными знаниями. 🙇‍♂️

В следующих несколько постах постараюсь дать некоторые инсайды от коллег, которые входят в разряд "слухи" или "сорока на хвосте принесла" 🤔🪬👽

#HighLoad

📜 Доклад от 2 декабря "Нетворкинг-зона «Базы данных и системы хранения»" (🚫🎥).

Было 4 стола с экспертами от Picodata, YDB, PostgreSQL, MySQL(MariaDB, MyDB). Удалось послушать только один стол с Picodata'ой. С экспертом Константином Осиповым. Что было на других столах - загадка... 🤷‍♂️

Несколько интересных тезисов:
❗️СУБД Tarantool была создана для того, чтобы уволить всех С/С++ программистов из Мэйл.ру. Эта СУБД предоставляет множество переиспользуемых кусков кода и достаточно посадить "перловика" для дальнейшей разработки на LUA. Как вы понимаете, ничего не вышло.

❗️Одна из главных проблем framework Jepsen - высокая стоимость обнаружения ошибок. Очень много времени и ресурсов тратится на обнаружение проблем работы кластера.

❗️Имплементации алгоритма ACCORD пока нет. Но обещают дожать...

❗️Хорошая команда по разработке СУБД стоит 500 млн. в год💰.Если вы не занимаетесь "консалтингом по Postgres", то этой суммы достаточно для развития продукта в правильном направлении.

❗️Нужно составлять грамотный роадмап развития продукта, а не заниматься "фигнёй"🤬. Это довольно простой тезис, но он практически никогда не работает. 🙃

❗️У VK есть своя реализация Jepsen на GO.

❗️Если ты делаешь хорошо достаточно уникальную вещь, то у тебя всё должно получиться.

❗️Сопровождение СУБД Picodata с кластером на 3000 ядер стоит 40 млн в год 👀. Однако, многие "крупные" компании содержать в штате более 160 человек, которые пытаются сделать что-то аналогичное. Пример, Сбер. Сберу прощу посадить тех же 160 человек пытаться изобрести велосипед еще раз, чем позволить какому-то вендеру с гораздо большей экспертизой вырасти. Эта одна из главных проблем рынка РФ. Не хватает зрелости...

❗️Picodata к концу 2025 года должна смочь тягаться с такими СУБД как Cassandra или ScyllaDB в кейсах быстрой хранилки данных с поддержкой SQL 🦾.

❗️Picodata находится в списке особозначимых проектов РФ. Важно, чтобы государство знало о проекте.

В финале всем советую посмотреть выступление Константина пару лет назад об "Истории развития Tarantool со слов Константина Осипова"

#HighLoad #Доклады_без_записи

📜Секция нетворкинга в отдельном зале Picodata (🚫🎥).
Серия докладов по Picodata. Презентации можно глянуть тут

Попробую аккумулировать итоговые тезисы:
❗️Кластеро-ориентированная архитектура лежит в основе Picodata.

❗️Почти все тесты идут на произвольной конфигурации кластера.

❗️Picodata выбирают исключительно для новых проектов. Проектов миграции у команды Picodata пока не было.

❗️Добавили поддержку SQL и Postgres-протокол.

❗️В начале 2025 года планируется полноценный драйвер для DBeaver.

❗️Сотни инстансов в кластере и максимум 5 в голосующих узлах и всего 1 лидер.

❗️Picodata обладает двумя движками memtx (для данных в ОЗУ) и vinil (для данных на диске).

❗️Количество виртуальных бакетов (bucket) всегда фиксировано и равно 30 000. Это позволяет минимизировать затраты на решардинге и при поиске информации в нужном бакете.

В заключение скажу, что в грядущем запуске курса по базам данных в 2025 году точно будет Picodata. Обязательно разберем теорию и пощупаем кластер на практике! 💯 Надеюсь, будет интересно! 😊

#HighLoad #Доклады_без_записи

🚀 Если кому-то сегодня скучно, то есть вариант глянуть от Яндекса Database Internals Meetup #5 (офлайн + онлайн): 5 докладов на конференции ISPRAS Open

❗Трасляция в ВК❗

Программа митапа будет плотной и насыщенной:
- 13:00 - 14:00 - Эволюция архитектуры СУБД на примере YDB, Андрей Фомичев, Яндекс, основатель и руководитель YDB
- 14:00 - 15:00 - Blue/green deploy для хранимых процедур в кластерной СУБД на примере Picodata, Константин Осипов, Picodata, основатель Picodata
- 15:00 - 16:00 - Оптимизация подсказками: ускоряем запросы, не изменяя планировщик. Сергей Зинченко, OpenGauss, Инженер
- 16:30 — 17:30 Панельная дискуссия: Перспективы создания модульного оптимизатора запросов. Павел Велихов, Владимир Озеров, Денис Пономарёв, Тимур Сафин, Максим Смяткин
- 17:30 - 18:30 - Переписывание запросов на основе материализованных представлений в аналитической системе CedrusData. Владимир Озеров, Александр Блажков, генеральный директор и разработчик CedrusData

Работа, учеба, экзамены, дедлайны...

Не забывайте кушать! С пятницей!

#mems

📜 Еще одна интересная секция "без записи" devhands.io ROOM (🚫🎥).

Название докладов просто бомба:
👉 Кто сможет в 1M RPS? В забеге участвуют: Valkey, Redis, Memcached, PostgreSQL, MySQL
👉 Корпоративное обучение в области высоких нагрузок: подход devhands
👉 Карта роста бэкендера
👉 Valkey: что это за зверь и потеснит ли он Redis?
И это только некоторые из них.

Все лекции и практики, в основном, проводим сам Алексей Рыбак, основатель devhands.io. Очень крутой специалист. Помимо всего того, чем занимается его компания, у него есть свои уникальные обучающие курсы для middle и более серьезных специалистов. "Джунов" он не обучает.

Презентации можно глянуть тут.

Основные тезисы, которые меня зацепили.
☄️ Обучение по программам DevHands очень гибкое. Если теория "плюс-минус" стандартизирована, то практические задания (ДЗ) создаются уникальные под каждого слушателя. Как я понял, перед началом курса они проводят собеседование и согласовывают набор практических заданий, т.к. техстек может сильно отличаться от компании к компании.

☄️ Сейчас Valkey почти не отличим от Redis.

☄️ Valkey нужно еще 2-3 года, чтобы продукт "созрел". Слишком много радикальных идей его развития по сравнению с Redis. Перспективы явно есть. Главное, чтобы в попытке добавления всеми желаемой многоядерности не получился второй DragonFly.

☄️ Товарищи из Яндекс.Облака потихонечку переходят с Redis на Valkey.

☄️ Исследователи из мира HighLoad и распределенных систем всё чаще смотрят на индустриальные кластерные СУБД. Такие продукты как Picodata или Shardman, возможно, являются будущим стандартом.

#HighLoad #Доклады_без_записи

📚Статья: Valkey: что нового и что дальше?

Напомню, что проект Valkey появился вследствие перехода СУБД Redis на другую более строгую лицензию, которая фактически запретила бесплатно использовать Redis облачным провайдерам. Хотите "перепродавать" возможности Redis своим клиентам - дайте денег. Компанию Redis labs можно понять.

Тем не менее, разработчики облачных провайдеров объединились вокруг проекта ValKey и начали его активно развивать и совершенствовать.
👉 Одной из главных фич является внедрение так всеми желанной многопоточности.
👉 В скором времени появится возможность активно взаимодействовать с JSON объектами. Не просто get/set, а добавить полноценные операции по изменению структуры документа.
👉 Эти изменения мы увидим уже в 2025 году в версии 8.0.
👉 Затем добавят вероятностные структуры данных, фильтры Блума.
👉 Уже ближе к 2026 году, а может и раньше, обновят кластерный механизм взаимодействия.

После прочтения статьи уважение к проекту Valkey возросло в разы!💪 Сообщество Redis настолько разрослось, что вполне способно поделиться надвое и продолжить развивать два независимых проекта. Очень здорово, что главные котребьютеры стремятся обновить уже устаревшие подходы. Дело даже не в многопоточности, а именно в работе кластера. Посмотрим, что они придумают 🤔

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

#NoSQLFM #Valkey

Кейс использования K6 в Picodata

Внутри эко-системы Grafana Labs есть инструмент для нагрузочного тестирования k6. Он немного странный (прожорливость, автоматизация на ява-скрипте, паралеллизация не по тредам/соединениям, а по параллельным пользовательским сессиям whatever it means). Но он становится всё более популярным, и выглядит мощно в плане кастомизаций. Кейс про то, как Picodata прикрутили k6 к тестированию своей СУБД.

Лонг-рид: https://habr.com/ru/companies/arenadata/articles/864974/

Ниже - краткое саммари (кстати, как вам промт?)

Кому будет интересна статья
* Гошникам
* Разработчикам распределённых систем и баз данных.
* Инженерам по нагрузочному тестированию.
* Специалистам, занимающимся построением инфраструктуры тестирования производительности.

Статья посвящена подходу компании Picodata к нагрузочному тестированию распределённых баз данных (NewSQL СУБД). Рассматриваются проблемы, с которыми сталкиваются разработчики таких систем, и выбор инструментов для создания практики тестирования производительности. Основное внимание уделяется созданию собственного решения — системы Picostress, основанной на инструментарии k6.

Используемые продукты и решения
* Picostress - разработанный инструмент для нагрузочного тестирования.
* Go - язык программирования, на котором написан весь код Picostress, а также k6
* k6 - утилита для создания нагрузочных тестов, поддерживающая выполнение скриптов на JavaScript.
* xk6-модуль: расширение для k6, реализованное для взаимодействия с Picodata через её нативные протоколы (iproto и pgproto).
* Cobra - Go-библиотека для создания CLI-приложений, использованная для создания обёртки вокруг k6.

Основные выводы
* Среди множества утилит для нагрузочного тестирования именно k6 оказался наиболее подходящим благодаря гибкости, расширяемости и поддержке пользовательских сценариев.
* Наиболее интересные особенности k6: интеграции в CI/CD процессы, создание сложных сценариев тестирования на JavaScript, поддержка постоянной нагрузки (constant throughput load) с учётом проблемы coordinated omission.
* Разработка собственного модуля: В Picodata был создан xk6-модуль для взаимодействия с нативными протоколами системы, что позволило реализовать нагрузочное тестирование, учитывающее специфику распределённых систем.
* Автоматизация и адаптивность: Picostress, основанный на k6, стал не только инструментом тестирования, но и ключевым элементом мониторинга и оптимизации производительности для каждого релиза продукта.

📚 Как вы думайте, какая книга по распределенным системам самая популярная среди ИТ-специалистов в РФ?

На каждом собеседовании на GO-разрабочика, ИТ-архитектора, аналитика данных, дата-сатаниста задаётся вопрос на знания из этой книги. Да, да да. Я говорю про "Designing Data-Intensive Applications" или на русском "Высоконагруженные приложения" или просто "Кабанчик".

Автор книги, Мартин Клеппман, начинал ее писать уже порядка 10 лет назад, а издана она была в 2017 году. Эта книга стала чуть ли не иконой для многих разработчиков! 🙏🧎 По до сих на многих конференция, митапах, форумах это книга всегда присутствует и её покупают в печатном издании.

Из минусов можно отметить то, что она теряет свою актуальность. Мир движется вперед с невероятной скоростью. Это понимаю я и это понимает сам автор.

Та-та-та-дам...Мартин Клеппман в соавторстве с Chris Riccomini, который работал в PayPal, LinkedIn, WePay, создал Apache Samza и SlateDB, а также написал книгу "The Missing README", начали писать 2-ое издание Кабанчика! 💥

Уже можно глянуть первые главы
1. Trade-offs in Data Systems Architecture
2. Defining Nonfunctional Requirements
3. Data Models and Query Languages
4. Storage and Retrieval

Полностью книга будет готова к следующему новому году.

В общем, рекомендую почитать на новогодних праздниках. За один-два вечера контент можно усвоить и прокачать свои знания!

#book #Architecture #DistributedSystems

Цените ваших коллег!

С пятницей!

#mems

Провокационная статья: 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.Конец.

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

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

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