ОЛАП

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

Системы поддержки принятия решений

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

Двумя распространенными схемами OLAP являются схема «звезда» и схема «снежинка», обе из которых основаны на логической структуре модели измерений и используются для описания взаимосвязи между таблицей фактов и таблицей измерений. Таблицы фактов — это таблицы, в которых хранятся измерения (например, продажи, прибыль и т. д.), а таблицы измерений — это таблицы, в которых хранится описательная информация (например, продукты, клиенты, время и т. д.).

Схема звезды: схема звезды — это простейшая схема хранилища данных. Ее структура похожа на звезду, с таблицей фактов в центре и несколькими таблицами измерений вокруг нее. Связь между таблицей фактов и таблицей измерений устанавливается через внешние ключи, и каждая таблица измерений имеет только один уровень, то есть существует только одна таблица для представления измерения. Преимущество звездообразной схемы — высокая производительность запросов, поскольку требуется лишь небольшое количество операций соединения; недостаток — высокая избыточность данных, поскольку каждая таблица измерений содержит все значения атрибутов.
Схема снежинки: схема снежинки является расширением схемы звезды. Ее структура похожа на снежинку. Центр также представляет собой таблицу фактов, окруженную несколькими таблицами измерений, но каждая таблица измерений может быть дополнительно разложена на таблицы подизмерений для формирования нескольких уровней. . Схема «снежинка» нормализует таблицу измерений, чтобы уменьшить избыточность данных и объем памяти; недостатком является низкая производительность запросов, поскольку требуется больше операций подключения.

Подводя итог, основные различия между схемой звезды и схемой снежинки заключаются в следующем:

Структура схемы «звезда» имеет звездообразную форму, а структура схемы «снежинка» — снежинчатую.
Схема «звезда» имеет только одну таблицу для каждого измерения, а схема «снежинка» может иметь несколько подтаблиц для каждого измерения.
Схема «звезда» — это метод проектирования сверху вниз, а схема «снежинка» — метод проектирования снизу вверх.
Схема «звезда» занимает больше места для хранения, а схема «снежинка» — меньше места.
Схема «звезда» не нормализует таблицу измерений, а схема «снежинка» нормализует таблицу измерений.
Производительность запроса схемы «звезда» высока, поскольку выполняется меньше операций подключения; производительность запроса схемы «снежинка» низкая, поскольку операций подключения много.
Сложность запроса схемы «звезда» низкая и ее легко понять; сложность запроса схемы «снежинка» высока и трудна для понимания.

Запуск схемы VS Snowflake,
проблема 1: нормализация

Режим «Снежинка» занимает меньше места.
Нестандартизированные модели данных могут привести к конфликтам целостности и согласованности.

Проблема 2. Сложность запроса.

Схемы «снежинка» требуют большего количества соединений для получения данных, необходимых для запроса.
Запросы по звездообразным схемам (обычно) выполняются быстрее.

Модели исполнения

Толкать против тянуть

Способ 1: отправить запрос к данным

Отправьте запрос (или его часть) узлам, содержащим данные.
Выполняйте как можно большую фильтрацию и обработку там, где находятся данные, прежде чем они будут переданы по сети.

Способ 2: извлечение данных для запроса

Передача данных узлам, выполняющим запросы, требующие их обработки.

В OLAP существует два метода модели запросов: Push Query to Data и Pull Data to Query, которые относятся к двум стратегиям выполнения запросов и обработки данных на разных узлах в системе распределенной базы данных. Проще говоря, это отправка запроса туда, где находятся данные, или отправка данных туда, где находится запрос.

Метод Push Query to Data заключается в отправке запроса (или его части) на узел, содержащий данные. Это снижает накладные расходы на сетевую передачу, поскольку там, где находятся данные, может выполняться максимально возможная фильтрация и обработка, и возвращаются только необходимые результаты. Этот подход подходит для архитектуры Shared Nothing (Shared Nothing), то есть каждый узел имеет свой собственный ЦП, память, локально подключенный диск, а база данных разделена на несвязанные подмножества между узлами. Например, Snowflake, Doris, ClickHouse и т. д. используют этот подход¹²³.

