Re:
От | Dmitry E. Oboukhov |
---|---|
Тема | Re: |
Дата | |
Msg-id | 20150313024303.GE11054@vdsl.uvw.ru обсуждение исходный текст |
Ответ на | Re: (Konstantin Gerasimenko <kred@gmx.net>) |
Список | pgsql-ru-general |
> я так понимаю тут ошибка закралась ... не первый запрос, а второй ? > так как по последним точкам собрать трек водилы не реально :-) ага, сорри :) > Что есть : > - у Вас примерно/максимум 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
Вложения
В списке pgsql-ru-general по дате отправления: