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


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


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

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

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

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

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

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

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

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

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

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

Теги:


Спасибо:


< 1 2 3 4  > >>
ingeniero

Фотография
Дата: 07.02.2012
Ответить


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

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


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

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

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

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

vvt

Фотография
Дата: 07.02.2012
Ответить


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

freelancer

Фотография
Дата: 07.02.2012
Ответить


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

transdex

Фотография
Дата: 07.02.2012
Ответить


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

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


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

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

А также:

http://rts.micex.ru/a237

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

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

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




Спасибо: Павел

tmt

Фотография
Дата: 07.02.2012
Ответить


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

Mikhail Sukhov

Фотография
Дата: 07.02.2012
Ответить


ingeniero Перейти

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

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


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

Павел

Фотография
Дата: 07.02.2012
Ответить


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

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

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

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

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

Mikhail Sukhov

Фотография
Дата: 11.02.2012
Ответить


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


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

tmt

Фотография
Дата: 11.02.2012
Ответить


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


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

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

ingeniero

Фотография
Дата: 11.02.2012
Ответить


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


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


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

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

Добавить файлы через драг-н-дроп, , или вставить из буфера обмена.

loading
clippy