Классика баз данных - статьи

       

Скорректированная цена дробления


Вычисления подобного рода часто производится в приложениях на Уолл-стрит. Имеется входной канал данных о разовых изменениях цены акций:

Ticks (symbol = C6, time = double, volume = integer, price = double),

которые могут поступать от одного из популярных поставщиков данных или через прямое соединение с биржей. Кроме того, имеется второй канал:

Splits (symbol = C6, time = double, split_factor = float).

Во втором канале поступают данные о моменте времени дробления акций, а также значение коэффициента дробления; т.е. для дробления 2 вместо 1 коэффициентом дробления является 1, а для дробления 1 вместо 2 (обратного) коэффициентом дробления будет 0.5. Целью этих вычислений является получение скорректированной цены дробления для канала Ticks. Поскольку акция с данным символом может дробиться более чем один раз, необходимо поддерживать текущую композицию всех коэффициентов дробления, наблюдавшихся до данного момента. Это состояние сохраняется в таблице Storage:

Storage (symbol = C6, total_split = float)

С помощью следующих операторов StreamSQL определяется требуемая обработка хранимой таблицы Storage и двух каналов Ticks и Splits:

UPDATE Storage FROM Splits S SET (total_split = total_splits * S.split_factor) WHERE S.symbol = Storage.Symbol

SELECT T.symbol, price = T.price * S.factor, T.volume, T.time FROM Ticks T, Storage S WHERE S.symbol = T.symbol

Приведенный код выполнялся в системе StreamBase на компьютере стоимостью в 1000 долларов (Pentium D 820 с частотой 2.8 Мгц, RAM объемом в 3 Гб и четыре дисковых устройства SATAII по 200 Гбт), и при этом была продемонстрирована пропускная способность в 333000 сообщений в секунду. Логика РСУБД, позволяющая решить ту же задачу, является немного более замысловатой. Один вариант состоит в создании хранимой таблицы Storage и выполнении оставшейся части приложения в некоторой хранимой процедуре. Этот подход позволяет обрабатывать 12640 сообщений в секунду. Второй подход заключается в том, чтобы заносить в базу данных данные из обоих каналов и потом использовать триггеры для выполнения требуемой обработки. Этот подход позволяет более полно использовать функциональные возможности СУБД, но значительно снижает производительность.

Чтобы показать РСУБД в лучшем свете, мы также реализовали третью альтернативу, разместив таблицу Splits в массиве внутри хранимой процедуры. В первом приближении в этом решении все приложение кодируется в виде хранимой процедуры, без использования каких-либо средств СУБД. Очевидно, более предпочтительным вариантом является собственная реализация приложения полностью вне СУБД. Однако мы сообщаем о результате этой попытки из категории «будет лучше всего, если вы встанете на голову», и в ней нам удалось добиться пропускной способности в 38000 сообщений в секунду.



Содержание  Назад  Вперед