LINUX.ORG.RU

PostgreSQL 10 лет.


0

0

Одной из самых продвинутых open-source СУБД 8 июля исполнилось 10 лет.
Этому событию была посвящена конференция разработчиков, закончившаяся
10 июля в Торонто, Канада.
Ссылки на материалы презентации, посвященной PostgreSQL internals:
http://www.alcove.com.au/~swm/hacking...
http://www.alcove.com.au/~swm/hacking...
В планах разработчиков выпуск версии 8.2, feature freeze для которой
назначен на первое августа.

>>> Освещение событий конференции проходит на сайте planetpostgresql.org .



Проверено: Shaman007 ()

От души поздравляю!

klon
()

Поздравляю. Есть повод выпить Йаду.

DIMON ★★★
()
Ответ на: комментарий от anonymous

>Почему "ОДНОЙ ИЗ самых продвинутых", что есть продвинутей?

Смотря как считать "продвинутось". По feature set PostgreSQL на первом месте среди open-source, а вот по популярности MySQL его превосходит.
Я согласен, лучше конечно the most advanced open-source database,
как написано на сайте. ;)

anonymous
()

Это хорошо... слонику 10 лет ну ничего ничего еще чуток солнику подрасти и будет бодать оракл :) А что касается криков про mysql - ффф топку она даже не реляционная.

Kalashmat
()

Есть ли у кого примеры применения PostgreSQL для больших баз
(работа с населением)? Может ли PG тягаться с MSSQL?
Как работает на многопроцессорных системах - два двухядерных процессора?
Фирма разработчик рекомендует MSSQL+MS Server 2003,
хотелось бы Linux+PG?

WinLin
()
Ответ на: комментарий от Metallic

>К большому сожалению PostgreSQL умудряется сейчас проигрывать MySQL :-(

О - их команды тоже принимали участие в чемпионате мира по футболу? Как поиграли?

ЗЫ: В чем проигрывает? По пенальти?

r ★★★★★
()
Ответ на: комментарий от WinLin

> Как работает на многопроцессорных системах - два двухядерных процессора?

Обычный SMP, грубо говоря у вас 4 процессора, при соединении 4 клиентов (и соответствующей работе планировщика ядра) запросы каждого из 4-х клиентов будут обрабатываться на отдельном процессоре.

saper ★★★★★
()
Ответ на: комментарий от r

>ЗЫ: В чем проигрывает? По пенальти?

Угу, на smp системах PostgreSQL проигрывает MySQL, по простой причине в том что постгре создан по принципу 1 запрос - 1 процесс, а мускул умеет нагрузку балансировать худо-бедно.

Metallic
()
Ответ на: комментарий от saper

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

saper ★★★★★
()
Ответ на: комментарий от WinLin

>Есть ли у кого примеры применения PostgreSQL для больших баз
>(работа с населением)?

Да, http://www.postgresql.org/about/casestudies/

>Может ли PG тягаться с MSSQL?

По соотношению цена/качество определенно.
По полноте фич MSSQL все-таки впереди, хотя некоторые возможности
(такие как репликация) доступны в виде разработок, не входящих
в дистрибутив, в т.ч. и open-source.

>Как работает на многопроцессорных системах - два двухядерных >процессора?

Для multiprocessor system лучше взять версию 8.1:

Improved Multiprocessor (SMP) Performance: the buffer manager for 8.1 has been enhanced to scale almost linearly with the number of processors, leading to significant performance gains on 8-way, 16-way, dual-core, and multi-core CPU servers.

>Фирма разработчик рекомендует MSSQL+MS Server 2003,
>хотелось бы Linux+PG?

PG можно использовать и на MS-платформах (на ядре windows 2000)
начиная с версии 8.0

mertvez
() автор топика
Ответ на: комментарий от Metallic

> Угу, на smp системах PostgreSQL проигрывает MySQL, по простой причине в том что постгре создан по принципу 1 запрос - 1 процесс, а мускул умеет нагрузку балансировать худо-бедно.

Возможно и так, но PostgreSQL сложные запросы выполняет быстрее MySQL на одной и той же конфигурации :-) хоть SMP, хоть нет.

