После года разработки представлен (http://www.postgresql.org/about/news/1415/) релиз новой стабильной ветки PostgreSQL 9.2 (http://www.postgresql.org). Кроме реализации новых функций в новой ветке проведена значительная работа по увеличению производительности и масштабируемости, как горизонтальной (распределение нагрузки на несколько серверов), так и вертикальной (оптимальная работа на больших мощных серверах). В качестве примеров возросшей производительности PostgreSQL приводится способность обрабатывать до 350 тыс. запросов на чтение в секунду (в 4 раза больше чем раньше) и до 14 тысяч запросов на запись в секунду (в 5 раз быстрее).Ключевые улучшения (http://wiki.postgresql.org/wiki/What%27s_new_in_Postgre...):
- Поддержка (http://www.postgresql.org/docs/9.2/static/datatype-json.html) типа данных JSON и встроенные средства для манипулирования данными в формате JSON, что позволяет создавать гибридные документо-реаляционные базы данных. Дополнительно представлен набор сопутствующих функций для преобразования массивов и строк в JSON-представление;
- Новые типы (http://www.postgresql.org/docs/devel/static/rangetypes.html) для определения диапазонов (INT4RANGE, INT8RANGE, NUMRANGE, TSRANGE, TSTZRANGE и DATERANGE), которые могут быть использованы в календарях, временных рядах и аналитических приложениях;
- Расширение возможностей оператора ALTER, упрощающих изменение и обновление структуры работающей БД. Снижение числа ситуаций, когда необходимо перестроение индексов и таблиц при выполнении ALTER TABLE. Поддержка выражения "IF EXIST", позволяющего игнорировать действие если элемент не существует (например, "ALTER FOREIGN TABLE IF EXISTS foo RENAME TO bar"). Добавлены выражения: ALTER FOREIGN DATA WRAPPER / RENAME, ALTER SERVER / RENAME, ALTER DOMAIN / RENAME;
- Поддержка (http://www.postgresql.org/docs/9.2/static/warm-standby.html#...) каскадных репликаций, при которых допускается репликация между slave-серверами (ранее slave-сервер мог получать данные только от master-сервера). Возможность создания территориально распределённых реплицированных резервных БД;- Включение в поставку утилиты pg_receivexlog (http://www.postgresql.org/docs/9.2/static/app-pgreceivexlog....) для архивирования изменений в файлах xlog по мере записи данных, не дожидаясь окончания полного формирования xlog-файла;
- Добавление в утилиту pg_basebackup (http://www.postgresql.org/docs/9.2/static/app-pgbasebackup.html) возможности создания основных резервных копий, используя данные с запасных standby-серверов, что позволяет снять нагрузку с основного сервера в процессе создания бэкапа;
- В представлениях (http://www.postgresql.org/docs/9.2/static/sql-createview.html) добавлена поддержка опции security_barrier для обеспечения изоляции (http://www.postgresql.org/docs/9.2/static/rules-privileges.html) на уровне строк;
- В libpq добавлена возможность указания строки инициирования соединения в форме URI. В libpq обеспечен однострочный (single-row) режим обработки запросов, позволяющий улучшить обработку больших результирующих наборов данных;
- Многочисленные оптимизации производительности, в том числе:
- Режим сканирования только по индексам при котором scan-операции манипулируют только содержимым индекса, не обращаясь к базовым таблицам. По заявлению разработчиков, выборка только по индексам позволяет увеличить скорость выполнения аналитических запросов от 2 до 20 раз;- Расширены возможности масштабирования работающих только на чтение конфгураций, поддерживается задействование до 64 процессорных ядер и обеспечения производительности на одном сервере на уровне сотен тысяч запросов в секунду;
- Ускорены операции записи данных, включая выполнение групповых коммитов;
- В планировщик выполнения запросов добавлена поддержка генерации отдельных планов выполнения запроса для специфичных значений параметров;
- Улучшение возможности планировщика запросов по использованию вложенных циклов при внутренних сканированиях индекса;
- Поддержка метода доступа к индексам SP-GiST (http://www.postgresql.org/docs/9.2/static/spgist.html) (Space-Partitioned GiST);- Снижена нагрузка на CPU в периоды простоя сервера, что позволило снизить потребление энергии и улучшить работу на встраиваемых системах и при использовании виртуализации;
- Проведена оптимизация производительности операций сортировки данных в памяти, что позволило добиться в некоторых ситуациях ускорения до 25%;
- Оптимизировано выполнение операции COPY, которая теперь приводит к установке меньшего числа внутритабличных блокировок и к генерации меньшего объема записей в WAL-лог.URL: http://www.postgresql.org/about/news/1415/
Новость: http://www.opennet.me/opennews/art.shtml?num=34794
Блин, а ктонить в курсе, полное задействование проца (всех ядер) для одного запроса, т.е. его распараллеливание, когданить сделают? или это для постгреса не реально?
Вы что из БД сделали?! А так, всё зависит от структуры запроса... Если вы используете функции для обработки, то всё хорошо и ядра все отработают и удалённые сервера через midleware можно вызвать))
Да не, удаленных никаких нет, а вот про функции не понял, сколько и как чего не делаю (один коннект/запрос) всегда загружено только одно ядро, и просто запрос и свои хранимки с циклами/курсорами и использованием встроенных функций - по любому на один коннект/запрос используется только одно ядро, досадно, большая таблица и по ней относительно не сложный запрос который можно было бы распараллелить, ибо просматривает все записи, ну и соответственно выполнить быстрее, однако нет - исполняет в один поток, проц недогружен.
Жесткий тоже паралельно таблицу читать будет? Или Partitioning используется?.
Хм, не используется, но ведь далеко не всегда в диск все упирается? индексы, разные встроенные функции, если бы оно могло утилизировать весь проц то уж когднанить заметил бы, или вы хотите сказать что овчинка того не стоит, т.е. в подавляющем большинстве случаев толку от распараллеливания по процу будет чуть?
всегда в диск упирается, если у вас все данные в память влезают то вам и база не нужна :)
Можно было бы понять если бы недозагружалось даже одно ядро, но он его под завязку выгребает, а значит хочет еще
pg под каждый коннект использует отдельный процесс с одним рабочим потоком, в этом у вас и вся проблема. Иначе pg пока работать не умеет. В прочем, не только он один среди открытых субд.
Досадно это, понятно что для многоконнектной системы это не проблема, но в один коннект проще, если бы он внутри базой распараллеливался было бы шикарно)
Юзай pool Люк.
PL/pgSQL Позволяет делать любые безобразия. Если, например, речь о SELECT, то там порядок вывода играет роль и делать его многопоточно нетривиальная задача. Если в целом, то для чистого sql: один запрос - один поток. Если же запускать выполнение pgSQL функции, то можно брать диапазоны из таблицы, отправлять дополнительные запросы (http://www.postgresql.org/docs/9.2/interactive/dblink.html). Любой же интерфейс поддерживает многопоточность (libpq, python, perl).
Если ваш запрос упёрся в производительность проца, а не памяти/диска, то пора читать мануал.
Ну а что там еще читать? Большие таблицы, где надо - индексы, на тяжелых запросах всегда полностью загружено одно ядро, очевидно что в него и упирается, не ну винт тоже конечно в напряге, но он хоть изредка помаргивает а ядро под завязку.
Ну... Я пол-года назад внутренностями postgres реализовывал перенос WP. Работало быстрее, чем NGINX и стандартные плагины WP для кеша.
> Ну... Я пол-года назад внутренностями postgres реализовывал перенос WP. Работало быстрее,
> чем NGINX и стандартные плагины WP для кеша.Спать, спать, спать... Уже не по теме отвечаю.
Суть - хорошо продуманный алгоритм на порядки эффективнее нового железа и "фич". Для реализации у postgres много инструмента, но вести какие-то вычисления необходимо в отдельных модулях.
Упираться в производительность железа - сигнал к рефакторингу и расширению. Может быть вас устраивает задержка и проблемы нет?
он то как раз хочет чтобы субд была субд, а не бд, понимаешь разницу? Твои эти мидлваре и dblink'и просто костыли, воркэраунды из-за отсутствия нормальной реализации фичи со стороны субд.
когда-нибудь да сделают, всё реально. Но хз когда это наступит, там есть более актуальные задачи на ближайшее время
Странно както, количество ядер растет, производительность дисковой подсистемы увеличивается, по идее этот вопрос будет все острее и острее, а у них насколько я знаю этого даже в широких планах нет, какието отдельные вещи параллелят но не сам основной движок, а ведь такое изменение наверное очень много за собой потянет, как бы фигня не созрела.
для OLTP нагрузки этого не нужно (т.е. паттерн обслуживания множества пользователей, вебня и прочая херня).для аналитки (DWH, OLAP) pg либо настраивают специальным образом (вероятно, под ваши запросы можно сделать специальный конфиг и выполнение больше не будет упираться в ядро. Нужно смотреть на каких именно операциях проседает), либо делать шардинг по нескольким субд вашей бд.
в общем, через костыли, но проблема часто как-то решаема.
> а у них насколько я знаю этого даже в широких планах нет, какието отдельные вещи параллелят но не сам основной движок
Его не просто распараллелить, прежде, например, нужно сделать нормальное партиционирование, а потом вашу задачу. Вот голосовалка фич pg:
http://postgresql.uservoice.com/forums/21853-general
Ваш кейс стоит на 3ем месте, так что скорее всего его скоро начнут делать.
На серверах всегда было много ядер и быстрые диски. Это на десктопах кол-во ядер растёт.
а дак начинали вроде делать, но заглохло. станичка в постгресовской вики с 2009 года висит с недописанным туду.динамическое партиционирование и параллельные запросы - штука нетривиальная, пока кого-то из клиентов с толстыми ЕТЛ запросами не припрет, и он сам не напишет или не заплатит, вряд ли кто не пошевелится. кто будет юзать ворованный оракл, кто - покупной мссикель.
можно подумать мссиквел намного дальше ушёл, ха!зыж
и почему оракл ворованный, а мссиквел купленный?
стандартная редакция оракла даже дешевле мссиквела, а если говорим уже о таких вот нагрузках, то без сервиспаков на ворованном далеко не уедешь.
> можно подумать мссиквел намного дальше ушёл, ха!по сравнению с нулем - не вижу смысла обсуждать, намного или ненамного. что смущает-то?
> зыж
> и почему оракл ворованный, а мссиквел купленный?
> стандартная редакция оракла даже дешевле мссиквела, а если говорим уже о таких
> вот нагрузках, то без сервиспаков на ворованном далеко не уедешь."если уж говорим о таких вот нагрузках", то 4-сокетовый вариант оракла да, он в тему.
последний раз, как я проверял, разница была сильно не в пользу оракла, но это было давно, возможно, что-то изменилось. и в любом случае совершщенно неважно. я мог бы написать "ворованный информикс" и "купленный сайбейс", сути примера это не изменило бы. разве что вылез бы какой-нибудь информикс-фаг и начал нудить "А чо сразу информикс?"
>по сравнению с нулем - не вижу смысла обсуждать, намного или ненамного. что смущает-то?с нулём? :D
угу
http://www.sql.ru/articles/mssql/2004/04112301resolvingblock...
>Блокировки присутствуют в любой реляционной системе управления базами данных (СУБД), т.к. на блокировках основана работа механизма обслуживания параллельных запросов.в синтетических тестах это да, прокатывает. в реальной системе только мешает.
ха! блокировки при селекте - фича на любителей. из разряда кожаных масках.зыж
фичи коммерческих субд порой больше рассчитаны на рекламный проспект, чем на использование.
хотя именно в данном конкретном случае оракл хоть это умеет правильно.
> http://www.sql.ru/articles/mssql/2004/04112301resolvingblock...
>>Блокировки присутствуют в любой реляционной системе управления базами данных (СУБД), т.к. на блокировках основана работа механизма обслуживания параллельных запросов.facepalm.jpg
чё сказать то хотел?пояснения требуются?
>>>Блокировки присутствуют в любой реляционной системе управления базами данных (СУБД), т.к. на блокировках основана работа механизма обслуживания параллельных запросов.блокировки то присутствуют в любой РСУБД, но НЕ в любой на блокировках основана работа механизма обслуживания параллельных запросов. :D
> чё сказать то хотел?
> пояснения требуются?
>>>>Блокировки присутствуют в любой реляционной системе управления базами данных (СУБД), т.к. на блокировках основана работа механизма обслуживания параллельных запросов.
> блокировки то присутствуют в любой РСУБД, но НЕ в любой на блокировках
> основана работа механизма обслуживания параллельных запросов. :Dвы ради разнообразия не пробовали прочесть тред, в который так удачно ворвались, _до_того_, как постить первое, что попалось в яндексе по словам "параллельные запросы"?
Хо!
В яндексе ещё надо знать какой вопрос задавать.
А посему, ваши не нулевые параллельные запросы в мсиквеле разбиваются о блокировки, которые он при этом использует.
Так что пользы от них на практике тотже 0. Вне зависимости какой у вас поисковик.:D
> Блин, а ктонить в курсе, полное задействование проца (всех ядер) для одного
> запроса, т.е. его распараллеливание, когданить сделают? или это для постгреса не
> реально?Чего конкретно http://www.postgresql.org/docs/9.1/static/geqo-intro.html не хватает?
Какие http://www.postgresql.org/docs/7.1/static/geqo.html#GEQO-INTRO слова не понятны?
Понятно что параллелить построение плана сложно, но когда он построен, почему бы не распараллелить его исполнение? В простейшем случае если известно что придется просмотреть определенный диапазон строк, то почему бы не разделить его на поддиапазоны и не натравить на каждый отдельное ядро?
> Блин, а ктонить в курсе, полное задействование проца (всех ядер) для одного
> запроса, т.е. его распараллеливание, когданить сделают? или это для постгреса не
> реально?Когда у вас будет 10-100 одновременных запросов к БД и будут загружены даже 24 ядра, вы поймете, что 1 запрос на ядро - это благо)
Лучше запрос одним ядром обрабатывается и не тратит время на переключения ядер.
А если у вас 1-2 одновременных запроса к БД, нужно менять логику работы с БД, если хотите параллелить.
Самым узким местом должен быть жесткий.
Если узкое место в чем-то другом, значит, есть место для оптимизации)
Параллельных запросов нет, они приходят редко, по одному, но должны выполняться максимально быстро, в крайнем случае выстраиваются внешней системой в очередь. В том то и дело что невозможно изменить обстоятельства и трудно изменить логику внешних систем, в общем случае я не могу параллелить запросы, мне нужно чтобы параллелился 1 запрос, это конечно можно сделать извне, но согласитесь было бы лучше если бы это делала база, по логике это ее задача.И почему узким местом должен быть жесткий? база это не набор готовых данных, это место хранения и обработки данных "средней степени сжатия" ибо запросы могут быть разные и есть требования по объему, а значит место вычислениям всегда есть. Оптимизация всегда выполняется относительно свободных ресурсов, в данном случае у меня свободен проц, почему бы не "упаковать" данные для экономии винта чтобы в него не упиралось, и при этом не задействовать свободный проц выполнив задачу быстрее? В винт упереться недолго, но при этом простаивает проц, в этом случае по моему глупо упираться в винт и говорить что так и должно быть.
Мое мнение что 1 запрос-одно ядро хорошо для OLTP систем,1 запрос-много ядер может быть хорошо для OLAP систем, особенно для "гибридных" систем, когда данные храняться в несовсем оптимальном для OLAP-систем виде.
Как бы там нибыло, на эту фишку есть спрос - значит и ситуации когда она необходима бывают.
> Мое мнение что 1 запрос-одно ядро хорошо для OLTP систем,
> 1 запрос-много ядер может быть хорошо для OLAP систем, особенно для "гибридных"
> систем, когда данные храняться в несовсем оптимальном для OLAP-систем виде.
> Как бы там нибыло, на эту фишку есть спрос - значит и
> ситуации когда она необходима бывают.Для удовлетворения этого спроса уже сейчас есть предложения - кластеры, масштабируемые БД и т.д.
Например, можно использовать MongoDB - развести инфу по куче узлов.
И работать с данными в стиле MapReduce.
Будет очень шустро.
Если не хочется велосипедить, можно взять уже существующие OLAP системы.
Хотя они, вроде бы, не дешевые.P.S.
Но всегда можно сказать "не не не, я не хочу ничего менять, я подожду, пока программисты Postgresql сделают это для меня бесплатно")
Гражданин начальник говорит раз постгрес так не может значит нах его, досадно однако.
> Когда у вас будет 10-100 одновременных запросов к БД и будут загружены
> даже 24 ядра, вы поймете, что 1 запрос на ядро -
> это благо)
> Лучше запрос одним ядром обрабатывается и не тратит время на переключения ядер.
> А если у вас 1-2 одновременных запроса к БД, нужно менять логику
> работы с БД, если хотите параллелить.
> Самым узким местом должен быть жесткий.
> Если узкое место в чем-то другом, значит, есть место для оптимизации)Made my day.
> Для удовлетворения этого спроса уже сейчас есть предложения - кластеры, масштабируемые
> БД и т.д.
> Например, можно использовать MongoDB - развести инфу по куче узлов.
> И работать с данными в стиле MapReduce.
> Будет очень шустро.Twice.
Отлично... JSON, интервалы, м-м-м!
Темпы разработки очень сильно пугают - в debian stable ещё нет 9.1, а они уже 9.2 пустили. Подскажите, а есть ли у postgres постоянные выпуски (помимо development) и LT версии?
Да ладно вам) пугают) Одна новая стабильная версия в год, потом каждая 3-5 лет поддерживается, на протяжении этого времени для каждой выходят доработки, оптимизации, исправления - по моему отлично, чем не LT? Сходите на офсайт и посмотрите. Ну а что там debian для вас заготовил это чисто ваши проблемы.
Разработчики PostgreSQL поддерживают четыре ветки одновременно + ветка разработки.
Самая классная реляционная СУБД для проектов любого масштаба (от небольших сайтов до корпоративного учета).Молодцы! Еще и такой прогресс.
JDBC драйвер что то у них не обновился.
А что там обновлять-то? По-моему клиентом MySQL от 3 версии до сих пор можно подключаться к MySQL хоть 5-й версии.
> А что там обновлять-то? По-моему клиентом MySQL от 3 версии до сих
> пор можно подключаться к MySQL хоть 5-й версии.можно, но это же не значит что он будет использовать новые функции, а в 9.2 появилась такая штука как построчное получение данных с сервера без курсора.
> можно, но это же не значит что он будет использовать новые функции,
> а в 9.2 появилась такая штука как построчное получение данных с
> сервера без курсора.ну так это в libpq, текущая версия JDBC libpq не использует.
Другое дело, добавить поддержку новых типов.
>> А что там обновлять-то? По-моему клиентом MySQL от 3 версии до сих
>> пор можно подключаться к MySQL хоть 5-й версии.
> можно, но это же не значит что он будет использовать новые функции,
> а в 9.2 появилась такая штука как построчное получение данных с
> сервера без курсора.Это что же, до сих пор нельзя было обрабатывать таблицы не умещающиеся в оперативной памяти?
А то я вот недавно с удивлением обнаружил, что клиент MySQL (любой, касается и консольного и Perl DBI и PHP) по умолчанию при выполнении селекта сначала всасывает в оперативку результат запроса целиком. Долго ломал голову, как мне слить нужные данные из таблицы в 70 гигабайт, потом всё-таки нашёл решение.