Собственно, как и было сказано ранее, я для упрощения изучения японского языка сделал такой вот сайтец — http://kanji.xskernel.org/. И обещал обновить его структуру. Сегодня залил свежий движок на пропатченную базу. Теперь осталось выпилить из базы лишние таблицы, которые уже не играют никакой роли. Наконец-то заработал словарь, который по мере изучения мною языка потихоньку пополняется новыми словами. Идею, предложенную товарищем stalkerg я постарался воплотить по-максимуму. А именно: сделал возможным поиск слова не только по кандзи, но и по фонетической составляющей (то есть, можно вписать слово каной либо ромадзи, при этом добавлена ещё одна фича: если вы не знаете, является гласный звук долгим или коротким, то словарь выдаст вам оба результата, если все гласные звуки будут введены как короткие).
Соответственно, раньше движок задумывался как запоминалка канзди, теперь же он всё больше и больше становится полноценным словарём, поэтому возможна трансляция как из японского в русский, так и из русского в японский. Единственное, что меня пока смущает, — это дополнения к слову. Их, скорее, следует переделать (вернее группировать), и я уже примерно представляю как. Но это позже. Сейчас меня больше беспокоит отсутствие админки, ввиду чего данные мне приходится пока по-прежнему вбивать специально написанными консольными скриптами.
Также в самом движке добавил задел на поддержку не только СУБД MySQL, но и СУБД Firebird. Если будет время — обязательно продолжу развитие движка в этом направлении. В общем, планов море, а времени и сил — чуть.
Опять же, если есть какие замечания/пожелания по поводу сайта, прошу писать отзывы.
И, напоследок. В процессе написания движка сайта (а пишется он на PERL), мне пришлось решить ряд задач, о которых могут выйти вполне интересные статьи. Если аудитории интересно — то я могу потихоньку выкладывать тут упрощённые кусочки движка с объяснением, как это работает. Заодно и блог оживёт, пожалуй.

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

В общем, сегодня решил, что ну её нафиг, эту 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 и ведением дампов, которые должны храниться на хосте контроллера.
Да, она обеспечивает обратную совместимость с приложениями, но на этом всё и заканчивается.
Если и делать кластер — то либо средствами разработчиков СУБД, либо таким костылём, который предложил я. Третье вряд ли дано.

Резюме

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