Re:

2015-03-16 8:53 GMT-07:00 Aln Kapa <alnkapa(at)gmail(dot)com>:
>> > Вопрос, если писать блоками в партиции, то надо как то разрулить
>> > граничные
>> > ситуации, когда блок данных перекрывает партицию и залезает на другую?
>>
>> Это какраз далача приемника определять в какой файл выгружать какие
>> данные. Он тут должен разные файлы дополнять в зависимости от того что
>> принял. Учтите также что дата которую будут присылать устройства не
>> всегда будет последовательна, т.е. устройства вполне могут присылать
>> данные за вчера после данных за сегодня, это как грубый пример.
>
> Вот и я все больше склоняюсь к схеме, одно устройство это отдельная таблица,
> а с учетом какую муру, иногда присылают устройства в место времени, так это
> вообще панацея.
> Единственное что пока останавливает, не равномерное заполнение таблиц, при
> реальном использование, будет где то густо, а где то пусто, и храние кучи
> пустых таблиц для мертвых устройств.

Хешь функция может быть device_id % 10, т.ч. каждый поток приёмника
будет обрабатывать 10% устройств, как и партиций по устройствам будет
10 на каждый день, если партиционировать о дням. Т.о. не будет пустых
партиций для мёртвых устройств.

>> > Вопрос, почему "буфер в файл" есть же очереди, и другие решения
>> > позволяющие
>> > писать в память, и предоставляющие приемлемую отказо-устойчивость?
>>
>> Другие решения есть, но это часто оверхед как в плане
>> ресурсов/производительности так и в плане администрирования/поддержки.
>> О них имеет смысл подумать если у вас полноценная pub/sub система,
>> т.е. много кто пишет и много кто читает, а тут 1н к 1му.
>
> Тут может легко возникнуть проблема с кол-вом открытых файловых дескрипторов
> и масштабируемостью.
> Спасибо за ответ.

Это врядли. Если потоков приёмника будет 10-100 такой проблемы не будет.

ps. Забываете ставить pgsql-ru-general в CC.

--
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(dot)ru(at)gmail(dot)com