|
За работу ЛИНТЕР в сетевых условиях отвечают две компоненты:
- сетевой драйвер клиента,
- сетевой драйвер сервера .
Кроме того, сетевые компоненты обладают чрезвычайно скромными требованиями к вычислительным ресурсам. Например, драйверу сервера необходим ~ 1Kb на каждое соединение.
Основа работы в сети – файл nodetab. В этом файле должны присутствовать все необходимые ЛИНТЕР-серверы: их логические имена, адреса, протоколы, операционные системы и т.п.
Режим «клиент-сервер»
Если приложениям не требуется обращаться за данными к двум серверам одновременно (когда все они работают только с одним сервером), то такой режим работы называется «клиент-сервер».
Для этого режима можно не указывать, на какой именно сервер (из тех, что в наличии) обращается приложение. Драйвер клиента можно настроить на работу с этим сервером, как с сервером по умолчанию.
В этом режиме драйвер клиента исполняет для приложения роль СУБД. Поэтому приложение можно вообще отлаживать в локальном режиме (на одной машине, без использования сети), и уже потом без изменений использовать его в сетевом режиме «клиент-сервер».
Режим «мультисервер»
Если приложению необходимо использовать несколько серверов баз данных (например, для перекачки информации с одного сервера на другой), то ему придётся явно указывать, к какому из них он обращается в каждый конкретный момент.
При этом используются логические имена серверов (описанных в файле nodetab). Эти имена передаются вместе с запросом и необходимы драйверу клиента для точной адресации при посылке запроса к нужному серверу.
Такой режим работы в документации по системе ЛИНТЕР называется «мультисервер». Отличие его от распределённости в том, что базы данных, расположенные на различных серверах, не составляют единого целого, таблицы различных серверов не могут участвовать в одном запросе, а также в том, что приложению необходимо явно указывать те серверы, к которым оно обращается.
Отлаживать такое приложение можно только в режиме «мультисервер».
Распределенная база данных
Концепция распределённости СУБД ЛИНТЕР позволяет прозрачно обрабатывать запросы к данным, находящимся в различных базах данных вне зависимости от их физического расположения. Это позволяет базам данных функционировать независимо друг от друга. Кроме того, эта концепция обеспечивает равноправный доступ пользователей к разным базам данных, расположенным в различных узлах вычислительной сети.
Основным понятием концепции является сетевое или логическое ЛИНТЕР-имя, которое представляет собой восьмисимвольное имя, прописанное в специальном файле ЛИНТЕР-имён – nodetab. В этом файле сетевые ЛИНТЕР-имена связаны с сетевыми параметрами узла запуска ядра ЛИНТЕР.
Кроме того, сетевое ЛИНТЕР-имя однозначно определяет в текущей операционной среде базу данных, для которой будет запущено независимое ядро СУБД ЛИНТЕР. Части выполняемого запроса, которые необходимо выполнить именно в данной базе будут переправляться по указанному в nodetab адресу с использованием ЛИНТЕР-имени.
Список баз данных (ЛИНТЕР-имён), которые могут участвовать в процессе выполнения распределённых запросов, содержится в специальной системной таблице – SERVERS. Эта таблица входит в системный словарь базы данных и подчиняется стандартным правилам работы со словарями, принятым в СУБД ЛИНТЕР.
В SERVERS хранится имя, по которому работает СУБД внутри и которое будет передано вовне для определения, на какой из удалённых серверов нужно пересылать запрос за недостающими данными.
В SERVERS не хранится связь имени с сетевой конфигурацией. Таким образом, при изменениях в сетевой конфигурации (через файл nodetab) трансляция имен внутри базы данных останется неизменной.
Создание/удаление узла распределённой базы данных производится специальным SQL-запросом CREATE/DROP NODE.
Теперь о технологии распределённости в СУБД ЛИНТЕР.
Главная компонента аппарата распределённости – loltp – процесс, который работает с удаленным сервером. Он принимает запрос от локального ядра во внутреннем формате и формирует из него SQL-запрос к удалённому серверу. Соответственно, при этом используется сетевой клиентский драйвер.
Другая модификация системы позволяет создавать многомашинные СУБД-комплексы на основе асинхронной репликации.
Такие системы используются чаще всего в WEB-приложениях, где запросы на поиск гораздо более часты, нежели запросы на модификацию (поисковые системы, интернет-магазины и т.п.). В таких приложениях можно достичь практически пропорционального масштабирования при увеличении числа машин в комплексе, например, при двукратном увеличении числа ЭВМ, мы получим практически двукратное увеличение скорости обработки общего потока запросов.
|
