Наткнулся сегодня на интересный подкаст, рассказывающий об экстремальной обработке данных. В основном с упором на Java, но есть и интересные общие мысли.
Некоторые мысли оттуда:
1) Для некоторых приложений имеет значение латентность из-за ограниченной скорости света (!!!), так что Java не подходит из-за больших латентностей GC. В таких применениях рулит С/C++.
2) Базы данных — перестают быть центром вселенной и точками интеграции. Тем более, что они не дают достаточной скорости по сравнению с in-memory системами.
3) Так что сейчас начинают рулить системы обмена сообщениями, распределённые in-memory кэши и grid-системы.
4) Большое железо сново начинает рулить. Так как имея 1000 процессоров на одной железке и 500Гб оперативы мы избегаем латентности на сетевом обмене.
5) Современные успешные системы масштабируются в обе стороны системы — от лэптопа до кластера из кучи компьютеров. Никому не нужен сервер приложений, тратящий гигабайты оперативки на запуск hello world.
6) Spring стал стандартом де-факто.
Здравствуйте, Cyberax, Вы писали:
C>1) Для некоторых приложений имеет значение латентность из-за ограниченной скорости света (!!!), так что Java не подходит из-за больших латентностей GC. В таких применениях рулит С/C++.
Не вижу связи. Латентность из за ограниченной скорости света действительно имеется при организации связи на большие расстояния (иногда и 100 метров — большое расстояние, если речь идет о связях внутри кластера). Но причем тут GC?
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Не вижу связи. Латентность из за ограниченной скорости света действительно имеется при организации связи на большие расстояния (иногда и 100 метров — большое расстояние, если речь идет о связях внутри кластера). Но причем тут GC?
Там в подкасте говорится, что выигрыш в одну миллисекунду времени реакции в торгах на бирже выливается в миллионные прибыли в год.
Поэтому даже миллисекундные паузы от GC — губительны. Особенно тем, что они появляются во время активной работы с большим количеством сообщений. То есть как раз в тех случаях, когда нужно принимать быстрое решение.
Здравствуйте, Cyberax, Вы писали:
C>Там в подкасте говорится, что выигрыш в одну миллисекунду времени реакции в торгах на бирже выливается в миллионные прибыли в год. C>Поэтому даже миллисекундные паузы от GC — губительны. Особенно тем, что они появляются во время активной работы с большим количеством сообщений. То есть как раз в тех случаях, когда нужно принимать быстрое решение.
Дожили... Скоро к биржевым софтам будут предъявляться требования жесткого реал-тайм, как для управления крылатыми ракетеми.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Дожили... Скоро к биржевым софтам будут предъявляться требования жесткого реал-тайм, как для управления крылатыми ракетеми.
Так уже предъявляют.
Здравствуйте, McSeem2, Вы писали:
MS>Дожили... Скоро к биржевым софтам будут предъявляться требования жесткого реал-тайм, как для управления крылатыми ракетеми.
Это неизбежно. Алгоритмы усложняются, количество торгующих увеличивается. В mq4 сделали возможность делать вызовы функций из внешних dll.
1) Алго-трэйдинг сейчас пишется на Java/.NET-e и очень успешно. То что в 5% банковского софта нужно учитывать скорости света и тормоза GC, автор загнул, это скорее всего даже не 0.05%. Более того, там где это действительно так, без RT OS, а часто и спец-железа не обойтись.
2) Про большое железо. В конце на вопрос, почему не использовать Linux-ферму и 10GB/Infiniband интер-коннект, он ответил, что мол все это г.... по латентности, по сравнению с Azul-ом. Перед этим он битый час пиарил EC2 и коммерческие распределенные кеши. Ему надо бы или крест снять или штаны надеть.
3) Про базы данных согласен. Полная комодити, никому не интересная. За программирование в хранимках сейчас просто убивают.
Судя по описанным проектам, общей сумбурности в голове выступающего и энтузиазму к коммерческим технологиям и явной ориентации на back-office, выступающий явно из племени "архитектор"-ов, которому интересно поиграть с дорогими игрушками безотносительно к их реальной полезности.
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, Cyberax, Вы писали:
C>>Там в подкасте говорится, что выигрыш в одну миллисекунду времени реакции в торгах на бирже выливается в миллионные прибыли в год. C>>Поэтому даже миллисекундные паузы от GC — губительны. Особенно тем, что они появляются во время активной работы с большим количеством сообщений. То есть как раз в тех случаях, когда нужно принимать быстрое решение.
MS>Дожили... Скоро к биржевым софтам будут предъявляться требования жесткого реал-тайм, как для управления крылатыми ракетеми.
так давно уже.
К собственно "биржевым софтам" (т.е. движкам бирж) это уже тыщу лет, на этом конкуренция разных бирж строится в том числе; ну и ко всяким программам-трейдерам, которые сидят на market data и посылают ордера, как только представляется возможность выгодно купить/продать — очевидно, что из двух похожим образом работающих стратегий выиграет (причем с огромным отрывом!) та, которая ворочается (т.е. обрабатывает market data, обсчитывает мат. модель, принимает решения и посылает ордера) быстрее — просто потому что она будет снимать сливки, а остальным останется обрат.
Именно поэтому сейчас биржи наперебой предлагают colocation вплоть до того, чтоб компании ставили свои сервера прямо в здании биржи — чтоб свести почти к нулю сетевые задержки как для ордеров, так и для market data.
да, очень смешно было посмотреть
типа: "Внимание! Мы прокачиваем 130к сообщения в секунду!" А потом маленькими буквами: "Ну только это... На специализированной железке с 777 ядрами, которая стоит как раз столько, на сколько вы собираетесь увеличить свою прибыль"
А распределенные системы, основанные на обмене сообщениями и на отсутствии БД (потому что все состояние восстанавливается проигрыванием сообщений, которое должно быть быстрым — вот почему я eao197 спрашивал относительно этих характеристик его SObjectizer'a), опять же, тыщу лет уж как есть, взять тот же FIX Protocol.
Здравствуйте, jazzer, Вы писали:
J>А распределенные системы, основанные на обмене сообщениями и на отсутствии БД (потому что все состояние восстанавливается проигрыванием сообщений, которое должно быть быстрым — вот почему я eao197 спрашивал относительно этих характеристик его SObjectizer'a), опять же, тыщу лет уж как есть, взять тот же FIX Protocol.
Не, для таких задач мы еще SObjectizer не дорастили. Но более-менее понятно, куда стремиться.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Cyberax, Вы писали:
C>Наткнулся сегодня на интересный подкаст, рассказывающий об экстремальной обработке данных. В основном с упором на Java, но есть и интересные общие мысли. C>http://www.theserverside.com/news/thread.tss?thread_id=50836 (прямая ссылка на подкаст: http://media.techtarget.com/audioCast/TSSCOM/TSSJS_Davies.MP3 ) C>6) Spring стал стандартом де-факто.
Простите за то что трупик "оживил", я не могу к сожалению просмотреть весь подкаст,
хотелось бы услышать почему "Spring стал стандартом де-факто." т.е. какие факты автор подкаста выдвагает
утверждая такое?
