Database

Дизайн хранилища типа Ключ-Значене состоит из понимания следующих тем:

• Что мы хотим от хранилища Ключ-Значение?
• Односерверное хранилище Ключ-Значение
• РАСПРЕДЕЛЕННОЕ хранилище Ключ-Значение:
  • Теорема CAP
  • Реальные компромиссы для распределенных систем
• Системные компоненты:
  • Партиционирование данных
  • Репликация данных
  • Консистентность
  • Разрешение неконсистентности: Версии
  • Обработка всех типов сбоев: Обнаружение сбоев, Обработка ВРЕМЕННЫХ сбоев, Обработка ПОСТОЯННЫХ сбоев, Устранение сбоев в работе центра обработки данных
• Схема архитектуры системы
• Путь записи
• Путь чтения

Эти пункты раскрыты в очень интересной главе 6 книги:

Консистентное хеширование является краеугольной технологией для распределенных систем. Многие разработчики программного обеспечения этого не осознают, но консистентное хеширование необходимо во многих местах: балансировщики нагрузки, кэши, CDN, генераторы id, базы данных, чаты/социальные сети и многие другие системы.

Эта тема состоит из:

• Проблема с перехешированием и почему нам нужно, чтобы хеширование было ПОСЛЕДОВАТЕЛЬНЫМ
• Хэш-пространство и хэш-кольцо
• БАЗОВЫЙ подход (введенный Каргером и др. в MIT)
• Расширенный подход с ВИРТУАЛЬНЫМИ УЗЛАМИ

Эти моменты раскрыты в очень интересной главе 5 книги:

Четыре стандартных этапа собеседования по проектированию ИТ-систем. Однако я бы думал о них шире: как о четырех начальных шагах проектирования любого ПО.

• Шаг 1. Понимание проблемы и определение скоупа проектирования
• Шаг 2. Предложите дизайн высокого уровня и получите одобрение
• Шаг 3. Спроектируйте глубокое погружение
• Шаг 4. Завершение

Глава 3 книги раскрывает подробности о каждом шаге, хорошие вопросы, которые нужно задать (над которыми следует подумать), а также то, что НУЖНО и НЕЛЬЗЯ делать. Она также показывает хороший пример процесса разработки системы новостных лент в соц сетях.

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

Концепции, которые должен знать КАЖДЫЙ разработчик программного обеспечения:

• “Сила двух”
• Стандартные цифры задержки! Насколько быстрой является память, насколько медленным является диск и т.д.
• Показатели доступности
• Про какие ключевые метрики стоит думать

Эти понятия и числа раскрыты во второй главе книги:

“System Design. Подготовка к сложному интервью” Алекса Сюй. Оригинал: “System Design Interview – An insider’s guide” by Alex Xu

Отличный общий план для масштабирования любого приложения с нуля до миллионов пользователей.

• Настройка одного сервера
• Выбор и использование базы данных
• Вертикальное масштабирование против горизонтального масштабирования подходов. И почему вы должны предпочесть горизонтальный
• Добавлен балансировщик нагрузки для горизонтального масштабирования
• Добавление репликации базы данных для горизонтального масштабирования
• Добавление кеша
• Добавление CDN
• Архитектура без сохранения состояния и с сохранением состояния и использование внешнего хранилища состояния
• Добавление дополнительных центров обработки данных
• Добавление очереди сообщений
• Добавление ведения журнала, метрик и автоматизации
• Масштабирование базы данных
• и дальнейшие шаги…

Все это тщательно, но кратко раскрыто в Главе 1 книги:

Книжный клуб у нас в компании выбрал следующую чудесную книгу для чтения:

Роберт Мартин - Чистая Архитектура - Искусство Разработки Программного Обеспечения

Robert Martin - Clean Architecture - a Craftsman’s Guide to Software Structure and Design

👍

Часть VI подрывает некоторые устои 😀:

• Вы знаете, что База Данных - это “деталь”? Неважная второстепенная низкоуровневая необязательная функция, которой можно пренебречь при проектировании архитектуры!
• Вы знаете про Веб тоже самое? Это просто неважное устройство ввода-вывода, которым также следует пренебречь при проектировании архитектуры!
• А как насчет фреймворков? То же самое. Не женитесь на своём фреймворке. Используйте безопасный, а еще лучше - удаленный секс. 🤣
• Несколько примеров того, как похожие архитектуры могут приводить или не приводить к проблемам. И что использовать, чтобы избежать проблем (спойлер: Инкапсуляцию)
• Все вышеперечисленное и краткий недостающий совет…

Вобщем, отличная информация! Все подробности в моих ментальных картах:

Ранее в этом году книжный клуб нашей компании изучил отличную книгу:

Martin Kleppmann - Designing Data-Intensive Applications

Мартин Клеппман - Высоконагруженные приложения. Программирование, масштабирование, поддержка

Это - лучшая книга о создании комплексных масштабируемых программных систем, которые я когда-либо читал. 💪

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

Глава 1:

• Строительные блоки приложений
• Что такое надежность, масштабируемость и ремонтопригодность. Примеры и определения.
  • Неисправности и отказы
  • Производительность, нагрузка, задержка и время отклика
  • Работоспособность, простота, эволюционируемость
• Почему вы должны убивать свои сервера случайным образом 😅
• Как Twitter доставляет 12 000 твитов в секунду до 300 000 пользователей в секунду. (Очень интересно!)
• Сколько денег Amazon теряет за каждые 100мс задержки ответа
• Как быстро рассчитать персентили для мониторинга времени отклика в PROD

Скачать всю майнд-мапу в PDF