>>в книге описывается только настрйока и масштабирование ??
да
>>Подойжет ли книга не только как справочник. а как пособие для начинающих изучать Postgree ??
нет
Если у Вас не игра (которые не все готовы к повороту), то я не вижу смысла блокировать поворот в приложении для пользователя. А на планшетах под Андроидом это очень даже раздражает :)
>>И первый же select count(*) from articles для построения постранички приведет к тому, что БД полезет шуршать по всем партициям, что в случае с постгресом, будет означать N запросов.
Что вам мешает хранить количество в отдельном поле другой таблици и обновлять через тригеры? Тем более партиции могут делится по разным атрибутам.
>>Запросы select * from article where id = X будут выполняться так же быстро, как без партиционирования. А в умную БД которая поймет, что при ORDER BY id DESC LIMIT 10 надо смотреть только в последнюю партицию мне не верится.
Проблемы СУБД в том, что сначала будет делаться выборка по запросу, а потом лимитируется выборка. Если таблица большая — СУБД будет не сладко сделать LIMIT 10.
>>Я затрудняюсь привести пример, когда партишнинг таблицы в рамках одного сервера приведет к заметному выигрышу в производительности. Обратных примеров видел достаточно.
Партиционирование (partitioning) — это разбиение больших таблиц на логические части по выбранным критериям. Звучит сложно, но на практике все просто.
Скорее всего у Вас есть несколько огромных таблиц (обычно всю нагрузку обеспечивают всего несколько таблиц СУБД из всех имеющихся). Причем чтение в большинстве случаев приходится только на самую последнюю их часть (т.е. активно читаются те данные, которые недавно появились). Примером тому может служить блог — на первую страницу (это последние 5…10 постов) приходится 40…50% всей нагрузки, или новостной портал (суть одна и та же), или системы личных сообщений… впрочем понятно. Партиционирование таблицы позволяет базе данных делать интеллектуальную выборку — сначала СУБД уточнит, какой партиции соответствует Ваш запрос (если это реально) и только потом сделает этот запрос, применительно к нужной партиции (или нескольким партициям). Таким образом, в рассмотренном случае, Вы распределите нагрузку на таблицу по ее партициям. Следовательно выборка типа “SELECT * FROM articles ORDER BY id DESC LIMIT 10” будет выполняться только над последней партицией, которая значительно меньше всей таблицы.
Если уж мастер умер с концами(сгорел хостинг или посыпался винт), тогда достаточно проверить через на слейвах
select pg_last_xlog_replay_location()
Где наибольшее число — тот ставим мастером. Переносим данные через онлайн бекап на те слейвы, что отличаются (на те, которые успели — не надо) и работаем дальше. При этом мастер во время переноса разницы через онлайн бекап может работать без перегрузок.
Согласен. Многое из сказаного верно, но насчет
>>Большая система она должна собираться с учетом всего и каждый элемент должен взаимодействовать с другим и знать о нем все.
взаимодействовать — да, знать о нем все — нет.
да
>>Подойжет ли книга не только как справочник. а как пособие для начинающих изучать Postgree ??
нет
Если у Вас AsyncTask запускается в onCreate Activity — получите ошибку.
Что вам мешает хранить количество в отдельном поле другой таблици и обновлять через тригеры? Тем более партиции могут делится по разным атрибутам.
>>Запросы select * from article where id = X будут выполняться так же быстро, как без партиционирования. А в умную БД которая поймет, что при ORDER BY id DESC LIMIT 10 надо смотреть только в последнюю партицию мне не верится.
Проблемы СУБД в том, что сначала будет делаться выборка по запросу, а потом лимитируется выборка. Если таблица большая — СУБД будет не сладко сделать LIMIT 10.
>>Я затрудняюсь привести пример, когда партишнинг таблицы в рамках одного сервера приведет к заметному выигрышу в производительности. Обратных примеров видел достаточно.
Обратный пример пожалуйста :)
Партиционирование (partitioning) — это разбиение больших таблиц на логические части по выбранным критериям. Звучит сложно, но на практике все просто.
Скорее всего у Вас есть несколько огромных таблиц (обычно всю нагрузку обеспечивают всего несколько таблиц СУБД из всех имеющихся). Причем чтение в большинстве случаев приходится только на самую последнюю их часть (т.е. активно читаются те данные, которые недавно появились). Примером тому может служить блог — на первую страницу (это последние 5…10 постов) приходится 40…50% всей нагрузки, или новостной портал (суть одна и та же), или системы личных сообщений… впрочем понятно. Партиционирование таблицы позволяет базе данных делать интеллектуальную выборку — сначала СУБД уточнит, какой партиции соответствует Ваш запрос (если это реально) и только потом сделает этот запрос, применительно к нужной партиции (или нескольким партициям). Таким образом, в рассмотренном случае, Вы распределите нагрузку на таблицу по ее партициям. Следовательно выборка типа “SELECT * FROM articles ORDER BY id DESC LIMIT 10” будет выполняться только над последней партицией, которая значительно меньше всей таблицы.
Многие СУБД поддерживают партиционирование на том или ином уровне, например:
dev.mysql.com/doc/refman/5.1/en/partitioning.html — Партиционирование в Mysql, отлично реализовано на уровне СУБД (убедитесь, что Ваша версия >= 5.1).
www.postgresql.org/docs/8.1/interactive/ddl-partitioning.html — Партиционирование в Postgres, не так хорошо, но все же возможность есть.
select pg_last_xlog_replay_location()
Где наибольшее число — тот ставим мастером. Переносим данные через онлайн бекап на те слейвы, что отличаются (на те, которые успели — не надо) и работаем дальше. При этом мастер во время переноса разницы через онлайн бекап может работать без перегрузок.
>>Большая система она должна собираться с учетом всего и каждый элемент должен взаимодействовать с другим и знать о нем все.
взаимодействовать — да, знать о нем все — нет.