К вопросу о централизованной базе данных


К вопросу о централизованной базе данных
Atom Reply
1/17/2012


Господа, предлагаю обсудить проблему, с которой, очевидно, сталкиваемся мы все.

Я имею в виду экспорт и хранение информации о тиковых сделках и стаканах.
Каждый из нас вынужден ежедневно выполнять одни и те же действия: включение торгового терминала, запуск Гидры, старт экспорта.

Не кажется ли Вам, коллеги, что в 21 веке мы имеем все возможности для того, чтобы избавить себя от этой каждодневной рутины?
И не волноваться о пропущенном начале торгов.

Мне представляется, что все мы заинтересованы в одном: в доступе к надежной и полной базе данных по всем инструментам. Причем сегодня нам нужен фьючерс РТС, а через месяц мы вдруг решим поработать с рынком спот. Кто же скачает за нас стаканы с ММВБ за этот месяц? А если через полгода Вы неожиданно откроете для себя опционы?

Какой выход я предлагаю из этой ситуации?
Очевидно, VPS.

Я пользовался триальным сервером [цензура] и остался доволен качеством предоставляемых услуг. Они периодически отправляют мне свои рекламные предложения, и сейчас у них проходит акция с 35%-ной скидкой на годовое обслуживание.
Прошу Вас не считать это рекламой. Уверен, в случае необходимости мы сможем найти и другие приемлемые альтернативы.

Как инициатор я готов взять на себя все вопросы, связанные с организацией сбора средств, покупкой хостинга и установкой соответствующего ПО. И, безусловно, внести оплату в размере: (1/n)*(стоимость годового обслуживания), где n-количество первоначальных пользователей.

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

Система сбора и отправки платежей будет организована таким способом (PayPal?), что все денежные переводы будут контролироваться участниками и любая попытка использования этих средств не по назначению будет невозможна.

Прошу Вас высказывать свое мнение в этом топике и в случае, если Вы готовы принять участие в проекте, сообщить о своем решении.

Tags:


Thanks:




61 Answers
1 2 3  >
Alexander

Avatar
Date: 1/17/2012
Reply


Цитата:
вносить условную сумму, которая пойдет на развитие проекта


А о каком проекте речь? RollEyes
Thanks:

Павел

Avatar
Date: 2/4/2012
Reply


Видимо, речь идет о централизованно наполняемой базе данных на каком-нибудь "облачном" сервисе?
Thanks:

ingeniero

Avatar
Date: 2/5/2012
Reply


Павел
Видимо, речь идет о централизованно наполняемой базе данных на каком-нибудь "облачном" сервисе?


На первоначальном этапе это, конечно, будет VPS.
В перспективе, если БД будет востребована, можно купить хоть выделенный сервер.

Экспорт будет осуществляться через торговый терминал.
На мой взгляд, имеет смысл сохранять тиковые сделки и стаканы по всем инструментам (акции, фьючерсы, опционы) со всех площадок (ММВБ, РТС Стандарт, ФОРТС).
Когда появится коннектор к Zen-Fire, можно попросить у создателей коннектора интегрировать его в Гидру (в той части, которая отвечает за экспорт).
Потом открыть «пустой» счет у Mirus и сохранять маркет-дату по фьючерсам CME (+несколько инструментов на ICE, EUREX, NYSE Liffe).
Для доступа на все площадки нужен будет коннектор и, соответственно, аккаунт IB.

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

Павел

Avatar
Date: 2/6/2012
Reply


Но ведь объем данных будет колоссальным?!
Особенно если хранить "тиковые сделки и стаканы". Наверняка нужен сервер уровня используемых на биржах...

Но, вообще, мне это интересно как разработчику.
Готов сделать такую базу на PostgreSQL.
Thanks:

Alexander

Avatar
Date: 2/6/2012
Reply


Павел Перейти
Но ведь объем данных будет колоссальным?!
Особенно если хранить "тиковые сделки и стаканы". Наверняка нужен сервер уровня используемых на биржах...

Но, вообще, мне это интересно как разработчику.
Готов сделать такую базу на PostgreSQL.


Так у нас уже есть поддержка SQLite...
Thanks:

Павел

Avatar
Date: 2/6/2012
Reply


Alexander Mukhanchikov Перейти
Павел Перейти
Но ведь объем данных будет колоссальным?!
Особенно если хранить "тиковые сделки и стаканы". Наверняка нужен сервер уровня используемых на биржах...

Но, вообще, мне это интересно как разработчику.
Готов сделать такую базу на PostgreSQL.


Так у нас уже есть поддержка SQLite...

