Как рационально объединить большие массивы структур. - страница 3

 
Sergey Savinkin:
Можно и в Access, и в SQL, и в любой базе данных. У меня задача не просто объединить данные. Суть в том, что несколько индикаторов работают на одном графике (в разных терминалах) и пишут историю в один файл. Чтобы не было конфликтов, и один не затер данные другого, а наоборот - добавил пропуски, мне и нужно считывать большие массивы из файла, обновлять и записывать. А чтобы пропусков на истории было еще меньше - время считывания / проверки / перезаписи должно быть минимальным.

Отметки времени, которые Вы пишете в один файл, проставляются разными серверами, у каждого свое системное время. Лет 8 назад я сравнивал последнее достигнутое время на 31 ДЦ по окну обзора рынка, разница в 3 секунды - это было еще ничего, у некоторых время вообще не синхронизировалось с астрономическим. Вас интересует последовательность значений курсов или не надо, хватит и просто неупорядоченного их списка? Если Вы будете в момент записи заменять серверное время на локальный момент записи на диск, оно будет скакать вместе с системным таймером на 16 мс в зависимости от длины текущих очередей потоков за процессорным временем. Куда девать эту рассинхронизацию?

Преодолеть эту проблему можно так: каждый из терминалов пишет в свой файл, а программа, которая эти данные считывает, делает это каждые 16 мс и проставляет им единое время считывания по своему системному таймеру. Тогда "время" будет означать момент, когда Ваш компьютер уже мог использовать данные.

 
Vladimir:

Отметки времени, которые Вы пишете в один файл, проставляются разными серверами, у каждого свое системное время. Лет 8 назад я сравнивал последнее достигнутое время на 31 ДЦ по окну обзора рынка, разница в 3 секунды - это было еще ничего, у некоторых время вообще не синхронизировалось с астрономическим. Вас интересует последовательность значений курсов или не надо, хватит и просто неупорядоченного их списка? Если Вы будете в момент записи заменять серверное время на локальный момент записи на диск, оно будет скакать вместе с системным таймером на 16 мс в зависимости от длины текущих очередей потоков за процессорным временем. Куда девать эту рассинхронизацию?

Преодолеть эту проблему можно так: каждый из терминалов пишет в свой файл, а программа, которая эти данные считывает, делает это каждые 16 мс и проставляет им единое время считывания по своему системному таймеру. Тогда "время" будет означать момент, когда Ваш компьютер уже мог использовать данные.

1. Что касается 16 мс - это не критично, запись все равно ведется с точностью до секунды. В файл пишутся показания на конец секунды.

2. Что же касается разницы в 3 секунды - это важно. Не знал, что данные с одного счета, но с разных терминалов обрабатываются на разных серверах. Дайте ссылку, пожалуйста, где это можно изучить подробнее.

З.Ы. Не знаю, важно ли это, но запись идет не с ДЦ, а с FORTS, брокер БКС.

 
Sergey Savinkin:

1. Что касается 16 мс - это не критично, запись все равно ведется с точностью до секунды. В файл пишутся показания на конец секунды.

2. Что же касается разницы в 3 секунды - это важно. Не знал, что данные с одного счета, но с разных терминалов обрабатываются на разных серверах. Дайте ссылку, пожалуйста, где это можно изучить подробнее.

З.Ы. Не знаю, важно ли это, но запись идет не с ДЦ, а с FORTS, брокер БКС.

Я говорил о разных ДЦ на розничном форекс. Соответственно, о разных счетах. Хотя не понимаю, как Вы связываете момент прихода тика в терминал с обработкой торговых приказов.

Если биржа - все, отбой. У них торговля реальная, отметка времени критична, применяется синхронизация с астрономическим по протоколам с погрешностью порядка 50 микросекунд, отдельный сервер раздачи времени, в итоге отличия от астрономического на каждом из торговых серверов не хуже 20 миллисекунд. БКС отметку (штамп) времени не портит, передает как есть.