| 1.1, Аноним (-), 21:44, 20/02/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Надо бы посмотреть как в динамике будет развиваться в этой ситуации. А то свежераздампленная база постгреса всегда раз в полтора быстрее старой на той же версии сервер, из-за отсутствия лишних версий, меньшего места на диске и более точных планов.
| | |
| |
| 2.2, pavel_simple (??), 21:50, 20/02/2008 [^] [^^] [^^^] [ответить]
| +/– |
В 8.3 действительно много изменений касательно производительности -- все ведут к повышению быстродействия по объективным причинам
Молодцы !
| | |
|
| |
| 2.8, Konwin (ok), 00:00, 21/02/2008 [^] [^^] [^^^] [ответить]
| +/– |
 >догоним и перегоним MySQL?)
Ну вы сравнили - промышленную СУБД с СУБД уровня приложений :)
| | |
| |
| 3.9, smb (?), 00:03, 21/02/2008 [^] [^^] [^^^] [ответить]
| +/– | |
+1
было бы что догонять. смотришь на тесты falcon - и понимаешь кривоту рук мускульовцев, лучший движок ведь innodb(имхо!!), не обновлявшийся кучу лет и скупленный ораклом....
| | |
| |
| 4.12, Кирилл (??), 09:41, 21/02/2008 [^] [^^] [^^^] [ответить]
| +/– |
>+1
>
>было бы что догонять. смотришь на тесты falcon - и понимаешь кривоту
>рук мускульовцев, лучший движок ведь innodb(имхо!!), не обновлявшийся кучу лет и
>скупленный ораклом....
инодб лучший движок? ))))) Это обычный ISAM двадцатилетней давности.
| | |
|
| 3.10, Aleksey (??), 07:58, 21/02/2008 [^] [^^] [^^^] [ответить]
| +/– |
Как я понимаю читать надо: "Ну вы сравнили - промышленную СУБД (PostgreSQL) с СУБД уровня приложений (MySQL) :)"
| | |
| |
| 4.13, Konwin (ok), 10:05, 21/02/2008 [^] [^^] [^^^] [ответить]
| +/– |
>Как я понимаю читать надо: "Ну вы сравнили - промышленную СУБД (PostgreSQL)
>с СУБД уровня приложений (MySQL) :)"
Совершенно верно
| | |
|
|
|
| 1.7, Аноним (14), 23:59, 20/02/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
бжжж... а разве не давно перегнали? скорее ораклу нужно будет подвинуться :D
| | |
| |
| 2.11, parad (ok), 09:31, 21/02/2008 [^] [^^] [^^^] [ответить]
| +/– | |
>бжжж... а разве не давно перегнали? скорее ораклу нужно будет подвинуться :D
да, через пару лет по производительности постгрес будет стоять на ровне с монструальным (не путать с менструальным) ораклом. однако по кол-ву разных вкусностей оракл будет лидировать до тех пор, пока в постгре не начнут собирать, сортировать и накапливать модули под разные нужды, например, как это сделано в перле - cpan; все для этого уже имеется - потрясающий апи, удобная портируемость, гибкие настройки.
а так - хорошая работа - великолепный пример успешного BSD проекта. также радует, что все чаще в заголовках интересных новостей все чаще встречаются имена русских девелоперов. молодцы, так держать!
| | |
|
| 1.15, Veter (??), 18:18, 21/02/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
На выборках из нескольких таблиц версия 8.3 в несколько раз медленнее версии 8.1 с той же базой, да еще на более сложных запросах временами строит кривой план выполнения (в 8.1 на тех же запросах строит нормальный). До промышленного использования версии 8.3 еще немало времени пройдет. Релиз очень интересный, но его надо "доводить до ума". Хотя на серверах с перегруженной дисковой подсистемой стоит уже и задуматься, т.к. нагрузка на диск существенно уменьшилась, что может для кого-то стать спасением.
| | |
| 1.16, Veter (??), 18:24, 21/02/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Кстати, сравнивать версии 8.3 и 8.2 некорректно - версия 8.2 медленнее, чем 8.1. К тому же в постгресе четные версии скорее полигон, чем продакшен. Намного интереснее сравнить с 8.1. Кроме того, работа с базой в ОЗУ слишком вырожденный случай. Про планировщик запросов ни слова, видимо, чтобы не вспоминать о грустном.
| | |
| |
| 2.17, Иван Золотухин (?), 19:46, 21/02/2008 [^] [^^] [^^^] [ответить]
| +/– |
работа с базой в ОЗУ -- 95% случаев, так как 4-8ГБ памяти позволить себе все могут, а объем баз у большинства людей вообще меньше гигабайта, о чем тут говорить. пока люди не перестанут думать о том, что это вырожденный случай, новички будут кричать, что mysql быстрее postgresql, при этом даже не удосуживаясь поменять конфиг и положить всю БД в память. тут даже спорить нечего.
| | |
| |
| 3.18, Veter (??), 21:45, 21/02/2008 [^] [^^] [^^^] [ответить]
| +/– | |
Постгрес хорош не в качестве записной кннижки, а как СУБД уровня предприятия. И mysql здесь абсолютно не конкурент (низкая надежность, нет набора встраиваемых языков для организации бизнес-логики в СУБД, примитивный планировщик, "прожорливость" по отношению к ОЗУ и процессорному времени, etc.) Сравнивать стоит с ораклом, но утверждение, что на оракле 95% баз помещается в ОЗУ, совершенно несостоятельно. Что касается ниши пхп+мускул, так тут вообще в 95% случаев (не считал, может, и в 99%, просто позаимствовал число у вас) можно без реляционных СУБД обойтись. С ораклом тягаться тяжело, однако крупные проекты можно с успехом реализовывать на постгресе, во многом благодаря его расширяемости и встроенной поддержке скриптовых языков. И при больших базах, которые не помещаются в ОЗУ, постгрес умеет работать, но есть свои проблемы, которые требуют больше или меньше времени на их решение или поиск обходных путей, пока в этом классе задач версия 8.1 выигрывает особенно, когда запросы под эту версию уже оптимизированы) и смысла переходить на 8.3 нет.
P.S. Неужели ваша компания предлагает услуги коммерческой поддержки форумов на домашних страничках и не интересуется корпоративным сектором? Может, я что-то не понимаю, но как раз мускульщики коммерческого интереса не представляют (за редким исключением). А найти информацию об использовании постгреса в крупном бизнесе почти нереально, увы.
| | |
| |
| 4.20, Иван Золотухин (?), 12:37, 26/02/2008 [^] [^^] [^^^] [ответить]
| +/– |
>P.S. Неужели ваша компания предлагает услуги коммерческой поддержки форумов на домашних страничках
>и не интересуется корпоративным сектором? Может, я что-то не понимаю, но
>как раз мускульщики коммерческого интереса не представляют (за редким исключением). А
>найти информацию об использовании постгреса в крупном бизнесе почти нереально, увы.
Ну чушь какую-то вы говорите. Во-первых, 2-3 ГБ *активных* данных -- это не домашняя страничка. Во-вторых, да, таких инсталляций подавляющее большинство, не вижу в этом ничего плохого. У нас даже большинство клиентов (а это компании среднего размера) с 1С имеет такие базы. В-третьих, из этого не следует, что оставшимся 5% клиентов не нужна помощь. Крупный бизнес тоже использует PostgreSQL, но тщательно это скрывает и зачастую пока не решается использовать его в mission critical задачах, в отличие от компаний среднего размера, которые все же более поворотливы и имеют меньше стереотипов.
Смею вас заверить, что мало кто лучше астрономов разбирается в оптимизации баз, которые совсем не ложатся в память (т.е. гигантских баз), а у нас имеется именно астрономический опыт, который мы успешно применяем в коммерческих проектах. Что касается 8.3 и баз, не влезающих в RAM, читайте рассылки -- уже полно usecase-ов, однозначно свидетельствующих в пользу новой версии.
Я пытаюсь сказать лишь одно на самом деле: Постгрес хорош на любых объемах данных; в самом популярном сегменте небольших баз он абсолютно ни в чем (в т.ч. по скорости) не уступает остальным СУБД. Пока мы совместными усилиями не популяризируем эту простую идею, крупный бизнес не будет знать о PostgreSQL, потому что о нем не говорят на каждом перекрестке.
| | |
|
| 3.19, Антон (??), 22:19, 21/02/2008 [^] [^^] [^^^] [ответить]
| +/– |
>работа с базой в ОЗУ -- 95% случаев, так как 4-8ГБ памяти
>позволить себе все могут, а объем баз у большинства людей вообще
Покажите, pls, пример настроек конфига postgres, связанных с памятью, при 4-8Гб оперативы ? shared_buffers сколько лучше поставить, а то сильно задирать боязно, уж больно мало по дефолту стоит. Остальное что-нибудь нужно тюнить, или shared_buffers увеличить достаточно ?
| | |
| |
| 4.21, Иван Золотухин (?), 12:42, 26/02/2008 [^] [^^] [^^^] [ответить]
| +/– |
>>работа с базой в ОЗУ -- 95% случаев, так как 4-8ГБ памяти
>>позволить себе все могут, а объем баз у большинства людей вообще
>
>Покажите, pls, пример настроек конфига postgres, связанных с памятью, при 4-8Гб оперативы
>? shared_buffers сколько лучше поставить, а то сильно задирать боязно, уж
>больно мало по дефолту стоит. Остальное что-нибудь нужно тюнить, или shared_buffers
>увеличить достаточно ?
Антон, по такому короткому описанию оптимальную конфигурацию указать сложно. Все зависит от ваших данных, характера работы приложения с ними. Грубо, вам можно пытаться увеличивать shared_buffers до 1-2 ГБ, аккуратно измеряя эффект после изменения. Остальные параметры тоже можно тюнить, но вслепую я не решусь о них говорить.
| | |
|
|
|
|