Предположим, у нас есть распределенная система баз данных с четырьмя узлами, и каждый узел хранит отдельный раздел данных. Мы хотим выполнить запрос, который вычисляет средний возраст для каждой страны. Мы можем разбить этот запрос на два этапа: первый этап — агрегировать локальные данные на каждом узле и вычислить сумму количества людей и возрастов для каждой страны; второй этап — отправить результаты первого этапа в Координирующий узел. На узле выполняется окончательное агрегирование для всех стран и рассчитывается средний возраст каждой страны. Таким образом, мы избегаем отправки координатору всех данных, а только некоторых промежуточных результатов.

Метод извлечения данных для запроса заключается в передаче данных на узел, выполняющий запрос, которому нужны данные для обработки. Это позволяет использовать больше вычислительных ресурсов, поскольку запросы могут выполняться на любом узле. Этот метод подходит для архитектуры общего диска (Shared Disk), то есть каждый узел получает доступ к логическому диску через соединение, но также имеет собственную частную память и кратковременное хранилище. Например, такой подход взяли на вооружение Oracle Exadata, Amazon Redshift и т. д.

Предположим, у нас есть система базы данных на общем диске с четырьмя узлами, каждый из которых имеет доступ к одному и тому же логическому диску. Мы хотим выполнить запрос, который вычисляет средний возраст для каждой страны. Мы можем назначить этот запрос для выполнения любому узлу. Узлу необходимо прочитать все данные с диска и агрегировать их в локальной памяти. Этот процесс может быть медленнее, если данные на диске не кэшируются в памяти. Но если данные на диске уже были кэшированы другими узлами, то этот процесс будет быстрее. Таким образом, мы можем воспользоваться эффектами кэширования для повышения производительности запросов.

Оба метода имеют свои преимущества и недостатки, и какой из них выбрать, следует рассматривать комплексно, исходя из таких факторов, как объем данных, пропускная способность сети, вычислительная мощность и сложность запросов. Вообще говоря, если объем данных велик, пропускная способность сети мала, вычислительная мощность велика, а сложность запроса высока, то метод Push Query to Data более подходит; если объем данных небольшой, Пропускная способность сети велика, а вычислительная мощность относительно высока.Слабая и низкая сложность запроса, тогда более подходящим является метод извлечения данных для запроса.

Данные, полученные узлами из удаленных источников, кэшируются в буферных пулах.

Это позволяет СУБД поддерживать промежуточные результаты, превышающие объем доступной памяти.
Временные страницы не сохраняются после перезапуска

Что произойдет с длительно выполняющимися запросами OLAP, если узел выйдет из строя во время выполнения?

Отказоустойчивость запросов

Большинство распределенных СУБД OLAP без совместного использования ресурсов разработаны с учетом того, что узлы не выходят из строя во время выполнения запроса.
Если один узел выйдет из строя во время выполнения запроса, весь запрос завершится неудачно.

СУБД может делать снимки промежуточных результатов запроса во время выполнения, чтобы запрос можно было возобновить в случае сбоя узла.

Планирование запросов

Все оптимизации, которые мы обсуждали ранее, по-прежнему применимы к распределенным средам.

предикат
Преждевременное предсказание
Оптимизация порядка соединений

Фрагменты плана запроса

Метод 1: Физические операторы

Создает единый план запроса, который затем разбивается на части, относящиеся к конкретному разделу.

Способ 2: SQL

Перепишите исходный запрос как запрос для конкретного раздела.
Позволяет локальную оптимизацию на каждом узле.

Физические операторы и SQL относятся к двум стратегиям разложения плана запроса на несколько подзапросов в системе распределенной базы данных, а затем их выполнения и объединения на разных узлах. Проще говоря, это преобразовать план запроса в физические операторы или операторы SQL, а затем отправить их на соответствующие узлы в соответствии с разделом данных.

