Как писать данные из триггера Oracle в memcache?

Question

[Алексей Сумин]

Задача: после обновления записи в таблице Oracle, эту запись надо скопировать в memcache. Как можно (и можно ли вообще) подключиться к серверу memcache из Oracle?

Answer 1

[gelas]

С одной стороны, как мне помнится, там есть пакет по работе с TCP, а у memcached есть текстовый протокол.

С другой стороны есть Java Stored Procedures

Но с третьей стороны memcached, видимо используется для кеширования, там почему бы не кешировать специфические данные, которые нужны именно приложениям, а не результаты запросов из базы еще и использовать их из разных приложений, вероятно поддерживать стало бы проще.

Comments

[Алексей Сумин]

Очень много запросов на выборку данных (только по ID) и данные могут устаревать (а могут и не устаревать) за минуту, отдавать на запрос актуальные данные принципиально важно, поэтому пришла мысль о подогреваемом кеше.

[gelas]

Так оракл же и сам неплохо кеширует частые запросы.
Если таблица небольшая, то она и так вероятно будет в кеше (ну или частые запросы).
Можно попробовать поиграться с настройками кеширования, чтоб нужные результаты из него не выпадали.
Либо сделать кеш побольше или таблицу покомпактнее. Или поместить в индекс все нужные поля.
Или сделать materialized view только с актуальными данными.
Вообщем от характера данных зависит конечно сильно.
Но по-моему, в любом случае лучше сначала попробовать имеющиеся у оракла средства для оптимизации, чем добавлять еще одну неочевидно работающую прослойку.

[Алексей Сумин]

хочется совсем отказаться от коннектов к базе для этого приложения. Несмотря на кеш и индексы время коннекта к БД + время выборки много больше прямой выборки из memcache по ID, к тому же данные из memcache может напрямую поднимать nginx.

[gelas]

Ну в таком случае попробовать стоит конечно.
А самый простой вариант, вероятно таки, с использованием UTL_TCP — строчек в 10 уложитесь, я думаю.
Удачи!

Answer 2

[rPman]

начните работу с этой кнопки ;)
www.datadisk.co.uk/html_docs/oracle/external_procedures.htm

p.s. настоятельно рекомендую еще раз продумать архитектуру вашего приложения… что то грустное у вас получается, а как станет грустно тем кто будет ваше приложение поддерживать в будущем.

Answer 3

[egorinsk]

Разве не логичнее делать это в коде приложения?

Хотя, я чувствую, у вас там и так нескучный код.

Comments

[Алексей Сумин]

а если в базу может писать несколько приложений?

Answer 4

[bugman]

+1 к «попробовать имеющиеся у оракла средства оптимизации»:

— в приложении не создавать / дестроить коннект каждый раз а держать его постоянным, препейрить запросы, переменные биндить
— запустить AWR в модной веб-консольке Oracle Enterprise Manager, посмотреть что найдет
— поднять SGA, увеличить буффер кеш
— убедиться что соблюдены элементарные правила разделения датафайлов, редулогов, архивлогов по дискам и нет даунгрейда со стороны дисковой подсистемы, системных и оракловых джобов
— собрать статистику, посмотреть на фрагментацию (chained rows), помониторить сами запросы, посмотреть планы -> возможно что-то еще можно разогнать
— материализовать тяжелые запросики, из наиболее частоджоинящихся табличек сделать кластеры

Мне представляется, если у вас есть некий дополнительный свободный ресурс (ram, cpu) которое вы собираетесь отдать стороннему кеширующему решению, может сначала попытаться добавить тот же ресурс серверу бд + немного тюнинга?
Я просто боюсь, что любая самопальная схема инвалидации кеша, живущая на триггерах on every row будет создавать больше задержек -> несогласованность данных при чтении из кеша