caxapa.ru :: Я не о том, во что сложить - CSV проходит (пока), а как сложить, чтобы потом можно было восстановить исходный порядок посылок и пакетов

MBedder^{терминатор} (10.07.2020 18:55, просмотров: 824) ответил fk0 на В общем случае, если задача решается в лоб использованием SQL-базы данных, то её и нужно использовать. Будет проще во многом. Другое дело, что может получиться _сильно_ не оптимально и избыточно. В данном случае непонятно какие выборки из базы данных потом будут осуществляться. Если нужно просто разделить по источникам, то что мешает сразу писать в разные же файлы, и потом брать только нужные. А для передачи -- запаковать в зип. В случае SQL же, любая другая база данных

Я не о том, во что сложить - CSV проходит (пока), а как сложить, чтобы потом можно было восстановить исходный порядок посылок и пакетов

Ответить

- Наверное, в таких случаях лучше всего использовать для хранения Базы данных временных рядов - BlackPrapor(10.07.2020 19:28, ссылка)
- Пишет один процесс или разные? В один файл или в разные? Если файл один (без буферизации, разумеется, и с O_APPEND), то порядок очевиден... можно таймштамп добавить (но он может совпадать у соседних записей). Если процесс один, поток один, есть точка, где всё упорядочивается явно, то там можно порядковый номер записи добавить. fk0(1858 знак., 10.07.2020 19:24)
  - Запись-то в один файл, но порядок неочевиден - пакеты рвать нельзя, а так они неизбежно будут друг на друга наезжать - MBedder(10.07.2020 19:43)
    - Ничего не понял. Так или иначе можно записывать пакеты в файл последовательно -- какой первый появился, тот и записывается в файл целиком. Чем не решение? Потом кто-то другой так же последовательно вычитывает и обрабатывает, или кладёт в базу для обчётов по разным критериям. Если пакеты мелкие, то можно положиться на атомарную запись. Если большие, то сериализовать ручками через разделяемую память, через множество пайпов (по пайпу на каждый источник, который читается всегда fk0(123 знак., 10.07.2020 19:49)
      - Пайпы у меня программисты курят, а я бросил :)) - MBedder(10.07.2020 20:36)
  - Про сокеты - можно просто взять ZeroMQ, там такой сценарий есть из коробки XPUB/XSUB. Записывать в один поток в получателе - lloyd(10.07.2020 19:34)
    - Спасибо, бум поглядеть - MBedder(10.07.2020 20:37)
    - А ZeroMQ зачем? Если положим, что пишем текстовые строчки. Записать можно и с помощью socat'a или программы на C из десятка строк. - fk0(10.07.2020 19:39)
      - А вот затем, что см. комментарий выше - 0MQ обеспечивает границу сообщений на любом транспорте (межпотоковый, межпроцессный, TCP). Там получаешь или все, или ничего (такое тоже бывает) - lloyd(10.07.2020 19:48)
        
        Границу сообщений можно сделать массой разных способов, 0MQ не серебряная пуля. Если размер сообщения известен в момент отправки, то очевидно, можно каждое сообщение предварять его длиной. - fk0(10.07.2020 19:51)
        
        Как будто ZMTP под капотом делает что-то другое. Вообще суть предложения была в том, чтобы не пытаться героически превозмогать многопоточную задачу, а перевести ее в однопоточку брокера сообщений - lloyd(10.07.2020 19:54)
        
        Вызвать write() для записи в пайп -- это героическое превозмогание? Почему бы за уши не притянуть ещё всяких брокеров, они ж такие полезные. А потом с этом всем попытаться взлететь... - fk0(10.07.2020 19:57)
        
        Я так полагаю самая сложная задача - не в файл записать, а данные получить. Но пусть ТС меня поправит - lloyd(10.07.2020 20:02)
        
        И то, и это важно - записать так, чтобы можно было без временнЫх искажений распаковать эту кучу в отдельные файлы - MBedder(10.07.2020 20:34)

Средства и методы разработки