essbase.ruМожно ли в кластерном режиме развернуть на Virtuoso сервер приложений ? Т.е. внести всю бизнес логику на встроенный язык ?Можно, даже очень желательно.
essbase.ru1) Код выполнятся на случайной ноде или на всехС точки зрения клиента, все ноды кластера равноправны. Администратор сети разрешает, на свой вкус, доступ по ODBC/UDBC/IODBC/JDBC/ADO.NET к нескольким или всем нодам, и либо разным клиентам говорит разные хосты/порты для подключения, либо ставит round-robin balancer маршрутизатор, либо round-robin DNS --- кому как удобнее. Узлы кластера не обязаны быть одинаковыми, и разные клиенты могут хотеть цепляться к узлам разных сортов. Если таких заумностей нет, то обычно или используют какой-то round-robin или назначают одну машину "пресс-секретарём" и надеются, что накладные расходы на работу с клиентскими коннекциями не станут узким местом. Из похожих соображений администратор решает, какие узлы и как обрабатывают HTTP/WebDAV/SOAP/...
Получив запрос, нода радостно начинает его исполнять. Если это хранимка, то тело хранимки исполняется на этой ноде, разве что программист в теле хранимки явно захочет исполнить что-то на другой конкретной ноде или на всех нодах одновременно. Если это SQL или SPARQL запрос --- прямо от клиента или вызываемый из хранимки, то он распараллеливается continuation-ами: если ноде A нужны данные, находящиеся на нодах B1, B2, B3..., то на каждую ноду Bn будет отправлен сам скомпилированный запрос, все параметры, описывающие его текущее состояние, "закладку", показывающую то место, с которого ноде Bn надо продолжить работу и инструкция, указывающая ноду, которая должна получить результат. Каждая нода Bn, выполнив ту часть, для которой у неё "под рукой" есть данные, либо возвращает результат в соответствии с инструкцией, либо сама готовит набор continuation-ов для нод Cn1, Cn2, Cn3,... и инструкцией возвращать результаты либо самой Bn, либо (если ей самой делать ничего не надо) прямо ноде A. Все выборки по возможности сильно векторизуются, сетевые сообщения по возможности собираются в достаточно большие пакеты, чтобы использовать сеть с максимальным КПД и уменьшить вредные эффекты латентности сети.
essbase.ru2) Можно ли запускать паралелльные потоки ?SQL-запрос умеет распараллеливаться сам, хранимки надо распараллеливать явно (
http://docs.openlinksw.com/virtuoso/ASYNCEXECMULTITHREAD.html ) . Кроме того, в хранимке можно работать с целыми векторами данных вместо отдельных скалярных значений, используя те же векторные операции, которые использует SQL-интерпретатор. На практике это означает, что разработчик первой строчкой хранимки пишет команду vectored;, пробует её скомпилировать, и если компилятор ему не возразил "так не бывает", то этого достаточно :)
essbase.ru3) Есть ди интерфейсы обмена данными между хранимками ?Боюсь, я не понял вопрос. Можно позвать хранимку из хранимки, можно, если очень хочется, использовать две ссылки на один thread-safe ассоциативный словарь в памяти и делать dict_put() в одной нити и dict_get() в другой, можно использовать connection_get()/connection_set() для переменных, привязанных к клиентской коннекции, а не к исполняемому запросу, но на практике это редкость.
essbase.ru4) Как насчет Джобов ? Тригеров ?Есть планировщик, триггеры на CRUD, обработчики системных событий вроде логина клиента.
essbase.ru5) Есть ли ограничения по внешнему взаимодествию в коде хранимок.Разумеется.
1. В языке есть именованные мьютексы, процедуры могут координировать свою работу через них, если обычных "табличных" методов не хватает (скажем, при работе с файловой системой и прочими внешними вещами). Для защиты от дедлоков процедура может запустить функцию ожидания мьютекса только если она не держит никаких локов на записях. Посреди транзакции доступна только функция "попробовать захватить мьютекс сходу, но не ждать его освобождения".
2. Процедурам нежелательно звать свой собственный кластер через клиентские интерфейсы этого кластера. Если веб-клиент запустит страницу X, хранимка на той странице залочит какие-то записи, запустит встроенного веб-клиента и попросит его получить страницу Y с того же кластера, то может так получиться, что страница Y начнёт ждать записи, залоченные транзакцией на X, а X будет ждать ответа от Y. Поскольку диспетчер транзакций ничего не будет знать о зависимости X от Y, для него X будет просто "хранимкой, которая выполняется очень долго", и дедлок будет разорван только таймаутом HTTP. Правильным решением было бы просто позвать хранимку Y из хранимки X.
2.1. Особо вредный случай --- протокол URIQA, в котором веб-сервер на запрос "расскажи мне про X" либо даёт ответ сам, либо от своего имени отправляет аналогичные запросы на те серверы, которые, по его мнению, могут что-то знать про X. Чтобы запросы не ходили кругами слишком долго и не устраивали "распределённые дедлоки", каждый сервер Virtuoso на пути запроса ставит свой "почтовый штемпель", а получив запрос со своим собственных штемпелем --- удивляется и ругается со всеми подробностями.
3. Каждый thread-safe ассоциативный словарь имеет счётчик изменений, который увеличивается при каждой правке данных в нём.
Если в одной нити хранимка будет выполнять цикл по всему содержимому словаря, а в другой хранимка попробует записать в словарь, цикл обнаружит изменение счётчика, эту ситуацию надо обрабатывать отдельно. Ещё такой словарь имеет счётчик ссылок на него, и особо "разрушительные" операции, вроде полной очистки словаря, снабжены дополнительным флажком --- что делать, если словарь внезапно используется где-то ещё.
essbase.ru6) Есть ли понятие "табличные" функции ?Да. Есть табличные функции, есть create procedure view. Кстати, create aggregate тоже есть. Для написания транзитивных запросов, кстати, в SQL есть transitive subqiery с богатым функционалом, так что некоторую часть табличных функций можно вообще не писать.
