Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 97
тип данных xml, правильная сериализация/десериализация, ну и да — функции экспорта (XMLELEMENT, XMLAGG и т.д.) по стандарту
В частности, это возможность хранить данные в специальном XML-типе (теперь встроен в ядро PostgreSQL), возможность выполнять xpath-запросы по таким колонкам (даже используя индексы!), куча функций для т.н. публикации XML и еще много чего интересного...
ну, индексы использовать можно не для выполнения xpath-запросов, а, скорее, для избежания их выполнения %-)
верно, но факт остается фактом: легко можно добиться очень быстрого выполнения запросов вроде SELECT * FROM table WHERE xml_column = xpath('/company/employee/firstname') = 'John'; (ну синтакс не точный, ну приблизительно).
блин, чушь написал, конечно
правильнее так:
SELECT * FROM table WHERE xpath(xml_column,'//company/employee/firstname')[0] = 'John';
правильнее так:
SELECT * FROM table WHERE xpath(xml_column,'//company/employee/firstname')[0] = 'John';
да, если ваши запросы смогут использовать функциональный индекс, скорость будет превосходна. уже существуют production-системы с сотнями тысяч (не супер объем, но все же) XML-документов, которые используют именно эту функциональность в PostgreSQL.
Скорость конечно на уровне, ибо легко в таком случае заюзать обычный функциональный btree-индекс ;-)
А реляционные БД давным-давно в прошлом, смотрите стандарт, другие СУБД. Всякие там анонимные строчные типы, массивы и тд и тп. В Постгресе это intarray, hstore с нормальными GiST/GIN-индексами от Олега и Фёдора. Слабоструктурированные данные в реляционке хранить теперь просто и приятно. EAV во многих случаях уходит на второй план, т.к. проигрывает в гибкости разработки и прозводительности.
А реляционные БД давным-давно в прошлом, смотрите стандарт, другие СУБД. Всякие там анонимные строчные типы, массивы и тд и тп. В Постгресе это intarray, hstore с нормальными GiST/GIN-индексами от Олега и Фёдора. Слабоструктурированные данные в реляционке хранить теперь просто и приятно. EAV во многих случаях уходит на второй план, т.к. проигрывает в гибкости разработки и прозводительности.
Кстати, система тэгов и всякие там специализированные каталоги в соц. сетях (типа школ, вузов, компаний и т.п.) — это вот как раз такие случаи.
Постараюсь рассказать об этом подробнее в ближайших заметках.
Постараюсь рассказать об этом подробнее в ближайших заметках.
Интересно, это каким же образом b-tree индекс ускорит xpath? Неужели каждый узел dom-модели xml отдельно в индекс суется? Бредятина, сэр!
Для упомянутого SELECT-a:
CREATE INDEX i_zzz ON table1 USING btree((xpath(xml_column,'//company/employee/firstname')[0]));
CREATE INDEX i_zzz ON table1 USING btree((xpath(xml_column,'//company/employee/firstname')[0]));
Не вижу смысла в этом. Зачем делать индекс на запрос xpath? В таком случае гораздо быстрее будет данные не в xml хранить. А что делать в случае, если запрос xpath генерится в процессе работы? Индексировать каждый? Я все к тому, что производительность при использовании xpath к полю xml будет не очень... Хотя не могу отрицать полезность этого дела в частных случаях.
да, вы правы. именно об этом и речь. просто я лично именно с таким счастливым случаем и сталкивался: модель данных предполагала хранение исключительно в XML; наиболее распространенными выборками при этом были запросы на сравнение значений определенных узлов XML-деревьев. конечно, можно распарсить эти значения и хранить их в varchar-колонках, к примеру. но куда приятнее использовать встроенные возможности, функциональный индекс и дополнительные XML-фильтры, когда запрос по индексу уменьшил кол-во возвращаемых записей до нескольких десятков, согласитесь.
К одной неработающей модели добавили другую неработающую модель - в чём проблема ?
Если честно, то дальше BDB API (запрос данных по ключу плюс транзакции) всё абстракции "протекают", причём очень сильно. По хорошему - их лучше бы вообще не пользовать (все абстракции "протекают", но когда масштаб "протечек" превышает определённый рубеж, то борьба с ними превышает выигрыш об абстракций), но столько рекламы здравому смыслу никогда не перебить...
Если честно, то дальше BDB API (запрос данных по ключу плюс транзакции) всё абстракции "протекают", причём очень сильно. По хорошему - их лучше бы вообще не пользовать (все абстракции "протекают", но когда масштаб "протечек" превышает определённый рубеж, то борьба с ними превышает выигрыш об абстракций), но столько рекламы здравому смыслу никогда не перебить...
7 лет ковыряний с одним продуктом запросто справляются с рекламой :-) Мы именно до этого уровня (запрос по ключу + транзакции) и добрались в итоге, но борьба с протечками заняла в самом деле очень много времени:
http://maximkr.livejournal.com/12147.htm…
Причем транзакции тоже под вопросом: если приложение достает данные из СУБД не каждый раз, а вынуждено что-то хранить в памяти, то эти данные в памяти СУБД-шными транзакциями уже не охватываются и приходится блокировки, их репликацию между узлами кластера и т.п. писать вручную.
http://maximkr.livejournal.com/12147.htm…
Причем транзакции тоже под вопросом: если приложение достает данные из СУБД не каждый раз, а вынуждено что-то хранить в памяти, то эти данные в памяти СУБД-шными транзакциями уже не охватываются и приходится блокировки, их репликацию между узлами кластера и т.п. писать вручную.
только этта
SELECT (xpath('/value/text()',data))[1] FROM xmltable where cast((xpath('/value/text()',xml_column))[1] as text) like '%ab%';
и индекс соответсвенно:
CREATE INDEX i_zzz ON xmltable USING btree(cast((xpath('/value/text()',xml_column))[1] as text));
только это никак не помогает в like запросах
SELECT (xpath('/value/text()',data))[1] FROM xmltable where cast((xpath('/value/text()',xml_column))[1] as text) like '%ab%';
и индекс соответсвенно:
CREATE INDEX i_zzz ON xmltable USING btree(cast((xpath('/value/text()',xml_column))[1] as text));
только это никак не помогает в like запросах
— Слон полосатый, редкий, очень любит рыбий жир, при звуках флейты — теряет волю… ©
Сколько можно об одном и том же? Уже как минимум третий пост про постгрю.
а где первые два?
ну, блог "я умный", видимо, не лучшее место.
а справочник не в тему, это не объявление о выходе.
моя статья о новинках 8.3 тут была ещё в октябре, её вы почему не вспомнили? ;-)
а справочник не в тему, это не объявление о выходе.
моя статья о новинках 8.3 тут была ещё в октябре, её вы почему не вспомнили? ;-)
Автору того поста подкинул кармы. Подкиньте кто-нибудь ещё, чтобы в будущем постил в правильные блоги и дублей становилось меньше ;-)
Справочник, как и этот пост, опубликован в соответствующем сообществе. Если вам не нравится, как работает хабр в смысле вывода на главную тематических сообществ - жалуйтесь создателям.
А LINQ они планируют поддерживать?
Товарищи Самохвалов и Бесков проведите нам семинар по новым функциям, производительности и т.п.
Господа, а кто-нибудь может доступно обрисовать сравнение PostgreSQL vs MySQL?
1 - значит на маленько-средних проектах MySQL выигрывает (хотя возможно, что более глубокий тюнинг позволит выигрывать и на больших проектах с большими нагрузками)
2 - аналогично
3 - outdate
2 - аналогично
3 - outdate
Не будет он выигрывать на больших проектах с большими нагрузками на одной СУБД.
если смотреть на второй тест, то непонятно как "глубокий тюнинг позволит выигрывать".
более чем в 10 раз разогнать не получится)
более чем в 10 раз разогнать не получится)
Там разница всего в 2 раза при максильном конкуренси.
Опять же, тесту больше 1 года уже...
Опять же, тесту больше 1 года уже...
ой. извиняюсь. я о первом
http://wiki.sysfaq.ru/wiki/MySQL_vs_PostgreSQL
5.0.32-Debian_3-log vs PostgreSQL 8.1.8 on i486-pc-linux-gnu
в PostgreSQL может и есть изменения, но в MySQL я не замечаю никаких изменений в сторону увеличения производительности (з.ы. сам пока юзаю MySQL)
http://wiki.sysfaq.ru/wiki/MySQL_vs_PostgreSQL
5.0.32-Debian_3-log vs PostgreSQL 8.1.8 on i486-pc-linux-gnu
в PostgreSQL может и есть изменения, но в MySQL я не замечаю никаких изменений в сторону увеличения производительности (з.ы. сам пока юзаю MySQL)
Этот тест у меня вызывает сомнения если честно.
Я вот тоже нашел "MySQL Beats Sybase and PostgreSQL in Throughput and Power Efficiency", но к сожалению будут перетестровать, так как из Sybase пожаловались =)
http://www.worlds-fastest.com/wfz988.html
Я вот тоже нашел "MySQL Beats Sybase and PostgreSQL in Throughput and Power Efficiency", но к сожалению будут перетестровать, так как из Sybase пожаловались =)
http://www.worlds-fastest.com/wfz988.html
Могу здесь сказать только одно: в постгресе с времен 8.1.8 произошли без преувеличения гигантские изменения в сторону улучшения производительности, читайте хотя бы описание этого релиза, даже опуская новшества версии 8.2.
Если в проекте нужны транзакции (практически в любом проекте с ненулевой надежностью они нужны), то PostgreSQL обгоняет MySQL по скорости на любых размерах, начиная с небольших проектов и кончая гигантскими вроде Skype.
imho, не так всё просто. хватает примеров огромных проектов, отлично чувствующих себя на MySQL (те же гугл, яху).
да, конечно, вы правы.
полно вполне нормальных ситуаций, когда даже и транзакции-то не нужны: например каунтеры li.ru работают на MySQL, потому что ценности в информации об одном из сотен миллионов кликов в сутки нет никакой. но если нужна mission critical запись в БД, с MySQL не все так радужно по общему мнению.
полно вполне нормальных ситуаций, когда даже и транзакции-то не нужны: например каунтеры li.ru работают на MySQL, потому что ценности в информации об одном из сотен миллионов кликов в сутки нет никакой. но если нужна mission critical запись в БД, с MySQL не все так радужно по общему мнению.
А правдо ли что с мускула можно безболезнено перейти на постгрес?
А вот на ораклы и другие сайбезы точно низя( нету оператора LIMIT, то да се, так да сяк )
А вот на ораклы и другие сайбезы точно низя( нету оператора LIMIT, то да се, так да сяк )
Истинная правда
http://www.postgresql.org/docs/techdocs.…
http://www.postgresql.org/docs/techdocs.…
Если есть уже готовый проект, "заточенный" под MySQL, то безболезненно - не получится.
Взять всё те же ENUM, SET, inet_aton/inet_ntoa, INSERT DELAYED, password, etc, etc.
Взять всё те же ENUM, SET, inet_aton/inet_ntoa, INSERT DELAYED, password, etc, etc.
совсем безболезненно не получится, но усилия стоят того — проверено на личном опыте, мигрировали живую production-систему.
всё, что перечислено в этом небольшом списке, — не проблема, всё делается легко
Также, как и здесь? :-)
ENUM в 8.3 как раз сделали.
INSERT DELAYED можно заменить на использование асинхронных транзакций достаточно безболезненно.
INSERT DELAYED можно заменить на использование асинхронных транзакций достаточно безболезненно.
ENUM, несмотря на его очевидные преимущества, мягко говоря, не совсем тот, к которому привыкли пользователи MySQL.
Речь всё-таки о:
» А правдо ли что с мускула можно безболезнено перейти на постгрес?
А теперь представьте, что по старой привычке у Вас полмиллиона запросов, разбросанных по многочисленным клиентским и т.п. приложениям выбирает enum-значения по их целочисленному индексу.
Речь всё-таки о:
» А правдо ли что с мускула можно безболезнено перейти на постгрес?
А теперь представьте, что по старой привычке у Вас полмиллиона запросов, разбросанных по многочисленным клиентским и т.п. приложениям выбирает enum-значения по их целочисленному индексу.
такс... Энто хорошо... бум обновлять сервак :)
Все приемущества слона грубо обрываются на том что его мало где найдёшь на хостингах да и движки в бОльшем случае юзают мускуль :)
Хорошие движки поддерживают PostgreSQL, потому что поддерживать его легко. Что касается хостинга — то да, с ним есть проблемы. Но ситуация меняется в лучшую сторону, потому как спрос на постгрес растет неуклонно.
Вопрос - какие CMS используют постгрис - особенно про OpenSource интересует
На чем должна быть написана CMS? Сходу назову не CMS, но тоже "движки" на постгресе: MediaWiki (см. wikipedia.org), Serendipity (blog engine), CakePHP (CMF)
drupal, mediawiki
маловато... тем более DB инджил прикрутили в 5,2 пора бы его уже поприменять
скажите, что вам нужно и решение найдется. если гуглить, продуктов будет более чем достаточно даже для предвзятого пользователя.
Вы меня не правильно поняли , я просто сказать хотел что при всей своей крутости и тд база используется маловато :( интересны причины
Причины: миф о легкости и лучшей производительности MySQL, за которой стоит коммерческая компания с ее рекламными бюджетами, способствует тому, что новички с их нетребовательными приложениями на нее подсаживаются, не подозревая о том, что есть лучшая альтернатива. Вот и юзают 80% малоопытных пользователей MySQL, создавая много шума по этому поводу. Оно может для них и лучше, спорить не буду, но если вы считаете, что попадаете в 20% более продвинутых, то по крайней мере необходимо осознавать, что к чему в мире СУБД. Впрочем, и для новичков, изучающих SQL, лучше начинать не с диалекта MySQL и не ACID-совместимого продукта, а с гораздо более стандартного и ACID-совместимого PostgreSQL.
Не CMS, но поддерживается Django-й
Интересно было бы найти желающих провести собственное тестирование. Например у меня есть Mysql на таком то сервере, у кого то есть Postgre. Давайте составим проверочную структуру данных и потестим.
сильно грубо будет. нужно на одном и том же сервере тестить.
с одним и тем же наполнением БД
с одним и тем же наполнением БД
Именно такой ответ и ожидал :) Думаю не скоро мы найдём желающего, с двумя обеими установленными БД (и временем для тестов). Можно пробовать и на разных (однозначно с одинаковой структурой и наполнением ДБ). Если до сих пор сохраняется такая "разительная" разница в производительности как в старых сравнительных тестах, то это и так будет понятно, а если получим что-то схожее будем делать поправку на аппаратное обеспечение или может и не прийдётся ;)
Результаты подобных тестов (с различающимся оборудованием, но с одинаковыми схемами БД и данными) были опубликованы летом 2007-го. Причём очень на высоком уровне, тестировали инженеры Sun на протяжении многих месяцев.
http://postgresmen.ru/news/view/44
Это самое лучшее, самое серьёзное сравнение различных СУБД на сегодняшний день. Даже с учётом того, что оборудование было разным.
http://postgresmen.ru/news/view/44
Это самое лучшее, самое серьёзное сравнение различных СУБД на сегодняшний день. Даже с учётом того, что оборудование было разным.
Я не считаю это тестирование правильным и точным.
Тока укажите критерии тестирования. Я работал и с MySQL и с PostgreSQL. Из моего опыта работы следует, что PostgreSQL работает стабильнее и быстрее на больших объемах данных и при количестве операций ввода-вывода с двадцати и более. Кроме этого PostgreSQL тюнить надо существенно меньше по сравнению с MySQL. Стабильная работа MySQL наблюдается только на InnoDB. MyISAM будет более менее работать только при распределении профиля нагрузки между двумя серверами (один на чтение, второй на запись).
MyISAM - сам по себе формат не предполагает одновременную запись и чтение (ввиду отсутствия в нем транзакций). Чтобы использовать сервер баз данных на полную
, нужно хорошо разбираться в принципах его функционирования (думаю это касается любого сервера БД).
P.S. обратите внимание на http://blogs.ittoolbox.com/database/soup/archives/postgresql-publishes-first-real-benchmark-17470
"This publication shows that a properly tuned PostgreSQL is not only as fast or faster than MySQL"
Люди не кричат что наше сервер БД быстрее всех, а весьма осторожно - "не медленнее, а может и быстрее"
, нужно хорошо разбираться в принципах его функционирования (думаю это касается любого сервера БД).
P.S. обратите внимание на http://blogs.ittoolbox.com/database/soup/archives/postgresql-publishes-first-real-benchmark-17470
"This publication shows that a properly tuned PostgreSQL is not only as fast or faster than MySQL"
Люди не кричат что наше сервер БД быстрее всех, а весьма осторожно - "не медленнее, а может и быстрее"
MyISAM - сам по себе формат не предполагает одновременную запись и чтение (ввиду отсутствия в нем транзакций).
Вообще СУБД как раз таки подразумевает наличие одновременного чтения и записи.
Чтобы использовать сервер баз данных на полную, нужно хорошо разбираться в принципах его функционирования
Я вполне разбираюсь как работает MySQL, но от этого он быстрее и стабильнее чем PostgreSQL вести себя не начинает.
Люди не кричат что наше сервер БД быстрее всех, а весьма осторожно - "не медленнее, а может и быстрее
Я вообще-то указывал при каких условиях MySQL менее производителен. В тесте так же указано как и что тестировалось. Можете проверить результаты.
Я вовсе не собирался спорить и утверждать, что MySQL лучше или хуже PostgreSQL. Просто считаю, что не имеет сравнивать производительность плоско (одни и те же структуры данных одни и те же запросы). К этому нужно подходить более гибко, то есть ставить задачу: такой то набор данных, такая то задача по выборке и обновлению. После чего уже писать под каждую БД свою структуру и свои запросы, и уже тогда сравнивать производительность по скорости выполнения самой постановочной задачи. Так ИМХО будет более точно (недаром инженеры сан потратили на тестирование несколько месяцев, а не дней), и результаты будут не такими однозначными.
Просто считаю, что не имеет сравнивать производительность плоско (одни и те же структуры данных одни и те же запросы). К этому нужно подходить более гибко, то есть ставить задачу: такой то набор данных, такая то задача по выборке и обновлению.
Описаная в тесте задача, вообщем-то не является синтетической, такого рода структуры часто встречаются. Дополнительно можно добавить индексы, но ситуацию это кардинально не исправит. Если у вас есть предложения как вот на конкретно разобранной задаче увеличить производительность, то опишите как это сделать.
После чего уже писать под каждую БД свою структуру и свои запросы, и уже тогда сравнивать производительность по скорости выполнения самой постановочной задачи.
В случае больших проектов это не имеет смысла. По сути вы можете сделать двойную работу.
PS Да MySQL может дать большую производительность при определенных условиях. Но это обычно требует дополнительных шаманств.
немного занудства: всегда думал что СУБД мужского рода - все-таки сервер, а не женского
После безапелляционной фразы "... лучшей СУБД в мире ..." остальное читать даже не хочется. Хоть бы улыбочку какую поставили. Детский сад, штаны на лямках, ей Богу!
По многим показателям действительно лучшая. Вам сюда: http://www.postgresql.org/about/
А мою заметку, конечно, не читайте, если нет желания.
А мою заметку, конечно, не читайте, если нет желания.
+1
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Слоны уже тут. Быстрые, надёжные, мощные. PostgreSQL 8.3!