https://opennet.ru/openforum/vsluhforumID3/86398.html После года разработки представлен (http://www.postgresql.org/about/news/1415/) релиз новой стабильной ветки PostgreSQL 9.2 (http://www.postgresql.org). Кроме реализации новых функций в новой ветке проведена значительная работа по увеличению производительности и масштабируемости, как горизонтальной (распределение нагрузки на несколько серверов), так и вертикальной (оптимальная работа на больших мощных серверах). В качестве примеров возросшей производительности PostgreSQL приводится способность обрабатывать до 350 тыс. запросов на чтение в секунду (в 4 раза больше чем раньше) и до 14 тысяч запросов на запись в секунду (в 5 раз быстрее).<br><br><br><br><br><br>Ключевые улучшения (http://wiki.postgresql.org/wiki/What%27s_new_in_PostgreSQL_9.2):<br><br><br><br>- Поддержка (http://www.postgresql.org/docs/9.2/static/datatype-json.html) типа данных JSON и встроенные средства для манипулирования данными в формате JSON, что позволяет создавать гибридные документо-реаляционные базы данных. Дополнительно представлен набор сопутствующих функц https://opennet.ru/openforum/vsluhforumID3/86398.html#55 Wed, 10 Oct 2012 13:10:29 GMT &gt;&gt; А что там обновлять-то? По-моему клиентом MySQL от 3 версии до сих <br>&gt;&gt; пор можно подключаться к MySQL хоть 5-й версии.<br>&gt; можно, но это же не значит что он будет использовать новые функции, <br>&gt; а в 9.2 появилась такая штука как построчное получение данных с <br>&gt; сервера без курсора.<br><br>Это что же, до сих пор нельзя было обрабатывать таблицы не умещающиеся в оперативной памяти?<br><br>А то я вот недавно с удивлением обнаружил, что клиент MySQL (любой, касается и консольного и Perl DBI и PHP) по умолчанию при выполнении селекта сначала всасывает в оперативку результат запроса целиком. Долго ломал голову, как мне слить нужные данные из таблицы в 70 гигабайт, потом всё-таки нашёл решение.<br> https://opennet.ru/openforum/vsluhforumID3/86398.html#54 Thu, 13 Sep 2012 12:51:42 GMT &gt; Когда у вас будет 10-100 одновременных запросов к БД и будут загружены <br>&gt; даже 24 ядра, вы поймете, что 1 запрос на ядро - <br>&gt; это благо) <br>&gt; Лучше запрос одним ядром обрабатывается и не тратит время на переключения ядер. <br>&gt; А если у вас 1-2 одновременных запроса к БД, нужно менять логику <br>&gt; работы с БД, если хотите параллелить.<br>&gt; Самым узким местом должен быть жесткий.<br>&gt; Если узкое место в чем-то другом, значит, есть место для оптимизации) <br><br>Made my day.<br><br>&gt; Для удовлетворения этого спроса уже сейчас есть предложения - кластеры, масштабируемые <br>&gt; БД и т.д.<br>&gt; Например, можно использовать MongoDB - развести инфу по куче узлов.<br>&gt; И работать с данными в стиле MapReduce.<br>&gt; Будет очень шустро.<br><br>Twice.<br><br> https://opennet.ru/openforum/vsluhforumID3/86398.html#53 Thu, 13 Sep 2012 10:44:19 GMT Гражданин начальник говорит раз постгрес так не может значит нах его, досадно однако.<br> https://opennet.ru/openforum/vsluhforumID3/86398.html#52 Thu, 13 Sep 2012 10:27:17 GMT &gt; Мое мнение что 1 запрос-одно ядро хорошо для OLTP систем, <br>&gt; 1 запрос-много ядер может быть хорошо для OLAP систем, особенно для "гибридных" <br>&gt; систем, когда данные храняться в несовсем оптимальном для OLAP-систем виде.<br>&gt; Как бы там нибыло, на эту фишку есть спрос - значит и <br>&gt; ситуации когда она необходима бывают.<br><br>Для удовлетворения этого спроса уже сейчас есть предложения - кластеры, масштабируемые БД и т.д.<br>Например, можно использовать MongoDB - развести инфу по куче узлов.<br>И работать с данными в стиле MapReduce.<br>Будет очень шустро.<br>Если не хочется велосипедить, можно взять уже существующие OLAP системы.<br>Хотя они, вроде бы, не дешевые.<br><br>P.S.<br>Но всегда можно сказать "не не не, я не хочу ничего менять, я подожду, пока программисты Postgresql сделают это для меня бесплатно")<br> https://opennet.ru/openforum/vsluhforumID3/86398.html#51 Thu, 13 Sep 2012 08:41:29 GMT Мое мнение что 1 запрос-одно ядро хорошо для OLTP систем, <br><br>1 запрос-много ядер может быть хорошо для OLAP систем, особенно для "гибридных" систем, когда данные храняться в несовсем оптимальном для OLAP-систем виде.<br><br>Как бы там нибыло, на эту фишку есть спрос - значит и ситуации когда она необходима бывают.<br> https://opennet.ru/openforum/vsluhforumID3/86398.html#50 Wed, 12 Sep 2012 21:32:29 GMT Параллельных запросов нет, они приходят редко, по одному, но должны выполняться максимально быстро, в крайнем случае выстраиваются внешней системой в очередь. В том то и дело что невозможно изменить обстоятельства и трудно изменить логику внешних систем, в общем случае я не могу параллелить запросы, мне нужно чтобы параллелился 1 запрос, это конечно можно сделать извне, но согласитесь было бы лучше если бы это делала база, по логике это ее задача.<br><br>И почему узким местом должен быть жесткий? база это не набор готовых данных, это место хранения и обработки данных "средней степени сжатия" ибо запросы могут быть разные и есть требования по объему, а значит место вычислениям всегда есть. Оптимизация всегда выполняется относительно свободных ресурсов, в данном случае у меня свободен проц, почему бы не "упаковать" данные для экономии винта чтобы в него не упиралось, и при этом не задействовать свободный проц выполнив задачу быстрее? В винт упереться недолго, но при этом простаивает проц, в этом случае по моему глу https://opennet.ru/openforum/vsluhforumID3/86398.html#49 Wed, 12 Sep 2012 21:15:08 GMT Понятно что параллелить построение плана сложно, но когда он построен, почему бы не распараллелить его исполнение? В простейшем случае если известно что придется просмотреть определенный диапазон строк, то почему бы не разделить его на поддиапазоны и не натравить на каждый отдельное ядро?<br> https://opennet.ru/openforum/vsluhforumID3/86398.html#48 Wed, 12 Sep 2012 19:34:14 GMT &gt; Блин, а ктонить в курсе, полное задействование проца (всех ядер) для одного <br>&gt; запроса, т.е. его распараллеливание, когданить сделают? или это для постгреса не <br>&gt; реально?<br><br>Когда у вас будет 10-100 одновременных запросов к БД и будут загружены даже 24 ядра, вы поймете, что 1 запрос на ядро - это благо)<br>Лучше запрос одним ядром обрабатывается и не тратит время на переключения ядер.<br>А если у вас 1-2 одновременных запроса к БД, нужно менять логику работы с БД, если хотите параллелить.<br>Самым узким местом должен быть жесткий.<br>Если узкое место в чем-то другом, значит, есть место для оптимизации)<br> https://opennet.ru/openforum/vsluhforumID3/86398.html#47 Wed, 12 Sep 2012 18:39:06 GMT &gt; Блин, а ктонить в курсе, полное задействование проца (всех ядер) для одного <br>&gt; запроса, т.е. его распараллеливание, когданить сделают? или это для постгреса не <br>&gt; реально?<br><br>Чего конкретно http://www.postgresql.org/docs/9.1/static/geqo-intro.html не хватает?<br>Какие http://www.postgresql.org/docs/7.1/static/geqo.html#GEQO-INTRO слова не понятны?<br>