Метод физических операторов заключается в том, чтобы выразить план запроса в виде серии физических операторов, таких как сканирование, выбор, проекция, объединение, агрегирование и т. д. Затем по способу разделения данных эти операторы разбиваются на разные фрагменты (Fragment), и каждый фрагмент соответствует одному или нескольким операторам. Каждый фрагмент имеет входные и выходные данные. Входные данные могут быть разделом данных или выходными данными другого фрагмента, а выходные данные могут быть набором результатов или входными данными другого фрагмента. Таким образом, план запроса можно разделить на несколько параллельных или последовательных подзапросов, каждый из которых выполняется на узле. Преимущество этого метода заключается в том, что для повышения производительности запросов можно использовать методы оптимизации физических операторов, такие как выборочное распространение, конвейерная обработка, векторизация и т. д. Недостатком этого подхода является то, что он требует сложного разделения и планирования физических операторов, а также работы с зависимостями данных и накладными расходами на связь.

Метод SQL заключается в переписывании плана запроса на несколько операторов SQL, и каждый оператор SQL соответствует разделу данных или промежуточному результату. Затем, в зависимости от местоположения раздела данных, эти операторы SQL отправляются на соответствующие узлы для выполнения. После выполнения инструкции SQL на каждом узле будет возвращен набор результатов или промежуточный набор результатов. Наконец, объедините все наборы результатов или промежуточные наборы результатов в окончательный набор результатов. Преимущество этого подхода заключается в том, что он позволяет использовать преимущества гибкости и выразительности языка SQL, а также выполнять локальную оптимизацию на каждом узле. Недостатком этого подхода является то, что он требует сложного переписывания и преобразования операторов SQL, а также решения проблем согласованности и избыточности данных.

Алгоритмы распределенного соединения

Чтобы объединить таблицы R и S, СУБД необходимо получить правильные кортежи на одном узле.

Как только данные поступают на узлы, СУБД выполняет тот же алгоритм соединения, который мы использовали в предыдущих разделах.

Алгоритмы распределенного соединения в распределенной OLAP относятся к некоторым алгоритмам эффективного выполнения операций соединения между двумя или более распределенными таблицами в системе распределенной базы данных. Операция соединения — это общий запрос OLAP, который объединяет данные из разных таблиц на основе одного или нескольких общих атрибутов. Например, в соответствии с идентификатором клиента таблица заказов и таблица клиентов могут быть связаны для получения информации о клиенте, соответствующей каждому заказу.

В системе распределенных баз данных данные обычно делятся на несколько разделов (Partition) и хранятся на разных узлах. Это улучшает масштабируемость данных и отказоустойчивость, но также создает проблемы для операций объединения. Потому что две или более таблицы, участвующие в операции соединения, могут быть распределены по разным узлам, и на каждом узле может находиться только часть данных. Следовательно, для завершения операции соединения необходимо передавать и обрабатывать данные между узлами, что приведет к увеличению накладных расходов сети и вычислений.

Чтобы решить эту проблему, в распределенной OLAP предлагаются некоторые алгоритмы распределенного соединения, которые могут выбрать подходящий способ выполнения операций соединения в соответствии с различными сценариями и требованиями. В целом эти алгоритмы можно разделить на следующие категории:

Широковещательное соединение. Этот алгоритм заключается в полном копировании таблицы меньшего размера (обычно правой таблицы) в операции соединения на все узлы, а затем использовании алгоритма локального соединения (например, хеш-соединения или сортировки слиянием) на каждом узле) для завершения широковещательного соединения. операция подключения. Этот алгоритм подходит для случая, когда правая таблица маленькая, а левая таблица большая, поскольку позволяет избежать передачи данных левой таблицы. Но если правая таблица еще и очень большая, то этот алгоритм будет занимать много пропускной способности сети и места в памяти.
Случайное соединение. Этот алгоритм заключается в разделении двух таблиц (левой таблицы и правой таблицы) в операции соединения на несколько подмножеств в соответствии с ключом соединения (ключ соединения) и отправкой подмножества одного и того же значения ключа соединения в один и тот же узел. а затем используйте алгоритм локального подключения на каждом узле для завершения операции подключения. Этот алгоритм подходит для ситуации, когда две таблицы большие и значения ключей соединения распределены равномерно, поскольку он может сбалансировать нагрузку и сетевые издержки каждого узла. Но если распределение значений ключей подключения неравномерно, то этот алгоритм приведет к перекосу данных и неравномерной загрузке.
Colocate Join: этот алгоритм учитывает потребности операций соединения при разделении и хранении данных, так что две объединяемые таблицы разделяются на несколько подмножеств одинаковым образом и хранятся на одном узле. Таким образом, нет необходимости в передаче данных при выполнении операции подключения, и для завершения операции подключения на каждом узле необходимо использовать только локальный алгоритм подключения. Этот алгоритм подходит для ситуаций, когда часто требуются операции подключения и значение ключа подключения может быть известно заранее, поскольку он может минимизировать сетевые и вычислительные издержки. Но если вам нужно выполнить несколько операций подключения разными способами или если вы не можете заранее узнать значение ключа подключения, то этот алгоритм не сработает или будет неэффективен.

Четыре сценария в деталях

Сценарий 1: Каждый узел реплицирует таблицу. Каждый узел параллельно объединяет свои локальные данные, а затем отправляет результаты на координирующий узел.

Алгоритм, соответствующий этому сценарию, — широковещательное соединение, то есть меньшая таблица (обычно правая таблица) в операции соединения полностью копируется во все узлы, а затем используется локальный алгоритм соединения (например, хэш-соединение или сортировка слиянием соединения) для завершить операцию соединения. Этот алгоритм подходит для случая, когда правая таблица маленькая, а левая таблица большая, поскольку позволяет избежать передачи данных левой таблицы. Но если правая таблица еще и очень большая, то этот алгоритм будет занимать много пропускной способности сети и места в памяти.

Например, предположим, что у нас есть распределенная система баз данных с четырьмя узлами, каждый из которых хранит отдельный раздел данных. Мы хотим выполнить запрос, который соединяет таблицу «Заказ» (Заказ) с таблицей «Клиент» (Клиент) на основе идентификатора клиента (CustomerID). Предположим, что таблица заказов большая, а таблица клиентов маленькая. Для выполнения этого запроса мы можем использовать алгоритм широковещательного соединения. Конкретные шаги следующие:

Шаг 1. Полностью скопируйте таблицу клиентов на все узлы.
Шаг 2. Используйте локальный алгоритм соединения (например, хэш-соединение или сортировку слиянием) на каждом узле, чтобы соединить таблицу заказов и таблицу клиентов, и подключайтесь в соответствии с идентификатором клиента.
Шаг 3: Отправьте результаты подключения на каждом узле на координирующий узел для окончательного объединения и вывода.
Таким образом, мы можем выполнить этот запрос и получить информацию о клиенте, соответствующую каждому заказу.

Сценарий 2: Таблица секционирована по атрибуту соединения. Каждый узел выполняет объединение локальных данных, которые затем отправляются на координирующий узел для объединения.

Алгоритм, соответствующий этому сценарию, — Colocate Join, который учитывает требования операции соединения при разделении и хранении данных, так что две соединяемые таблицы разделяются на несколько подмножеств одинаковым образом и хранятся на одном узле. Таким образом, нет необходимости в передаче данных при выполнении операции подключения, и для завершения операции подключения на каждом узле необходимо использовать только локальный алгоритм подключения. Этот алгоритм подходит для ситуаций, когда часто требуются операции подключения и значение ключа подключения может быть известно заранее, поскольку он может минимизировать сетевые и вычислительные издержки. Но если вам нужно выполнить несколько операций подключения разными способами или если вы не можете заранее узнать значение ключа подключения, то этот алгоритм не сработает или будет неэффективен.

