Обсуждение: Re:

В сообщении от 3 мая 2007 Alexey Kolosov написал(a):
> Возможно ли преобразовать значение типа record в массив text[]?
> Если можно, то как?
на plsql нельзя... зато на plperl или plpython можно! просто никогда не писал
на них ХП! помогите пожалуйста! 

CREATE OR REPLACE FUNCTION test2()
  RETURNS SETOF text AS
$BODY$
    my $row;
    my $sth = spi_query("select * from audio limit 1;");
    while (defined ($row = spi_fetchrow($sth)))
    {
      my @k = (%$row);    
      for ($i=0; $i < ($#k + 1)/2; $i++)
      {

      # название_поля = значение
       return_next($k[$i*2].' = '.$k[$i*2+1]);
      }
    }

return undef;              
$BODY$
  LANGUAGE 'plperlu' VOLATILE; 

День/Ночь  добрый.

предлагаю пропустить обсуждение о том как это сделать правильно в
"постгресте",
а сразу перейти к обсуждению о том как это сделать правильно вообще.

Посмотреть в сторону "биг дата" и изучить две вещи:
- Hadoop
- HBase

Дальше научиться агрегировать данные на "мап/редусе" и потом это лить в
реляционалку для "... низнаю для чего ... ".

Всё ... жизнь наладилась.


Удачи. Но если будут вопросы по этим двум пунктам буду рад ответить в
"привате".

С Уважением Константин.



10.03.2015 15:02, Aln Kapa пишет:
> Добрый день.
>
>
> Есть 5000 устройств присылающих информация примерное 1 раз в секунду.
> Хранить информацию в доступном резерве надо около 3-х лет.
> Надо обеспечить быструю запись и приемлемый селект.
>
> Так вот как по вашему мнению лучше всего организовать хранение данных,
> в одной таблице с партицированием или создать по одной таблице на
> устройство.
>
> В основном будут COPY и SELECT только с одной из таблиц, запросы по
> нескольким таблицам будут, но их можно будет "подождать" не критично.
>
>
>

2015-03-10 7:02 GMT-07:00 Aln Kapa <alnkapa@gmail.com>:
> Есть 5000 устройств присылающих информация примерное 1 раз в секунду.
> Хранить информацию в доступном резерве надо около 3-х лет.
> Надо обеспечить быструю запись и приемлемый селект.

Софт-приёмник сохраняет поток в tab-separated текстовые файлы по
максимум N записей. Загрузчик периодически делает COPY FROM
завершенным файлам в таблицу postgres базы.

> Так вот как по вашему мнению лучше всего организовать хранение данных, в
> одной таблице с партицированием или создать по одной таблице на устройство.
>
> В основном будут COPY и SELECT только с одной из таблиц, запросы по
> нескольким таблицам будут, но их можно будет "подождать" не критично.

Партиции можно организовать как матрицу (hash(device_id), time_range).
Например, (device_id % 100, now()::date). Старые партиции, которые
страрше 3х лет, COPY TO PROGRAM gzip в архив и DROP TABLE.

Для партиционирования можно использовать вот этот тул
https://github.com/keithf4/pg_partman. Старые таблицы архивировать
можно вот этим https://github.com/grayhemp/pgcookbook/blob/master/bin/archive_tables.sh.
Архив чистить find /mnt/archive -mtime +2000 -type f -delete.

В дальнейшем, с ростом объёмов и потребностей, можно подумать о
https://github.com/citusdata/pg_shard.

-- 
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

> День/Ночь  добрый.

> предлагаю пропустить обсуждение о том как это сделать правильно в
> "постгресте",
> а сразу перейти к обсуждению о том как это сделать правильно вообще.

> Посмотреть в сторону "биг дата" и изучить две вещи:
> - Hadoop
> - HBase

> Дальше научиться агрегировать данные на "мап/редусе" и потом это
> лить в реляционалку для "... низнаю для чего ... ".

> Всё ... жизнь наладилась.

> Удачи. Но если будут вопросы по этим двум пунктам буду рад ответить
> в "привате".


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


PS: у нас подобная задача: собираем координаты с тысяч устройств, но
передают они их не раз в секунду а раз в 10 секунд (разница
непринципиальная).

поставили перед постгрисом аггрегатор (демончик) который либо ждет 10
секунд и сбрасывает данные в постгрис либо ждет накопления 1000 точек
и так же льет.
в итоге сейчас постгриска в контейнере OpenVZ на одном CPU вполне
собирает за день где-то 2-4гига точек и при этом отвечает быстро на
вопрос "дай мне ближайших к заданной" и отвечает относительно быстро
на вопрос "дай мне трек машинки XXX со времени A по время B"

партицируем тупо по датам: новый день - новая партиция.

--

. ''`.                               Dmitry E. Oboukhov
: :’  :   email: unera@debian.org jabber://UNera@uvw.ru
`. `~’              GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537

11.03.2015 05:56, Dmitry E. Oboukhov пишет:
> очень сомнительный совет. если на постгре такая задача отлично
> решается, то хадуп потребует где-то x20 ресурсов железных при том что
> только теоретически будет масштабируем. PS: у нас подобная задача:
> собираем координаты с тысяч устройств, но передают они их не раз в
> секунду а раз в 10 секунд (разница непринципиальная). поставили перед
> постгрисом аггрегатор (демончик) который либо ждет 10 секунд и
> сбрасывает данные в постгрис либо ждет накопления 1000 точек и так же
> льет. в итоге сейчас постгриска в контейнере OpenVZ на одном CPU
> вполне собирает за день где-то 2-4гига точек и при этом отвечает
> быстро на вопрос "дай мне ближайших к заданной" и отвечает
> относительно быстро на вопрос "дай мне трек машинки XXX со времени A
> по время B" партицируем тупо по датам: новый день - новая партиция.

Дмитрий у вас записей по максимуму 1000*6*60*24*365*3=9.460.800.000 (9.5
миллиарда.)

 >Есть 5000 устройств присылающих информация примерное 1 раз в секунду.
 >Хранить информацию в доступном резерве надо около 3-х лет.

5000*1*24*60*60*365*3 = 473.040.000.000 (473 миллиарда.)

Мне кажется разница видна не вооруженным взглядом.
К тому же предположение что потребуется х20 ресурсов как то ... слишком
пессимистически  рассчитано.
На хадуп понадобиться минимум три сервера остальное точно по желанию, в
варианте с постгрестом
понадобиться минимум два мощных сервера или мы все надеемся что один
сервак никогда не сломается ?

Вы привели только два запроса к данным и сразу намекая что такой то
запрос "отвечает относительно быстро", а
сколько у вас рассчитываюся более сложные запросы ?  а есть какая то
аналитика по данным или она не входит в задачу ?

Думаю дальше обсуждать не стоит.

ЗЫ делайте кластеризацию Ваших партиций по индексу "машинки_ид" и тогда
Ваш последний запрос тоже будет мухой рассчитываться.

>> очень сомнительный совет. если на постгре такая задача отлично
>> решается, то хадуп потребует где-то x20 ресурсов железных при том
>> что только теоретически будет масштабируем. PS: у нас подобная
>> задача: собираем координаты с тысяч устройств, но передают они их
>> не раз в секунду а раз в 10 секунд (разница непринципиальная).
>> поставили перед постгрисом аггрегатор (демончик) который либо ждет
>> 10 секунд и сбрасывает данные в постгрис либо ждет накопления 1000
>> точек и так же льет. в итоге сейчас постгриска в контейнере OpenVZ
>> на одном CPU вполне собирает за день где-то 2-4гига точек и при
>> этом отвечает быстро на вопрос "дай мне ближайших к заданной" и
>> отвечает относительно быстро на вопрос "дай мне трек машинки XXX
>> со времени A по время B" партицируем тупо по датам: новый день -
>> новая партиция.

> Дмитрий у вас записей по максимуму 1000*6*60*24*365*3=9.460.800.000
> (9.5 миллиарда.)

я сказал "тысячи", вот сегодня у нас на линии 15 тыс таксистов
наименьшее число - во вторник утром, наибольшее - в пятницу вечером.
в среднем где-то 15К.
вы посчитали ориентируясь на 1К, то есть в 15 раз ошиблись.
итого 9.5 млрд * 15 ~= 150 млрд
сравнить с 500 млрд - вполне сопоставимые вещи.



>> Есть 5000 устройств присылающих информация примерное 1 раз в секунду.
>> Хранить информацию в доступном резерве надо около 3-х лет.

> 5000*1*24*60*60*365*3 = 473.040.000.000 (473 миллиарда.)

> Мне кажется разница видна не вооруженным взглядом.

да и она очень небольшая.

таблица за день набегает как я говорил 2-4 гигабайта (вместе с
индексами).
триггерами собираем таблицу "последние точки"
и таким образом постгрис из индекса (GIST) отвечает на вопрос "дай
ближайшие машины к данной" и из индекса (BTREE) отвечает на вопрос
"дай трек вот этого водителя за период от A до B"

CHECK'и на таблицах позволяют во всех запросах обращаться не более чем
к двум таблицам.

итого:
1. две таблицы за день помещаются в RAM и хорошо кешируются
2. можно делать реляционные запросы (при "разборах полетов" например)
3. все это вертится в одном контейнере OpenVZ (8 Гиг RAM, дофига
дисков) на одном CPU


> К тому же предположение что потребуется х20 ресурсов как то ...
> слишком пессимистически  рассчитано.

реалистично, я бы сказал :)
хадуп мы пробовали.
для задачи "запись большого трафика данных" он реально x20 от Pg.

а Pg где-то x20 от raw xlog (если xlog писать самим)

при этом на вопросы, на которые отвечают GIST, GIN индексы в хадупе
надо еще очень подумать как ответить :)

> На хадуп понадобиться минимум три сервера остальное точно по
> желанию, в варианте с постгрестом
> понадобиться минимум два мощных сервера или мы все надеемся что один
> сервак никогда не сломается ?

зачем не сломается? мы это хозяйство еще и реплицируем + бакапы
делаем.
да, до шардинга еще не добрались, но пока не упирались в железо-то :)


> Вы привели только два запроса к данным и сразу намекая что такой то
> запрос "отвечает относительно быстро", а
> сколько у вас рассчитываюся более сложные запросы ?  а есть какая то
> аналитика по данным или она не входит в задачу ?

у нас агрегатор служб такси. как я сказал выше - сейчас в среднем
15 тыс машин. от сервиса координат требуется отвечать на вопросы

1. трек водителя
2. ближайшие машины к точке
3. иногда (ручные запросы) - разбор полетов

первый вопрос отвечает быстро - из индекса по 15К (25К в пике)
последних точек.

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

--

. ''`.                               Dmitry E. Oboukhov
: :’  :   email: unera@debian.org jabber://UNera@uvw.ru
`. `~’              GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537

у нас агрегатор служб такси. как я сказал выше - сейчас в среднем
15 тыс машин. от сервиса координат требуется отвечать на вопросы

1. трек водителя
2. ближайшие машины к точке
3. иногда (ручные запросы) - разбор полетов

первый вопрос отвечает быстро - из индекса по 15К (25К в пике)
последних точек.

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

> я так понимаю тут ошибка закралась ... не первый запрос, а второй ?
> так как по последним точкам собрать трек водилы не реально :-)

ага, сорри :)

> Что есть :
> - у  Вас  примерно/максимум 4ГБ данных (с индексами) в день.

именно. и у того кто спрашивает тоже так будет.

> - вы запускаете один единственный запрос, а именно поиск по внешнему
> индексированному ключу к данным которые лежат в кеше.

дык каждую задачу с базами данных идеально и правильно сводить именно
к поиску по индексированному ключу.

> (про возможные джойны с остальными табличками я не рассматриваю так как не
> интересно)

а вот это зря. денормализация будет рулить и бибикать и сейчас и в
следующем веке.

пока, во всяком случае, базы данных не научатся строить внешние
индексы, затрагивающие несколько таблиц.

> - вы успеваете проанализировать/проагрегировать приходящие данные и по уже
> проагрегированным данным делаете запрос номер два (кто тут рядом сейчас).
> - ручные запросы ...
> - данные что ушли из кеша уже лежат только как архив.

> Подведу итоги:
> - из всей базы реально доступно менее одного процента данных так как кеша мало
> (2 дня из: "хотя бы одного года")
> - по этим данным вы делаете запрос одного вида.
> - и параллельно костыль в виде агрегатора входящие данные и уже по ним ищете
> второй вопрос "кто рядом сейчас"
> - по данным "мёртво" лежащим на диске можно делать ручные запросы ... но долго
> ждать пока диски всё перечитают )))
> - один  пользователь базы данных ...

> на отдельной машине поддерживаете копию...

> Вы знаете Дмитрий для Вашей задачи действительно "биг дата" не нужна, а Вы
> уверены что для этой задачи нужен  постгрес ?

если уж в философию удариться, то вообще-то самая сложная задача
многих больших баз данных - это разделение данных на оперативные и
архивные.

тут, как правило, все упирается в то что распределение нагрузки в
большинстве проектов такая:

 - имеется нагрузка X
 - X / 10 нагрузки идет в "старые данные"
 - 9 * X / 10 нагрузки идет в "оперативные данные"

то есть если это соцсеть или форум, то пользователи в основном читают недавно
написанные посты. если это такси, то работа ведется по недавно
сформированным заказам. рассматривается в реалтайме именно последнее
положение транспортного средства. если это биллинг, то пользователи
смотрят в основном последние списания и баланс, и так далее

и соответственно если говорить о highload то иногда данные разделяют
на оперативные явным образом (раскладывают по разным базам данных,
таблицам итп), но чаще всего имеется очень хорошее мотивирующее
желание укладывать данные в одну кучу, чтобы обращаться и с
оперативными данными и с архивом единообразно.
Желание растет от того что критерий "оперативности" данных трудно
формализуем (причем трудности в основном в отказе его формализовать, а
не в собственно трудностях формализации).

желание хорошее, но обычно именно его реализация и дает все проблемы
на хайлоаде.

вот если вернуться к авторской задаче, то скорее всего у него окажется
тоже самое: seelect'ы ему нужны будут прежде всего по тем же данным
что были недавно вставлены, и ОЧЕНЬ редко по остальным.

> Вы уверены что для этой задачи нужен  постгрес ?

для этой задачи было нужно

1. низкая стоимость разработки
2. желательно низкая стоимость содержания
3. приемлемый "запас прочности" (то есть чтобы лет на 5 вперед рост
нагрузки не беспокоил)

постгрес эту задачу мне решил.
пробовали другие решения (Хадуп, ручные XLOG, две разные БД:
in-memory+Pg) но они или по пункту 1 или по пункту 2 не проходят.

Хотя, возможно, что со временем этот проект отразвивается до
in-memory+Pg (в неявном виде он уже сейчас такой - тот самый
"демончик", который Вам почему-то не понравился - есть in-memory
часть).

> Если из всей базы данных данные используете только за последние пару дней ..
> почему вы их храните в базе ?

ну а почему бы их не хранить в базе?
хранение данных в базе помимо других плюшек что есть - удобно.

> Все это можно было за пару дней реализовать в том самом "демончике" который у
> вас
> перед постгрестом данные собирает  в блоки, а писать он их мог бы в те же файлы
> ...  да и это было бы на много эффективнее
> не только в размере хранения, но и в скорости обработки (фильтрации и поиске).

я же говорил, что тут мы экспериментировали, да.

чистый XLOG быстрее Pg где-то в 20 раз
Pg быстрее Хадупа на этой задаче где-то в 20 раз

при этом решение на Pg получается наиболее дешевым и (главное)
расширяемым.

вот эти описанные два вопроса к базе - это те вопросы, что создают
основную нагрузку на нее.

а так есть множество вопросов других, которые выполняются за более
длительные интервалы времени, но поскольку пользователям нужны редко,
то выполняются одним (единственным) worker'ом очереди: пользователь
написал "требуется отчет XXX", таска в очередь упала, далее не сильно
важно выполнялась она 1 секунду или 15 секунд: по выполнении
пользователь уведомляется и все хорошо :)

а поскольку данные в реляционке, то новый воркер с новым отчетом
сделать очень дешево :)


> Поймите же Дмитрий что обработка данных в виде "спагетти" (я так называю данные
> в виде лог файлов) не является целевой
> задачей для реляционной базы данных которой является постгрес.

кстати


мы ОЧЕНЬ долгое время хранили логи проекта в постгресе. с
партицированием.
Логи получались с БДиШ. Накапливали они существенно больше: где-то 20
гиг за день.

то же самое - агрегатор(ы) и партицирование.
проект был прямо похож на этот.

вебморда просмотра логов была написана итп

с логами все тоже самое: если в них лезешь то КАК ПРАВИЛО тебя
интересует в режиме "срочно" только недавний лог.
а архив идет уже в режиме "не срочно"

отказались мы от хранения логов в Pg только по одной причине:

было большое желание видеть логи (кстати именно оперативные логи)
и на машине-источнике тоже

то есть проблемы нагрузки нас совсем не беспокоили, когда мы тут
отказывались от хранения логов в Pg :)

и в итоге логи сейчас мы собираем syslog'ом :)


--

