Re:

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

ага, сорри :)

> Что есть :
> - у  Вас  примерно/максимум 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