The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Релиз СУБД PostgreSQL 9.2"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Релиз СУБД PostgreSQL 9.2"  +/
Сообщение от opennews (??) on 10-Сен-12, 22:15 
После года разработки представлен (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

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


3. "Релиз СУБД PostgreSQL 9.2"  +2 +/
Сообщение от Аноним (??) on 10-Сен-12, 22:22 
Блин, а ктонить в курсе, полное задействование проца (всех ядер) для одного запроса, т.е. его распараллеливание, когданить сделают? или это для постгреса не реально?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "Релиз СУБД PostgreSQL 9.2"  +/
Сообщение от sam002_tmp on 10-Сен-12, 22:44 
Вы что из БД сделали?! А так, всё зависит от структуры запроса... Если вы используете функции для обработки, то всё хорошо и ядра все отработают и удалённые сервера через midleware можно вызвать))
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

6. "Релиз СУБД PostgreSQL 9.2"  +/
Сообщение от Аноним (??) on 10-Сен-12, 23:00 
Да не, удаленных никаких нет, а вот про функции не понял, сколько и как чего не делаю (один коннект/запрос) всегда загружено только одно ядро, и просто запрос и свои хранимки с циклами/курсорами и использованием встроенных функций - по любому на один коннект/запрос используется только одно ядро, досадно, большая таблица и по ней относительно не сложный запрос который можно было бы распараллелить, ибо просматривает все записи, ну и соответственно выполнить быстрее, однако нет - исполняет в один поток, проц недогружен.
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

9. "Релиз СУБД PostgreSQL 9.2"  +1 +/
Сообщение от anonymous (??) on 10-Сен-12, 23:28 
Жесткий тоже паралельно таблицу читать будет? Или Partitioning используется?.
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

13. "Релиз СУБД PostgreSQL 9.2"  –1 +/
Сообщение от Аноним (??) on 10-Сен-12, 23:44 
Хм, не используется, но ведь далеко не всегда в диск все упирается? индексы, разные встроенные функции, если бы оно могло утилизировать весь проц то уж когднанить заметил бы, или вы хотите сказать что овчинка того не стоит, т.е. в подавляющем большинстве случаев толку от распараллеливания по процу будет чуть?
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

29. "Релиз СУБД PostgreSQL 9.2"  +/
Сообщение от Аноним (??) on 11-Сен-12, 14:25 
всегда в диск упирается, если у вас все данные в память влезают то вам и база не нужна :)
Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

14. "Релиз СУБД PostgreSQL 9.2"  +/
Сообщение от Аноним (??) on 11-Сен-12, 00:03 
Можно было бы понять если бы недозагружалось даже одно ядро, но он его под завязку выгребает, а значит хочет еще
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

18. "Релиз СУБД PostgreSQL 9.2"  +/
Сообщение от Аноним (??) on 11-Сен-12, 00:23 
pg под каждый коннект использует отдельный процесс с одним рабочим потоком, в этом у вас и вся проблема. Иначе pg пока работать не умеет. В прочем, не только он один среди открытых субд.
Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

19. "Релиз СУБД PostgreSQL 9.2"  +/
Сообщение от Аноним (??) on 11-Сен-12, 00:45 
Досадно это, понятно что для многоконнектной системы это не проблема, но в один коннект проще, если бы он внутри базой распараллеливался было бы шикарно)
Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

24. "Релиз СУБД PostgreSQL 9.2"  +/
Сообщение от o on 11-Сен-12, 09:42 
Юзай pool Люк.
Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