Да, я знаю об этом. Но PostgreSQL для задачи создания большой, многопользовательской, быстрой, транзакционной БД подойдет гораздо лучше. По сути это "бесплатный ORACLE".
Thanks:

Alexander

Avatar
Date: 2/6/2012
Reply


Павел Перейти
Alexander Mukhanchikov Перейти
Павел Перейти
Но ведь объем данных будет колоссальным?!
Особенно если хранить "тиковые сделки и стаканы". Наверняка нужен сервер уровня используемых на биржах...

Но, вообще, мне это интересно как разработчику.
Готов сделать такую базу на PostgreSQL.


Так у нас уже есть поддержка SQLite...

Да, я знаю об этом. Но PostgreSQL для задачи создания большой, многопользовательской, быстрой, транзакционной БД подойдет гораздо лучше. По сути это "бесплатный ORACLE".


У нас и поддержка MSSQL есть если что :)
Thanks:

Павел

Avatar
Date: 2/6/2012
Reply


Alexander Mukhanchikov Перейти
У нас и поддержка MSSQL есть если что :)

Так речь же идет не о поддержке СУБД, а о создании "большой базы данных".
Думаете, имеет смысл ориентироваться именно на коммерческий продукт, несовместимый с Linux?

Кстати, где можно почитать, что может нынешнее хранилище на MSSQL?
Thanks:

transdex

Avatar
Date: 2/6/2012
Reply


Павел Перейти
Но ведь объем данных будет колоссальным?!
Особенно если хранить "тиковые сделки и стаканы". Наверняка нужен сервер уровня используемых на биржах...

Колоссальным - это сколько?
Thanks:

Alexander

Avatar
Date: 2/6/2012
Reply


Павел Перейти
Alexander Mukhanchikov Перейти
У нас и поддержка MSSQL есть если что :)

Так речь же идет не о поддержке СУБД, а о создании "большой базы данных".
Думаете, имеет смысл ориентироваться именно на коммерческий продукт, несовместимый с Linux?

Кстати, где можно почитать, что может нынешнее хранилище на MSSQL?


sqlite с линуксом совместим.
почитать - в документации, раздел Гидра.
Thanks:

ingeniero

Avatar
Date: 2/7/2012
Reply


Павел
Но ведь объем данных будет колоссальным?!

Об объеме данных трудно судить, не имея архива за репрезентативный период времени.
Меня больше волнует требуемая производительность (и, соответственно, стоимость) машины, нежели объем жесткого диска.


Павел
PostgreSQL для задачи создания большой, многопользовательской, быстрой, транзакционной БД подойдет гораздо лучше.

Согласен. Но поддержку этой СУБД нужно еще добавить в Гидру.

Раз уж зашел разговор о Linux.
Безусловно, сервер на этой оси предпочтительнее. И дешевле.
Только, если портирование Гидры для Linux я еще представляю, что делать с коннекторами и торговыми терминалами?
Из наших терминалов (Quik, SmartCOM, AlfaDirect, Transaq, Alor), по-моему, ни один не имеет версии под Linux.
Можно настроить экспорт через виртуальную машину, но это потребует дополнительных ресурсов. И неизвестно, что будет дешевле: платить за лицензию или за ресурсы.

В итоге запустил я Гидру на VPS.
Предлагаю желающим настроить экспорт всех инструментов с Финама и РТС (или через терминал с пустым счетом), оценить объем данных и посмотреть на работу приложения при ограниченном объеме ресурсов.
Отписавшимся в этой теме отправил логины для доступа.
Topic starter
Thanks:

vvt

Avatar
Date: 2/7/2012
Reply


Отличная идея, готов поддержать.
Thanks:

freelancer

Avatar
Date: 2/7/2012
Reply


Кажется, всё это - околобиржевая ерунда.
Thanks:

transdex

Avatar
Date: 2/7/2012
Reply


ingeniero Перейти
Павел
Но ведь объем данных будет колоссальным?!

Об объеме данных трудно судить, не имея архива за репрезентативный период времени.
Меня больше волнует требуемая производительность (и, соответственно, стоимость) машины, нежели объем жесткого диска.


Рекомендую для начала ознакомиться:

http://bidaskhistory.ru/home.html
(судя по обновлению сайта , идея о "history стаканов за отдельную плату" не сильно популярна в массах)

А также:

http://rts.micex.ru/a237

Грубый подсчет:

http://ftp.rts.ru/pub/info/historical_data/

дает для RTS 4.5GB в месяц (сжатые текстовые файлы)




Thanks: Павел

tmt

Avatar
Date: 2/7/2012
Reply


