Re:

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

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

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

:))

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

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

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