SQL 2005: масштабируемость решений с помощью контентно-зависимой маршрутизации.
Начну сей творческий труд с пары оговорок:
1) Оригинальная тема, возможно, называется несколько иначе. Английское название технологии звучит так: Scaling out with Data Dependant routing. Термин “Scale Out” сам по себе является достаточно интересным событием: исходя из перевода, это должно означать что-то типа уменьшения масштаба. Ну, когда, все вещи становятся меньше, так сказать, видны с высоты птичьего полета. По сути, никто, конечно серверы уменьшать не будет. Касаемо Data Dependant Routing - возьму на себя смелость объявить это как «контентно- или контекстно-зависимой маршрутизацией». Потом объясню почему.
2) Пример архитектуры, который я собираюсь описать, вообще-то не зависит от версии SQL Server. SQL Server 2005 был разработан с учетом пожеланий клиентов в этом направлении. По сути, тех же самых результатов, но с большими затратами ресурсов можно было достигнуть и в более ранних версиях.
Итак, начнем-с.
Всякая компания рано или поздно мечтает стать большой, солидной организацией. Чтобы все с уважением относились к имени компании, чтобы клиентов было много. Отделы ИТ тоже мечтают, чтобы их компании росли. Только вот, сам по себе рост, с точки зрения ИТ подразделения, приносит и головную боль: растут базы клиентов-то! Растет, понимаешь, объем документов на серверах! Вводятся, всякие там, ERP, CRM и т.д.
На первых порах этот рост, достаточно успешно, можно контролировать покупкой новых, более мощных серверов. Затем, у всякого архитектора, либо же начальника ИТ подразделения возникает дилемма: с одной стороны – здоровенный парк еще пока актуального железа, с другой – можно купить ОДИН СУПЕР БОЛЬШОЙ и водрузить все на него. «Хорошо, а если и этот СУПЕР БОЛЬШОЙ вдруг упрется в пределы производительности, как я потом нашему директору (финансисту, хозяину компании, вице-президенту,_вставь свое название должности_) объясню, что давеча вот, потратили деньги – а нужно еще и больше?»- думает человек. В какой-то момент, стоимость лишнего гигагерца и мегабайта становятся просто-таки золотыми.
Итого, получаем практически всем известную картину: «Но вчера были раки!!! Но большие!! Но по пять.. А сегодня – маленькие.. Но по три». Что делать-то? Выбивать деньги или есть еще какие-то варианты? Есть. Этим вариантом, собственно и является scale out решение, построенное на том, что система будет иметь возможность «жить» не на одном БОЛЬШОМ сервере, а будет состоять из данных, распределенных грамотным образом по разным серверам плюс приложение, которое будет знать, как их собрать. Тем самым можно достигнуть теоретически неограниченной возможности роста приложения без грандиознейших затрат.
Контекстно-зависимая маршрутизация
Итак, вроде принято решение использовать scale-out решение, контекстно-зависимую маршрутизацию, что делать дальше? Дальше надо думать, как использование этого подхода отразится на работе приложения. То есть, что останется, а что придется переписывать, так как на приложение ложится задача знать, куда, на какой сервер отправить запрос. При контесктно-зависимой маршрутизации запроса не используются представления, объединяющие данные с нескольких серверов. Как раз наоборот, каждый сервер становится независимым ( за исключением одного сервера, который хранит схему. Приложение же должно хранить схему того, как данные разбиты и куда отправлять запросы.
Как следить за тем, где живут записи? Допустим, у нас есть приложение для дистрибьюторской компании, и база данных для этого приложения находится на той же машине, что и Web-приложение, через которое клиенты работают с нашей базой. Все данные разбиты на куски по клиентским ID, соответственно нужно создать таблицу соответствия ID номеру секции
Получится что-то типа:
|
Customer ID |
Partition ID |
|
10015 |
1 (Data 1) |
|
10016 |
2 (Data 2) |
|
10017 |
1 |
|
10018 |
3 (Data 3) |
Более наглядно схему работы решения можно представить следующим образом:
Где компьютер желтого цвета и есть то самое приложение среднего уровня, которое и хранит выше приведенную таблицу соответствий.
Что происходит дальше?
Клиентское приложение шлет запрос «покажите все транзакции клиента 10015», жёлтый сервер сам определяет , куда этот запрос отправить дальше, а именно – на сервер Data1.В данной ситуации нет абсолютно никакой необходимости привлекать серверы Data 2 и Data3.
Теперь мы решили провести инвентаризацию всех продуктов. Т.е надо построить отчет по всем Product ID. Данные у нас разбиты по Customer ID. Скорее всего , на каждом сервере найдутся записи с Product ID, соответственно и «допрашивать» придется всех. Что будет делать приложение? Правильно – опрашивать все серверы и строить общий отчет, на базе данных, что будут получен с каждого сервера. Выглядит, как очень трудоемкий процесс с подключением большого количества ресурсов. Так оно, собственно и есть, поэтому такого рода задачи необходимо запускать как «фоновые» и в то время, когда это наименьшим образом повлияет на клиентов или пользователей.
«Узкие места» или чем это все грозит?
Достоинство системы, построенной на базе контекстно-зависимой маршрутизации очевидно: при появлении новых пользователей, мы просто добавляем еще один сервер, потом еще и т.д. Не надо тратиться на дорогущий сервер с огромным дисковым пространством. Но, как известно, бесплатный сыр бывает только в мышеловке, поэтому за любыми достоинствами скрываются какие-то ограничения.
В данной ситуации придется считаться со следующими вещами:
1) Управление и администрирование. Чем больше решение растет « в ширь», тем большим количеством серверов придется заниматься, выполняя как рутинные задачи, так те, что будут «сваливаться» в процессе эксплуатации. Т.е установка фиксов, обновлений, резервное копирование – все это будет умножено на количество поддерживаемых серверов. Хотя, с другой стороны, добавление еще одно сервера будет менее болезненной процедурой.
2) Разбиение ( группирование) данных. Это одна из основных «головных болей». Правильность выбора критерия разбиения данных будет означать, насколько легко и безболезненно будет расти решение. Если параметр разбиения будет задан неверно, то это может потянуть за собой огромный список неприятностей. Необходимо очень хорошо понимать бизнес-логику и возможности ее модификации, чтобы минимизировать проблемы при росте приложения.
3) Изменение бизнес логики приложения. Со временем правила , по которым работает компания, могут видоизменяться, соответственно это накладывает ограничение на приложение среднего уровня, которое в свою очередь, отвечает за знание куда отправить запрос. Что будет , если нужно ввести новые элементы логики? Переписывать все полностью? Что будет, если добавится новый тип данных? ( В принципе, этот пункт тесно связан с предыдущим)
4) Доступность данных. Еще один узкий момент, где нужно своевременное правильное решение может избавить от кучи проблем – что произойдет с работой всего решения, если один из серверов данный просто упадет? А если «умрет» сервер, где хостится приложение?
Все эти вопросы были очень удачно освещены в решении, разработанном для MSN Communication Services Platform, описанием которого я и займусь немного позже.