diff --git a/assets/distributed/Horizontal-Sharding.png b/assets/distributed/Horizontal-Sharding.png index 1a90d21..f649c40 100644 Binary files a/assets/distributed/Horizontal-Sharding.png and b/assets/distributed/Horizontal-Sharding.png differ diff --git a/assets/distributed/Keybased-Sharding.png b/assets/distributed/Keybased-Sharding.png new file mode 100644 index 0000000..c30fff1 Binary files /dev/null and b/assets/distributed/Keybased-Sharding.png differ diff --git a/bibliography.bib b/bibliography.bib index 591e8b3..31e5924 100644 --- a/bibliography.bib +++ b/bibliography.bib @@ -190,7 +190,7 @@ @book{Date2005 url = {http://tc.kpi.ua/content/lib/vvedenie_v_sistemy_baz_dannyh_8izdanie.pdf} } @online{Oracle, - author = {Sql-oracle}}, + author = {Sql-oracle}, title = {{Представления словаря данных}}, url = {http://sql-oracle.ru/predstavleniya-slovarya-dannyx.html}, urldate = {2020-05-30}, @@ -344,6 +344,46 @@ @online{Jalili2 year={2021} } + +@online{Greenplum, + title = {{Greenplum DB}}, + author = {kapustor}, + url = {https://habr.com/ru/company/tinkoff/blog/267733/}, + urldate = {2015-10-13}, + year={2015} +} + +@online{DatabaseShardingIndusEdition, + title = {{Database Sharding – System Design Interview Concept}}, + author = {anuupadhyay}, + url = {https://www.geeksforgeeks.org/database-sharding-a-system-design-concept/}, + urldate = {2021-09-02}, + year={2021} +} + +@online{DatabaseSharding, + title = {{Understanding Database Sharding}}, + author = {Mark Drake}, + url = {https://www.digitalocean.com/community/tutorials/understanding-database-sharding}, + urldate = {2019-07-02}, + year={2019} +} + +@online{Replication, + title = {{Путеводитель по репликации баз данных}}, + author = {hard\_sign}, + url = {https://habr.com/ru/post/514500/}, + urldate = {2020-08-10}, + year={2020} +} + +@article{Baron-Ladyzhensky1994, + author = {Г. Барон, Г. Ладыженский}, + title = {Технология тиражирования данных с распределенных системах}, + journal = {Открытые системы. СУБД}, + year = {1994} +} + @book{Patterson, author = {David A. Patterson, Garth Gibson, Randy H. Katz}, title = {{A Case of Redundant Arrays of Inexpensive Disks}}, @@ -404,30 +444,6 @@ @online{Klyukin year={2022} } -@online{Greenplum, - title = {{Greenplum DB}}, - author = {kapustor}, - url = {https://habr.com/ru/company/tinkoff/blog/267733/}, - urldate = {2015-10-13}, - year={2015} -} - -@online{DatabaseSharding, - title = {{Database Sharding – System Design Interview Concept}}, - author = {anuupadhyay}, - url = {https://www.geeksforgeeks.org/database-sharding-a-system-design-concept/}, - urldate = {2021-09-02}, - year={2021} -} - -@online{Replication, - title = {{Путеводитель по репликации баз данных}}, - author = {hard\_sign}, - url = {https://habr.com/ru/post/514500/}, - urldate = {2020-08-10}, - year={2020} -} - @online{DataDictionary, author = {Wesley Chai}, title = {data dictionary}, diff --git a/part/distributed.tex b/part/distributed.tex index 90fad3e..bef868f 100644 --- a/part/distributed.tex +++ b/part/distributed.tex @@ -586,9 +586,10 @@ \subsection{Протоколы фиксации} представления, временные параметры, их композицию, необходимы унифицированные базы данных. \subsection{Тиражирование данных} -\textbf{Тиражирование данных} - это асинхронный перенос изменений объектов исходной базы данных (source database) -в базы данных, принадлежащие к различным узлам распределенной системы. Тиражирование данных может происходит -двумя различными способами: \textbf{шардингом} (или, иначе говоря, шардированием, фрагментацией) и \textbf{репликацией}. +Согласно \autocite{Baron-Ladyzhensky1994}, \textbf{тиражирование данных} - это асинхронный перенос изменений объектов +исходной базы данных (source database) в базы данных, принадлежащие к различным узлам распределенной системы. +Тиражирование данных может происходить двумя различными способами: \textbf{шардингом} (или, иначе говоря, шардированием, +фрагментацией) и \textbf{репликацией}. \paragraph{Шардинг (sharding)} ~\\ \textbf{Шардинг} (иногда \textbf{шардирование}) — это принцип проектирования базы данных, при котором логически @@ -620,43 +621,34 @@ \subsection{Тиражирование данных} работы системы, причем ни пользовательские программы, ни терминальные операции при этом не затрагиваются. Таким образом, если обеспечивается независимость от шардирования, пользователи получают данные в виде некоторого -представления, в котором шарды логически скомбинированы с помощью соответствующих операций соединения и объединения. -К обязанностям системного оптимизатора относится определение шардов, к которым требуется физический доступ для +представления, в котором фрагменты логически скомбинированы с помощью соответствующих операций соединения и объединения. +К обязанностям системного оптимизатора относится определение фрагментов, к которым требуется физический доступ для выполнения любого из поступивших запросов пользователя. \autocite{IntroBD2014} \paragraph{Алгоритмы шардинга} ~\\ Ранее уже упоминалось о двух основных вида шардинга: горизонтальный и вертикальный. Стоит их разобрать по подробнее и -рассказать и про другие виды шардирования, такие как шадинг на основе каталогов и шардинг на основе ключей. - -\paragraph{Горизонтальное шардирование} ~\\ -В этом методе мы разбиваем данные на основе диапазонов заданного значения, присущего каждой сущности. Допустим, у вас -есть база данных имен ваших онлайн-клиентов и информации об электронной почте. Вы можете разделить эту информацию на -два осколка. В одном осколке вы можете хранить информацию о клиентах, чье имя начинается с A-P, а в другом - информацию -об остальных клиентах. - -\begin{figure}[H] - \centering - \includegraphics[width=100mm]{assets/distributed/Horizontal-Sharding} - \caption{Горизонтальное шардирование} - \label{fig:Horizontal-Sharding} -\end{figure} - -\textbf{Горизонтальное шардирование} - самый простой метод сегментирования для реализации. Каждый осколок содержит -другой набор данных, но все они имеют ту же схему, что и исходная база данных. В этом методе вам просто нужно -определить, в какой диапазон попадают ваши данные, а затем вы можете сохранить запись в соответствующий шард. Этот -метод лучше всего подходит для хранения нестатических данных (например, хранение контактной информации студентов -колледжа). +рассказать и про другие виды шардирования, такие как шадинг на основе каталогов и шардинг на основе ключей. Стоит +отметить следующий факт: в русскоязычном сегменте интернета ограничиваются только вертикальным и горизонтальным видом +шардинга, в то время как в англоязычном сегменте горизонтальное шардирование разделяют на несколько видов, которые, +можно сказать, являются частными случаями горизонтального шардинга. Чаще этими видами являются: +\begin{itemize} + \item Range based sharding - шардинг на основе диапазонов (к данному типу лучше всего подходит название - горизонтальный шардинг); + \item Directory based sharding - шардинг на основе каталогов; + \item Hash based sharding - шардинг на основе хэшей. +\end{itemize} -Недостатком этого метода является то, что данные могут быть неравномерно распределены по шардам. В приведенном выше -примере у вас может быть много клиентов, имена которых попадают в категорию A-P. В таких случаях первый осколок должен -будет взять на себя больше нагрузки, чем второй, и это может стать узким местом системы. \autocite{DatabaseSharding} +В общем случае в русcкоязычном сегменте интернета описание горизонтального шардинга совпадает с Range based sharding, +поэтому для порядка в данной главе опишем еще и Directory based sharding вместе с Hash based sharding. Англоязычным +источником будет служить статья с digitalocean.com, которая является самой ранней из всех мной найденных. В +принципе, про вертикальный шардинг выше уже было рассказано, но для порядка и полного понимания ниже представлен расунок +и подробное описание из \autocite{DatabaseShardingIndusEdition}. \paragraph{Вертикальное шардирование} ~\\ В этом методе мы разделяем весь столбец из таблицы и помещаем эти столбцы в новые отдельные таблицы. Данные полностью независимы от одного раздела к другому. Кроме того, каждый раздел содержит как отдельные строки, так и столбцы. Возьмем, к примеру, функции Twitter. Мы можем разделить различные функции объекта на разные сегменты на разных машинах. В Твиттере у пользователя может быть профиль, количество подписчиков и некоторые твиты, опубликованные им самим. Мы можем -разместить профили пользователей на одном осколке, подписчиков - на втором, а твиты - на третьем. +разместить профили пользователей на одном фрагменте, подписчиков - на втором, а твиты - на третьем. \begin{figure}[H] \centering @@ -670,42 +662,38 @@ \subsection{Тиражирование данных} согласованности. Это одно из главных преимуществ этого метода. Основным недостатком этой схемы является то, что для ответа на некоторые запросы вам, возможно, придется комбинировать -данные из разных шардов, что неоправданно увеличивает сложность разработки и эксплуатации системы. Кроме того, если +данные из разных фрагментов, что неоправданно увеличивает сложность разработки и эксплуатации системы. Кроме того, если ваше приложение будет расти позже, и вы добавите в него еще несколько функций, вам придется дополнительно сегментировать -базу данных с конкретными функциями на нескольких серверах. \autocite{DatabaseSharding} +базу данных с конкретными функциями на нескольких серверах. -\paragraph{Шардинг на основе каталогов} ~\\ -В этом методе мы создаем и поддерживаем службу поиска или таблицу поиска для исходной базы данных. В основном мы -используем ключ осколка для таблицы поиска и делаем сопоставление для каждого объекта, существующего в базе данных. -Таким образом, мы отслеживаем, какие осколки базы данных содержат какие данные. - -Таблица поиска содержит статический набор информации о том, где можно найти конкретные данные. На приведенном выше -изображении вы можете видеть, что мы использовали зону доставки в качестве ключа осколка. Во-первых, клиентское -приложение запрашивает службу поиска, чтобы узнать осколок (раздел базы данных), на котором размещены данные. Когда -служба поиска возвращает осколок, она запрашивает/обновляет этот осколок. +\paragraph{Горизонтальное шардирование} ~\\ +Горизонтальное шардирование или Range based sharding включает данные сегментирования на основе диапазонов заданного +значения. Для иллюстрации, скажем, у вас есть база данных, в которой хранится информация обо всех продуктах в каталоге +продавца. Вы можете создать несколько разных фрагментов и разделить информацию о каждом продукте в зависимости от +ценового диапазона, в который они попадают, например: \begin{figure}[H] \centering - \includegraphics[width=100mm]{assets/distributed/Directory-Based-Sharding} - \caption{Шардинг на основе каталогов} - \label{fig:Directory-Based-Sharding} + \includegraphics[width=100mm]{assets/distributed/Horizontal-Sharding} + \caption{Горизонтальное шардирование} + \label{fig:Horizontal-Sharding} \end{figure} -Сегментация на основе каталогов гораздо более гибкая, чем сегментация на основе диапазонов и ключей. В сегменте на -основе диапазонов вы обязаны указать диапазоны значений. В key-based вы обязаны использовать фиксированную хэш-функцию, -которую трудно изменить позже. При таком подходе вы можете использовать любой алгоритм, который хотите назначить для -записей данных в сегменты. Кроме того, при таком подходе легко динамически добавлять шарды. +Основное преимущество горизонтального шардирования заключается в том, что его относительно просто реализовать. Каждый +фрагмент содержит различный набор данных, но все они имеют идентичную схему, а также исходную базу данных. Код приложения +просто читает, в какой диапазон попадают данные, и записывает их в соответствующий фрагмент. -Основным недостатком этого подхода является единственная точка отказа таблицы поиска. Если он будет поврежден или не -удался, это повлияет на запись новых данных или доступ к существующим данным из таблицы. \autocite{DatabaseSharding} +С другой стороны, шардирование на основе диапазона не защищает данные от неравномерного распределения, что приводит к +вышеупомянутым «горячим точкам» базы данных. Если посмотреть на диаграмму примера, даже если каждый фрагмент содержит +одинаковое количество данных, существует вероятность того, что конкретным продуктам будет уделено больше внимания, чем +другим. Их соответствующие фрагменты, в свою очередь, получат непропорциональное количество операций чтения. \autocite{DatabaseSharding} \paragraph{Шардинг на основе ключей} ~\\ -Этот метод также известен как сегментация на основе хэша. Здесь мы берем значение объекта, такого как идентификатор -клиента, адрес электронной почты клиента, IP-адрес клиента, почтовый индекс и т. д., и мы используем это значение в -качестве входных данных хэш-функции. Этот процесс генерирует хэш-значение, которое используется для определения того, -какой шард нам нужно использовать для хранения данных. Мы должны иметь в виду, что значения, введенные в хэш-функцию, -должны поступать из одного и того же столбца (ключ осколка), чтобы данные размещались в правильном порядке и -согласованно. В принципе, ключи осколков действуют как первичный ключ или уникальный идентификатор для отдельных строк. +Шардинг на основе ключей, также известный как шардинг на основе хэшей, предполагает использование значения, взятого из +вновь записанных данных, таких как идентификационный номер клиента, IP-адрес клиентского приложения, почтовый индекс и +т.д. - и подключив его к хэш функции, чтобы определить, в какой сегмент должны идти данные. Полученное значение хэша +является идентификатором фрагмента, который используется для определения, на каком фрагменте будут храниться входящие +данные. В целом процесс выглядит так: \begin{figure}[H] \centering @@ -714,24 +702,75 @@ \subsection{Тиражирование данных} \label{fig:Keybased-Sharding} \end{figure} -Рассмотрим пример, что у вас есть 3 сервера баз данных, и каждый запрос имеет идентификатор приложения, который -увеличивается на 1 каждый раз, когда регистрируется новое приложение. Чтобы определить, на каком сервере должны быть -размещены данные, мы выполняем операцию по модулю для этих приложений id с номером 3. Затем остаток используется для -идентификации сервера для хранения наших данных. +Чтобы обеспечить правильное размещение записей в правильных фрагментах, все значения, введенные в хэш-функцию, должны +поступать из одного столбца. Этот столбец известен как shard key. Проще говоря, ключи сегментов похожи на primary keys, +поскольку оба являются столбцами, которые используются для определения уникального идентификатора для отдельных строк. +Вообще говоря, ключ фрагмента должен быть статическим, то есть он не должен содержать значений, которые могут меняться +со временем. В противном случае это увеличит объем работы, выполняемой операциями обновления, и может снизить +производительность. + +Хотя основанное на ключах разбиение является довольно распространенной архитектурой разбиения, оно может усложнить +задачу при динамическом добавлении или удалении дополнительных серверов в базе данных. Когда вы добавляете серверы, +каждому из них потребуется соответствующее значение хеш-функции, и многие из ваших существующих записей, если не все, +необходимо будет переназначить на новое, правильное значение хеш-функции, а затем перенести на соответствующий сервер. +Когда вы начнете перебалансировать данные, ни новые, ни старые хеширующие функции не будут действительны. Следовательно, +ваш сервер не сможет записывать какие-либо новые данные во время миграции, и ваше приложение может быть подвержено +простою. + +Основная привлекательность этой стратегии заключается в том, что ее можно использовать для равномерного распределения +данных с целью предотвращения горячих точек. Кроме того, поскольку он распределяет данные алгоритмически, нет +необходимости поддерживать карту расположения всех данных, как это необходимо для других решений, таких как разделение +на основе диапазона или каталога. \autocite{DatabaseSharding} -Недостатком этого метода является эластичная балансировка нагрузки, что означает, если вы попытаетесь динамически -добавлять или удалять серверы баз данных, это будет сложный и дорогостоящий процесс. Например, в приведенном выше -примере, если вы добавите еще 5 серверов, вам нужно добавить больше соответствующих хэш-значений для дополнительных -записей. Кроме того, большинство существующих ключей необходимо переназначить на их новое, правильное хэш-значение, -а затем перенести на новый сервер. Хэш-функция должна быть изменена с модуля 3 на модуль 8. В то время как миграция -данных действует, как новые, так и старые хэш-функции не будут действительны. Во время миграции ваше приложение не -сможет обслуживать большое количество запросов, и вы будете испытывать простои для своего приложения до завершения -миграции. \autocite{DatabaseSharding} +\paragraph{Шардинг на основе каталогов} ~\\ +Чтобы реализовать шардинг на основе каталогов, необходимо создать и поддерживать таблица поиска, которая использует ключ +фрагмента, чтобы отслеживать, какой фрагмент содержит какие данные. В двух словах, таблица поиска - это таблица, которая +содержит статический набор информации о том, где можно найти конкретные данные. Следующая диаграмма показывает +упрощенный пример шардинга на основе каталогов: + +\begin{figure}[H] + \centering + \includegraphics[width=100mm]{assets/distributed/Directory-Based-Sharding} + \caption{Шардинг на основе каталогов} + \label{fig:Directory-Based-Sharding} +\end{figure} + +В этом методе мы создаем и поддерживаем службу поиска или таблицу поиска для исходной базы данных. В основном мы +используем ключ фрагмента для таблицы поиска и делаем сопоставление для каждого объекта, существующего в базе данных. +Таким образом, мы отслеживаем, какие фрагменты базы данных содержат какие данные. + +Таблица поиска содержит статический набор информации о том, где можно найти конкретные данные. На приведенном выше +изображении вы можете видеть, что мы использовали зону доставки в качестве ключа фрагмента. Во-первых, клиентское +приложение запрашивает службу поиска, чтобы узнать фрагмент (раздел базы данных), на котором размещены данные. Когда +служба поиска возвращает фрагмент, она запрашивает/обновляет этот фрагмент. + +Здесь столбец Delivery Zone определяется как ключ фрагмента. Данные от ключа фрагмента записываются в таблицу поиска +вместе с любым фрагментом, в который должна быть записана каждая соответствующая строка. Это похоже на сегментирование +на основе диапазона (вертикальное шадирование), но вместо определения того, в какой диапазон попадают данные ключа +сегмента, каждый ключ привязывается к своему определенному фрагменту. Разделение на основе каталогов является хорошим +выбором по сравнению с разделением на основе диапазона в случаях, когда ключ сегмента имеет низкую мощность, и для +фрагмента не имеет смысла хранить диапазон ключей. Обратите внимание, что он также отличается от шардинга на основе +ключей тем, что он не обрабатывает ключ фрагмента с помощью хэш-функции; он просто проверяет ключ по таблице +соответствия, чтобы увидеть, куда должны быть записаны данные. + +Основная привлекательность шардинга на основе каталогов - это его гибкость. Шардирование на основе диапазонов +ограничивают вас указанием диапазонов значений, тогда как архитектуры на основе ключей ограничивают вас использованием +фиксированной хеш-функции, которую, как упоминалось ранее, впоследствии может быть чрезвычайно трудно изменить. +Разделение на основе каталогов, с другой стороны, позволяет вам использовать любую систему или алгоритм, который вы +хотите назначить для ввода данных в фрагменты, и сравнительно легко динамически добавлять фрагменты с помощью этого +подхода. + +В то время как разделение на основе каталогов является наиболее гибким из рассмотренных здесь методов разделения, +необходимость подключения к таблице соответствия перед каждым запросом или записью может отрицательно сказаться на +производительности приложения. Кроме того, таблица поиска может стать единой точкой отказа: если она повреждена или +иным образом выходит из строя, это может повлиять на способность записывать новые данные или получать доступ к их +существующим данным.\autocite{DatabaseSharding} \paragraph{Географический шардинг} ~\\ -Шардирование по географическому признаку позволяет хранить определенные данные вблизи своих потребителей и +В принципе, можно остановиться на том, что было описано выше про шардинг, но лучше в явном виде написать про еще один +вид горизонтального шардинга - шардинг по географическому признаку, который позволяет хранить определенные данные вблизи своих потребителей и удовлетворять нормативным требованиям, когда данные должны находиться в определенной юрисдикции. Однако данный способ -шардирования не является самодостаточным: шарды могут быть загружены не равномерно, и отличие может быть на порядки. +шардирования не является самодостаточным: фрагменты могут быть загружены не равномерно, и отличие может быть на порядки. На пример, экземпляр базы данных, хранящий данные пользователей Москвы и Московской области, будет намного превышать другой экземпляр базы данных, который хранит информацию о пользователях из Владимира. Таким образом, недостатком данного метода является необходимость дополнительного использования других методов шардирования. @@ -770,7 +809,7 @@ \subsection{Тиражирование данных} При блочной репликации каждая операция записи выполняется не только на основном диске, но и на резервном. Таким образом тому на одном массиве соответствует зеркальный том на другом массиве, с точностью до байта повторяющий основной том. -К достоинствам такой репликации можно отнести простоту настройки и надёжность. Записывать данные на удалённый диск может +К достоинствам такой репликации можно отнести простоту настройки и надежность. Записывать данные на удалённый диск может либо дисковый массив, либо нечто (устройство или программное обеспечение), стоящее между хостом и диском. Если дисковый массив не способен реплицировать данные, между хостом и массивом может быть установлен агент, осуществляющей запись на два массива сразу. Агент может быть как отдельным устройством, так и программным компонентом. В отличие от дискового diff --git a/part/statistical.tex b/part/statistical.tex index d3f185a..c836d62 100644 --- a/part/statistical.tex +++ b/part/statistical.tex @@ -1,6 +1,6 @@ \section{Безопасность в статистических БД} -Инфы про статистические базы данных на русском языке мало и большая часть бредовая. Гуглите statistical database. Все источники будут на английском, переведено специально для вас. Источников несколько \cite{ComputerSecurity2008} \cite{IntroBD2014}, под конец была найдена статья, \cite{SDB1989} в которой есть вся собранная инфа, еще есть более свежий источник \citep{SDB1999}. +Инфы про статистические базы данных на русском языке мало и большая часть бредовая. Гуглите statistical database. Все источники будут на английском, переведено специально для вас. Источников несколько \cite{ComputerSecurity2008} \cite{IntroBD2014}, под конец была найдена статья, \cite{SDB1989} в которой есть вся собранная инфа, еще есть более свежий источник \cite{SDB1999}. \subsection{Общие сведения} Определение статистической БД. Классификация статистических БД. Характеристики статистических БД.