Назвали бы хоть какие то цифры назвали.. я думаю что все скинутся по 10 баксов и не раз скинутся Smile И этого на месяц, два хватит.
Thanks:

Mikhail Sukhov

Avatar
Articles author Programmer Trader
Date: 2/7/2012
Reply


ingeniero Перейти

Павел
PostgreSQL для задачи создания большой, многопользовательской, быстрой, транзакционной БД подойдет гораздо лучше.

Согласен. Но поддержку этой СУБД нужно еще добавить в Гидру.


А для чего в этой задаче вообще БД?
Thanks:

Павел

Avatar
Date: 2/7/2012
Reply


Mikhail Sukhov Перейти
ingeniero Перейти

Павел
PostgreSQL для задачи создания большой, многопользовательской, быстрой, транзакционной БД подойдет гораздо лучше.

Согласен. Но поддержку этой СУБД нужно еще добавить в Гидру.

А для чего в этой задаче вообще БД?

Вот и обсуждаем :). Для данных "read only" это всегда вопрос обсуждаемый.
Если речь идет просто о хранении массивов котировок, то СУБД вроде и не нужна.
А вот если заниматься анализом данных, например, искать максимумы/минимумы, корреляции и т.п., то может и пригодиться.
К тому же, допустим, скачивать котировки и в "режиме реального времени" их транслировать желающим проще с помощью СУБД. Или я ошибаюсь?
Thanks:

Mikhail Sukhov

Avatar
Articles author Programmer Trader
Date: 2/11/2012
Reply


Павел Перейти
Вот и обсуждаем :). Для данных "read only" это всегда вопрос обсуждаемый.
Если речь идет просто о хранении массивов котировок, то СУБД вроде и не нужна.
А вот если заниматься анализом данных, например, искать максимумы/минимумы, корреляции и т.п., то может и пригодиться.
К тому же, допустим, скачивать котировки и в "режиме реального времени" их транслировать желающим проще с помощью СУБД. Или я ошибаюсь?


В начале говорилось о неком сервере, который копит исторические данные, и на который можно зайти и скачать необходимый для себя объем. Теперь речь идет не только об скачивание данных, но уже об анализе над ними. Так какую проблему решаем?
Thanks:

tmt

Avatar
Date: 2/11/2012
Reply


Mikhail Sukhov Перейти
Павел Перейти
Вот и обсуждаем :). Для данных "read only" это всегда вопрос обсуждаемый.
Если речь идет просто о хранении массивов котировок, то СУБД вроде и не нужна.
А вот если заниматься анализом данных, например, искать максимумы/минимумы, корреляции и т.п., то может и пригодиться.
К тому же, допустим, скачивать котировки и в "режиме реального времени" их транслировать желающим проще с помощью СУБД. Или я ошибаюсь?


В начале говорилось о неком сервере, который копит исторические данные, и на который можно зайти и скачать необходимый для себя объем. Теперь речь идет не только об скачивание данных, но уже об анализе над ними. Так какую проблему решаем?

По-моему сначало надо сделать 1ую часть, а анализ уже на своем ПК. Сомневаюсь что это надо всем, анализировать данные.
Thanks:

ingeniero

Avatar
Date: 2/11/2012
Reply


Mikhail Sukhov Перейти
Павел Перейти
Вот и обсуждаем :). Для данных "read only" это всегда вопрос обсуждаемый.
Если речь идет просто о хранении массивов котировок, то СУБД вроде и не нужна.
А вот если заниматься анализом данных, например, искать максимумы/минимумы, корреляции и т.п., то может и пригодиться.
К тому же, допустим, скачивать котировки и в "режиме реального времени" их транслировать желающим проще с помощью СУБД. Или я ошибаюсь?


В начале говорилось о неком сервере, который копит исторические данные, и на который можно зайти и скачать необходимый для себя объем. Теперь речь идет не только об скачивание данных, но уже об анализе над ними. Так какую проблему решаем?


На данный момент речь идет об экспорте тиковых сделок и стаканов по всем инструментам ММВБ-ФОРТС(-РТС Стандарт) через торговый терминал в файлы БД SQLite.
Если наберется достаточное количество заинтересованных участников и, соответственно, капитала (как финансового, так и интеллектуального), можно заняться решением более серьезных задач.

В любом случае надо с чего-то начинать.
И поскольку несколько человек уже сообщили о своем намерении участвовать в проекте, после решения организационных вопросов будем покупать хостинг.
Topic starter
Thanks:

Mikhail Sukhov

Avatar
Articles author Programmer Trader
Date: 2/11/2012
Reply


ingeniero Перейти