11. "Релиз СУБД PostgreSQL 9.2"  +2 +/
Сообщение от sam002_tmp on 10-Сен-12, 23:42 
PL/pgSQL Позволяет делать любые безобразия. Если, например, речь о SELECT, то там порядок вывода играет роль и делать его многопоточно нетривиальная задача. Если в целом, то для чистого sql: один запрос - один поток. Если же запускать выполнение pgSQL функции, то можно брать диапазоны из таблицы, отправлять дополнительные запросы (http://www.postgresql.org/docs/9.2/interactive/dblink.html). Любой же интерфейс поддерживает многопоточность (libpq, python, perl).
Если ваш запрос упёрся в производительность проца, а не памяти/диска, то пора читать мануал.
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

15. "Релиз СУБД PostgreSQL 9.2"  +/
Сообщение от Аноним (??) on 11-Сен-12, 00:08 
Ну а что там еще читать? Большие таблицы, где надо - индексы, на тяжелых запросах всегда полностью загружено одно ядро, очевидно что в него и упирается, не ну винт тоже конечно в напряге, но он хоть изредка помаргивает а ядро под завязку.
Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

22. "Релиз СУБД PostgreSQL 9.2"  +/
Сообщение от sam002_tmp on 11-Сен-12, 01:46 
Ну... Я пол-года назад внутренностями postgres реализовывал перенос WP. Работало быстрее, чем NGINX и стандартные плагины WP для кеша.
Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

23. "Релиз СУБД PostgreSQL 9.2"  +2 +/
Сообщение от sam002_tmp on 11-Сен-12, 02:01 
> Ну... Я пол-года назад внутренностями postgres реализовывал перенос WP. Работало быстрее,
> чем NGINX и стандартные плагины WP для кеша.

Спать, спать, спать... Уже не по теме отвечаю.
Суть - хорошо продуманный алгоритм на порядки эффективнее нового железа и "фич". Для реализации у postgres много инструмента, но вести какие-то вычисления необходимо в отдельных модулях.
Упираться в производительность железа - сигнал к рефакторингу и расширению. Может быть вас устраивает задержка и проблемы нет?

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

17. "Релиз СУБД PostgreSQL 9.2"  +1 +/
Сообщение от Аноним (??) on 11-Сен-12, 00:21 
он то как раз хочет чтобы субд была субд, а не бд, понимаешь разницу? Твои эти мидлваре и dblink'и просто костыли, воркэраунды из-за отсутствия нормальной реализации фичи со стороны субд.
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

16. "Релиз СУБД PostgreSQL 9.2"  +/
Сообщение от Аноним (??) on 11-Сен-12, 00:17 
когда-нибудь да сделают, всё реально. Но хз когда это наступит, там есть более актуальные задачи на ближайшее время
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

20. "Релиз СУБД PostgreSQL 9.2"  +/
Сообщение от Аноним (??) on 11-Сен-12, 01:01 
Странно както, количество ядер растет, производительность дисковой подсистемы увеличивается, по идее этот вопрос будет все острее и острее, а у них насколько я знаю этого даже в широких планах нет, какието отдельные вещи параллелят но не сам основной движок, а ведь такое изменение наверное очень много за собой потянет, как бы фигня не созрела.
Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

21. "Релиз СУБД PostgreSQL 9.2"  +5 +/
Сообщение от all_glory_to_the_hypnotoad (ok) on 11-Сен-12, 01:19 
для OLTP нагрузки этого не нужно (т.е. паттерн обслуживания множества пользователей, вебня и прочая херня).

для аналитки (DWH, OLAP) pg либо настраивают специальным образом (вероятно, под ваши запросы можно сделать специальный конфиг и выполнение больше не будет упираться в ядро. Нужно смотреть на каких именно операциях проседает), либо делать шардинг по нескольким субд вашей бд.

в общем, через костыли, но проблема часто как-то решаема.

> а у них насколько я знаю этого даже в широких планах нет, какието отдельные вещи параллелят но не сам основной движок

Его не просто распараллелить, прежде, например, нужно сделать нормальное партиционирование, а потом вашу задачу. Вот голосовалка фич pg:

http://postgresql.uservoice.com/forums/21853-general

Ваш кейс стоит на 3ем месте, так что скорее всего его скоро начнут делать.

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

39. "Релиз СУБД PostgreSQL 9.2"  +/
Сообщение от vovans (ok) on 11-Сен-12, 22:20 
На серверах всегда было много ядер и быстрые диски. Это на десктопах кол-во ядер растёт.
Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

25. "Релиз СУБД PostgreSQL 9.2"  +/
Сообщение от Михрютка (ok) on 11-Сен-12, 12:39 
а дак начинали вроде делать, но заглохло. станичка в постгресовской вики с 2009 года висит с недописанным туду.

динамическое партиционирование и параллельные запросы - штука нетривиальная, пока кого-то из клиентов с толстыми ЕТЛ запросами не припрет, и он сам не напишет или не заплатит, вряд ли кто не пошевелится. кто будет юзать ворованный оракл, кто - покупной мссикель.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

26. "Релиз СУБД PostgreSQL 9.2"  +1 +/
Сообщение от ананим on 11-Сен-12, 13:50 
можно подумать мссиквел намного дальше ушёл, ха!

зыж
и почему оракл ворованный, а мссиквел купленный?
стандартная редакция оракла даже дешевле мссиквела, а если говорим уже о таких вот нагрузках, то без сервиспаков на ворованном далеко не уедешь.

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

28. "Релиз СУБД PostgreSQL 9.2"  +1 +/
Сообщение от Михрютка (ok) on 11-Сен-12, 14:18 
> можно подумать мссиквел намного дальше ушёл, ха!

по сравнению с нулем - не вижу смысла обсуждать, намного или ненамного. что смущает-то?

> зыж
> и почему оракл ворованный, а мссиквел купленный?
> стандартная редакция оракла даже дешевле мссиквела, а если говорим уже о таких
> вот нагрузках, то без сервиспаков на ворованном далеко не уедешь.

"если уж говорим о таких вот нагрузках", то 4-сокетовый вариант оракла да, он в тему.

последний раз, как я проверял, разница была сильно не в пользу оракла, но это было давно, возможно, что-то изменилось. и в любом случае совершщенно неважно. я мог бы написать "ворованный информикс" и "купленный сайбейс", сути примера это не изменило бы. разве что вылез бы какой-нибудь информикс-фаг и начал нудить "А чо сразу информикс?"

Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

31. "Релиз СУБД PostgreSQL 9.2"  +/
Сообщение от ананим on 11-Сен-12, 15:42 
>по сравнению с нулем - не вижу смысла обсуждать, намного или ненамного. что смущает-то?

с нулём? :D
угу
http://www.sql.ru/articles/mssql/2004/04112301resolvingblock...
>Блокировки присутствуют в любой реляционной системе управления базами данных (СУБД), т.к. на блокировках основана работа механизма обслуживания параллельных запросов.

в синтетических тестах это да, прокатывает. в реальной системе только мешает.
ха! блокировки при селекте - фича на любителей. из разряда кожаных масках.

зыж
фичи коммерческих субд порой больше рассчитаны на рекламный проспект, чем на использование.
хотя именно в данном конкретном случае оракл хоть это умеет правильно.

Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

32. "Релиз СУБД PostgreSQL 9.2"  +/
Сообщение от Михрютка (ok) on 11-Сен-12, 18:16 
> http://www.sql.ru/articles/mssql/2004/04112301resolvingblock...
>>Блокировки присутствуют в любой реляционной системе управления базами данных (СУБД), т.к. на блокировках основана работа механизма обслуживания параллельных запросов.

facepalm.jpg


Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

33. "Релиз СУБД PostgreSQL 9.2"  +/
Сообщение от ананим on 11-Сен-12, 18:42 
чё сказать то хотел?

пояснения требуются?
>>>Блокировки присутствуют в любой реляционной системе управления базами данных (СУБД), т.к. на блокировках основана работа механизма обслуживания параллельных запросов.

блокировки то присутствуют в любой РСУБД, но НЕ в любой на блокировках основана работа механизма обслуживания параллельных запросов. :D

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

35. "Релиз СУБД PostgreSQL 9.2"  +/
Сообщение от Михрютка (ok) on 11-Сен-12, 19:11 
> чё сказать то хотел?
> пояснения требуются?
>>>>Блокировки присутствуют в любой реляционной системе управления базами данных (СУБД), т.к. на блокировках основана работа механизма обслуживания параллельных запросов.
> блокировки то присутствуют в любой РСУБД, но НЕ в любой на блокировках
> основана работа механизма обслуживания параллельных запросов. :D

вы ради разнообразия не пробовали прочесть тред, в который так удачно ворвались, _до_того_, как постить первое, что попалось в яндексе по словам "параллельные запросы"?

Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

36. "Релиз СУБД PostgreSQL 9.2"  +/
Сообщение от ананим on 11-Сен-12, 22:02 
Хо!
В яндексе ещё надо знать какой вопрос задавать.
А посему, ваши не нулевые параллельные запросы в мсиквеле разбиваются о блокировки, которые он при этом использует.
Так что пользы от них на практике тотже 0. Вне зависимости какой у вас поисковик.:D
Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

47. "Релиз СУБД PostgreSQL 9.2"  +/
Сообщение от Andrey Mitrofanov on 12-Сен-12, 22:39 
> Блин, а ктонить в курсе, полное задействование проца (всех ядер) для одного
> запроса, т.е. его распараллеливание, когданить сделают? или это для постгреса не
> реально?

Чего конкретно http://www.postgresql.org/docs/9.1/static/geqo-intro.html не хватает?
Какие http://www.postgresql.org/docs/7.1/static/geqo.html#GEQO-INTRO слова не понятны?

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

49. "Релиз СУБД PostgreSQL 9.2"  –1 +/
Сообщение от Аноним (??) on 13-Сен-12, 01:15 
Понятно что параллелить построение плана сложно, но когда он построен, почему бы не распараллелить его исполнение? В простейшем случае если известно что придется просмотреть определенный диапазон строк, то почему бы не разделить его на поддиапазоны и не натравить на каждый отдельное ядро?
Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

48. "Релиз СУБД PostgreSQL 9.2"  +/
Сообщение от XoRe (ok) on 12-Сен-12, 23:34 
> Блин, а ктонить в курсе, полное задействование проца (всех ядер) для одного
> запроса, т.е. его распараллеливание, когданить сделают? или это для постгреса не
> реально?

Когда у вас будет 10-100 одновременных запросов к БД и будут загружены даже 24 ядра, вы поймете, что 1 запрос на ядро - это благо)
Лучше запрос одним ядром обрабатывается и не тратит время на переключения ядер.
А если у вас 1-2 одновременных запроса к БД, нужно менять логику работы с БД, если хотите параллелить.
Самым узким местом должен быть жесткий.
Если узкое место в чем-то другом, значит, есть место для оптимизации)

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

50. "Релиз СУБД PostgreSQL 9.2"  +/
Сообщение от Аноним (??) on 13-Сен-12, 01:32 
Параллельных запросов нет, они приходят редко, по одному, но должны выполняться максимально быстро, в крайнем случае выстраиваются внешней системой в очередь. В том то и дело что невозможно изменить обстоятельства и трудно изменить логику внешних систем, в общем случае я не могу параллелить запросы, мне нужно чтобы параллелился 1 запрос, это конечно можно сделать извне, но согласитесь было бы лучше если бы это делала база, по логике это ее задача.

И почему узким местом должен быть жесткий? база это не набор готовых данных, это место хранения и обработки данных "средней степени сжатия" ибо запросы могут быть разные и есть требования по объему, а значит место вычислениям всегда есть. Оптимизация всегда выполняется относительно свободных ресурсов, в данном случае у меня свободен проц, почему бы не "упаковать" данные для экономии винта чтобы в него не упиралось, и при этом не задействовать свободный проц выполнив задачу быстрее? В винт упереться недолго, но при этом простаивает проц, в этом случае по моему глупо упираться в винт и говорить что так и должно быть.

Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

51. "Релиз СУБД PostgreSQL 9.2"  +/
Сообщение от stopa85 (ok) on 13-Сен-12, 12:41 
Мое мнение что 1 запрос-одно ядро хорошо для OLTP систем,