Например, предположим, что у нас есть распределенная система баз данных с четырьмя узлами, каждый из которых хранит отдельный раздел данных. Мы хотим выполнить запрос, который соединяет таблицу «Заказ» (Заказ) с таблицей «Клиент» (Клиент) на основе идентификатора клиента (CustomerID). Предположим, что и таблица заказов, и таблица клиентов разделены в соответствии с идентификатором клиента, а данные с одним и тем же значением идентификатора клиента хранятся на одном и том же узле. Для выполнения этого запроса мы можем использовать алгоритм Colocate Join, конкретные шаги следующие:

Шаг 1. Используйте локальный алгоритм подключения (например, хэш-соединение или сортировку слиянием) на каждом узле, чтобы соединить таблицу заказов и таблицу клиентов, и подключайтесь в соответствии с идентификатором клиента.
Шаг 2. Отправьте результаты подключения на каждом узле на координирующий узел для окончательного объединения и вывода.
Таким образом, мы можем выполнить этот запрос и получить информацию о клиенте, соответствующую каждому заказу.

Сценарий 3: Обе таблицы секционированы по разным ключам. Если одна из таблиц мала, СУБД «транслирует» таблицу всем узлам.

Алгоритм, соответствующий этому сценарию, представляет собой вариант Broadcast Join, то есть при секционировании двух таблиц по разным ключам, если одна из таблиц мала, СУБД «транслирует» таблицу всем узлам, а затем объединяет каждую из них. Алгоритм подключения используется на каждом узле для завершения операции подключения. Этот алгоритм подходит для случая, когда правая таблица маленькая, а левая таблица большая, поскольку позволяет избежать передачи данных левой таблицы. Но если правая таблица еще и очень большая, то этот алгоритм будет занимать много пропускной способности сети и места в памяти.

Например, предположим, что у нас есть распределенная система баз данных с четырьмя узлами, каждый из которых хранит отдельный раздел данных. Мы хотим выполнить запрос, который соединяет таблицу «Заказ» (Заказ) с таблицей «Клиент» (Клиент) на основе идентификатора клиента (CustomerID). Предположим, таблица заказов разделена по идентификатору заказа (OrderID), а таблица клиентов — по имени клиента (CustomerName). Предположим, что таблица заказов большая, а таблица клиентов маленькая. Для выполнения этого запроса мы можем использовать вариант алгоритма Broadcast Join, конкретные шаги следующие:

Сценарий 4: Ни одна таблица не секционирована по ключу соединения. СУБД реплицируют таблицы, «перетасовывая» их по узлам.

Алгоритм, соответствующий этому сценарию, — это случайное соединение, которое делит две таблицы (левую таблицу и правую таблицу) в операции соединения на несколько подмножеств в соответствии с ключом соединения (Join Key) и отправляет подмножество одного и того же значения ключа соединения в том же узле, а затем используйте алгоритм локального подключения на каждом узле для завершения операции подключения. Этот алгоритм подходит для ситуации, когда две таблицы большие и значения ключей соединения распределены равномерно, поскольку он может сбалансировать нагрузку и сетевые издержки каждого узла. Но если распределение значений ключей подключения неравномерно, то этот алгоритм приведет к перекосу данных и неравномерной загрузке.

Например, предположим, что у нас есть распределенная система баз данных с четырьмя узлами, каждый из которых хранит отдельный раздел данных. Мы хотим выполнить запрос, который соединяет таблицу «Заказ» (Заказ) с таблицей «Клиент» (Клиент) на основе идентификатора клиента (CustomerID). Предположим, что ни таблица заказов, ни таблица клиентов не секционированы по идентификатору клиента. Для выполнения этого запроса мы можем использовать алгоритм Shuffle Join.Конкретные шаги следующие:

