ИПР: различия между версиями
FireWolf (обсуждение | вклад) |
FireWolf (обсуждение | вклад) |
||
Строка 1: | Строка 1: | ||
= | = L3 / Потокобезопастные структуры данных = | ||
= | = L3 / Нормализация БД (1-3 нормальные формы) = | ||
https://info-comp.ru/database-normalization | https://info-comp.ru/database-normalization | ||
Строка 46: | Строка 46: | ||
Таблица должна содержать правильные неключевые столбцы | Таблица должна содержать правильные неключевые столбцы | ||
= | = L3 / Шардирование Репликация = | ||
https://web-creator.ru/articles/partitioning_replication_sharding | https://web-creator.ru/articles/partitioning_replication_sharding | ||
Строка 65: | Строка 65: | ||
Например, в системах типа социальных сетей ключом для шардинга может быть ID пользователя, таким образом все данные пользователя будут храниться и обрабатываться на одном сервере, а не собираться по частям с нескольких. | Например, в системах типа социальных сетей ключом для шардинга может быть ID пользователя, таким образом все данные пользователя будут храниться и обрабатываться на одном сервере, а не собираться по частям с нескольких. | ||
= | = L3 / Типы данных в Redis = | ||
Ключи | Ключи | ||
Версия 14:28, 8 июля 2021
L3 / Потокобезопастные структуры данных
L3 / Нормализация БД (1-3 нормальные формы)
https://info-comp.ru/database-normalization
Первая нормальная форма (1NF)
https://info-comp.ru/first-normal-form
Требование первой нормальной формы (1NF) очень простое и оно заключается в том, чтобы таблицы соответствовали реляционной модели данных и соблюдали определённые реляционные принципы.
Таким образом, чтобы база данных находилась в 1 нормальной форме, необходимо чтобы ее таблицы соблюдали следующие реляционные принципы:
В таблице не должно быть дублирующих строк В каждой ячейке таблицы хранится атомарное значение (одно не составное значение) В столбце хранятся данные одного типа Отсутствуют массивы и списки в любом виде
Вторая нормальная форма (2NF)
https://info-comp.ru/second-normal-form
Чтобы база данных находилась во второй нормальной форме (2NF), необходимо чтобы ее таблицы удовлетворяли следующим требованиям:
Таблица должна находиться в первой нормальной форме Таблица должна иметь ключ Все неключевые столбцы таблицы должны зависеть от полного ключа (в случае если он составной) { Если какой-то атрибут (столбец) зависит только от одного столбца в ключе, значит, база данных не находится во второй нормальной форме. Иными словами, в таблице не должно быть данных, которые можно получить, зная только половину ключа, т.е. только один столбец из составного ключа. }
Третья нормальная форма (3NF)
https://info-comp.ru/third-normal-form
Требование третьей нормальной формы (3NF) заключается в том, чтобы в таблицах отсутствовала транзитивная зависимость.
Транзитивная зависимость – это когда неключевые столбцы зависят от значений других неключевых столбцов.
Если в первой нормальной форме наше внимание было нацелено на соблюдение реляционных принципов, во второй нормальной форме в центре нашего внимания был первичный ключ, то в третьей нормальной форме все наше внимание уделено столбцам, которые не являются первичным ключом, т.е. неключевым столбцам.
Чтобы нормализовать базу данных до третьей нормальной формы, необходимо сделать так, чтобы в таблицах отсутствовали неключевые столбцы, которые зависят от других неключевых столбцов.
Иными словами, неключевые столбцы не должны пытаться играть роль ключа в таблице, т.е. они действительно должны быть неключевыми столбцами, такие столбцы не дают возможности получить данные из других столбцов, они дают возможность посмотреть на информацию, которая в них содержится, так как в этом их назначение.
Главное правило третьей нормальной форме (3NF) звучит следующим образом:
Таблица должна содержать правильные неключевые столбцы
L3 / Шардирование Репликация
https://web-creator.ru/articles/partitioning_replication_sharding
Партиционирование (partitioning)
Партиционирование — это разбиение таблиц, содержащих большое количество записей, на логические части по неким выбранным администратором критериям. Партиционирование таблиц делит весь объем операций по обработке данных на несколько независимых и параллельно выполняющихся потоков, что существенно ускоряет работу СУБД. Для правильного конфигурирования параметров партиционирования необходимо, чтобы в каждом потоке было примерно одинаковое количество записей.
Например, на новостных сайтах имеет смысл партиционировать записи по дате публикации, так как свежие новости на несколько порядков более востребованы и чаще требуется работа именно с ними, а не со всех архивом за годы существования новостного ресурса.
Репликация (replication)
Репликация — это синхронное или асинхронное копирование данных между несколькими серверами. Ведущие сервера называют мастерами (master), а ведомые сервера — слэйвами (slave). Мастера используются для изменения данных, а слэйвы — для считывания. В классической схеме репликации обычно один мастер и несколько слэйвов, так как в большей части веб-проектов операций чтения на несколько порядков больше, чем операций записи. Однако в более сложной схеме репликации может быть и несколько мастеров.
Например, создание нескольких дополнительных slave-серверов позволяет снять с основного сервера нагрузку и повысить общую производительность системы, а также можно организовать слэйвы под конкретные ресурсоёмкие задачи и таким образом, например, упростить составление серьёзных аналитических отчётов — используемый для этих целей slave может быть нагружен на 100%, но на работу других пользователей приложения это не повлияет.
Шардинг (sharding)
Шардинг — это прием, который позволяет распределять данные между разными физическими серверами. Процесс шардинга предполагает разнесения данных между отдельными шардами на основе некого ключа шардинга. Связанные одинаковым значением ключа шардинга сущности группируются в набор данных по заданному ключу, а этот набор хранится в пределах одного физического шарда. Это существенно облегчает обработку данных.
Например, в системах типа социальных сетей ключом для шардинга может быть ID пользователя, таким образом все данные пользователя будут храниться и обрабатываться на одном сервере, а не собираться по частям с нескольких.
L3 / Типы данных в Redis
Ключи
Redis — хранилище данных в формате «ключ-значение». Факты о ключах:
Ключи в Redis — бинарно-безопасные (binary safe) строки. Слишком длинные ключи — плохая идея, не только из-за занимаемой памяти, но так же и в связи с увеличением времени поиска определенного ключа в множестве в связи с дорогостоящим сравнением. Хорошая идея — придерживаться схемы при построении ключей: «object-type:id:field».
Типы данных Redis
Строки (strings). Базовый тип данных Redis. Строки в Redis бинарно-безопасны, могут использоваться так же как числа, ограничены размером 512 Мб. Списки (lists). Классические списки строк, упорядоченные в порядке вставки, которая возможна как со стороны головы, так и со стороны хвоста списка. Максимальное количество элементов — 2^32 — 1. Множества (sets). Множества строк в математическом понимании: не упорядочены, поддерживают операции вставки, проверки вхождения элемента, пересечения и разницы множеств. Максимальное количество элементов — 2^32 — 1. Хеш-таблицы (hashes). Классические хеш-таблицы или ассоциативные массивы. Максимальное количество пар «ключ-значение» — 2^32 — 1. Упорядоченные множества (sorted sets). Упорядоченное множество отличается от обычного тем, что его элементы упорядочены по особому параметру «score».