LINUX.ORG.RU
ФорумAdmin

Существует ли SQL proxy с модификацией проходящих запросов?

 , ,


0

2

Есть такая странная задача:

Есть множество Oracle'овых баз с одинаковой структурой, которым нужно слать одинаковые запросы, буквально перебирая целевые базы в цикле.

Хотелось бы вот чего: добавлять в SELECT-запросы некий текст, который будет признаком целевой базы, отправлять запросы на некий SQL-прокси, который с точки зрения DBI будет выглядеть как single-СУБД.

Прокси-сервер увидит в теле SELECT'а идентификатор целевой базы, удалит его и отправит уже изменённый запрос на целевой хост.

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

Собственно, нашёл SQLRelay - штука отличная и умеет по регэкспам дистрибутить запросы... Но не умеет их модифицировать.

Последнее в принципе можно обойти (например, добавлять идентификатор цели в качестве «комментария»), но... вдруг есть ещё какие-то, более умные SQL-прокси? Собственно, это с прицелом на будущее, потому что на самом деле хотелось бы мутировать SQL-запросы на прокси таким образом, чтобы они подходили как для MySQL (в тестовой среде), так и для Oracle (в продакшн).

ОТВЕТ!

SQL Relay может транслировать запросы. Для этого существует механизм так называемых модулей трансляции. По умолчанию в поставке SQL Relay есть только один модуль, normalize. Для преобразования запросов он бесполезен, но его код можно использовать в качестве основы для написания своего модуля. Написание своего собственного модуля подробно описано в статье о модулях трансляции. То есть здесь: http://sqlrelay.sourceforge.net/sqlrelay/modules/translations.html

★★★★★

middleware это называется в общем случае.

SQL это язык запросов, а не протокол. У всех реализаций совсем разные несовместимые протоколы. Поэтому надо искать что-то под конкретно выбранную СУБД.

мутировать SQL-запросы на прокси таким образом, чтобы они подходили как для MySQL (в тестовой среде), так и для Oracle

А это вообще выглядит монструозно, может лучше использовать в тестовой среде какой-нибудь бесплатный oracle или более-менее совместимый postgres?

disarmer ★★★ ()
Ответ на: комментарий от disarmer

Я бы еще наверное вспомнил про проект Selta@Etersoft, который postgres транслировал в SQL Server, использовался с wine@Etersoft для старых 1С, которые Postgres не умели.

Проект действительно монструозный, это не SQLProxy.

BaBL ★★★★★ ()
Ответ на: комментарий от disarmer

SQL это язык запросов, а не протокол. У всех реализаций совсем разные несовместимые протоколы.

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

Собственно, если бы он ещё предоставлял трансляцию SQL-запросов - цены бы ему не было (вернее, он бы не стоил 1.99$ за бинарную сборку и даром - исходники).

DRVTiny ★★★★★ ()
Ответ на: комментарий от DRVTiny

Есть множество Oracle'овых баз с одинаковой структурой, которым нужно слать одинаковые запросы, буквально перебирая целевые базы в цикле.

Это достаточно кастомная штука ведь. Например что делать этому middleware, если на одной из БД не удалось выполнить запрос? Тут всё зависит от задачи, мне кажется это более уместно делать в приложении.

disarmer ★★★ ()
Ответ на: комментарий от disarmer

Например что делать этому middleware, если на одной из БД не удалось выполнить запрос?

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

DRVTiny ★★★★★ ()
Ответ на: комментарий от DRVTiny

Никакой транзакционности тогда не будет, если на части СУБД оно выполнится, а на части нет. Ну и отказоустойчивости, еще и шанс отказа увеличится в N раз.

disarmer ★★★ ()

Вставка идентификатора целевой базы во внутристрочный комментарий (/* ... */) - отлично работает с SQLRelay'ем, так что меня этот вариант вполне устраивает, могу считать данный вопрос самозаresolveнным :)

DRVTiny ★★★★★ ()
Ответ на: комментарий от disarmer

У меня нет задачи реально считать кучу разных баз одной-единственной целостной базой. И никаких транзакций там нет, одни селекты. Если селект вернул ошибку - я и сам пойму, что проблема с одной из конечных точек.

DRVTiny ★★★★★ ()

Добавил ответ по поводу преобразования SQL-запросов. SQL Relay предоставляет механизм преобразования, но соотв. модуль придётся писать самостоятельно (см. актуальную версию документа http://sqlrelay.sourceforge.net/sqlrelay/modules/translations.html , потому что к тому моменту, когда вы будете это читать, вполне возможно, что ситуация изменится к лучшему).

DRVTiny ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.