“Техническая база” для менеджеров продукта — часть 4— базы данных

Записи из курса по technical product manager; позиционируют как: “Говори с разработчиками на одном языка”.

Это 4я часть из серии, в ней собраны: классификация баз данных, выбор БД под проект, ORM, типы связей, sql и non sql, кэширование.

Базы данных: хранение и обработка

Для реализации БД системы (структура) нет готовых решений. Это делает разработчик и бизнес — аналитик на этапе описания ТЗ.

SQL — язык структурированных запросов;

Все базы данных делятся на 2 типа: реляционные (SQL) и не реляционные (nonSQL).

типы БД

Выбор БД, так же как и языка, зависит от задачи и типа данных. Стоит для себя ответить (составить запрос, провести анализ) на вопросы:

• простые: не содержат связей, несут описательный характер, простая связь key — value;
  Например: стол {высота, ширина, цвет, кол-во ножек, цена};
• сложные: имеют связи, зависимости,
  например: user {user_id, личные данные {}, данные от системы {}, возраст};
• запись: большое кол-во операция записи; key-value или колоночная;
• чтение: много выборок данных, поиск связей;
• отображение: для отчетов;
• аналитика: для поиска инсайтов;
• умеренно данных:
• много данных: (что такое много никто не знает), принято считать, когда больше одного носителя (сервера), кластера;

ORM

ORM (Object-Relational Mapping) — технология программирования (библиотека), которая связывает базу данных с концепциями языков программирования:

• объектное представление данных (модель): работа с сущностями кода, а не объектами БД;
• легко покрыть тестами;
• легко поддерживать и модифицировать;
• проектируем модели на уровне бизнес логики: изменения через код, влияют на хранение.

Узнать больше: https://habr.com/ru/company/pgdayrussia/blog/328690/; https://habr.com/ru/post/458286/

Проектирование модели: описание (на уровне кода), как будут выглядеть данные, с которыми программа будет взаимодействовать; нам не нужно знать, как это будет храниться в БД; есть служебные модели — знают всю информацию; модели для API — ограниченные модели для сторонних сервисов (без некоторых полей данных, урезанная модель). В базе — мы работаем с цифрами/значениями; в коде — с объектами/структурами;

Рекомендация: стоит использовать во всех проектах ORM (вместо чистого sql), т.к. он дает больше гибкости, легче настроить, меньше рутины, и тд.

Реляционные (SQL) БД:

Все данные хранятся в строго описанных таблицах (название колонок, тип данных, объем) и содержат связи между колонками по ключам и значениям (индексы). У них низкий порог входа. Такие БД похожи на Excell таблицы. Используют единый язык запросов — SQL.

Индексы (гуманитарное объяснение): способ сортировки данных в ножном порядке (удобном для поиска).
Например: есть телефонный справочник, где все абоненты записаны по фамилиям и по алфавиту;
если нужно найти Яковлева, то нет смылса листать весь справочник, можно сразу пойти с конца;
но, если нужно найти человека по имени (не зная фамилию)?
нужен второй справочник, который отсортирован по имени.

Типы связей:

1. 1 — к — 1: одной записи в табилце А, отвечает одна запись из таблицы Б; свзяь по полю id (индекс); работает в обе стороны;
   например: когда нужно вынести телефоны абоненентов или адрес в отдельную таблицу, чтобы не было избиточности;
2. 1 — к — многим: одной записи в табилце А, отвечают несколько записей из таблицы Б;
   например: один абонент, может иметь несколько телефонов или адресов;
3. много — к — многим:
   например: есть таблица с ролями (админ, польтзователь, бан), много пользователй в каждой группе; при этом в разном порядке;

Почему нельзя хранить все данные в одной таблице?
Избыточность: дублирование или хранение в одной таблице БД информации, которая там не должна быть (или уже есть в дургой таблице, или можно рассчитать по доступным данным, или сенсетив данные);
Их нужно нормализовать — привести в порядок;

Как выбирать данные?
Для этого нужно сделать запрос на языке SQL. Его нужно выучить отдельно. Пример запроса:

select “что нужно выбрать”
from “названеи таблицы”
where “фильтры”

Не реляционные (nonSQL) БД:

Такие БД не имеют связей (таблиц, отношений, id), данные хранятся в другом виде (без строгой структуры), не имеют единого языка запросов, имеют большую скорость обработки данных, легко масштабируются, нет транзакций (запросы потоковые, если хотя бы один из запросов не прошёл, запрос отменяется).

Способы организации не реляционных БД:

1. Табличная: ключ — значения, плоская таблица, где соотносятся свойства;
   например: хранение в браузере — local store; session store; reddis — хранение данных в операционной памяти для быстрой обработки;
   базы: Riak, Amazon DynamoDB.
2. Колоночная: каждая колонка — это как бы отдельная таблица из одной колонки, которая хранит только свои значения и id для связи; все данные хранятся в отсортированном виде; структура хранения данных напоминает индексы в обычных базах данных, однако между колонками нет физической связи;
   например: событийные таблицы, над которыми выполняются сложные выборки (агрегации, фильтры, сортировки, аналитических выборок) типа добавление товаров в корзину в интернет магазине;
   базы: Vertica, HBase, Cassandra.
3. Документоориентированные: в них нет понятия таблицы, но есть индекс (со своей структурой); очень похожа на табличную (ключ — значение), но значение представляет собой не строку, а объект (json, xml: несколько полей внутри);
   базы: Couchbase и MongoDB.
4. Графовые: используют рёбра и узлы для представления данных; узлы связаны между собой определённым отношениями, представленными рёбрами между ними; у узлов и отношений есть некоторые свойства. Используються в обучении нейронних сетей, геймдеве (сообщечства), соц сетях, контекстной релкаме.
   базы: GraphQL.

Кэширование

Часто, встает задача оптимизировать запросы: на выборку данных, при ответе API и тд. Для этого, можно кэшировать на время ответы.

Клиент делает запрос: через сайт из браузера, запрос летит на веб-сервер, тот обрабатывает его, обращается к коду, обращается к БД за данными, формирует и отдает ответ.

Есть несколько уровней кэширования:

• на уровне клиента: сохранять картинки, JS-код, статический контент на устройстве клиента (browser cache);
• на сетевом уровне: запросы могут идти из разных ГЕО; можно выбирать, с какого сервера ответить (если их много), чтобы сохранить время прохождения канала;
  CDN —content delivery network (пр. Cloudflare), сеть для распределения трафика между узлами системы.
• на уровне сервера: все запросы к БД и серверу, могут быть сохранены в cache server, и отдаваться с него;
• на уровне приложения: сохранять типовые расчеты в app cache;
• на уровне базы данных: DB cache, колонки или строки, к которым обращаются чаще других, можно заносить в кэш.

Идеальная машина для кэширования

Другие части

1. “Техническая база” для менеджеров продукта — часть 1 — общие понятия;
2. “Техническая база” для менеджеров продукта — часть 2 — frontend;
3. “Техническая база” для менеджеров продукта — часть 3 — backend;
4. туту
5. “Техническая база” для менеджеров продукта — часть 5 — архитектура продукта;
6. “Техническая база” для менеджеров продукта — часть 6 — сеть, информационная безопасность и СI/CD;
7. “Техническая база” для менеджеров продукта — часть 7 — GIT, системы контроля версий;
8. “Техническая база” для менеджеров продукта — часть 8 — Документация (техн, прод);
9. “Техническая база” для менеджеров продукта — часть 9 — Аналитика;
10. “Техническая база” для менеджеров продукта — часть 10 — Тестирование;
11. “Техническая база” для менеджеров продукта — часть 10 — Mobile;