Здравствуйте, Shota, Вы писали:
G>>говоря о БД для обработки time series — вы на моей территории, там, где я реально эксперт. S>Не могли бы вы рассказать, какие готовые time series БД существуют, более доступные и открытые, чем kdb? Тоже работаю в это области, есть свои наработки/велосипеды по хранению биржевых данных, хочу сравнить с другими системами. Недавно гуглил, но что-то ничего приличного из time series db не нашел .
По состоянию на 2001 год, когда мы проводили исследование предложения, специализированных движков кроме kdb не было. Кроме kdb, Informix давал datablade для timeseries, который нас сильно расстроил тогда. От kdb отказались, так как у нас весьма конкретные и специфические требования к движку, и готовый сервер приложеений, и мы вовсе не были уверены, что kdb адекватно выполнит все наши use cases. Например, CQG сервер не делает разницы между real time и historical данными — для него это фактически одно и то же, и все обновления происходят в реальном времени. Это очень нравится трейдерам, у конкурентов такого не было тогда.
Прототип на MS SQL показан неудовлетворительные результаты. Производительность просаживалась на межпроцессной передаче на порядок, ужасно медленно — практически внятяг по требованиям, обновлялись котировки в базе (и это после танцев с бубном). Язык запросов мешает, а не помогает. Мы его делали с одним парнем, который был MCSD. В результате, решили просто искать простой встраиваемый движок БД, поверх которого можно эффективно навернуть свой time series движок ручками.
Что мы выбрали в результате сказать не могу, извините. Насчет ситуации по движкам time series сейчас — я ее не отслеживал, но мой бывший коллега-MCSD, который сейчас делает решения для брокеров и автоматической торговли, говорит, что ситуация с тех пор изменилась не сильно.
Здравствуйте, dmz, Вы писали:
dmz>Дикий офтоп, но поскольку другие способы связаться не возымели успеха, пишу здесь. dmz>Gaperton! Очень нужно с тобой связаться, обсудить возможность консультации. Я таки ввязался в разработку части проекта на Эрланге, и хотя получилось так, что эта часть будет намного менее критичной, чем казалось ранее, и ее можно будет просто выкинуть, в крайнем случае, но хочется все сделать все хорошо сразу. Как можно связаться?
Здравствуйте, Gaperton, Вы писали:
G>Прототип на MS SQL показан неудовлетворительные результаты. Производительность просаживалась на межпроцессной передаче на порядок, ужасно медленно — практически внятяг по требованиям, обновлялись котировки в базе (и это после танцев с бубном). Язык запросов мешает, а не помогает. Мы его делали с одним парнем, который был MCSD. В результате, решили просто искать простой встраиваемый движок БД, поверх которого можно эффективно навернуть свой time series движок ручками.
Аналогично пробовали сначала с Firebird — скорость никакая, притом база быстро разрастается. Сейчас у нас двухуровневое решение — долговременное медленное хранилише со сжатием + кратковременный кеш на файл-маппинговом векторообразном контейнере. Насколько этот подход плох/хорош по вашему?
Меня этот вопрос еще вот с какой стороны интересует. Обчитавшись ДП и поверив в крутизну Эрланга , я задумал реализовать на нем наш сервер, чтобы упростить работу со многими клиентами, в часности, да и cpp-specific баги надоели . Однако уперся в работу с нашим хранилишем. Сейчас, с использованием файл-маппинга, расход RAM очень небольшой, по программе гуляют оберточные структуры. Причем ненужные файлы можно детерминированно выгружать из адресного пространства, без этого оно быстро кончится. Как с этии делом в Эрланге? Насколько я понимаю, такие трюки и автосборка мусора не очень совместимы... Жду совета от гуру .
Здравствуйте, Quintanar, Вы писали:
Q>Здравствуйте, Gaperton, Вы писали:
G>>В отличии от вас, я в работая в CQG такой сервер писал, так понтоваться не рекомендую, говоря о БД для обработки time series — вы на моей территории, там, где я реально эксперт. in memory DB не подходят для биржевых приложений. Сколько, по вашему занимает один день котировок с одной биржи, интересно, и как вы думаете — влезет ли он в память. 50К контрактов, примерно 30 миллионов котировок — нормально для хорошей электронной биржи. По 10 байт на котировку (4 байта price + 4 байта volume + 1 байт флаги + 1 байт секунды) это почти без компрессии и индексов — на самом деле больше будет) — 300 мегабайт. Сколько в мире крупных бирж? Положим, штук 20. Валяйте, храните в памяти. Ой какая крупная угроза идет со стороны in-memory database, уписаться.
Q>Я то как раз могу попонтоваться, поскольку прямо сейчас могу посмотреть котировки какого-нибудь MSFT за любую дату.
Не, так не пойдет. Это ж каждый может — online через futuresource или yahoo stocks . Ты вместо настоящих ядреных понтов какою-то ерунду мне хочешь подсунуть — расстройство одно. Я так понимаю, раз понты — так понты, блин, взялся — так уж будь любезен постарайся как следует. Короче, жду настоящих, серьезных понтов.
Q>И хранятся они (сюрприз!) в базе данных, без всякого сжатия.
Это для меня очень хорошая новость. Это меня радует .
Q>Таблица котировок занимает гигабайт 7-8 на диске за средний день для ведущих бирж США (CTS + NASD). Q>Много, конечно, но если на машине стоит 32-64 гигабайт памяти, то уже нормально. Если вам не давали купить память и приходилось извращаться и ужиматься в 4 гигабайта (надеюсь хоть машина была 64-х битная), то это ваши проблемы, это никак не опровергает того, что все данные по всем биржам мира за день можно уместить в памяти 3-х серверов и то ради удобства.
Мне как раз кажется извращением стараться уместить котировки в памяти.
Во-первых, насколько я припоминаю, каждый сервер CQG по правилам 2005 года должен хранить истории котировок за 10 лет по всем крупным биржам мира. А в мире, если мне не изменяет память, примерно двадцать крупных бирж, не считая мелких, которые тоже не фигово хранить.
Во вторых — ни единого резона держать котировки в памяти нет. При желании, мы можем читать их с диска раз как минимум в десять быстрее, чем их в состоянии обрабатывать торговые роботы. Только по понятным причинам это нахрен никому не нужно, тем более — держать в памяти их BD. Что касается тех редких ситуаций, когда это реально требуется (не припомню таких ярковыраженных случаев, кстати, поправьте меня, очень интересно увидеть контрпример), достаточно простого кэширования котировок и агрегатов OHLC в памяти по сегментам. Не нужна никакая in-memory DB.
G>>Не удивительно, вам вообще сложно что-либо объяснить. Вы должны были понять, что изволите спорить со мной сразу по двум темам, которые являются моей прямой специальностью. 6 лет в CQG я занимался разработкой их сервера БД для time series и финансовых приложений, и последние два года я профессионально занимаюсь стратегическим и продуктовым маркетингом и всякими там бизнес-стратегиями. Я в Эрланге и ФП гораздо меньше соображаю, право, чем по этим темам .
Q>Первое и моя специальность, не вижу причин, почему ваш локальный опыт лучше моего.
Гхм, то есть по второй — возражений нет? . Quintanar, я очень хорошо к вам отношусь, на самом деле. И я не собираюсь утверждать, что мой опыт в первой специальности лучше вашего. Вы первым начали . А я вам показываю, что меня за совсем лоха-то тоже не надо держать. Вот и получился замер пиписьками . Весело. Продолжим?
Здравствуйте, Shota, Вы писали:
S>Здравствуйте, Gaperton, Вы писали:
G>>Прототип на MS SQL показан неудовлетворительные результаты. Производительность просаживалась на межпроцессной передаче на порядок, ужасно медленно — практически внятяг по требованиям, обновлялись котировки в базе (и это после танцев с бубном). Язык запросов мешает, а не помогает. Мы его делали с одним парнем, который был MCSD. В результате, решили просто искать простой встраиваемый движок БД, поверх которого можно эффективно навернуть свой time series движок ручками.
S>Аналогично пробовали сначала с Firebird — скорость никакая, притом база быстро разрастается. Сейчас у нас двухуровневое решение — долговременное медленное хранилише со сжатием + кратковременный кеш на файл-маппинговом векторообразном контейнере. Насколько этот подход плох/хорош по вашему?
Вполне нормальный подход. На самом деле — зависит от use cases.
S>Меня этот вопрос еще вот с какой стороны интересует. Обчитавшись ДП и поверив в крутизну Эрланга ,
Черт, ну зачем я с Quintanar спорю? Надо было сразу сдаться. Дурак.
S>я задумал реализовать на нем наш сервер, чтобы упростить работу со многими клиентами, в часности, да и cpp-specific баги надоели . Однако уперся в работу с нашим хранилишем. Сейчас, с использованием файл-маппинга, расход RAM очень небольшой, по программе гуляют оберточные структуры. Причем ненужные файлы можно детерминированно выгружать из адресного пространства, без этого оно быстро кончится.
Я бы посоветовал завернуть ваше хранилище в драйвер или C-node.
S>Как с этии делом в Эрланге? Насколько я понимаю, такие трюки и автосборка мусора не очень совместимы... Жду совета от гуру .
Я не гуру в Эрланге, я только учусь. К тому же, я не хочу обсуждать технологию хранения биржевых данных в Эрланге, пока я не сделал свой прототип. Когда я буду уверен, что не собираюсь делать на нем движок биржевой обработки — тогда можно будет поговорить. Тем более — скажу правду и только правду — мне самому надо сделать серию прототипов, чтобы выбрать способ работы с данными. Я пока не знаю точно, как надо.
Здравствуйте, Gaperton, Вы писали:
G>Не, так не пойдет. Это ж каждый может — online через futuresource или yahoo stocks . Ты вместо настоящих ядреных понтов какою-то ерунду мне хочешь подсунуть — расстройство одно. Я так понимаю, раз понты — так понты, блин, взялся — так уж будь любезен постарайся как следует. Короче, жду настоящих, серьезных понтов.
Ну я, прям, даже не знаю.
Q>>И хранятся они (сюрприз!) в базе данных, без всякого сжатия. G>Это для меня очень хорошая новость. Это меня радует .
А в чем радость? Реально не вижу смысла в сжатии, это усложняет загрузку/сохранение и, фактически, лишает смысла колоночную организацию хранения и mmap.
G>Мне как раз кажется извращением стараться уместить котировки в памяти. G>Во-первых, насколько я припоминаю, каждый сервер CQG по правилам 2005 года должен хранить истории котировок за 10 лет по всем крупным биржам мира. А в мире, если мне не изменяет память, примерно двадцать крупных бирж, не считая мелких, которые тоже не фигово хранить.
В памяти достаточно хранить данные за текущий день, потому как
1) их необходимо обновлять в real-time, т.е. обрабатывать сотни миллионов сообщений в день.
2) они наиболее часто используются
остальные грузятся по мере необходимости и потом выгружаются.
10-ть лет в 2005 году — это террабайт 10, столько в память никогда не уместить. Но это и не надо, столь старые данные используются очень редко.
G>Во вторых — ни единого резона держать котировки в памяти нет. При желании, мы можем читать их с диска раз как минимум в десять быстрее, чем их в состоянии обрабатывать торговые роботы. Только по понятным причинам это нахрен никому не нужно, тем более — держать в памяти их BD. Что касается тех редких ситуаций, когда это реально требуется (не припомню таких ярковыраженных случаев, кстати, поправьте меня, очень интересно увидеть контрпример), достаточно простого кэширования котировок и агрегатов OHLC в памяти по сегментам. Не нужна никакая in-memory DB.
Вам не нужна, а нам нужна. Клиенты пользуются и не жалуются, им очень нравится скорость работы. Не могу понять, в чем состоит аргумент против БД. Единственный минус — стоимость обрудования и лицензии на ПО. Но если писать самим, то выгоды особой не будет все равно.
К тому же, я еще раз обращаю внимание, к БД прилагается еще очень мощный язык, который в своей области вне конкуренции. Он позволяет сделать с данными, что угодно, без необходимости что-то писать на С/C++/Java. Векторный Lisp по сути дела.
Вероятно, разногласия вызывает in memory. In memory она в том смысле, что все данные, кроме огромных исторических таблиц хранятся в памяти. История грузится по мере использования.
Здравствуйте, Quintanar, Вы писали:
Q>Вам не нужна, а нам нужна. Клиенты пользуются и не жалуются, им очень нравится скорость работы. Не могу понять, в чем состоит аргумент против БД. Единственный минус — стоимость обрудования и лицензии на ПО. Но если писать самим, то выгоды особой не будет все равно. Q>К тому же, я еще раз обращаю внимание, к БД прилагается еще очень мощный язык, который в своей области вне конкуренции. Он позволяет сделать с данными, что угодно, без необходимости что-то писать на С/C++/Java. Векторный Lisp по сути дела.
Мне очень интересно узнать где Вы работаете и подробности про kbd. Я предполагаю, что именно о ней Вы говорите выше.
Свяжитесь со мной, если не сложно, joel r1 a t gmail com.
Здравствуйте, Quintanar, Вы писали:
Q>>>И хранятся они (сюрприз!) в базе данных, без всякого сжатия. G>>Это для меня очень хорошая новость. Это меня радует .
Q>А в чем радость? Реально не вижу смысла в сжатии, это усложняет загрузку/сохранение и, фактически, лишает смысла колоночную организацию хранения и mmap.
Ну как сказать, просто есть разные подходы к хранению котировок. И меня очень радует тот факт, что в kdb применяется именно такой подход. Я уже вижу, как ее порвать на британский флаг на обработке котировок. Вот и радуюсь. Говорить пока не буду — во-первых, еще не порвал, во-вторых — пусть это будет моим маленьким секретом до поры.
G>>Мне как раз кажется извращением стараться уместить котировки в памяти. G>>Во-первых, насколько я припоминаю, каждый сервер CQG по правилам 2005 года должен хранить истории котировок за 10 лет по всем крупным биржам мира. А в мире, если мне не изменяет память, примерно двадцать крупных бирж, не считая мелких, которые тоже не фигово хранить.
Q>В памяти достаточно хранить данные за текущий день, потому как Q>1) их необходимо обновлять в real-time, т.е. обрабатывать сотни миллионов сообщений в день.
Обновлять тебе надо в 99 и 99999 % случаев только последнюю минуту, последовательно добавляя котировки. corrections редки для неэлектронных бирж, и практически отсуствуют для электронных, и для их обработки в любом случае нет real-time требований. Делайте выводы.
Q>2) они наиболее часто используются
Кем используются? Роботы историей котировок не пользуются, они на enevt-ах построены. Для исторической же аналитики применяются не котировки, а intraday и daily ohlc bars. Которые 1) не критичны к скорости построения, и 2) их, если вдуматься, можно очень по разному строить. Тоже пока не буду говорить, как.
Тем более, что обычно одновременно используются небольшой процент контрактов с биржи, занимать память на всякий случай под все — зачем?
Откровенно говоря, такой подход в kdb меня тоже сильно радует. Это означает, что характеристик движка kdb можно не слишком бояться — как-то слишком в лоб у них это сделано. Даже не верится. Реальная проблема — это их язык запросов. Но тут мы еще посмотрим, кто кого.
Q>остальные грузятся по мере необходимости и потом выгружаются.
Само собой.
Q>10-ть лет в 2005 году — это террабайт 10, столько в память никогда не уместить. Но это и не надо, столь старые данные используются очень редко.
Разумеется. Я это к тому привел, что in-memory DB вам не сильно поможет в данных задачах.
G>>Во вторых — ни единого резона держать котировки в памяти нет. При желании, мы можем читать их с диска раз как минимум в десять быстрее, чем их в состоянии обрабатывать торговые роботы. Только по понятным причинам это нахрен никому не нужно, тем более — держать в памяти их BD. Что касается тех редких ситуаций, когда это реально требуется (не припомню таких ярковыраженных случаев, кстати, поправьте меня, очень интересно увидеть контрпример), достаточно простого кэширования котировок и агрегатов OHLC в памяти по сегментам. Не нужна никакая in-memory DB.
Q>Вам не нужна, а нам нужна. Клиенты пользуются и не жалуются, им очень нравится скорость работы. Не могу понять, в чем состоит аргумент против БД. Единственный минус — стоимость обрудования и лицензии на ПО. Но если писать самим, то выгоды особой не будет все равно.
To make the things clear. Я не против kdb. Я считаю ее хорошим продуктом. Но я уверен, что учтя нюансы предметной области и используя свой опыт работы над сервером БД CQG смогу сделать лучше. И дешевле. Тут даже дело не столько в Эрланге. Сделать просто just for fun, но если получится хорошо — то можно попробовать и продать.
Q>К тому же, я еще раз обращаю внимание, к БД прилагается еще очень мощный язык, который в своей области вне конкуренции. Он позволяет сделать с данными, что угодно, без необходимости что-то писать на С/C++/Java. Векторный Lisp по сути дела.
Я не спорю, язык хорош, это серьезное достоинство kdb. Надо будет как следует подумать, что предложить взамен. Мне кажется, что учтя нюансы предметной области (там надо вполне конкретные вещи уметь делать, а не универсальные) и используя свой опыт работы над интерпретатором встроенного языка CQG (я ведущим спецом по архитектуре этого движка и встроенному языку был) я имею некоторые шансы сделать может и менее универсально, но не менее удобно в чем-то даже лучше .
Эти две темы — сервер котировок и встроенный язык — и были моей основной специализацией в CQG. Собственно, я был ведущим спецом именно по этим двум темам, и был тимлидом соответствующей группы разработки. По другим темам там были другие ведущие спецы, тем в CQG дохрена, как и ведущих спецов.
Теперь вы понимаете, почему я выбрал именно эти темы для своих развлечений с Эрлангом? Это вовсе не случайно. Просто это единственное, что я достаточно хорошо и глубоко знаю и пока еще помню — я ж не программил уже два последних года. Думаю, у меня есть определенные шансы на успех, как вам кажется?
Q>Вероятно, разногласия вызывает in memory. In memory она в том смысле, что все данные, кроме огромных исторических таблиц хранятся в памяти. История грузится по мере использования.
Разумеется, если они в память не влезают, то как еще.
Здравствуйте, Gaperton, Вы писали:
G>Ну как сказать, просто есть разные подходы к хранению котировок. И меня очень радует тот факт, что в kdb применяется именно такой подход. Я уже вижу, как ее порвать на британский флаг на обработке котировок. Вот и радуюсь. Говорить пока не буду — во-первых, еще не порвал, во-вторых — пусть это будет моим маленьким секретом до поры.
Хех, флаг в руки!
G>Обновлять тебе надо в 99 и 99999 % случаев только последнюю минуту, последовательно добавляя котировки. corrections редки для неэлектронных бирж, и практически отсуствуют для электронных, и для их обработки в любом случае нет real-time требований. Делайте выводы.
Недооцениваете количество corrections/cancelations. Реально их много, причем именно на электронных биржах. Особенно много на ADF. Но это, действительно, не существенно.
G>Кем используются? Роботы историей котировок не пользуются, они на enevt-ах построены. Для исторической же аналитики применяются не котировки, а intraday и daily ohlc bars. Которые 1) не критичны к скорости построения, и 2) их, если вдуматься, можно очень по разному строить. Тоже пока не буду говорить, как. G>Тем более, что обычно одновременно используются небольшой процент контрактов с биржи, занимать память на всякий случай под все — зачем? G>Откровенно говоря, такой подход в kdb меня тоже сильно радует. Это означает, что характеристик движка kdb можно не слишком бояться — как-то слишком в лоб у них это сделано. Даже не верится. Реальная проблема — это их язык запросов. Но тут мы еще посмотрим, кто кого.
Данные в памяти дают скорость. Не знаю, сколько у вас было клиентов, если мало, то такие рассуждения имеют право на существование, но когда к данным рвутся многие люди из разных отделов, которым надо разные данные, то желательно держать данные в памяти. Я тут посмотрел, типичный запрос выполняется меньше 100 миллисекунд.
G>Эти две темы — сервер котировок и встроенный язык — и были моей основной специализацией в CQG. Собственно, я был ведущим спецом именно по этим двум темам, и был тимлидом соответствующей группы разработки. По другим темам там были другие ведущие спецы, тем в CQG дохрена, как и ведущих спецов. G>Теперь вы понимаете, почему я выбрал именно эти темы для своих развлечений с Эрлангом? Это вовсе не случайно. Просто это единственное, что я достаточно хорошо и глубоко знаю и пока еще помню — я ж не программил уже два последних года. Думаю, у меня есть определенные шансы на успех, как вам кажется?
Попробуйте, попробуйте. Мне тоже очень приятна такая недооценка kdb-шного подхода. Тред выявил факт, что люди мало того, что не в курсе как оно бывает, так еще и не верят в эффективность метода.
Здравствуйте, Gaperton, Вы писали:
G>Насчет ситуации по движкам time series сейчас — я ее не отслеживал, но мой бывший коллега-MCSD, который сейчас делает решения для брокеров и автоматической торговли, говорит, что ситуация с тех пор изменилась не сильно.
Что думаете насчет Vertica? Это commercialization of the C-Store. Там и in-memory и компрессия. То же — пока (возможно, никогда) не открытая разновидность MonetDB — X100.
G>>Обновлять тебе надо в 99 и 99999 % случаев только последнюю минуту, последовательно добавляя котировки. corrections редки для неэлектронных бирж, и практически отсуствуют для электронных, и для их обработки в любом случае нет real-time требований. Делайте выводы.
Q>Недооцениваете количество corrections/cancelations. Реально их много, причем именно на электронных биржах. Особенно много на ADF. Но это, действительно, не существенно.
А Cancellations не надо резолвить при получении, зачем мне их учитывать. Их надо записывать так же, как и трейды. По другому некорректно.
G>>Кем используются? Роботы историей котировок не пользуются, они на enevt-ах построены. Для исторической же аналитики применяются не котировки, а intraday и daily ohlc bars. Которые 1) не критичны к скорости построения, и 2) их, если вдуматься, можно очень по разному строить. Тоже пока не буду говорить, как. G>>Тем более, что обычно одновременно используются небольшой процент контрактов с биржи, занимать память на всякий случай под все — зачем? G>>Откровенно говоря, такой подход в kdb меня тоже сильно радует. Это означает, что характеристик движка kdb можно не слишком бояться — как-то слишком в лоб у них это сделано. Даже не верится. Реальная проблема — это их язык запросов. Но тут мы еще посмотрим, кто кого.
Q>Данные в памяти дают скорость. Не знаю, сколько у вас было клиентов, если мало, то такие рассуждения имеют право на существование, но когда к данным рвутся многие люди из разных отделов, которым надо разные данные, то желательно держать данные в памяти. Я тут посмотрел, типичный запрос выполняется меньше 100 миллисекунд.
У нас на одной чикагской ферме 2000 клиентов висит одновременно. Так, для справки. CQG это не частная трейдерская конторка с отделами, это фид провайдер и сервис провайдер для профессиональных трейдеров и организаций в первой пятерке в США. Конкурирует с Bloomberg, reuters, и Trading Station.
Терминал CQG, который подсоединен к ферме, выполняющей мой код каждую секунду, вы найдете в любом крупном банке.
G>>Эти две темы — сервер котировок и встроенный язык — и были моей основной специализацией в CQG. Собственно, я был ведущим спецом именно по этим двум темам, и был тимлидом соответствующей группы разработки. По другим темам там были другие ведущие спецы, тем в CQG дохрена, как и ведущих спецов. G>>Теперь вы понимаете, почему я выбрал именно эти темы для своих развлечений с Эрлангом? Это вовсе не случайно. Просто это единственное, что я достаточно хорошо и глубоко знаю и пока еще помню — я ж не программил уже два последних года. Думаю, у меня есть определенные шансы на успех, как вам кажется?
Q>Попробуйте, попробуйте. Мне тоже очень приятна такая недооценка kdb-шного подхода. Тред выявил факт, что люди мало того, что не в курсе как оно бывает, так еще и не верят в эффективность метода.
Понимаете, какая между нами разница. Вы пользователь движка БД, а я их проектировщик . Вы только что дали мне достаточную информацию, по которой я уже могу оценить сильные и слабые стороны Kdb. Умею, понимаете? Вот все разное умеют, а я — это .
Здравствуйте, Gaperton, Вы писали:
G>У нас на одной чикагской ферме 2000 клиентов висит одновременно. Так, для справки. CQG это не частная трейдерская конторка с отделами, это фид провайдер и сервис провайдер для профессиональных трейдеров и организаций в первой пятерке в США. Конкурирует с Bloomberg, reuters, и Trading Station. G>Терминал CQG, который подсоединен к ферме, выполняющей мой код каждую секунду, вы найдете в любом крупном банке.
Не знаю. Bloomberg дает более качественные данные (его принято считать за эталон), у нас используется reuters для фидов, в перспективе, возможно, другие провайдеры, но о CQG речи не шло.
G>Понимаете, какая между нами разница. Вы пользователь движка БД, а я их проектировщик . Вы только что дали мне достаточную информацию, по которой я уже могу оценить сильные и слабые стороны Kdb. Умею, понимаете? Вот все разное умеют, а я — это .
Я вам не дал никакой информации, в том то и дело. Вы не знаете реально, как работает kdb, а имеете лишь приблизительное представление, искаженное вашими предрассудками.
И вот, реально, объясните зачем нужен Эрланг. Его главное преимущество — это параллельные процессы, как раз то, что не играет никакой роли в обработке униформных огромных объемов данных. Действительная арифметика там отстой, векторизации никакой нет, структуры данных типа таблиц не поддерживаются. Т.е. торможение во всем, а выгоды нет.
Здравствуйте, Quintanar, Вы писали:
G>>Терминал CQG, который подсоединен к ферме, выполняющей мой код каждую секунду, вы найдете в любом крупном банке.
Q>Не знаю. Bloomberg дает более качественные данные (его принято считать за эталон), у нас используется reuters для фидов, в перспективе, возможно, другие провайдеры, но о CQG речи не шло.
Фид Cqg на CBOT принят как эталон и применяется при разрешении споров. У Cqg очень качественный фид. Единственное — опционный фид говно, там биды с асками не отменяются, как в блумберге.
G>>Понимаете, какая между нами разница. Вы пользователь движка БД, а я их проектировщик . Вы только что дали мне достаточную информацию, по которой я уже могу оценить сильные и слабые стороны Kdb. Умею, понимаете? Вот все разное умеют, а я — это .
Q>Я вам не дал никакой информации, в том то и дело. Вы не знаете реально, как работает kdb, а имеете лишь приблизительное представление, искаженное вашими предрассудками.
Я могу многое вывести из ваших слов, больше чем вы можете представить, потому что знаю наперед практически все варианты, как может быть устроен сервер обработки котировок. Это было моей работой.
Q>И вот, реально, объясните зачем нужен Эрланг. Его главное преимущество — это параллельные процессы, как раз то, что не играет никакой роли в обработке униформных огромных объемов данных. Действительная арифметика там отстой, векторизации никакой нет, структуры данных типа таблиц не поддерживаются. Т.е. торможение во всем, а выгоды нет.
Хо-хо Не забывайте, что на очень тормозном эрланге сделан самый быстрый АТМ софтсвитч Axd301.
Вы упускаете фактор отказоустойчивости, и недооцениваете роль паралеллизма в данной задаче. Не говоря о мелочах вроде способности эрланга обрабатывать бинарные данные, его Real-time характеристики, способность держать высокую нагрузку, и распределенную бд Mnesia в стандартной либе.
Короче, не учитываете вы близость телекомовских и финансовых требований.
Насчет плавающей запятой — можно очень много и без этого. Сервер Cqg половину ареобразований производит в целых числах. Кроме того, она компилируется в родную запятую если поставить гвард.
Так что есть кое-какие ходы. Почитайте диссертацию Армстронга.
Здравствуйте, awson, Вы писали:
A>Здравствуйте, Gaperton, Вы писали:
G>>Насчет ситуации по движкам time series сейчас — я ее не отслеживал, но мой бывший коллега-MCSD, который сейчас делает решения для брокеров и автоматической торговли, говорит, что ситуация с тех пор изменилась не сильно.
A>Что думаете насчет Vertica? Это commercialization of the C-Store. Там и in-memory и компрессия. То же — пока (возможно, никогда) не открытая разновидность MonetDB — X100.
Vertica — выглядит как ацкая штука. У них в основателях сам Стоунбрейкер. Это звучит очень страшно на первый взгляд — прям также, как и "динозавр" "наклепает". О-о-о! Но давайте почитаем их white paper. Бояться не надо, надо знать.
Column-orientation
Since many database queries are “disk bound”, meaning D > C, the most obvious performance
advantage of Vertica is that it only needs to read the two columns involved in the query from disk.
In a traditional row-oriented database, the disk would need to scan over all five columns.
Для справки: все современные взрослые сервера реляционных баз данных (я говорю об Oracl, MS SQL, Sybase) используют именно такое представление спокон веков. Единственным заметным исключением является MySQG со своим InnoDB, где данные хранятся построчно. И разработчики рефлексируют на эту тему в соответствующих White Papers.
Но кстати, именно в финансовых приложений от такого представления толку полный ноль, там как раз выгоднее хранить данные построчно. Колонок, видите-ли немного. И количество популярных вариантов выборок совсем небольшое.
Aggressive Compression
Мурашки по коже. Ну все, концы. Читаем дальше.
This means that, rather than representing the price column as a list of the form
(price1, price1, ...., price2, price2, ... ), we can represent it as a run-length encoded (RLE) list of
the form (<count, price1>, <count, price2>, ....), which will be about 27 times smaller than the
initial representation.
Гы-гы-гы! От такой наивной компрессии на реальных котировках толку немного — повторение цен редко, цену постоянно колбасит вверх-вниз. Особенно, если хранить биды/аски в одной таблице с трейдами. К примеру, схемы компрессии, которые разрабатывались и применялись в моей группе, дают устойчивые коэффициенты компрессии в 4 раза на реальных котировках без повторений цены (плотнее ужать невозможно в принципе), при этом просты как топор и совершенно не нагружают ЦП.
То же самое касается компрессии LZ. Мимо.
А вот Delta Compression — это уже больше подходит к задаче. Это уже серьезно. Только есть нюанс — база не знает, что хранит временной ряд котировок. Зная это, они могли бы сделать эффективную схему компрессии, полагаясь на физическую упорядоченность данных по этому критерию, одновременно привязав к нему схему хранения данных на диске, а не зная этого — эффективную и простую схему компрессии сделать очень сложно (я бы сказал, в данной области универсальное решение будет сложнее и заметно проиграет по эффективности специализированному).
То, что они могут выполнять трансормации "прямо на закомпрессированных данных" — вранье, вернее, маркетинговый ход. Утверждение, лишенное особого инженерного смысла, но убедительно звучащее. Улыбнуло .
Тестам производительности и цифрам "ускорения" из white papers доверять нельзя — они не сообщают не то что информацию о тестах, но даже на каких классах финансовых приложений они это меряют.
В реальности, для out of process серверов финансовых данных основная проблема — даже не сжатие котировок, а скорость межпроцессного обмена. Вся прозводительность убьется на межпроцессной передаче. MS SQL, к примеру, теряет на ней производительность в 10 раз на финансовых задачах. И при этом смысла нет application server крутить целиком на хранимых процедурах — это очень геморройно.
kdb в целом выглядит существенно лучше. Он по крайней мере знает, что хранит временной ряд котировок, и у них есть готовые решения для финансовой области, начиная от парсеров фидов. А Vertica надо еще напильником допиливать, делая всю основную работу самому.
Короче, если работаешь в трейдерской компании, и не занимаешься профессионально разработкой движков БД в этой области — Vertico можно включить в рассмотрение, Oracle и MS SQL она судя по всему побьет. Но все это стадо на этом поле все равно отимеет kdb. Для компании-разработчика трейдерских технологий, таких как FutureSource, CQG, TradingStation — проще и лучше использовать качественный и простой in-process ISAM-движок.
MonetDB — вообще совершенно непонятно, почему должна подойти для финансовых приложений. Сложных запросов к данным, которые так классно типа выполняет MonetDB, и в чем ее основная рекламируемая фишка — в финансовых приложениях нет. Живет она в отдельном процессе, что либо замедлит обработку, либо вынудит весь сервер писать на хранимых процедурах или плагинах к MonetDB — ай как нехорошо, проще воспользоваться простой базой ISAM. Все запросы предельно тупые, в 99,9% случаев выполняются в одну пробежку по одной таблице. Не нужна и колоночная организация, от нее ноль бенефита. Не нужна in-memory database — все можно вполне успешно хранить на дисках, скорости хватит с избытком.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Quintanar, Вы писали: Q>>И вот, реально, объясните зачем нужен Эрланг. Его главное преимущество — это параллельные процессы, как раз то, что не играет никакой роли в обработке униформных огромных объемов данных. Действительная арифметика там отстой, векторизации никакой нет, структуры данных типа таблиц не поддерживаются. Т.е. торможение во всем, а выгоды нет.
G>Насчет плавающей запятой — можно очень много и без этого. Сервер Cqg половину ареобразований производит в целых числах. Кроме того, она компилируется в родную запятую если поставить гвард.
можно насчет плавающей точки поподробнее рассказать или указать где почитать? а то планирую кое какой софт выдать сравнительную версию на ерланг, но там плавающая точка достаточно важна (точнее важна до 3-5 знака после запятой в результате, но без потерь в получении этого результата в ходе мат операций)
Здравствуйте, BulatZiganshin, Вы писали: BZ>а ты сможешь ему обеспечить привычную по мегаполису среду существования? я не просто так спрашиваю, дело в том, что учёные проводили эксперименты и выяснили, что выходцы из крупных городов в отсуствии смога гибнут через 2-3 месяца
А вдруг он уже устал от города?
Я вот устал... пару лет назад перебрался жить в лес. (Правда северный и прохладный — не люблю жару...)
Здравствуйте, Alex EXO, Вы писали:
AE>Здравствуйте, BulatZiganshin, Вы писали: BZ>>а ты сможешь ему обеспечить привычную по мегаполису среду существования? я не просто так спрашиваю, дело в том, что учёные проводили эксперименты и выяснили, что выходцы из крупных городов в отсуствии смога гибнут через 2-3 месяца
AE>А вдруг он уже устал от города? AE>Я вот устал... пару лет назад перебрался жить в лес. (Правда северный и прохладный — не люблю жару...)
Я вот тоже думаю...
Правда может не совсем в лес, но от смога уже есть некоторая усталость — думаю, нужно ли оно мне?
.
, я задумал реализовать на нем наш сервер, чтобы упростить работу со многими клиентами, в часности, да и cpp-specific баги надоели 
. Quintanar, я очень хорошо к вам отношусь, на самом деле. 