> а мускул умеет нагрузку балансировать худо-бедно.

А это разве не забота-работа ядра?

Кажется в последней ветке на Win32 стали использовать потоки.

saper ★★★★★
()
Ответ на: комментарий от saper

>Возможно и так, но PostgreSQL сложные запросы выполняет быстрее MySQL на одной и той же конфигурации :-) хоть SMP, хоть нет.

На 8 гиговой базе? Если мускул будет на 4-х процессорах работать, а постгрес только на 1-ом из 4-х(!!!), постгрес явно быстрее не будет ;-)

Metallic
()
Ответ на: комментарий от anonymous

> а секционирование там уже сделали или в августе ?

Эмм, а что это такое?

saper ★★★★★
()
Ответ на: комментарий от saper

>Кажется в последней ветке на Win32 стали использовать потоки.
Нет, 8.1. в win32 использует процессы.
На самом деле это позволяет системе быть более устойчивой, т.к.
при отказе одного процесса postmaster может его завершить без
потери остальных процессов за счет хорошей изоляции данных.
Для создания такой модели на потоках пришлось бы принять много
таблеток анальгина :).

mertvez
() автор топика
Ответ на: комментарий от Metallic

> На 8 гиговой базе? Если мускул будет на 4-х процессорах работать, а постгрес только на 1-ом из 4-х(!!!), постгрес явно быстрее не будет ;-)

Цитата отсюда http://www.postgresql.org/about/ : "An enterprise class database, PostgreSQL boasts sophisticated features such as Multi-Version Concurrency Control (MVCC) ..."

Это -> многопользовательская <- СУБД корпоративного уровня.

saper ★★★★★
()
Ответ на: комментарий от Metallic

>Угу, на smp системах PostgreSQL проигрывает MySQL, по простой >причине в том что постгре создан по принципу 1 запрос - 1 процесс, а >мускул умеет нагрузку балансировать худо-бедно.

И что мускул уже научился нормально работать с внешними ключами, триггерами, хранимыми процедурами? RULES для создания возможности обновления views он умеет? Нормальную документацию, вместо уебищного html файла уже создали?

ЗЫ. Соединение и запрос разные вещи, ага.

anonymous
()
Ответ на: комментарий от saper

>Это -> многопользовательская <- СУБД корпоративного уровня.

Мне интересно получить ответ на свой вопрос, а не какого это уровня БД и т.д. ;-)

Metallic
()
Ответ на: комментарий от anonymous

>И что мускул уже научился нормально работать с внешними ключами, триггерами, хранимыми процедурами? RULES для создания возможности обновления views он умеет? Нормальную документацию, вместо уебищного html файла уже создали?

Умеет, насчет доков не знаю. см. 5ую ветку ;-)

>ЗЫ. Соединение и запрос разные вещи, ага.

Ага.

Metallic
()
Ответ на: комментарий от anonymous

>а секционирование там уже сделали или в августе ?
Если речь идет о table partiotioning, то реализовано в 8.1,
правда с ограничениями (не поддерживается update и delete),
которые скорее всего будут устранены в 8.2.

mertvez
() автор топика
Ответ на: комментарий от Metallic

>Угу, на smp системах PostgreSQL проигрывает MySQL, по простой причине в том что постгре создан по принципу 1 запрос - 1 процесс

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

r ★★★★★
()
Ответ на: комментарий от Metallic

>На 8 гиговой базе? Если мускул будет на 4-х процессорах работать, а >постгрес только на 1-ом из 4-х(!!!), постгрес явно быстрее не будет ;>-)
Архитектура PostgreSQL не ограничивает его выполнение одним
процессором.

На скорость выполнения запросов влияют не только скорость cpu,
но и скорость дисковой подсистемы и сети, причем не факт, что
в меньшей степени (детали, детали, все зависит от запроса).

Также сильно влияет механизм оптимизации запросов и эффективность
работы буферов. В PostgreSQL есть хитрый и эффективный
genetic query optimizer, про буферы уже писал.

Что может на это ответить MySQL ? ;)

mertvez
() автор топика
Ответ на: комментарий от Metallic

>Угу, на smp системах PostgreSQL проигрывает MySQL, по простой причине в том что постгре создан по принципу 1 запрос - 1 процесс

К тому же не 1 запрос, а одно соединение. А учитывая что все прогрессивное человечество *(и регрессивное тоже) давно пользуются пулами - до лампочки это преймущество.

r ★★★★★
()
Ответ на: комментарий от Metallic

> К большому сожалению PostgreSQL умудряется сейчас проигрывать MySQL :-(

В каком месте, интересно?

Misanthrope
()
Ответ на: комментарий от Metallic

>Если мускул будет на 4-х процессорах работать, а постгрес только на 1-ом из 4-х(!!!), постгрес явно быстрее не будет

С чего это вдруг?

r ★★★★★
()

10 лет пишут

А нормального клиента до сих пор не написали... Каждый день запускаю пгадмина и матерюсь.

anonymous
()
Ответ на: комментарий от anonymous

> 20 миллионов записей в месяц это много или мало ?
Зависит от характера информации:
1) просто писать в таблицу миллионы записей и делать
один запрос в конце месяца;
2)активно изменять, добавлять, делать отчеты в реальном времени.

WinLin
()
Ответ на: комментарий от mertvez

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

+1

Командочка kill для постгреса (особено в разработке) отличная вещь. Отстрелил ненужный коннекшен без всякого ущерба для базы и все хорошо.

r ★★★★★
()
Ответ на: 10 лет пишут от anonymous

> Каждый день запускаю пгадмина и матерюсь.

Каждый день запускаю psql и радуюсь как ребенок вспоминая тихий ужас консольной тулзени mysql.

r ★★★★★
()
Ответ на: комментарий от r

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

Всего на 40Гб рам уже мускул загадочно останавливается.

Metallic
()
Ответ на: комментарий от r

>>Угу, на smp системах PostgreSQL проигрывает MySQL, по простой причине в том что постгре создан по принципу 1 запрос - 1 процесс

>К тому же не 1 запрос, а одно соединение. А учитывая что все прогрессивное человечество *(и регрессивное тоже) давно пользуются пулами - до лампочки это преймущество.

Угумс, описалсо первый раз.

Metallic
()
Ответ на: комментарий от Metallic

>Умеет, насчет доков не знаю. см. 5ую ветку ;-)

Т.е. велосипед они уже изобрели? И как, ездит или еще нет? :)

anonymous
()
Ответ на: комментарий от r

>> Каждый день запускаю пгадмина и матерюсь.
>Каждый день запускаю psql и радуюсь как ребенок вспоминая тихий ужас >консольной тулзени mysql.

Ага, учитывая наличия ключа -f в psql можно записать часто
выполняемые команды в файл и получить полный UnixWay ;)

mertvez
() автор топика
Ответ на: комментарий от mertvez

> Ага, учитывая наличия ключа -f в psql можно записать часто выполняемые команды в файл и получить полный UnixWay ;)

А в MySQL уже это отменили разве? :-)

Metallic
()
Ответ на: комментарий от Metallic

>Зависит от лясипедиста :-D

Так что аналог Оракловских materialized views в мускуле уже можно реализовать?

anonymous
()
Ответ на: комментарий от Metallic

>На ящиках с 4-х процессорными оптеронами.

То есть для того чтобы mysql работал и масштабоировался нужно ящики с оптеронами искать. Грандиозно!

r ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.