Highload++ 2008: TimesTen — СУБД, которая работает в 10 раз быстрее классической СУБД

• http://highload.ru/papers2008/7186.html

TimesTen звучит как «таймстемп». Маркетингово-сейловый доклад. Но к чести сказать, не только гламурная презентация, но и макет-демонстрация:

• пара VMWare-машин на ноутбуке;
• самопальное окошко-приложение, грузящее макет CDR-файлов в БД, затем выполняющее тривиальный пересчет данных.

Бесплатный совет любым сейлам западных продуктов — первым делом написать или перевести русскоязычную статью в Википедии. В «англоязычной» Википедии рекламу убивают быстро (вот сейчас эта статья TimesTen под приговором), в «русскоязычной» — только если совсем оборзеть.

Утверждается, что достигнуто преимущество в 15-20 раз по скорости над обычным Oracle. А ведь 17 — это вроде как классическое «среднее» различие между скоростью доступа к памяти и последовательным доступом к диску, но докладчики утверждали, что это преимущество достигнуто на макетах с одинаковым выданным объемом памяти обоим. Видимо даже редкие fsync классической СУБД дают этот порядок тормозов. Плюс — максимальное использование random-доступа — T-tree/hash индексы вместо BTREE индексов, сортируют, наверно, тоже не слияниями. Можно выжать вообще максимум, используя API прямого доступа к внутренним структурам.

И все-таки несколько позорное для классического Oracle сравнение (неужели не могли ценных алгоритмов пересадить внутрь обычного Oracle?). Напоминает сценарий продажи «абсолютного щита и копья» двум покупателям — покупатель щита не купит его, т.к. оно пробивается абсолютным копьем, а покупатель копья не купит, узнав что есть абсолютный щит.

Вообще тренд — дешевеющая память (не только известный SSD, но и другие экспериментальные дешевые модели памяти) и повсеместный отход от классических архитектур СУБД, где есть только маленькое окно памяти в BUFFERS, а все остальное — неподъемный жесткий диск.

Так Oracle уже три года как купил (и вот переварил) TimesTen, а IBM купил и переваривает SolidDB. Ширится движение разных «Real Clusters» — базы в только в памяти, надежность — только дублированием в кластере. Да, докладчики от сравнения с «MySQL Real Cluster» уклонились.

Вроде как оракл переварил эту софтину успешно — софтина обучена более-менее Оракловому диалекту SQL (т.е. оракловые функции и т.п. — но не полностью!) — общается с обычным ораклом начиная с 9.2.0.8 клиента и 9.2.0.6 сервера. Софтина умеет жить сама по себе и в роли кеша для обычной оракловой базы. Т.е. если вы написали тормозящую систему на Oracle — поставьте перед ней memcache TimesTen, и все будет хорошо. И вроде как недорого ($1000 за процессор).

Забавный момент — это первая на моей памяти эффективная СУБД, у которой нативным интерфейсом является ODBC.

Были странные вопросы — сможет ли эта штука использовать память вне ОС — типа выше 4GB под Win32 (Заметим, что на самом деле под Win32 нельзя использовать больше ≈3GB). Типа «Доктор, я смогу после операции играть на скрипке…».

Однако далеко не все так безоблачно. Нарыл:

• http://www.oraclebi.ru/2007/11/05/imelnikov/#comment-24732

сведения о версионности Oracle TimesTen не соответствуют действительности. Пишущие транзакции не только блокируют читающие (а читающие — пишущие), но, более того, читающие транзакции блокируются читающими (на уровне строк). При многопользовательском доступе, это может существенно ухудшить масштабируемость системы (при наличии конфликтов доступа). Заблуждение относительно поддержки TimesTen версионного доступа могла возникнуть в результате того, что при подключении по протоколу ODBC, используемому TimesTen, по умолчанию действует режим AutoCommit, при котором каждый запрос к БД выполняется в рамках отдельной транзакции. При использовании ODBC, режим AutoCommit должен отключаться явно. Update: Автор доклада в комментах говорит, что это неправда.