2015-03-11 2:29 GMT-07:00 Aln Kapa <alnkapa@gmail.com>:
> 11 марта 2015 г., 7:19 пользователь Sergey Konoplev <gray.ru@gmail.com>
> написал:
>> Софт-приёмник сохраняет поток в tab-separated текстовые файлы по
>> максимум N записей. Загрузчик периодически делает COPY FROM
>> завершенным файлам в таблицу postgres базы.
>>
>> Партиции можно организовать как матрицу (hash(device_id), time_range).
>> Например, (device_id % 100, now()::date). Старые партиции, которые
>> страрше 3х лет, COPY TO PROGRAM gzip в архив и DROP TABLE.
>
> А зачем device_id, может будет проше по времени разделить.
"организовать как матрицу (hash(device_id), time_range)" - тут и по
устройствам и по времени разделение. По устройствам имеет смысл
партиционировать для распараллеливания заливки и ускорения выборок.
> Вопрос, если писать блоками в партиции, то надо как то разрулить граничные
> ситуации, когда блок данных перекрывает партицию и залезает на другую?
Это какраз далача приемника определять в какой файл выгружать какие
данные. Он тут должен разные файлы дополнять в зависимости от того что
принял. Учтите также что дата которую будут присылать устройства не
всегда будет последовательна, т.е. устройства вполне могут присылать
данные за вчера после данных за сегодня, это как грубый пример.
> Вопрос, почему "буфер в файл" есть же очереди, и другие решения позволяющие
> писать в память, и предоставляющие приемлемую отказо-устойчивость?
Другие решения есть, но это часто оверхед как в плане
ресурсов/производительности так и в плане администрирования/поддержки.
О них имеет смысл подумать если у вас полноценная pub/sub система,
т.е. много кто пишет и много кто читает, а тут 1н к 1му.
--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA
http://www.linkedin.com/in/grayhemp
+1 (415) 867-9984, +7 (499) 346-7196, +7 (988) 888-1979
gray.ru@gmail.com