Sequoia изнутри: заключение

Август 28th, 2009 по SadKo Оставить ответ »

Разбор полётов

В общем, сегодня решил, что ну её нафиг, эту Sequoia. Ибо я так и не нашёл в сети реализации класса, выполняющего бэкап данных СУБД ORACLE для Sequoia.
Разработчики много чего обещают, пророчат чуть ли не светлое будущее, а на самом деле ничего сверхнового и революционного в ней нет.
Изначально я думал, что разработчики написали свой парсер SQL-выражений под каждый движок, на деле же всё оказалось проще и прозаичнее: SQL-запросы тупо транслировались в базы.
Про атомарность транзакций я вообще молчу: в подобной архитектуре она в принципе не может быть реализована.

Также очень сомнительна предсказуемость работы такой «распределённой» БД: в случае, если будет, например, использоваться СУБД ORACLE, и в нём будут введены Sequences (которые инкрементируются независимо от того, прошла транзакция, или был выполнен rollback), рассинхронизация данных таблиц при частых распараллеленных commit/rollback очевидна.
Качая пакеты и исходники, я думал, что Sequoia — действительно серьёзный проект, так как архивы весили очень внушительно (21 метр для сорцов — не хухры-мухры), а на деле оказалось, что большую часть там занимали 3rd-party packages, а из исходников было только 86 файлов самого менеджера и примерно столько же файлов гламурной консоли управления.

Концепция

Несмотря на то, что Sequoia оказалось откровенной поделкой, концепция распределённой БД по принципу RAID достаточно интересна. Например, моё представление контроллера такой БД — это контроллер, который сам работает как БД, то есть имеет свой SQL-синтаксис, который потом адаптируется под синтаксис конкретного движка СУБД.
Пример: на вход контроллера подаётся такое выражение:

SELECT (nID, strMessage) FROM Tm_First
WHERE strMessage LIKE '%Hello%'
ORDER BY nID DESC LIMIT 2;

Для MySQL это транслируется в:

SELECT (`C_nID`, `C_strMessage`) FROM `T_Tm_First`
WHERE `C_strMessage` LIKE '%Hello%'
ORDER BY `C_nID` DESC LIMIT 2

А для Oracle, например, вот так:

SELECT "C_nID", "C_strMessage" FROM (
	SELECT "C_nID", "C_strMessage" FROM "T_Tm_First"
	WHERE "C_strMessage" LIKE "%Hello%"
	ORDER BY "C_nID" DESC)
WHERE rownum<=2

Как видно, в СУБД используется своя нотация, чтобы была возможность ведения системных таблиц для реализации транзакционности в распределённой базе.
Для этого в таблицы, например, при создании можно дописывать поля, такие как transaction_id, а также вести дополнительную таблицу незавершённых транзакций, чтобы обеспечить возможность отката, а также исключить видимость данных до вызова commit.
Таким образом, предыдущий пример усложняется для MySQL:

SELECT (`C_nID`, `C_strMessage`) FROM `T_Tm_First`
WHERE `C_strMessage` LIKE '%Hello%'
AND `trID` NOT IN (SELECT `nID` FROM `transactions`)
ORDER BY `C_nID` DESC LIMIT 2

И для ORACLE:

SELECT "C_nID", "C_strMessage" FROM (
	SELECT "C_nID", "C_strMessage" FROM "T_Tm_First"
	WHERE "C_strMessage" LIKE "%Hello%"
	AND "trID" NOT IN (SELECT "nID" FROM "transactions")
	ORDER BY "C_nID" DESC)
WHERE rownum<=2

Ну а про Recovery Log я вообще молчу: он должен быть в каждой БД, чтобы в случае отказа по другой БД можно было бы восстановить любую вновь введённую в строй.
Тем не менее, это очень ограничивает реальные рамки использования таких фич СУБД, как:

  • Триггеры (сложно, практически нереально сэмулировать сложные триггеры при batch-операциях без потери производительности);
  • Sequences (в принципе, можно сэмулировать);
  • PL/SQL (вообще непонятно как делать);
  • И т.д., и т.п. вещи, которые есть в одной СУБД, но отсутствуют или по-другому реализованы в другой.

Если подобные фичи не нужны, то, в принципе, можно написать адаптер под любую СУБД. Но тогда встаёт вопрос, зачем использовать столь мощную СУБД, если все её возможности не используются по максимуму.

Противопоставление

Естественно, ничего из предложенной мною концепции Sequoia не делает. Мало того, усугубляет всю свою «надёжную» схему в RAIDb1 введением дополнительной СУБД для Recovery Log и ведением дампов, которые должны храниться на хосте контроллера.
Да, она обеспечивает обратную совместимость с приложениями, но на этом всё и заканчивается.
Если и делать кластер — то либо средствами разработчиков СУБД, либо таким костылём, который предложил я. Третье вряд ли дано.

Резюме

Проект закрыть, исходники закопать и больше не выкапывать.

Реклама

Добавить комментарий

Blue Captcha Image
Refresh

*