1 запрос-много ядер может быть хорошо для OLAP систем, особенно для "гибридных" систем, когда данные храняться в несовсем оптимальном для OLAP-систем виде.

Как бы там нибыло, на эту фишку есть спрос - значит и ситуации когда она необходима бывают.

Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

52. "Релиз СУБД PostgreSQL 9.2"  +/
Сообщение от XoRe (ok) on 13-Сен-12, 14:27 
> Мое мнение что 1 запрос-одно ядро хорошо для OLTP систем,
> 1 запрос-много ядер может быть хорошо для OLAP систем, особенно для "гибридных"
> систем, когда данные храняться в несовсем оптимальном для OLAP-систем виде.
> Как бы там нибыло, на эту фишку есть спрос - значит и
> ситуации когда она необходима бывают.

Для удовлетворения этого спроса уже сейчас есть предложения - кластеры, масштабируемые БД и т.д.
Например, можно использовать MongoDB - развести инфу по куче узлов.
И работать с данными в стиле MapReduce.
Будет очень шустро.
Если не хочется велосипедить, можно взять уже существующие OLAP системы.
Хотя они, вроде бы, не дешевые.

P.S.
Но всегда можно сказать "не не не, я не хочу ничего менять, я подожду, пока программисты Postgresql сделают это для меня бесплатно")

Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

53. "Релиз СУБД PostgreSQL 9.2"  +/
Сообщение от Аноним (??) on 13-Сен-12, 14:44 
Гражданин начальник говорит раз постгрес так не может значит нах его, досадно однако.
Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

54. "Релиз СУБД PostgreSQL 9.2"  +/
Сообщение от Михрютка (ok) on 13-Сен-12, 16:51 
> Когда у вас будет 10-100 одновременных запросов к БД и будут загружены
> даже 24 ядра, вы поймете, что 1 запрос на ядро -
> это благо)
> Лучше запрос одним ядром обрабатывается и не тратит время на переключения ядер.
> А если у вас 1-2 одновременных запроса к БД, нужно менять логику
> работы с БД, если хотите параллелить.
> Самым узким местом должен быть жесткий.
> Если узкое место в чем-то другом, значит, есть место для оптимизации)

Made my day.

> Для удовлетворения этого спроса уже сейчас есть предложения - кластеры, масштабируемые
> БД и т.д.
> Например, можно использовать MongoDB - развести инфу по куче узлов.
> И работать с данными в стиле MapReduce.
> Будет очень шустро.

Twice.

Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

5. "Релиз СУБД PostgreSQL 9.2"  –3 +/
Сообщение от sam002_tmp on 10-Сен-12, 22:50 
Отлично... JSON, интервалы, м-м-м!
Темпы разработки очень сильно пугают - в debian stable ещё нет 9.1, а они уже 9.2 пустили. Подскажите, а есть ли у postgres постоянные выпуски (помимо development) и  LT версии?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "Релиз СУБД PostgreSQL 9.2"  +3 +/
Сообщение от Аноним (??) on 10-Сен-12, 23:14 
Да ладно вам) пугают) Одна новая стабильная версия в год, потом каждая 3-5 лет поддерживается, на протяжении этого времени для каждой выходят доработки, оптимизации, исправления - по моему отлично, чем не LT? Сходите на офсайт и посмотрите. Ну а что там debian для вас заготовил это чисто ваши проблемы.
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

12. "Релиз СУБД PostgreSQL 9.2"  +1 +/
Сообщение от Аноним (??) on 10-Сен-12, 23:43 
Разработчики PostgreSQL поддерживают четыре ветки одновременно + ветка разработки.
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

27. "Релиз СУБД PostgreSQL 9.2"  +6 +/
Сообщение от Владимир Z email on 11-Сен-12, 14:07 
Самая классная реляционная СУБД для проектов любого масштаба (от небольших сайтов до корпоративного учета).

Молодцы! Еще и такой прогресс.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

30. "Релиз СУБД PostgreSQL 9.2"  +/
Сообщение от pivo on 11-Сен-12, 15:29 
JDBC драйвер что то у них не обновился.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

34. "Релиз СУБД PostgreSQL 9.2"  +/
Сообщение от www2 (??) on 11-Сен-12, 19:04 
А что там обновлять-то? По-моему клиентом MySQL от 3 версии до сих пор можно подключаться к MySQL хоть 5-й версии.
Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

37. "Релиз СУБД PostgreSQL 9.2"  +1 +/
Сообщение от Аноним (??) on 11-Сен-12, 22:15 
> А что там обновлять-то? По-моему клиентом MySQL от 3 версии до сих
> пор можно подключаться к MySQL хоть 5-й версии.

можно, но это же не значит что он будет использовать новые функции, а в 9.2 появилась такая штука как построчное получение данных с сервера без курсора.

Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

42. "Релиз СУБД PostgreSQL 9.2"  +/
Сообщение от Аноним (??) on 12-Сен-12, 00:41 
> можно, но это же не значит что он будет использовать новые функции,
> а в 9.2 появилась такая штука как построчное получение данных с
> сервера без курсора.

ну так это в libpq, текущая версия JDBC libpq не использует.

Другое дело, добавить поддержку новых типов.

Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

55. "Релиз СУБД PostgreSQL 9.2"  +/
Сообщение от www2 (??) on 10-Окт-12, 17:10 
>> А что там обновлять-то? По-моему клиентом MySQL от 3 версии до сих
>> пор можно подключаться к MySQL хоть 5-й версии.
> можно, но это же не значит что он будет использовать новые функции,
> а в 9.2 появилась такая штука как построчное получение данных с
> сервера без курсора.

Это что же, до сих пор нельзя было обрабатывать таблицы не умещающиеся в оперативной памяти?

А то я вот недавно с удивлением обнаружил, что клиент MySQL (любой, касается и консольного и Perl DBI и PHP) по умолчанию при выполнении селекта сначала всасывает в оперативку результат запроса целиком. Долго ломал голову, как мне слить нужные данные из таблицы в 70 гигабайт, потом всё-таки нашёл решение.

Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру