Re:

>> очень сомнительный совет. если на постгре такая задача отлично
>> решается, то хадуп потребует где-то 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