Шаг 1. Разделите таблицу заказов и таблицу клиентов на несколько подмножеств в соответствии с идентификатором клиента и отправьте подмножества с одинаковым значением идентификатора клиента на один и тот же узел.
Шаг 2. Используйте локальный алгоритм соединения (например, хэш-соединение или сортировку слиянием) на каждом узле, чтобы соединить таблицу заказов и таблицу клиентов, и подключайтесь в соответствии с идентификатором клиента.
Шаг 3: Отправьте результаты подключения на каждом узле на координирующий узел для окончательного объединения и вывода.
Таким образом, мы можем выполнить этот запрос и получить информацию о клиенте, соответствующую каждому заказу.

Полусоединение

Алгоритм Semi-Join — это метод выполнения операций соединения в системе распределенной базы данных. Он может фильтровать данные в другой таблице на основе данных в одной таблице без фактического соединения двух таблиц. Результат алгоритма Semi-Join содержит данные только из левой или правой таблицы, но не данные из другой таблицы.

Функции и сценарии использования алгоритма Semi-Join следующие:

Алгоритм Semi-Join может повысить производительность запросов, поскольку ему не требуется полностью соединять две таблицы или возвращать избыточные данные. Ему просто нужно проверить, есть ли совпадающая запись в обеих таблицах, и вернуть запись из одной из таблиц.
Алгоритм Semi-Join может реализовать функцию подзапроса (Subquery), то есть фильтровать данные в другой таблице по данным в одной таблице. Например, если бы мы хотели найти всех клиентов с заказами, мы могли бы использовать подзапрос:

SELECT * FROM Customer WHERE CustomerID IN (SELECT CustomerID FROM Order);

Или используйте левое полусоединение:

ВЫБРАТЬ * ИЗ Клиента ЛЕВОЕ ПОЛУСОЕДИНЕНИЕ Заказ НА Customer.CustomerID = Order.CustomerID;

Оба эти метода могут дать один и тот же результат, но использование левого полусоединения может быть более эффективным, поскольку позволяет избежать временной таблицы, созданной подзапросом.

Алгоритм Semi-Join может реализовать функцию исключения, то есть исключать данные в другой таблице на основе данных в одной таблице. Например, если мы хотим запросить всех клиентов, у которых нет заказов, мы можем использовать обратный подзапрос (NOT IN):

SELECT * FROM Customer WHERE CustomerID NOT IN (ВЫБРАТЬ CustomerID FROM Order);

Или используйте правое полусоединение:

ВЫБЕРИТЕ * ИЗ ПРАВА клиента ПОЛУСОЕДИНЕНИЕ Заказ НА Customer.CustomerID = Order.CustomerID;

Оба эти метода могут дать один и тот же результат, но использование правого полусоединения может быть более эффективным, поскольку позволяет избежать временной таблицы, созданной обратным подзапросом.

Процесс выполнения алгоритма Semi-Join можно разделить на следующие этапы:

Шаг 1: Рассчитайте проекцию левой таблицы на ключ соединения на узле, где расположена левая таблица, и отправьте ее в узел, где расположена правая таблица.
Шаг 2: На узле, где расположена правая таблица, выполняется операция полуобъединения согласно полученной проекции левой таблицы и правой таблицы, и результат отправляется обратно в узел, где расположена левая таблица.
Шаг 3: На узле, где расположена левая таблица, выполните окончательную операцию соединения согласно полученному результату правой таблицы и левой таблицы и выведите результат.

Например, предположим, что у нас есть распределенная система баз данных с четырьмя узлами, каждый из которых хранит отдельный раздел данных. Мы хотим выполнить запрос, который соединяет таблицу «Заказ» (Заказ) с таблицей «Клиент» (Клиент) на основе идентификатора клиента (CustomerID). Предположим, таблица заказов хранится на узле 1, а таблица клиентов — на узле 2. Для выполнения этого запроса мы можем использовать алгоритм Semi-Join, конкретные шаги следующие:

