ИПР: различия между версиями
FireWolf (обсуждение | вклад) |
FireWolf (обсуждение | вклад) |
||
(не показано 19 промежуточных версий этого же участника) | |||
Строка 1: | Строка 1: | ||
= | = L3 / Потокобезопастные структуры данных = | ||
= L3 / Нормализация БД (1-3 нормальные формы) = | |||
https://info-comp.ru/database-normalization | https://info-comp.ru/database-normalization | ||
== Первая нормальная форма (1NF) == | |||
https://info-comp.ru/first-normal-form | https://info-comp.ru/first-normal-form | ||
Строка 14: | Строка 17: | ||
Отсутствуют массивы и списки в любом виде | Отсутствуют массивы и списки в любом виде | ||
== Вторая нормальная форма (2NF) == | |||
https://info-comp.ru/second-normal-form | https://info-comp.ru/second-normal-form | ||
Строка 26: | Строка 30: | ||
} | } | ||
== Третья нормальная форма (3NF) == | |||
https://info-comp.ru/third-normal-form | https://info-comp.ru/third-normal-form | ||
Строка 42: | Строка 46: | ||
Таблица должна содержать правильные неключевые столбцы | Таблица должна содержать правильные неключевые столбцы | ||
= 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». | |||
= L3 / Redis: Как построить кластер, его особенности, для чего нужны Sentinel = | |||
= L3 / Xml-processing: DOM / SAX / StAX / JAXB = | |||
= L3 / Мультипоточность: классическая модель и многозадачность = | |||
== Executors == | |||
(Single-Thread, Fixed, Pooled) Scheduled executor Callable/Future interface | |||
== Объекты синхронизации == | |||
ReentrantLock, ReentrantReadWriteLock Atomic* (Integer, Boolean, etc) Concurrent collections: CopyOnWriteArrayList/Set, ConcurrentSkipListMap/Set, ConcurrentHashMap Thread States BlockingQueues/Dequeues (Linked*, Array*, Priority*,etc...) |
Текущая версия на 14:40, 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».
L3 / Redis: Как построить кластер, его особенности, для чего нужны Sentinel
L3 / Xml-processing: DOM / SAX / StAX / JAXB
L3 / Мультипоточность: классическая модель и многозадачность
Executors
(Single-Thread, Fixed, Pooled) Scheduled executor Callable/Future interface
Объекты синхронизации
ReentrantLock, ReentrantReadWriteLock Atomic* (Integer, Boolean, etc) Concurrent collections: CopyOnWriteArrayList/Set, ConcurrentSkipListMap/Set, ConcurrentHashMap Thread States BlockingQueues/Dequeues (Linked*, Array*, Priority*,etc...)