. ''`.                               Dmitry E. Oboukhov
: :’  :   email: unera@debian.org jabber://UNera@uvw.ru
`. `~’              GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537

13.03.2015 03:43, Dmitry E. Oboukhov пишет:
>> я так понимаю тут ошибка закралась ... не первый запрос, а второй ?
>> так как по последним точкам собрать трек водилы не реально :-)
> ага, сорри :)
>
>> Что есть :
>> - у  Вас  примерно/максимум 4ГБ данных (с индексами) в день.
> именно. и у того кто спрашивает тоже так будет.
не факт, так как Ваш сенсор даёт примерно 28 байт ... а про его мы
ничего не знаем.
>> - вы запускаете один единственный запрос, а именно поиск по внешнему
>> индексированному ключу к данным которые лежат в кеше.
> дык каждую задачу с базами данных идеально и правильно сводить именно
> к поиску по индексированному ключу.
спорное утверждение.
>> (про возможные джойны с остальными табличками я не рассматриваю так как не
>> интересно)
> а вот это зря. денормализация будет рулить и бибикать и сейчас и в
> следующем веке.
>
> пока, во всяком случае, базы данных не научатся строить внешние
> индексы, затрагивающие несколько таблиц.
есть матвью (даже в постгресте). но разговаривать об этом это уход из темы.
>> Вы знаете Дмитрий для Вашей задачи действительно "биг дата" не нужна, а Вы
>> уверены что для этой задачи нужен  постгрес ?
> если уж в философию удариться, то вообще-то самая сложная задача
> многих больших баз данных - это разделение данных на оперативные и
> архивные.
разделение данных происходит не в одной базе, а на уровне приложения.
тоесть есть оперативная база для обработки своей задачи (в Вашем случае
это данные за последние 2 дня)
и есть архивная база где совсем другие требованию к поставленной задаче.

Перемешивать их не стоит... но как правило многие это делают из
соображения экономии. или других причин.
>
> вот если вернуться к авторской задаче, то скорее всего у него окажется
> тоже самое: seelect'ы ему нужны будут прежде всего по тем же данным
> что были недавно вставлены, и ОЧЕНЬ редко по остальным.
мы об этом не знаем. , но скорее всего вы правы.
>
>> Вы уверены что для этой задачи нужен  постгрес ?
> для этой задачи было нужно
>
> 1. низкая стоимость разработки
> 2. желательно низкая стоимость содержания
> 3. приемлемый "запас прочности" (то есть чтобы лет на 5 вперед рост
> нагрузки не беспокоил)
>
> постгрес эту задачу мне решил.
> пробовали другие решения (Хадуп, ручные XLOG, две разные БД:
> in-memory+Pg) но они или по пункту 1 или по пункту 2 не проходят.
Я согласен с Вашими причинами воспользоваться постгрестом для этой задачи ,
но остаюсь при своём мнении что в данном случае постгрес это такой
комбайн (ага микроскоп) на
котором можно сделать данную задачу ... и пока он будет с ней справляться,
и не факт что получиться вырасти хотя бы в 10 раз
> Хотя, возможно, что со временем этот проект отразвивается до
> in-memory+Pg (в неявном виде он уже сейчас такой - тот самый
> "демончик", который Вам почему-то не понравился - есть in-memory
> часть).
нет я ничего не говорил про то что он мне не нравиться ... , к тому же в
прошлом письме
я и писал что в том самом "демончике" можно запросто решать задачу по
поиску "кто рядом"
>> Если из всей базы данных данные используете только за последние пару дней ..
>> почему вы их храните в базе ?
> ну а почему бы их не хранить в базе?
> хранение данных в базе помимо других плюшек что есть - удобно.
Часто бывает есть два решения данной задачи : правильное и удобное. Так
и в этом случае.
>
>> Все это можно было за пару дней реализовать в том самом "демончике" который у
>> вас
>> перед постгрестом данные собирает  в блоки, а писать он их мог бы в те же файлы
>> ...  да и это было бы на много эффективнее
>> не только в размере хранения, но и в скорости обработки (фильтрации и поиске).
> я же говорил, что тут мы экспериментировали, да.
>
> чистый XLOG быстрее Pg где-то в 20 раз
> Pg быстрее Хадупа на этой задаче где-то в 20 раз
>
> при этом решение на Pg получается наиболее дешевым и (главное)
> расширяемым.
>
> вот эти описанные два вопроса к базе - это те вопросы, что создают
> основную нагрузку на нее.
>
> а так есть множество вопросов других, которые выполняются за более
> длительные интервалы времени, но поскольку пользователям нужны редко,
> то выполняются одним (единственным) worker'ом очереди: пользователь
> написал "требуется отчет XXX", таска в очередь упала, далее не сильно
> важно выполнялась она 1 секунду или 15 секунд: по выполнении
> пользователь уведомляется и все хорошо :)
то есть постгрес не справляется с нагрузкой больше одного запроса/отчота
....
или оно так работает что уже не нужно ?
мой вам совет поставте ссд диски в сервер :-)
> а поскольку данные в реляционке, то новый воркер с новым отчетом
> сделать очень дешево :)
вы пробовали пиг ? или хив ?
>
>> Поймите же Дмитрий что обработка данных в виде "спагетти" (я так называю данные
>> в виде лог файлов) не является целевой
>> задачей для реляционной базы данных которой является постгрес.
> кстати
>
>
> мы ОЧЕНЬ долгое время хранили логи проекта в постгресе. с
> партицированием.
> Логи получались с БДиШ. Накапливали они существенно больше: где-то 20
> гиг за день.
зачем ХРАНИТЬ ЛОГИ в реляционной базе ???  хранить их нужно в файлах
сжатыми какимто компрессором,
ЗАЧЕМ ???

вы хотите их обрабатывать ?  так для этого есть решение в гугле
"elasticsearch kibana logstash"
постгрес может их обрабатывать , но он не для этого создавался.
> и в итоге логи сейчас мы собираем syslog'ом :)
ну просто подтверждение моих слов :-)


Хороших выходных.

Константин.

>> дык каждую задачу с базами данных идеально и правильно сводить именно
>> к поиску по индексированному ключу.
> спорное утверждение.

это собственно суть такого явления как "База данных"

давайте с Вами обсудим философский вопрос "что такое база данных?"

:))

мое определение: база данных - линейный массив данных + средства
ускорения поиска по нему. и вот из этого все и растет.

а Ваше определение какое?

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

а почему другая?
частичный индекс по таблице - вполне себе годится под опрделение
оперативной БД. о чем я говорю.

>> вот если вернуться к авторской задаче, то скорее всего у него окажется
>> тоже самое: seelect'ы ему нужны будут прежде всего по тем же данным
>> что были недавно вставлены, и ОЧЕНЬ редко по остальным.
> мы об этом не знаем. , но скорее всего вы правы.
>>
>>> Вы уверены что для этой задачи нужен  постгрес ?
>> для этой задачи было нужно
>>
>> 1. низкая стоимость разработки
>> 2. желательно низкая стоимость содержания
>> 3. приемлемый "запас прочности" (то есть чтобы лет на 5 вперед рост
>> нагрузки не беспокоил)
>>
>> постгрес эту задачу мне решил.
>> пробовали другие решения (Хадуп, ручные XLOG, две разные БД:
>> in-memory+Pg) но они или по пункту 1 или по пункту 2 не проходят.
> Я согласен с Вашими причинами воспользоваться постгрестом для этой задачи ,
> но остаюсь при своём мнении что в данном случае постгрес это такой
> комбайн (ага микроскоп) на
> котором можно сделать данную задачу ... и пока он будет с ней справляться,
> и не факт что получиться вырасти хотя бы в 10 раз

1. хадуп потребует ресурсов раз в 20 больше для ЭТОЙ задачи уже сейчас
2. когда нагрузка возрасте в 10 раз, я 100% уверен что кроме RAM для
этого роста ничего особо добавлять и не придется.


>>> Если из всей базы данных данные используете только за последние пару дней ..
>>> почему вы их храните в базе ?
>> ну а почему бы их не хранить в базе?
>> хранение данных в базе помимо других плюшек что есть - удобно.
> Часто бывает есть два решения данной задачи : правильное и удобное.
> Так и в этом случае.

о и это опять философия.

я говорю что удобное -- очень часто и есть -- правильное.

>>
>>> Все это можно было за пару дней реализовать в том самом "демончике" который у
>>> вас
>>> перед постгрестом данные собирает  в блоки, а писать он их мог бы в те же файлы
>>> ...  да и это было бы на много эффективнее
>>> не только в размере хранения, но и в скорости обработки (фильтрации и поиске).
>> я же говорил, что тут мы экспериментировали, да.
>>
>> чистый XLOG быстрее Pg где-то в 20 раз
>> Pg быстрее Хадупа на этой задаче где-то в 20 раз
>>
>> при этом решение на Pg получается наиболее дешевым и (главное)
>> расширяемым.
>>
>> вот эти описанные два вопроса к базе - это те вопросы, что создают
>> основную нагрузку на нее.
>>
>> а так есть множество вопросов других, которые выполняются за более
>> длительные интервалы времени, но поскольку пользователям нужны редко,
>> то выполняются одним (единственным) worker'ом очереди: пользователь
>> написал "требуется отчет XXX", таска в очередь упала, далее не сильно
>> важно выполнялась она 1 секунду или 15 секунд: по выполнении
>> пользователь уведомляется и все хорошо :)
> то есть постгрес не справляется с нагрузкой больше одного
> запроса/отчота ....

отчет вне индексов или агрегаторный запрос - с этим в общем любая БД
не справляется.
тут выходов только два: либо строить отчет на лету (счетчики)
либо строить отчет as is но уже за столько времени за сколько он
строится (см определение "что такое база данных?")

>> мы ОЧЕНЬ долгое время хранили логи проекта в постгресе. с
>> партицированием.
>> Логи получались с БДиШ. Накапливали они существенно больше: где-то 20
>> гиг за день.
> зачем ХРАНИТЬ ЛОГИ в реляционной базе ???  хранить их нужно в файлах
> сжатыми какимто компрессором,
> ЗАЧЕМ ???

у нас логзапись каждая была структурой данных.
где можно было приатачить например входящий запрос, исходящий запрос
итп итд

и соответственно база данных - было удобное средство хранения и ПОИСКА
(например по тегам)

--

. ''`.                               Dmitry E. Oboukhov
: :’  :   email: unera@debian.org jabber://UNera@uvw.ru
`. `~’              GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537

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

2015-03-16 8:53 GMT-07:00 Aln Kapa <alnkapa@gmail.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.ru@gmail.com