Re:

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'ом :)
ну просто подтверждение моих слов :-)


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

Константин.