На данный момент речь идет об экспорте тиковых сделок и стаканов по всем инструментам ММВБ-ФОРТС(-РТС Стандарт) через торговый терминал в файлы БД SQLite.


Тики и стаканы сохраняются просто на диск ввиде файлов.

ingeniero Перейти

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

В любом случае надо с чего-то начинать.
И поскольку несколько человек уже сообщили о своем намерении участвовать в проекте, после решения организационных вопросов будем покупать хостинг.


Давайте и я поддержку проект. Сколько с носа?
Thanks:

ingeniero

Avatar
Date: 2/13/2012
Reply


В ближайшее время подготовлю несколько серверов для сравнения.
Выберем оптимальный вариант, тогда можно будет озвучить цены.
Topic starter
Thanks:

dvoris

Avatar
Date: 2/13/2012
Reply


Возможно, готов поучаствовать финансово в проекте (зависит от суммы), при условии что будет сохраняться направление тиковых сделок. Если будем писать ОИ для деривативов, то будем совсем хорошо :)
Thanks:

ingeniero

Avatar
Date: 2/20/2012
Reply


Господа,

Изучая рынок VPS-хостинга, прихожу к следующим выводам:
1. Стоимость сервера с приемлемой производительностью составляет $70-100 в месяц.
Таким образом, годовое обслуживание обойдется в 25000-30000 рублей.
На эту сумму можно купить компьютер уровня даже не виртуального, а выделенного сервера.
Плюс оплатить услуги двух интернет-провайдеров с учетом статического IP-адреса.

2. Является ли хостинговая компания (тем более зарубежная) надежным звеном при создании инфраструктуры?
Гарантирует ли кто-нибудь бесперебойную работу сервера?

3. От первоначальной идеи – создание единой базы данных по всем инструментам не отказываюсь, меняется лишь мое представление о концепции подобного сервиса.
Если раньше я считал, что коллективная покупка хостинга с установкой соответствующего ПО, избавит нас от проблем с экспортом, то сейчас я так не думаю. Такой подход решает одни проблемы, но добавляет другие.

Считаю, что необходимо поднимать свой сервер, настраивать экспорт и раздавать информацию по ftp. На данный момент создание подобной инфраструктуры не является для меня приоритетным, поэтому предлагаю вернуться к обсуждению через несколько месяцев.
Интересно будет посмотреть, если кто-то реализует подобное решение у себя.
Topic starter
Thanks:

tmt

Avatar
Date: 2/21/2012
Reply


ingeniero Перейти
Господа,

Изучая рынок VPS-хостинга, прихожу к следующим выводам:
1. Стоимость сервера с приемлемой производительностью составляет $70-100 в месяц.
Таким образом, годовое обслуживание обойдется в 25000-30000 рублей.
На эту сумму можно купить компьютер уровня даже не виртуального, а выделенного сервера.
Плюс оплатить услуги двух интернет-провайдеров с учетом статического IP-адреса.

2. Является ли хостинговая компания (тем более зарубежная) надежным звеном при создании инфраструктуры?
Гарантирует ли кто-нибудь бесперебойную работу сервера?

3. От первоначальной идеи – создание единой базы данных по всем инструментам не отказываюсь, меняется лишь мое представление о концепции подобного сервиса.
Если раньше я считал, что коллективная покупка хостинга с установкой соответствующего ПО, избавит нас от проблем с экспортом, то сейчас я так не думаю. Такой подход решает одни проблемы, но добавляет другие.

Считаю, что необходимо поднимать свой сервер, настраивать экспорт и раздавать информацию по ftp. На данный момент создание подобной инфраструктуры не является для меня приоритетным, поэтому предлагаю вернуться к обсуждению через несколько месяцев.
Интересно будет посмотреть, если кто-то реализует подобное решение у себя.

Я может смогу делиться стаканами RIH2.. Сегодня переделал гидру под себя, чтоб переподключался, правда у меня нетбук работает, но уже в автоматическом режиме. Сам выключается - включается, запускает квик, логинется и начинает качать) если кто-то предложит, как мне огранизовать передачу этих стаканов Вам (дело в том, что статический ip щас), то без проблем смогу делиться

И кстати.. Как можно будет качать стаканы всех инструментов(ну или тики)?! К примеру у меня за сутки программа перезапустилась 40 раз и это только по 1 инструменту (перезупуск происходит, как проходит 20 сек. с момента получения последнего стакана), чтож будет на 200 инструментах.. или 5000 я не представляю
Thanks:
1 2 3  >

Attach files by dragging & dropping, , or pasting from the clipboard.

loading
clippy