Основные концепции ядра хранилища Spider

Типичная установка Spider имеет архитектуру кластера с разделенными ресурсами. Система работает с любым недорогим оборудованием и имеет минимальные требования к аппаратному или программному обеспечению. Она состоит из набора компьютеров, на каждом из которых работают один или несколько процессов MariaDB, известных как узлы.

Узлы, хранящие данные, будут спроектированы как Backend Nodes, и могут быть любыми экземплярами MariaDB, MySQL или Oracle, использующими любой движок хранилища, доступный в бэкэнде.

Spider Proxy Nodes — это экземпляры, работающие как минимум на MariaDB 10. Spider Proxy Nodes используются для объявления привязки каждой таблицы к узлам бэкэнда. Кроме того, Spider Proxy Nodes может быть настроено, чтобы разрешить разделение и дублирование таблиц на нескольких Backend Nodes.

Общее использование Spider

В стандартной настройке высокой доступности узлы Spider генерируют ошибки SQL, когда сервер бэкэнда не отвечает. Мониторинг по таблицам может быть настроен для обеспечения доступности в случае неоткликающихся бэкэндов monotoring_bg_kind=1 или monotoring_bg_kind=2. Мониторинговые узлы Spider будут взаимосвязаны с использованием системной таблицы mysql.link_mon_servers для управления разделением сети. Более известное как проблема «разделенного мозга», должно быть настроено чётное число Spider Monitor Nodes для достижения консенсуса на основе большинства. Либо один отдельный общий Monitoring Node экземпляр, либо как минимум 3 Spider Nodes. Более подробную информацию можно найти здесь.

Федерация хранилища Spider

Spider — это подключаемый движок хранилища, работающий как прокси между оптимизатором и удалёнными бэкендами. Когда оптимизатор запрашивает несколько вызовов движка хранилища, Spider обеспечивает согласованность, используя протокол двухфазной фиксации для бэкэндов и создавая транзакции на бэкендах для сохранения атомарных операций для одного выполнения SQL. Сохранение атомарных операций во время выполнения используется на нескольких уровнях архитектуры. Для обычного плана оптимизатора это относится к multiple split reads, а для одновременных сканирований разделов — к semi transactions.

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

Модель потоков Spider

Spider использует модель по разделам и по таблицам для одновременного доступа к удалённым узлам бэкэнда. Для задач с высокой нагрузкой на память данное свойство может быть использовано для определения нескольких разделов на одном узле удалённого бэкэнда, чтобы лучше адаптировать одновременность к доступным ЦПУ в оборудовании.

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

Модель памяти Spider

Spider хранит наборы результатов в памяти, но spider_quick_mode=3 хранит наборы результатов во внутренних временных таблицах, если наборы результатов больше, чем quick_table_size.