Как писать удаленно в БД? TCP/FTP?

Доброго времени суток!

Есть com-port, с которого льется поток ~< 3000 characters/second.
Этот поток необходимо записывать в БД, находящуюся удаленно.
В этой связи решения два:
1) читать поток через cat, и затем передавать по TCP, что-то типо: cat /dev... | nc ..
На приемной стороне, организовать TCP сервер, на Python, например. откуда уже писать в БД.
Либо
2) писать поток в файл, каждую секунду, который затем передавать по FTP, с последующей обработкой на сервере, после приема.

В первом случае придется предусмотреть ситуации, когда БД вдруг офлайн, писать в файлы, которые затем пересылать.
Однако задержки нет, поток пришел -- сразу пишем.

Что предпочесть, может есть какие проблемы с передачей по FTP, менее стабильно../etc?

Заранее благодарен!

UPD:
Всем спасибо за дискуссию!
Выбрал такую связку: с COM_port'a лью данные в файлы (nc > filename), проверяю на той же машине на вилидность (python). Если оки -> отправляю по scp, если дошло - удаляю (scp .. && rm ..);
  • Вопрос задан
  • 649 просмотров
Решения вопроса 1
@remzalp
Программер чего попало на чем попало
Я бы сначала локально лил в файл, чтобы на случай пропадания связи проблем не было.
Потом можно локально уже распарсить поток до структурного состояния, а дальше уже интереснее.

Вариант 1: прямое соединение по ssh с пробросом портов (тогда БД наружу не торчит) и лить запросами в БД
Вариант 2: небольшой веб REST сервис поднять на получателе, куда скидывать хоть через wget пакеты, которые будут обрабатываться и литься в БД.

выбор варианта сильно зависит от компа, на который приходит ком-порт. Если там достаточно ресурсов, парсить локально и лить на удаленный сервер. В этом случае больше контроля. Если будет пропадание сети, то просто будет локально копиться и ждать отправки.

Вариант с веб-сервисом - профдеформация, всю черновую работу в этом случае отдаём стороннему софту, на плечи серверного приложения остаётся только обработать пришедшие данные. Можно и TCP реализовать, не проблема.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 3
@tupen
Зависит ТОЛЬКО от задачи:

  • как критично не потерять данные или можно пропустить часть данных (нужен ли надежный промежуточный буфер)
  • как оперативно данные должны поступать в БД (можно ли повешать на крон отсылку накопленных в буфере данных)
  • и сколько времени/человеческих ресурсов можно выделить для решения задачи
  • секьюрности проекта (если это не внутренний сервер, в небольшой конторе где не может быть атак - то еще можно использовать FTP, иначе - категорически нет).


И это будет очень большой разбег. Буквально от 10 минут до 10 дней работы

Ваш вопрос состоит в том, что вы просите нас оценить ваши особенности задачи, которые мы оценить не можем, не зная о требованиях к задаче.
Ответ написан
Комментировать
@aynur_safin
2) писать поток в файл, каждую секунду, который затем передавать по FTP, с последующей обработкой на сервере, после приема.


А зачем каждую секунду писать, пишите поминутные файлы,
если 1 character = 1 byte, то минута это 180Kb примерно, хороший размер для передачи по FTP.
Раз в 5 минут, например, запускаем синхронизацию локального каталога с FTP сервера ~ 1Mb.
И тут же - файлы, например старше суток, - удаляем.
Обнаружив новые файлы, сервис на сервере, неспешно заливает их в базу - 5 минут у него есть.
Ответ написан
Комментировать
@yaror
10 лет в мобильном телекоме
Я бы:
1. Парсил прямо на машине, принимающей поток с COM-порта
2. Сливал в БД прямо с этой же машины, через SQL: "insert into туда-то values такие-то". В случае вылезшего exception (нет связности с БД, БД упала и т.д.), распарсенные значения можно было бы залоггировать локально
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы