Имхо, тут напрашивается цепочка простейшая:
датчик - сервер (читает на порту пишет по TCP в центральную базу) - сервер.
Вот и все.. зачем что-то городить то?

FavnIP в полях, как бы это помягче, в наших широтах не надежен :) Промежуточные файлы нужны для асинхронности передачи, повтора заливки при ошибках и выживания не отправленных данных при сбоях сети/оборудования.
Вы наверно не поняли..
Это уже пройденный этап и все складно работает.
Стоит машина и на 232-порту слушает датчик (или их множество, но тут уже общую шину надо и есно собирать это с 485 на 232, но это нюансы). Принимает он эти данные, обрабатывает (а логику уж там можно реализовать любую) и по заданному алгоритму ( у меня тупо по времени) посылает данные, т.е. фактически пишет, на сервер СУБД (у меня сразу в базу пишет, если обрыв связи, а есть клиенты разнесенные на 50 км.. то пишет в локальную БД, потом просто открывает транзакцию и досылает данные).. отдельно у меня был открыт серверный поток для клиентов, которые в любой момент времени могли в реальном времени читать данные с датчиков (ка), т.е. это фактически вьющки, которые могли получать данные и только их отображать.
Ну а уж как сделать идентификацию – тут гораздо все проще – каждый клиент может иметь свой номер, который будет ID в базе.. в общем – задача тривиальная, на «пару дней работы».

Степан H.
я уже сомнивался в том, что оно вообще работает )) ....

Конечно, при заявленном времени,... Это и не должно работать по определению. :)
Степан H.
однако, я б (делал) сделал так.
1. выбросить на удаленных компах базу
2. писать данные в файл, потом архивировать (или писать в архив)
3. файл на сервере в базу вставлять одной транзакцией (в Postgres метод COPY)
4. в зависимости от способов дальнейшей обработки попробуйте использовать партицирование.
5. в зависимоти от того что нужно получить в "конечном итоге" попробуйте "размазать" нагрузку проца на сервере "по времени", тоесть не "напрягать" его, допустим, "раз в час" а чтоб постоянно занимался "предобработкой" данных, например на триггерном уровне. Бизнес-логика должна быть построена внутри самой СУБД.
п.5 возможно неактуальный
Если отбросить условия автора, и допустить реально выполнимые, то, в чем потаённый смысл такого усложнения?
Почему нельзя сразу писать в базу???

javamachine
На компе под OS WinXP...

1. Это не система реального времени. Если есть жесткие требования ко времени исполнения, стоит обратить внимание или на ОС реального времени, или, в крайнем случае, использовать например Lunux, и возможно не на новых ядрах (например, Debian на 2.0.х или 2.2.х).
javamachine
За одну секунду нужно добавлять в таблицу тысячу записей (каждый кортеж состоит из десятка INTов). Сеанс наблюдений (сбор данных с датчиков) продолжается сутки (итого из расчёта 1000 записей в секунду имеем около ста миллионов записей максимум в таблицы). В ходе сеанса сами данные никак не модифицирутся. После окончания сеанса информация из таблицы экспортируется в файлы с архивами, а сама таблица сносится ко всем чертям.

2. Исходя из первого.. Вы не сможете гарантировать такой интервал чтения/записи (чтение с порта запись на диск). По мимо всего прочего, ОС нужно время на собственные нужды.
javamachine
Всё это хозяйство работает медленнее, чем хотелось бы. Полного загрузочного тестирования я ещё не производил, но боюсь, что система с ним не справится. В связи с этим очень прошу порекомендовать мне какие-нибудь решения для данной ситуации.

3. Выражение «работает медленнее, чем хотелось бы» не допустимо при таких требованиях. Вы верно заметили – «Полного загрузочного тестирования я ещё не производил, но боюсь, что система с ним не справится.».
javamachine
В частности, возникают следующие вопросы: какую СУБД стоит использовать для подобных задач;
какие настройки (в общих словах: тип таблиц, etc.) вы порекомендуете использовать и почему?

4. Вопрос выбора СУБД второстепенный в данном случае. На первом месте, имхо, стоит выбор ОС. Но, возможно (в зависимости от нагрузки и требований, а также «полевых испытаний»), понадобится СУБД реального времени (например, IndustrialSQL, InfoPlus и т.д.). Все эти решения стоят денег. Хотя, можно что поискать и на халяву.
javamachine
А если более глобально - как бы вы решали подобную задачу (передача данных с удалённых объектов по TCP/IP c целью их дальнейшей обработки)?

5. А вот тут, все зависит от удаленности этих объектов. Можно ли их посадить на общую шину (485)? Если да, то садим и принимает данные на одной машине, на ней же и БД в которую пишется. Но, тут опять же, требования ко времени.. Возможно, при жестком требовании наоборот, не объединять объекты а работать с каждым по отдельности. В любом случае, не надо забывать и о времени прохождения пакета в ЛВС.. и о серверной стороне. Все же, наверно более актуально писать сразу в БД или использовать трехзвездную архитектуру с промежуточным звеном (сервер приложений) на котором будут постоянно открыты порты, например по UDP как более быстрые но не гарантирующие доставку, или TCP если нужна квитация. На сервере приложений будут писаться данные в файлы и по запросу забираться, или паковаться.
Когда требования к реакции системы спускаются ниже 1 секунды, то появляется необходимость использовать специализированные инструменты.. Потому что заявления «мы гарантируем вам сохранение информации каждые 100 микросекунд в СУБД Oracle» при это строя систему на Windows XP – мягко говоря, рассчитаны только на менеджеров.

--------------------------------------
Желаемое и возможное – две большие разницы.

Ну и в догонку..
Есть (как пример) прибор «Х», его назначение: сбор данных с различных датчиков, 48 аналоговых и 16 дискретных (в разных версиях по разному). У него есть внутренний буфер на 256 кб. Прибор получает данные постоянно, а на другом порту (485) по запросу отдаёт. Если прошла авария, срабатывает триггер и буфер «замыкается» с интервалом ~ 8 минут (4 до и 4 после), пока не будет считана авария (внешним АРМ), прибор не перетерает буфер. Таким образом, сохраняется история с нужной дискретностью и вполне нормально это живет потом на Windows 2000 (пишет в Dbase, хотя, можно писать куда угодно, т.к. временные ограничения сняты аппаратно) с помощью внешнего АРМ.
Я к тому, что возможно стоит поискать такие решения.

--------------------------------------
Желаемое и возможное – две большие разницы.