Шаг 1: Рассчитайте проекцию таблицы заказов на идентификатор клиента на узле 1, то есть Order.CustomerID, и отправьте ее на узел 2.
Шаг 2. Выполните операцию полуобъединения на узле 2 на основе полученного Order.CustomerID и таблицы клиентов, то есть Customer LEFT SEMI JOIN Order.CustomerID, и отправьте результат обратно на узел 1.
Шаг 3: Выполните окончательную операцию подключения на узле 1 в соответствии с полученным результатом Customer и таблицей заказов, то есть Order JOIN Customer, и выведите результат.

Таким образом, мы можем выполнить этот запрос и получить информацию о клиенте, соответствующую каждому заказу.

Облачная система

Поставщики предлагают предложения «база данных как услуга» (DBaaS) в виде размещенных сред СУБД.

Подход 1. Управляемая СУБД. Поставщики предлагают предложения «База данных как услуга» (DBaaS) в качестве управляемой среды СУБД. (Наиболее используемый метод)
Способ 2. Облачная СУБД: система специально разработана для работы в облачной среде; обычно на основе архитектуры общего диска.

Бессерверные базы данных

«Бессерверная» СУБД не всегда поддерживает вычислительные ресурсы для каждого клиента, а вместо этого вытесняет арендаторов, когда они простаивают.

Бессерверные базы данных — это облачная служба баз данных, которая может автоматически распределять и настраивать вычислительные ресурсы и ресурсы хранения в соответствии с потребностями пользователя. Пользователям не нужно заботиться о настройке и расширении базы данных, а также им не нужно заранее вносить фиксированную плату, а нужно платить только в соответствии с фактически используемыми ресурсами. Бессерверные базы данных могут повысить эффективность и экономичность разработки пользователей, а также повысить производительность и надежность баз данных.

«Бессерверная» СУБД бессерверных баз данных означает, что система управления базами данных (СУБД) не резервирует постоянно вычислительные ресурсы для каждого клиента или арендатора (арендатора), а удаляет арендаторов (выселение), когда они простаивают или испытывают низкую нагрузку, тем самым освобождая ресурсы. для использования другими арендаторами. Таким образом, СУБД может динамически распределять ресурсы в зависимости от активности арендаторов, избегая растраты ресурсов и простоя. Когда арендатор снова инициирует запрос, СУБД перераспределит ресурсы арендатору и восстановит его состояние и данные. Этот процесс обычно прозрачен для пользователя, и пользователю не нужно заботиться о распределении и переработке ресурсов.

«Бессерверная» СУБД бессерверных баз данных имеет ряд преимуществ:

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

Конечно, «бессерверная» СУБД бессерверных баз данных также имеет некоторые проблемы и ограничения, такие как:

Это может увеличить время ответа пользователя, поскольку, когда арендатора выселяют и он снова инициирует запрос, необходимо перераспределить ресурсы и восстановить состояние и данные, что может вызвать определенную задержку.
Это может повлиять на согласованность данных пользователя, поскольку, когда арендатор вытесняется и снова делает запрос, он может столкнуться с проблемами синхронизации данных или недействительности кэша.
Это может ограничить функциональность и контроль пользователя, поскольку пользователь не может самостоятельно настраивать и управлять параметрами и настройками базы данных, а также не может самостоятельно выбирать версию и тип базы данных.

Озера данных

Облачная система баз данных Data Lakes — это сервис для создания озер данных и управления ими на облачной платформе. Озеро данных — это централизованное хранилище, в котором могут храниться данные любого типа и размера, как структурированные, так и неструктурированные. Озера данных могут поддерживать различные методы анализа, такие как SQL-запросы, обработка больших данных, машинное обучение, анализ в реальном времени и т. д., тем самым помогая пользователям получать больше пользы и информации из данных.

Облачная система баз данных Data Lakes имеет следующие преимущества:

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

Распределенная база данных OLAP