|
|
|
Проектирование БД для хранения временных рядов.
|
|||
|---|---|---|---|
|
#18+
Приветствую всех, с наступившим НГ и наступающем рождеством. Коллеги, стоит задача проектирования БД - хранилища информации о биржевых котировках. Все дело будет строиться на SQL CE или Express Edition, предпочтительно 1й вариант. Храниться будет информация о котировках разных биржевых инструментов. Предполагаемые объемы информации (верхняя граница): 500-1000 инструментов * 100 000 записей. Данные представляют собой времянные ряды, упорядоченные по времени. Дилема следующая, хранить ли все записи в одной таблице или под каждый инструмент выделить отдельную таблицу, чтобы сократить время на поиск и размер БД (т.к. будет отсутствовать поле с названием инструмента, на вскидку экономия 100-200 мб)? Опять же оптимально ли выделение отдельных таблиц под каждый инструмент, нет ли ограничения на максимальное количество таблиц в БД? Спасибо. Модератор: Тема перенесена из форума "Microsoft SQL Server". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2009, 15:49 |
|
||
|
Проектирование БД для хранения временных рядов.
|
|||
|---|---|---|---|
|
#18+
Наверное надо Edition по серьезнее, секционировать по кластерному индексу (дате). А Ограничения на кол-во таблиц в MS SQL нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2009, 16:32 |
|
||
|
Проектирование БД для хранения временных рядов.
|
|||
|---|---|---|---|
|
#18+
Angeld, Коллега подумайте на данном этапе об архитектуре. SQL Server CE Edition разумно использовать для оперативной организации Ваших Данных, но никак не для статического хранилища. Вам стОило бы посмотреть в сторону BI (OLAP) тулс на основе Enetrprise как минимум. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2009, 16:50 |
|
||
|
Проектирование БД для хранения временных рядов.
|
|||
|---|---|---|---|
|
#18+
Mr Marmelad Коллега подумайте на данном этапе об архитектуре. SQL Server CE Edition разумно использовать для оперативной организации Ваших Данных, но никак не для статического хранилища. Не могли бы вы объяснить почему, или указать где об этом можно прочитать. В принципе БД нужна как хранилище кеша, т.е. нагрузка на нее не будет слишком большой, как альтернатива можно написать свой небольшой DataBase Engine, однако пока решил изучить вопрос с помощью имеющихся средств. Mr MarmeladВам стОило бы посмотреть в сторону BI (OLAP) тулс на основе Enetrprise как минимум. Понятно, что SQL CE и Express не чета Enterprise, однако хочу добиться того, чтобы приложение было переносимым, без установки сервера, поэтому решил остановиться на SQL CE. Боюсь что на Enterprise не хватит бюджета. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2009, 17:30 |
|
||
|
Проектирование БД для хранения временных рядов.
|
|||
|---|---|---|---|
|
#18+
AngeldВ принципе БД нужна как хранилище кеша, т.е. нагрузка на нее не будет слишком большой А простите что имеется ввиду - если Хранилище данных - понятно, если КЭШ тоже - а это - как вы сказали ? Хранилище КЭША? Не объектную ли базу Вы имеете ввиду Коллега? Есть продукт под названием CASHE от InterSystems ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2009, 17:54 |
|
||
|
Проектирование БД для хранения временных рядов.
|
|||
|---|---|---|---|
|
#18+
> SQL CE или Express Edition Нормальные СУБД религия не позволяет использовать, обязательно кастрированные? > Дилема следующая Нет никакой дилеммы. Отталкиваться следует от аналитической софтинки, которую предполагается использовать, и характера обработки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2009, 18:22 |
|
||
|
Проектирование БД для хранения временных рядов.
|
|||
|---|---|---|---|
|
#18+
Mr Marmelad А простите что имеется ввиду - если Хранилище данных - понятно, если КЭШ тоже - а это - как вы сказали ? Хранилище КЭША? Не объектную ли базу Вы имеете ввиду Коллега? Есть продукт под названием CASHE от InterSystems Вобщем, есть программа поставщик биржевых данных (сервер), работает в real-time и хранит данные в RAM, интервал данных ограничен текущим днем. Есть клиенты, которые получают данные от сервера, иногда клиентам необходимо получить доступ к данным старше текущего дня, например за предыдущую неделю - для этого нужно хранилище данных. После получения данных клиентом от сервера из хранилища, эти данные кешируются самим клиентом, и в дальнейшем используется только текущая информация которая доступна в оперативной памяти. Таким образом доступ к данным сервера-хранилища происходит несколько раз в минуту (пик нагрузки), что не так много. ПОЭТОМУ, меня устроит любое решение с производительностью получения 10 000 записей в 3-5 секунд, основные требования: 1. Мобильность БД - без установки громоздкого сервера 2. Относительная надежность. Т.к. с базой данных будет работать максимум 1-3 клиента, особой прыти от БД не требуется. з.ы. Mr Marmelad, когда Вы говорили то SQL CE не приспособлен для хранения данных, что именно имели ввиду? Тормознутость, ненадежность, или что-то другое. Спасибо, Коллега! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2009, 18:45 |
|
||
|
Проектирование БД для хранения временных рядов.
|
|||
|---|---|---|---|
|
#18+
guest_20040621> SQL CE или Express Edition Нормальные СУБД религия не позволяет использовать, обязательно кастрированные? Религия, требует мобильности, т.е. CE или файлы - это круг моего выбора. Опять же? задачи не такого масштаба чтобы под них приобретать Enterprise версии. guest_20040621 > Дилема следующая Нет никакой дилеммы. Отталкиваться следует от аналитической софтинки, которую предполагается использовать, и характера обработки. Характер софтины описал в предыдущем посте. 90% запросов в виде "select * from table_name where DatTime > '2009-01-01 10:00:00'" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2009, 18:50 |
|
||
|
Проектирование БД для хранения временных рядов.
|
|||
|---|---|---|---|
|
#18+
> Религия, требует мобильности, т.е. CE или файлы - это круг моего выбора Не могу вспомнить терминал, который бы работал только с СУБД. На мой взгляд, такой необходимости нет. Перезаказать архивные данные для клиента - это простая и незатратная операция. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2009, 19:06 |
|
||
|
Проектирование БД для хранения временных рядов.
|
|||
|---|---|---|---|
|
#18+
AngeldПОЭТОМУ, меня устроит любое решение с производительностью получения 10 000 записей в 3-5 секунд, основные требования: 1. Мобильность БД - без установки громоздкого сервера 2. Относительная надежность. Т.к. с базой данных будет работать максимум 1-3 клиента, особой прыти от БД не требуется. з.ы. Mr Marmelad, когда Вы говорили то SQL CE не приспособлен для хранения данных, что именно имели ввиду? Тормознутость, ненадежность, или что-то другое. Спасибо, Коллега! Судя по данному описанию платформа выбрана верно. У Вас есть центральное хранилище к которому Вы обращаетесь за текущими значениями. Пример такой архитектуры описан здесь Но сама база - пожалуйста имейте это в виду - ХРАНИЛИЩЕ ДАННЫХ - должна быть серъёзно разработана прежде чем вы перейдёте к клиентскому приложению. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2009, 19:12 |
|
||
|
Проектирование БД для хранения временных рядов.
|
|||
|---|---|---|---|
|
#18+
AngeldХарактер софтины описал в предыдущем посте. 90% запросов в виде "select * from table_name where DatTime > '2009-01-01 10:00:00'" Коллега, Ваша задача создать отличный аналитический тул с возможностью динамического поиска по дате. Для начала постройте модель ХРАНИЛИЩА. Разберитесь КАК им управлять и как складировать Ваши данные. Посмотрите литературу по Data Warehouse, Data mart, Data Mining. Создайте рабочую модель. Размещение ее ДОЛЖНО БЫТЬ НА СОЛИДНОМ и УСТОЙЧИВОМ железе. Оперативный доступ к нему Вам пожалуй будет удобнее вести из СЕ. Для полной уверенности создайте ВСЕ возможные варианты ваших запросов. А потом делайте решение как их осуществлять. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2009, 19:21 |
|
||
|
Проектирование БД для хранения временных рядов.
|
|||
|---|---|---|---|
|
#18+
Так всетаки как лучше сделать в моем случае,с позиции производительности, много таблиц под каждый инструмент или все данные в одной таблице? Спасибо за ответы! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2009, 20:18 |
|
||
|
Проектирование БД для хранения временных рядов.
|
|||
|---|---|---|---|
|
#18+
Angeld...или все данные в одной таблице? Коллега А что в ЭТОЙ ОДНОЙ ТАБЛИЧКЕ Вы хотели бы увидеть, позвольте Вас спросить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2009, 21:47 |
|
||
|
Проектирование БД для хранения временных рядов.
|
|||
|---|---|---|---|
|
#18+
Angeld...или все данные в одной таблице? Традиционную системку подобную Вашей делают на основе Дата мартов. Дата Марты состоят из табличек входящих в СТАР схемки и СНЕЖИНКИ схемки. Такое размещение особенно поддерживается для большого и сложного поиска. Участки (лучи или измерения) звёздочек которые динамически меняются медленно рекомендуется статически содержат на клиенте. aka CE Client Footprint. Фактическую часть или динамику поиска обновлять по мере необходимости. Но до этих тонкостей как я понимаю Вам пока ещё далеко. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2009, 21:53 |
|
||
|
Проектирование БД для хранения временных рядов.
|
|||
|---|---|---|---|
|
#18+
> с позиции производительности Много таблиц. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2009, 22:02 |
|
||
|
Проектирование БД для хранения временных рядов.
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Много таблиц. Не однозначно. Если потребуется сравнивать разные инструменты для получения какого-либо собственного индекса (а вдруг их много?), то автор замучается. Если данные различаются только видом инструмента, то достаточно одной таблицы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2009, 23:35 |
|
||
|
Проектирование БД для хранения временных рядов.
|
|||
|---|---|---|---|
|
#18+
Angeld, бесплатные версии имеют ограничения на размер БД. Посчитайте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2009, 23:42 |
|
||
|
Проектирование БД для хранения временных рядов.
|
|||
|---|---|---|---|
|
#18+
Angeld, Может Вам задуматься о выборе СУБД? Вы сами эту тему "трёте" здесь уже долго. Это в другой топик. Но готовьтесь к буре "оваций" и к тому что про Вас скоро забудут. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.01.2009, 00:30 |
|
||
|
Проектирование БД для хранения временных рядов.
|
|||
|---|---|---|---|
|
#18+
> Не однозначно. Если хотите выглядеть многозначительно, лучше при этом ковырять пальцем в носу. Выглядит убедительнее. > Если потребуется сравнивать разные инструменты для получения какого-либо собственного индекса (а вдруг их много?), то > автор замучается. Какой индекс? Какие сравнения? Чего с чем? Вы себе хотя бы приблизительно представляете функции клиентского терминала? Автору: не парьтесь, нафиг здесь не нужны СУБД. Файлов достаточно. Нужна клиенту аналитика - дайте ему конвертор, пусть заливает котировки куда угодно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.01.2009, 01:08 |
|
||
|
Проектирование БД для хранения временных рядов.
|
|||
|---|---|---|---|
|
#18+
guest_20040621, Уважаемый, термин "индекс" - это не только базы данных. У автора топика задача хранить биржевые котировки. По ним можно строить аналитеческие индекы. Возможно Вам надо подучиться , а затем направлять чужие пальцы. Ваша активность на этом форуме похвальна, но иногда Вас заносит. Надо быть сдержанней. Это полезно для здоровья (без шуток). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.01.2009, 01:19 |
|
||
|
Проектирование БД для хранения временных рядов.
|
|||
|---|---|---|---|
|
#18+
> У автора топика задача хранить биржевые котировки. Читать я умею, спасибо. > По ним можно строить аналитеческие индекы. В совершенстве владея телепатическими методами, я догадался, что под "индексами" Вы таки имеете в виду технический анализ. Кроме статистической обработки временных рядов (что является единственно приемлемым методом при системной торговле) активно используются и графические методы анализа. Правда, статистическая обработка так и называется "статистической обработкой", а стандартные функции для графического анализа (вообще говоря, не обязательно графического) называются индикаторами. Такой вот устоявшийся термин. Индекс - применительно к биржевой торговле - это такая функция, которая отражает состояние некоторого набора биржевых инструментов. Индексы часто формируются торговыми площадками и как правило носят справочный или технический характер (реже - выступают в качестве самостоятельных инструментов срочного рынка). > Возможно Вам надо подучиться , а затем направлять чужие пальцы. Полагаю, приведенных выше сведений достаточно для того, чтобы посмотреть в зеркало и увидеть там того, кому "надо подучиться"? > Ваша активность на этом форуме похвальна, но иногда Вас заносит. Надо быть сдержанней. Вопросов в этом форуме я давно не задаю и советы мне без надобности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.01.2009, 02:20 |
|
||
|
Проектирование БД для хранения временных рядов.
|
|||
|---|---|---|---|
|
#18+
в случае, если информацию необходимо просто хранить, по запросу выдавать только "больше даты", то смысла в РСУБД нет. достаточно persistent-объектов. но вот насчет объемов данных, мне кажется, вы ошибаетесь. взять ту же ММВБ, думаю там инструментов много больше 500 - как минимум бонды, акции, фьючерсы и прочие деривативы, валюта. бонды еще бьются на корпоративные, госы, муниципальные. и ведь в России не одна биржа. с какой частотой вы собираетесь сохранять котировки? посчитаем "в лоб" минимальный объем данных: идентификатор инструмента - 2 байта котировка bid - 8 байт котировка ask - 8 байт дата и время - 8 байт итого на одну запись - 26 байт. отбросим выравниванием строк на страницах данных. 26 байт * 1 000 * 100 000 получается примерно 2.6 ГБ, а не 100-200 МБ. добавить индексы - +20-30% к объему. можно конечно подсократить размер строки, но порядок цифр все равно превышает ваши ожидания. 2Mr Marmelad - не надо под любым словом "хранилище" понимать именно хранилище данных (Data Warehouse). хотя разработка ХД - это как правило большой и вкусный проект ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.01.2009, 02:40 |
|
||
|
Проектирование БД для хранения временных рядов.
|
|||
|---|---|---|---|
|
#18+
guest_20040621, Похвально. Читать Вы умеете. Собирать информацию по разным "педиям" тоже. Я, собственно, предположил о возможной потребности автора строить собственные аналитические индексы. Имею ввиду получать аналитику в том или ином виде. Ваш совет со многими таблицами (по автору 500 - 1000) поспешен. Offtop. Заявления типа "давно не спрашиваю", "советы не нужны" присущи людям ограниченным, агрессивным, не коммуникабельным. Вас не имею ввиду. Но... Успехов. P.S. Возможно прочитав все топики автора Вы зделаете предположения о его действительной проблеме. И если "копались в кишочках" данной предметной области, поймете Вашу неправоту с файлами, конверторами и прочим. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.01.2009, 02:57 |
|
||
|
Проектирование БД для хранения временных рядов.
|
|||
|---|---|---|---|
|
#18+
guest_20040621Вопросов в этом форуме я давно не задаю и советы мне без надобности. Имелась ввиду Ваша активность в ответах. :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.01.2009, 03:08 |
|
||
|
Проектирование БД для хранения временных рядов.
|
|||
|---|---|---|---|
|
#18+
> Собирать информацию по разным "педиям" тоже. "Педиями" не пользуюсь. > Ваш совет со многими таблицами (по автору 500 - 1000) поспешен. Мой совет автору вопроса - избегать таблиц. Файлов достаточно. Ибо нафиг не нужны клиенту таблицы. Напрасный оверхед и для работы, и для хранения, и для обновления. Более того, и файлы можно дополнительно разбить по таймфреймам. > И если "копались в кишочках" данной предметной области, поймете Вашу неправоту с файлами, конверторами и прочим. Назначение терминала - оперативная реакция трейдера или МТС. Не существует ни одного терминала с вменяемой аналитикой. И "прикрутить" такую аналитику - чрезвычайно геморройное занятие. По двум причинам: во-первых, специализированные аналитические пакеты приемлемого качества уже стоят смешных денег, во-вторых, бессмысленно развивать монстрообразный пакет, который будет потенциально интересен очень ограниченному количеству пользователей. Кроме того, качество и функционал существующих терминалов с точки зрения их основного назначения - это отдельная большая проблема, работать нужно в первую очередь над ней, а не над финтифлюшками. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.01.2009, 04:18 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=35746208&tid=1543483]: |
0ms |
get settings: |
7ms |
get forum list: |
11ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
176ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
52ms |
get tp. blocked users: |
1ms |
| others: | 241ms |
| total: | 502ms |

| 0 / 0 |
