Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 111
Работаю с MySQL, но давно уже присматриваюсь к PostgreSQL. Заинтересовало использование CTE для организации рекурсивных запросов и пользовательские типы данных, которые не поддерживаются в MySQL.
Раньше использовал MySQL. Два года назад перешел на PostgreSQL. Не пожалел. Оно того стоит. Личное впечатление: «отличаются как небо и земля»
А конкретнее. Какие профиты вы получили?
По моему опыту — несопоставимо качество работы оптимайзера запросов. На чуть сложных запросах MySQL норовит свалиться в full table scan с соответствующим влиянием на производительность, PostgreSQL же честно разруливает сложные запросы и выполняет их гораздо быстрее.
Постгрес тоже часто на сложных запросах в full table scan сваливается — я несколько раз за последние пару лет наткнулся. 9.1 значительно лучше 8.х в этом отношении, конечно.
Странно, у меня (при условии нормально проставленных индексов) такого не встречалось — а запросы были очень сложными. Но даже если такое действительно встречается (может, мне просто везло) — всё равно, с mysql никак не сравнить.
один случай был — при большом количестве JOIN-ов, оптимизатор учитывал только первые 6-8 JOIN-ов (у постгресса в настройках есть параметр), а остальные не оптимизировал. Получалось, что смена порядка JOIN-ов изменяла скорость выполнения запроса в раз в 20. Это дело было починено в 9.1. Другой случай — в сложном запросе был sub-query, который по логике должен был запущен 1 раз, а запрос с ним выполнялся в 100 раз медленнее, чем должен был. Тоже было починено в 9.1, а в 8.4 помогла замена на JOIN. Ну и прилично было таких случаев. Был даже случай, когда 9.1 начал тормозить на запросе, нормально выполнявшемся в 8.4, но не помню уже, в чем там дело было.
Сегодня разнообразные открытые СУБД встают лицом к лицу против массивных, неуклюжих и дорогостоящих «корпоративных» систем, таких как SQL Server и Oracle. Часто открытые СУБД прекрасно работают лучше закрытых систем, не уступая даже в функциональных возможностях.
Всегда любил такие высказывания. Особенно ничем не подкрепленные.
У меня есть друг. Его зовут Роб Салливан и он DBA. Вместе с ним мы провели небольшой эксперимент: загрузили в Postgres архив данных StackOverflow, содержащий шесть миллионов текстовых записей. После этого мы расчехлили свои инструменты (для запросов к базе данных) и начали оптимизировать нашу систему, сравнивая её поведение с поведением SQL Server. Postgres не просто показал сравнимую производительность, он во многих случаях значительно превзошёл решение от Microsoft!
А MSSQL при этом оптимизировали, или нет? И где результаты тестов в цифрах?
Это перевод, и автор оригинальной статьи наверняка ответит на все вопросы. Странно, но хабр не подсвечивает тег <abbr>, которым размечено второе предложение.
Я знаю, что это перевод. Но если уж кто-то его здесь разместил, то его и пообсуждать здесь можно, не так ли?
(а иначе в чем смысл)
(а иначе в чем смысл)
Так а в чём проблема? Гуглим по Postre vs SQL server и находим кучу сравнений. Почти всегда — закономерно не в пользу последней кроме странных синтетических случаев. Уже давно Postrgre считается самой адекватной свободной СУБД, практически не уступающей и во многом превосходящей оракл и тем паче MSSQL. Эта характеристика за постгрёй закрепилась не просто так, так что изначальный автор по сути просто ещё раз про неё напомнил.
Гуглим по Postre vs SQL server и находим кучу сравнений
То есть мне еще надо и погуглить, чтобы подтвердить точку зрения автора статьи, с которой я еще и не согласен.
Вообще-то бремя доказательства лежит на утверждающем.
Почти всегда — закономерно не в пользу последней кроме странных синтетических случаев.
А что в этом закономерного?
А что в этом закономерного?
Вы не опенсорс-фанатик, должно быть. Тогда что вы тут делаете? ;)
Любопытствую альтернативами MS SQL.
Сережа, все правда так про постре. Оно как минимум не хуже)
Все зависит от задачи. Ваш К.О.
Но задачи у PostgreSQL и MS SQL/Oracle те же. Это реляционная БД, масштабируемая, очень стабильная и современная.
С MS SQL работать не довелось; но существенных проблем с PostgreSQL по сравнению с Ораклом совершенно точно в наших внедрениях не было. Более того, Постгрес значительно проще в администрировании.
С MS SQL работать не довелось; но существенных проблем с PostgreSQL по сравнению с Ораклом совершенно точно в наших внедрениях не было. Более того, Постгрес значительно проще в администрировании.
Но задачи у PostgreSQL и MS SQL/Oracle те же.
Вы не учитываете такую маленькую и незаметную «задачу» как необходимость быть совместимыми со всем остальным стеком используемого ПО.
:)
Да уж, вот тут у продуктов MS под виндой конкурентов быть по определению не может. Они ж столько лет на это работали…
… и всем по-прежнему все равно. Я к тому, что на корпоративном рынке мало кто руководствуется благом техническим.
Тот же Оракл на Server Edition довольно жутко вкатывается. Молчу уж про то, что он достаточно нетривиально удаляется, оставляя за собой либы и непонятный мусор в реестре.
Да уж, вот тут у продуктов MS под виндой конкурентов быть по определению не может. Они ж столько лет на это работали…
… и всем по-прежнему все равно. Я к тому, что на корпоративном рынке мало кто руководствуется благом техническим.
Тот же Оракл на Server Edition довольно жутко вкатывается. Молчу уж про то, что он достаточно нетривиально удаляется, оставляя за собой либы и непонятный мусор в реестре.
… и всем по-прежнему все равно. Я к тому, что на корпоративном рынке мало кто руководствуется благом техническим.
Ну, вы за всех-то не говорите. Вполне себе есть проекты, где делают оценку совместимости.
За всех говорить не буду. Локально встречаются начальники отделов и ведущие разработчики, старающиеся держать хотя бы свои участки в чистоте и порядке.
Но возьмем среднюю такую корпорацию тысячи эдак на четыре человек. Там будет SAP, будет заказной софт на Джаве и будет заказной софт для .NET. И Оракл тоже будет — для Джавы той же. И MS SQL — для .NET, который тоже где-нибудь рядышком найдется.
И все эти сотни тысяч — если не миллионы — строк еще через какую-нибудь шину должны будут переплевываться сообщениями…
А как так вышло? Вышло так, потому что в 2007 был один зам, который протолкнул свое решение. Через четыре года — другой. Еще одно решение. А когда-то кто-то еще что-то…
Я, кстати, про реальную корпорацию говорю. И ведь не потому так вышло, что какой-то из отделов плохо свою работу делал…
Но возьмем среднюю такую корпорацию тысячи эдак на четыре человек. Там будет SAP, будет заказной софт на Джаве и будет заказной софт для .NET. И Оракл тоже будет — для Джавы той же. И MS SQL — для .NET, который тоже где-нибудь рядышком найдется.
И все эти сотни тысяч — если не миллионы — строк еще через какую-нибудь шину должны будут переплевываться сообщениями…
А как так вышло? Вышло так, потому что в 2007 был один зам, который протолкнул свое решение. Через четыре года — другой. Еще одно решение. А когда-то кто-то еще что-то…
Я, кстати, про реальную корпорацию говорю. И ведь не потому так вышло, что какой-то из отделов плохо свою работу делал…
Я, кстати, не вижу в описанной ситуации ничего плохого.
Я как раз хочу сказать, что находясь в подобной ситуации .net-разработчик скорее уж выберет mssql, чем postresql. Поэтому «не хуже» окажется весьма субъективным.
Я как раз хочу сказать, что находясь в подобной ситуации .net-разработчик скорее уж выберет mssql, чем postresql. Поэтому «не хуже» окажется весьма субъективным.
не вижу ничего хорошего в разнобое, это просто такие рабочие реалии.
Акцент был на другом. Внедрение стека .NET или Java — вопрос, который часто определяется не архитектурными соображениями, а связями тех или иных людей, ответственных за решения.
И пофиг, кто и что лучше знает…
Акцент был на другом. Внедрение стека .NET или Java — вопрос, который часто определяется не архитектурными соображениями, а связями тех или иных людей, ответственных за решения.
И пофиг, кто и что лучше знает…
А разница между «связями» и «кто, что лучше знает»? В обоих случаях это не объективное ТЭО, а субъективный выбор.
Эт точно, субъективный.
Но хрен ведь сравнишь такого калибра системы, тем более — со стороны. Бывают, конечно, принципиальные киллер-фичи или принципиальные технические ситуации, но уж точно не в случае выбора между PostgreSQL и Oracle.
Но хрен ведь сравнишь такого калибра системы, тем более — со стороны. Бывают, конечно, принципиальные киллер-фичи или принципиальные технические ситуации, но уж точно не в случае выбора между PostgreSQL и Oracle.
Иногда — нужно взять любой ценой — тогда побеждают монстры вроде Oracle, здесь не поспоришь. Иногда — приходится считать сколько «копеек» заплатить за фичу, тогда всё совсем не однозначно.
Например, горизонтально смасштабировать приложение на low-cost оборудовании — это однозначно не про Оракл или MS. При этом возможности Postgres — это не такая уж и наколенная поделка, если разобраться. Ряд интегрируемых в базу языков, таких как Python или R, развитая система типов, делающих Postgres гибридом реляционных и модных нынче NoSQL решений, позволяющая соединить плюсы обоих подходов.
Скажем, по моему субъективному мнению, Postgres на голову выше Firebird и иже с ним коммерческого Interbase по ряду возможностей (по крайней мере так было лет пять назад, когда я интересовался вопросом, и именно нужных мне возможностей).
Например, горизонтально смасштабировать приложение на low-cost оборудовании — это однозначно не про Оракл или MS. При этом возможности Postgres — это не такая уж и наколенная поделка, если разобраться. Ряд интегрируемых в базу языков, таких как Python или R, развитая система типов, делающих Postgres гибридом реляционных и модных нынче NoSQL решений, позволяющая соединить плюсы обоих подходов.
Скажем, по моему субъективному мнению, Postgres на голову выше Firebird и иже с ним коммерческого Interbase по ряду возможностей (по крайней мере так было лет пять назад, когда я интересовался вопросом, и именно нужных мне возможностей).
>Да уж, вот тут у продуктов MS под виндой конкурентов быть по определению не может.
Почему? Постгрес прекрасно крутится на винде.
Почему? Постгрес прекрасно крутится на винде.
От «стэка» зависит. Если продукт напрямую не завязан на MS SQL Server, то скорее он использует что-то вроде ODBC или другой DBAL.
Если бы вы работали с пространственными данными в postgres и mssql — то знали бы что postgres очень сильно уступает в производительности с пространственными данными
А для чего утверждающему Вам что-то доказывать? Не хотите гуглить — значит тема не особо и интересна, просто забудьте.
Правильное название — PostgreSQL или Postgres, но не “postgre”.:)
А MSSQL при этом оптимизировали, или нет? И где результаты тестов в цифрах?
Подозреваю, что сравнивали с боевой конфигурацией stackoverflow, и что-то мне подсказывает, что там она тоже оптимизированная. Но все равно тут могут оказаться нюансы, например Postgres могли взять и оптимизировать исключительно на чтение, в то время, как sql server на stackoverflow еще и активное наполнение/изменение данных.
Спасибо автору за перевод, но статья больше походит на «холивар-мину».
Звучит убедительно.
> чумовые типы данных.
Killer-feature.
<sarcasm>> К счастью, с этими вещами у Postgres полный порядок.
Звучит убедительно.
> чумовые типы данных.
Killer-feature.
</sarcasm>
> Killer-feature.
Вот Вы конечно можете сомневаться, но всё-таки это — действительно killer-feature.
Один только тип hstore стоит хорошей статьи на хабре — тип, превращающий поле в key-value хранилище, с операциями манипуляции над ключами как множествами и полноценной индексацией всего этого добра — из коробки.
Вот Вы конечно можете сомневаться, но всё-таки это — действительно killer-feature.
Один только тип hstore стоит хорошей статьи на хабре — тип, превращающий поле в key-value хранилище, с операциями манипуляции над ключами как множествами и полноценной индексацией всего этого добра — из коробки.
Никаких сомнений, просто тема ну ни капельки не раскрыта!
Вот если бы ка вы в двух словах написали было бы намного информативнее или хотя бы в скобочках перечислили имена этих «чумовых» типов.
Вот если бы ка вы в двух словах написали было бы намного информативнее или хотя бы в скобочках перечислили имена этих «чумовых» типов.
если честно, у меня не получается придумать применения этой фиче в работе.
если у вас есть опыт использования этой штуки, поделитесь пожалуйста, было бы очень интересно почитать про реальное использование, а не синтетические примеры.
если у вас есть опыт использования этой штуки, поделитесь пожалуйста, было бы очень интересно почитать про реальное использование, а не синтетические примеры.
Список свойств товаров.
в чём преимущество хранения списка свойств товара в одном поле перед хранением списка свойств в виде отдельных записей в таблице?
hstore удобно использовать, когда список свойств часто меняется, или отличается от объекта к объекту. Когда можно было бы использовать отдельную таблицу для хранения key-value пар, hstore часто оказывается удобнее и быстрее, и бесплатно дает возможность делать запросы, которые при отдельной таблице были бы сложнее.
Зачастую, если нужно указать какое-то дополнительное свойство или пару для какого-то объекта, делать для этого отдельную колонку в таблице неудобно. А создавать таблицу key-value еще более неудобно.
Для меня важный плюс — это делает проще код. Например, ипользуя django-hstore, им пользуешься как обычным словарем. В противном случае было бы намного больше строк, даже учитывая ORM.
Зачастую, если нужно указать какое-то дополнительное свойство или пару для какого-то объекта, делать для этого отдельную колонку в таблице неудобно. А создавать таблицу key-value еще более неудобно.
Для меня важный плюс — это делает проще код. Например, ипользуя django-hstore, им пользуешься как обычным словарем. В противном случае было бы намного больше строк, даже учитывая ORM.
Значительно проще, как с точки зрения программиста, так и с точки зрения планировщика, построение запросов, более компактное расположение данных — в отдельной таблице связанные записи могут быть очень разбросаны по дисковым страницам, в одном поле же, они хранятся на минимально необходимом количестве страниц, ещё и хранятся со сжатием, не нужен дополнительный индекс для выборки по ключевому полю и само ключевое поле для связки, меньше памяти нужно для построения плана запроса, меньше размывается кеш за счёт чтения не нужных в данный момент страниц при больших таблицах. Это так, навскидку — возможно ещё что-то не учёл или не знал
ну а если, положим, я хочу сделать поиск по товарам, обладающим каким-либо свойством? если они лежат списками в специализированных полях, то субд при поиске вынуждена залезать в каждое такое поле, парсить его, искать в нём нужное значение и только потом сравнивать с запросом. сжатие дело хорошее, но когда нужно найти среди пары миллионов записей те, которые обладают тем или иным свойством, оно по-моему скорее затормозит работу, чем ускорит.
но самое главное, что я хотел бы уточнить — как с такими списками контролировать целостность данных? можно ли на уровне субд накладывать на них ограничения? если я храню свойства товаров в отдельной таблице, то я могу заранее определить список свойств и субд будет контролировать сама, что никаких других свойств у товаров появиться не может, т.е. никто не сможет завести у одного товара свойство «цвет», у другого «цвет корпуса», а у третьего «расцветка» — у всех свойство будет называться одинаково и соответственно поиск будет более релевантным. а можно ли аналогично ограничивать множество значений в hstore?
но самое главное, что я хотел бы уточнить — как с такими списками контролировать целостность данных? можно ли на уровне субд накладывать на них ограничения? если я храню свойства товаров в отдельной таблице, то я могу заранее определить список свойств и субд будет контролировать сама, что никаких других свойств у товаров появиться не может, т.е. никто не сможет завести у одного товара свойство «цвет», у другого «цвет корпуса», а у третьего «расцветка» — у всех свойство будет называться одинаково и соответственно поиск будет более релевантным. а можно ли аналогично ограничивать множество значений в hstore?
В постгрес есть два типа индексов: GIST и GIN, которые хорошо подходят для индексации множеств, каждое со своими особенностями — на этом построен и полнотекстовый поиск. GIST быстрее на создание и модификацию, GIN — эффективней на поиске при больших множествах значений, таких как множество слов в языке.
Просто логические ограничения накладывать можно — можно создавать произвольные constraint'ы. Более сложные ограничения, зависящие от данных в других таблицах — только строить через триггеры (и эта задача может оказаться нетривиальной, но это уже отдельная тема).
Ссылочная целостность данных — на уровне базы не контролируется и это в какой-то степени минус данного решения. Но поле hstore можно использовать как кеш для таблицы связей, а триггеры на изменения в таблице связей просто будут обновлять соответствующее поле в основной таблице. Полагаю всё зависит от особенностей задачи и эксплуатации базы.
Просто логические ограничения накладывать можно — можно создавать произвольные constraint'ы. Более сложные ограничения, зависящие от данных в других таблицах — только строить через триггеры (и эта задача может оказаться нетривиальной, но это уже отдельная тема).
Ссылочная целостность данных — на уровне базы не контролируется и это в какой-то степени минус данного решения. Но поле hstore можно использовать как кеш для таблицы связей, а триггеры на изменения в таблице связей просто будут обновлять соответствующее поле в основной таблице. Полагаю всё зависит от особенностей задачи и эксплуатации базы.
Кстати, касательно возможностей PostgreSQL, кому приходилось использовать на практике:
— наследование таблиц;
— тип данных массив.
Поделитесь пожалуйста опытом: для решения каких задач использовалась данная возможность?
— наследование таблиц;
— тип данных массив.
Поделитесь пожалуйста опытом: для решения каких задач использовалась данная возможность?
Если мне не изменяет память, то на предыдущей работе массивы использовались для хранения списка категорий продукта в товарном каталоге при денормализации данных. Postgres имеет возможность выполнять запросы над массивами как над обычными таблицами. Благодаря этому можно было фильтровать, агрегировать и выдавать данные без лишних преобразований.
1. Использовалось для натягивания на БД объектной структуры бизнес-модели. Не спрашивайте, зачем :-)
В 2008 году ни один известный на тот момент ORM это не переваривал, и мы использовали iBatis.
В 2008 году ни один известный на тот момент ORM это не переваривал, и мы использовали iBatis.
Я не использовал ни то, ни другое (просто я постгресом почти не пользовался), но, это довольно очевидно:
наследование может пригодиться в таком кейсе например: вы строите простейшую crm-систему, у вас есть сущности сделок, контактов, тасков. мало того, что это довольно логично, создать базовую сущность (ну как минимум для контактов и сделок), так к тому же это поможет решить проблему дэшборда, где надо вывести и сделки и контакты, etc
а типы данных в виде массива пригодятся тогда, когда данные просто нет смысла нормализовывать. опять же юз-кейс на примере црм — у контакта может быть много телефонов, и вам совершенно не зачем выносить их в отдельную таблицу и связывать как many-to-many, т.к., ну, это не нужно, в этом нет потребности
наследование может пригодиться в таком кейсе например: вы строите простейшую crm-систему, у вас есть сущности сделок, контактов, тасков. мало того, что это довольно логично, создать базовую сущность (ну как минимум для контактов и сделок), так к тому же это поможет решить проблему дэшборда, где надо вывести и сделки и контакты, etc
а типы данных в виде массива пригодятся тогда, когда данные просто нет смысла нормализовывать. опять же юз-кейс на примере црм — у контакта может быть много телефонов, и вам совершенно не зачем выносить их в отдельную таблицу и связывать как many-to-many, т.к., ну, это не нужно, в этом нет потребности
Это из задачи составления расписания и части документооборота в ВУЗе
Много пробовал, но по другому получается плохо. Создание view можно будет упростить, когда в PostgreSQL встроят Grouping Sets
Таблицы
CREATE TABLE tblПотоки (
pk_поток SERIAL PRIMARY KEY,
fk_надПоток INTEGER REFERENCES tblПотоки(pk_поток),
fk_учебныйГод INTEGER REFERENCES tblУчебныеГода(pk_учебныйГод) NOT NULL,
fk_факультет INTEGER REFERENCES tblФакультеты(pk_факультет) NOT NULL,
название TEXT NOT NULL,
дополнение HSTORE,
UNIQUE(fk_учебныйГод, fk_факультет, название)
);
CREATE TABLE tblГруппы (
pk_группа SERIAL PRIMARY KEY,
fk_формаОбучения INTEGER REFERENCES tblФормыОбучения(pk_формаОбучения) NOT NULL,
fk_специальность INTEGER REFERENCES tblСпециальности(pk_специальность) NOT NULL,
курс INTEGER NOT NULL,
комм BOOLEAN NOT NULL,
колБюджет INTEGER NOT NULL,
колКомм INTEGER NOT NULL,
дополнение HSTORE
) INHERITS (tblПотоки);
CREATE TABLE tblПодгруппы (
pk_подгруппа SERIAL PRIMARY KEY,
fk_группа INTEGER REFERENCES tblГруппы(pk_группа) NOT NULL,
fk_разбиение INTEGER REFERENCES tblРазбиения(pk_разбиение) NOT NULL,
колБюджет INTEGER NOT NULL,
колКомм INTEGER NOT NULL,
дополнение HSTORE
) INHERITS (tblПотоки);
Представление
CREATE VIEW vwПотоки AS
WITH RECURSIVE Потоки(fk_поток, fk_группа, fk_подгруппа) AS (
(SELECT
tblГруппы.pk_поток, tblГруппы.pk_группа, NULL
FROM
tblПотоки tbl1 INNER JOIN tblГруппы ON tbl1.pk_поток = tblГруппы.pk_поток)
UNION
(SELECT
tblПодгруппы.pk_поток, NULL, tblПодгруппы.pk_подгруппа
FROM
tblПотоки tbl2 INNER JOIN tblПодгруппы ON tbl2.pk_поток = tblПодгруппы.pk_поток)
UNION ALL
SELECT
tbl3.fk_надПоток, Потоки.fk_группа, Потоки.fk_подгруппа
FROM
tblПотоки tbl3 INNER JOIN Потоки ON tbl3.pk_поток = Потоки.fk_поток
WHERE
tbl3.fk_надПоток IS NOT NULL
)
SELECT
*
FROM
Потоки;
Много пробовал, но по другому получается плохо. Создание view можно будет упростить, когда в PostgreSQL встроят Grouping Sets
Я это использовал для шардинга (как и автор)
Я наследование использовал для базы данных сайта недвижимости. Данная предметная область содержит в себе объекты недвижимости, которые имеют ряд общих свойств (id, адрес, стоимость, владелец, и т.д.) и различаются по типу недвижимости (квартира, офис, склад, и т.д.) и некоторым частным свойствам присущих специфическим типами недвижимости.
Так вот, у меня была одна общая таблица, содержащая все общие данные об объектах недвижимости, и несколько наследуемых таблиц, по одной для каждого типа недвижимости, содержащии специфическую информацию.
С такой структурой было очень удобно работать, потому что у меня была таблица со всеми общими данными по всем объектам недвижимости вне зависимости от типа, и у меня был набор таблиц содержащих полную информацию о конкретном типе недвижимости. При этом данные не дублировались в базе данных, что очень удобно.
Так вот, у меня была одна общая таблица, содержащая все общие данные об объектах недвижимости, и несколько наследуемых таблиц, по одной для каждого типа недвижимости, содержащии специфическую информацию.
С такой структурой было очень удобно работать, потому что у меня была таблица со всеми общими данными по всем объектам недвижимости вне зависимости от типа, и у меня был набор таблиц содержащих полную информацию о конкретном типе недвижимости. При этом данные не дублировались в базе данных, что очень удобно.
На самом деле, насколько я вижу, люди только для избегания юниона и используют наследование )
Не хочу сказать что это плохо, просто заметил
Не хочу сказать что это плохо, просто заметил
Да согласен что данную возможность можно реализовать c использованием view (в котором union-ятся таблицы), но все таки этот вариант больше подходит для задач на чтение данных. С другой стороны, имея родительскую таблицу, мы можем вносить изменения в структуру таблицы, и эти изменения будут автоматически применены в наследуемых таблицах. Плюс я все таки подозреваю что на уровне реализации, данная возможность (наследование) реализованна умно, что в свою очередь позволяет сэкономить ресурсы.
>>Кстати, касательно возможностей PostgreSQL, кому приходилось использовать на практике:
>>— наследование таблиц
Открыл для себя наследование в постгре благодаря вопросу в QA.
Использование наслдеования, имеет вполне документированные подводные камни, и, фактически, заставляет отказаться от таких чтук, как PK/FK, что очень сужает область применимости до ничтожной.
>>— наследование таблиц
Открыл для себя наследование в постгре благодаря вопросу в QA.
Использование наслдеования, имеет вполне документированные подводные камни, и, фактически, заставляет отказаться от таких чтук, как PK/FK, что очень сужает область применимости до ничтожной.
Так StackOverflow таки работает на Postgres?
Учитывая то, что он работает на дотнете, и то, что в посте упомянут SQL Server около StackOverflow, скорее всего на SQL Server
Ну и вот интересный линк :)
blog.stackoverflow.com/2008/09/what-was-stack-overflow-built-with/
blog.stackoverflow.com/2008/09/what-was-stack-overflow-built-with/
«Из всех открытых систем управления базами данных самой умной, производительной и функциональной системой является Postgres, которая заслуженно привлекает всё больше и больше внимания.»
Ушел сносить с боевых серверов оракл и ставить Postgres.
Надо, чтобы надпись «Перевод» была гораздо крупнее и жирнее, а то хочется ушат сразу вылить на того, кто запостил, а не автора оригинального поста ;)
Ушел сносить с боевых серверов оракл и ставить Postgres.
Надо, чтобы надпись «Перевод» была гораздо крупнее и жирнее, а то хочется ушат сразу вылить на того, кто запостил, а не автора оригинального поста ;)
Еще один огромный бонус постгреса для меня, это JSON как тип: www.postgresql.org/docs/devel/static/datatype-json.html
Я всем рекомендую расширение hstore. За счет его введения устраняется один из основных недостатков реляционных баз данных.
Коллеги, а можете порекомендовать проверенное и 100% рабочее без костылей решение для master-master репликации?
Родного нет пока. Даже синхронная мастер-слейв репликация появилась только что. Недавно читал, что в MySql мастер-мастер асинхронный, со всеми вытекающими… Пруф не нашёл, может знающие опровергнут. Сам я мускуль стараюсь не юзать.
Вместо Oracle и MS SQL использовать Postgres и MySQL?
А теперь дружно подумаем, почему если есть такие замечательные бесплатные средства как MySQL & Postgres, большие серьезные компании настойчиво продолжают использовать Oracle или MS SQL? Или еще большую экзотику Informix, Progress, etc ???
Такие сравнения все от лукавого по сути. Понятно что для веб-разработки можно использовать бесплатные решения и радоваться жизни, однако, как только в ваш лексикон добавляется хотя бы слово OLAP, на бесплатных СУБД становится грустно. Назовите мне хоть одно решение для бизнес-аналитики на данных бесплатных СУБД? Тот и оно! Я конечно знаю про аналитические запросы в Postgres, но давайте быть честными это же совсем не тоже самое что MDX.
Их можно прекрасно использовать для OLTP, но не более. А зачастую потребности бизнеса это не «штоб все круто и быстро было», а «штоб быстро и круто можно было строить аналитические отчеты».
Многие конечно никогда с этим не столкнутся. Многие не используют и на 20% возможности MySQL и Postgres используя ORM считая это за истинное благо. Мало кто использует всю мощь данных СУБД. И в данном контексте даже ActiveRecord не всегда будет удобен, хотя по сути является этакой «лайт» версией ORM.
Слишком уж «синтетические тесты» приведены в статье, по сути не всегда можно взять Postgres и радоваться жизни, я бы конечно очень хотел чтобы на Postgres можно было делать бизнес-аналитику, но реалии другие. Даже если строить серьезный(подчеркиваю серьезный) интернет магазин, то OLAP уже маст-хев сразу же. Потому что аналитика, потому что прогнозирование.
Можно конечно сделать проще — для OLTP использовать свободные СУБД, а для Bussiness Intellegence покупать коммерческие, однако многим организациям проще держать одну СУБД, да и зачастую когда покупается СУБД, она либо покупается вместе с продуктом где используется аналитика, либо в архитектуру изначально заложена составляющая аналитики, и когда покупаются коммерческие СУБД, они не выбираются по принципу «Это круто», а в следствии полноценного анализа будущей архитектуры приложения.
Если уж и сравнивать СУБД, то вероятно их надо сравнивать не только по принципу скорости SELECT & INSERT. В том же MySQL есть свои плюсы для высоконагруженных систем, которые уделают PostgreSQL. C другой стороны и в Postgres полно магии подобно oid, tid, etc аналогов которых в MySQL я не знаю (возможно в силу того что давно не использовал MySQL).
Как-то так. Было бы интересно если бы кто либо написал бооольшой такой огроменный пост о реальном сравнении о функциональных возможностях и особенностях хотя бы самых известных СУБД. А не анализ по синтетическим тестам которые всем уже надоели да и не отражают действительности в плане функционалаи его необходимости для конкретных задач. А то так можно и договорится до того что SQLite самый крутой так как у него INSERT шустрее чем у других.
PS:
Я не говорю что одна СУБД хуже другой. Все СУБД разные и то что годится для одной задачи, может не подходить под другую, кому-то будет удобнымиспользование «микса» из разных СУБД, кому-то проще будет вложится в коробочное решение.
А теперь дружно подумаем, почему если есть такие замечательные бесплатные средства как MySQL & Postgres, большие серьезные компании настойчиво продолжают использовать Oracle или MS SQL? Или еще большую экзотику Informix, Progress, etc ???
Такие сравнения все от лукавого по сути. Понятно что для веб-разработки можно использовать бесплатные решения и радоваться жизни, однако, как только в ваш лексикон добавляется хотя бы слово OLAP, на бесплатных СУБД становится грустно. Назовите мне хоть одно решение для бизнес-аналитики на данных бесплатных СУБД? Тот и оно! Я конечно знаю про аналитические запросы в Postgres, но давайте быть честными это же совсем не тоже самое что MDX.
Их можно прекрасно использовать для OLTP, но не более. А зачастую потребности бизнеса это не «штоб все круто и быстро было», а «штоб быстро и круто можно было строить аналитические отчеты».
Многие конечно никогда с этим не столкнутся. Многие не используют и на 20% возможности MySQL и Postgres используя ORM считая это за истинное благо. Мало кто использует всю мощь данных СУБД. И в данном контексте даже ActiveRecord не всегда будет удобен, хотя по сути является этакой «лайт» версией ORM.
Слишком уж «синтетические тесты» приведены в статье, по сути не всегда можно взять Postgres и радоваться жизни, я бы конечно очень хотел чтобы на Postgres можно было делать бизнес-аналитику, но реалии другие. Даже если строить серьезный(подчеркиваю серьезный) интернет магазин, то OLAP уже маст-хев сразу же. Потому что аналитика, потому что прогнозирование.
Можно конечно сделать проще — для OLTP использовать свободные СУБД, а для Bussiness Intellegence покупать коммерческие, однако многим организациям проще держать одну СУБД, да и зачастую когда покупается СУБД, она либо покупается вместе с продуктом где используется аналитика, либо в архитектуру изначально заложена составляющая аналитики, и когда покупаются коммерческие СУБД, они не выбираются по принципу «Это круто», а в следствии полноценного анализа будущей архитектуры приложения.
Если уж и сравнивать СУБД, то вероятно их надо сравнивать не только по принципу скорости SELECT & INSERT. В том же MySQL есть свои плюсы для высоконагруженных систем, которые уделают PostgreSQL. C другой стороны и в Postgres полно магии подобно oid, tid, etc аналогов которых в MySQL я не знаю (возможно в силу того что давно не использовал MySQL).
Как-то так. Было бы интересно если бы кто либо написал бооольшой такой огроменный пост о реальном сравнении о функциональных возможностях и особенностях хотя бы самых известных СУБД. А не анализ по синтетическим тестам которые всем уже надоели да и не отражают действительности в плане функционалаи его необходимости для конкретных задач. А то так можно и договорится до того что SQLite самый крутой так как у него INSERT шустрее чем у других.
PS:
Я не говорю что одна СУБД хуже другой. Все СУБД разные и то что годится для одной задачи, может не подходить под другую, кому-то будет удобнымиспользование «микса» из разных СУБД, кому-то проще будет вложится в коробочное решение.
В принципе, со всем согласен (особенно с последним абзацем), но хотел бы уточнить, что OLAP для PostgreSQL всё-таки есть.
Не холивара ради, но почему Вы считаете, что Postgres подойдет для OLTP, но для BI нет?
Мне казалось, что для того чтобы сделать BI СУБД должна уметь партиционирование, индексы, процедуры и ETL.
Мне казалось, что для того чтобы сделать BI СУБД должна уметь партиционирование, индексы, процедуры и ETL.
Ну сделайте =) можно конечно сделать ROLAP с SQL запросами, но дать это аналитикам… ) как то жестоко
Автор замечательной книги PostgreSQL 9.0 High Performance, который довольно активен в сообществе PostgreSQL, хоть и является приверженцом этой СУБД, честно пишет в этой книге, что на данный момент времени коммерческие базы больше подходят для data analytics, потому что в постгресе некоторых вещей, нужных для этого, просто нет. И известный бенчмарк TPC-H в postgres выполняется несоизмеримо медленнее чем в коммерческих субд.
Тем не менее, postgres прекрасно подходит для нужд большинства проектов.
Тем не менее, postgres прекрасно подходит для нужд большинства проектов.
А теперь дружно подумаем, почему если есть такие замечательные бесплатные средства как MySQL & Postgres, большие серьезные компании настойчиво продолжают использовать Oracle или MS SQL?
Аналогичный вопрос: почему в крупных компаниях корпоративным стандартом до сих пор является IE-8? Ведь есть же отличные бесплатные хром и фаерфокс. Проводить тесты, обсуждать Killer-feature и доказывать что Chrome/FF лучше IE-8 — бесполезно. Есть какое то другое объяснение.
Есть какое то другое объяснение.
Управляемость доменными политиками, например?
Фаерфокс это умеет
Умеют. Вы еще начните доказывать, что аналогов AD/AD LDS для RHEL не найти!
Комментом выше я уже написал: кроме того, что это должен уметь софт, это еще должны уметь админы и управляющий софт в компании.
Админы умеют то, что надо уметь. Уж разобраться с Лисом можно и без трехмесячного тренинга в Штатах! Это ж не SAP!
Впрочем вам, вероятно, виднее. Я, к счастью, давно уже не занимаюсь корпоративным софтом. По старой памяти зацепился. :)
Впрочем вам, вероятно, виднее. Я, к счастью, давно уже не занимаюсь корпоративным софтом. По старой памяти зацепился. :)
Afaik, Mondrian работает с PostgreSQL, но на практике проверять не доводилось пока, как раз размышляем в этом направлении
Комментарии все какие злобные, это зависть?
Ололо, а не статья. И правильно заметили выше — надо ярче указывать, что это перевод, а то переводчик может незаслуженно пострадать :)
Отличная СУБД для больших и средних проектов. Для мелких настольных проектов я бы все-таки рекомендовал что-то «полегче»: Firebird — для многопользовательских систем(или нужен полноценный PSQL); либо SQLite если нужно «попроще да получше».
Насчет популярности Mysql относительно Postgres я думаю что тут все просто, Mysql повезло оказаться такой какая она есть в момент бума и поэтому она получила все, а postgres несмотря на свои достоинства остатки. Тут сработал принцип победитель получает все.
Ну а уповать на рациональность выбора… ну большинству людей на это лень тяжело тратить время. Поэтому имеем что имеем. Сложно сказать сколько так будет продолжаться, но я не вижу что Postgres вытеснит Mysql в ближайшее время. Может быть что-нибудь третье?
Хотя прогнозы такие прогнозы.
Ну а уповать на рациональность выбора… ну большинству людей на это лень тяжело тратить время. Поэтому имеем что имеем. Сложно сказать сколько так будет продолжаться, но я не вижу что Postgres вытеснит Mysql в ближайшее время. Может быть что-нибудь третье?
Хотя прогнозы такие прогнозы.
Не совсем так. У Mysql и Postgres немного различное назначение (вернее, различное назначение, исходящее из разного рыночного позиционирования).
Собственно Mysql как изначально так и по сей день достаточно четко позиционируется как СУБД для веб-сайтов и веб приложений. Это и определяет вектор его развития, т.е. Mysql изначально не претендует на «шибко умную субд для серьезного бизнеса», поскольку вся бизнес-логика «в биосфере mysqlа» реализуется на уровне веб-приложения, а mysql-сервер занимается только быстрой обработкой select/insert/update/delete тем более большего от него и не требуют (сам своими ушами мнного раз слышал удивленные возгласы вида «а что, в мускуле есть view, не знал», «а что, в мускуле есть view, не знал», ...).
Postgres же, позиционирует себя как «умную СУБД» и пытается лезть еще и в «нишу серьезного бизнеса»… а в этой рыночной нише Postgres тут же подвергают безжалостному сравнению с Oracle, причем, как вы понимаете, зачастую, не в пользу Postgresа.
Собственно Mysql как изначально так и по сей день достаточно четко позиционируется как СУБД для веб-сайтов и веб приложений. Это и определяет вектор его развития, т.е. Mysql изначально не претендует на «шибко умную субд для серьезного бизнеса», поскольку вся бизнес-логика «в биосфере mysqlа» реализуется на уровне веб-приложения, а mysql-сервер занимается только быстрой обработкой select/insert/update/delete тем более большего от него и не требуют (сам своими ушами мнного раз слышал удивленные возгласы вида «а что, в мускуле есть view, не знал», «а что, в мускуле есть view, не знал», ...).
Postgres же, позиционирует себя как «умную СУБД» и пытается лезть еще и в «нишу серьезного бизнеса»… а в этой рыночной нише Postgres тут же подвергают безжалостному сравнению с Oracle, причем, как вы понимаете, зачастую, не в пользу Postgresа.
Ну… Oracle — штука непередаваемо большая, у них вокруг СУБД очень много чего понаверчено за десятилетия самых разных корпоративных трендов.
Мне довелось на деле сравнивать обе БД и, как программист и как внедренец должен заметить: Oracle — БД с точки зрения программиста неплохая, но абсолютно кошмарная с точки зрения администрирования. Если админ, конечно, не сертифицированный спец исключительно по Ораклу :)
PostgreSQL поприятней в этом смысле будет; а во многих других смыслах может как минимум равняться на корпоративного конкурента.
Другое дело, что в корпорациях отнюдь не по объективным параметрам выбор делают. Да и существуют ли объективные параметрых сравнения столь сложных систем..?
Мне довелось на деле сравнивать обе БД и, как программист и как внедренец должен заметить: Oracle — БД с точки зрения программиста неплохая, но абсолютно кошмарная с точки зрения администрирования. Если админ, конечно, не сертифицированный спец исключительно по Ораклу :)
PostgreSQL поприятней в этом смысле будет; а во многих других смыслах может как минимум равняться на корпоративного конкурента.
Другое дело, что в корпорациях отнюдь не по объективным параметрам выбор делают. Да и существуют ли объективные параметрых сравнения столь сложных систем..?
У mysql действительно множество недостатков, но приводить то, что отключается ОДНОЙ настройкой, в качестве основного… Автор — тролль. :)
> Благодаря наследованию таблиц мы легко можем партиционировать таблицы
Вот тут ребята прикололись — «партиционировать таблицы» по постгрессе ужасно неудобно, о чем неоднократно упоминали в форумах разработчиков постгресса. Как раз в коммерческих СУБД партицирование нормально сделано.
Вот тут ребята прикололись — «партиционировать таблицы» по постгрессе ужасно неудобно, о чем неоднократно упоминали в форумах разработчиков постгресса. Как раз в коммерческих СУБД партицирование нормально сделано.
Наблюдал за топиком со старта, но ответа на свой невысказанный вопрос не увидел. Теперь высказываю: всегда ли есть смысл заменять MySQL (или его форки) на PostgreSQL? Или есть какие-то формальные метрики, свидетельствующие о том, что пора переходить. Или в любом случае затраты на перевод синтаксиса будет оправданы, даже если не используются триггеры, процедуры и т. п., а Бд выступает в роли тупого хранилища?
Если база данных используется как тупая записная книжка через ORM, то вряд ли получится заметно ощутить преимущества PostgresSQL. Если запросы довольно сложные, то стоит посмотреть на
EXPLAIN и сравнить работу двух оптимизаторов. Думаю, это достаточно формальный критерий для принятия решения.Когда я переходил на Postgres — ощутимых завязок на синтаксис не заметил — фактически все возможности MySQL прекрасно мапятся в Postgres. Есть несколько подводных камней, они обходимы. Во времена, когда пользовался MySQL вся логика была в приложении и сам MySQL действительно был как хранилище. В Postgres'е я развернулся по возможностям, тем более и цель перед собой такую поставил — плотнее изучить возможности баз. Недавно меня пригласили в один проект, где до моего прихода использовался MySQL — ощущение, наверно, сравнимое с тем, как если бы счастливого владельца BMW посадили за руль Таврии и попросили показать класс езды. Чего только стоит некаскадность триггеров в MySQL сводящая их роль к минимальной и грозящая неприятными сюрпризами и в то же время, посмотреть на возможности ORM Zend Framework — там реализована эмуляция триггеров! То есть спрос на эту функциональность есть, если её реализовали на уровне сервера приложений, где ей совсем, казалось бы, не место. Или невозможность одновременно использовать полнотекстовый поиск и транзакции. И так — куда ни копни. Пока не пользуешься — вроде и не нужно, но когда привык — уже никуда без этих возможностей.
Я конечно понимаю, техническая статья, но про цены как-то очень вскользь упомянуто. У постгреса разумная цена администрирования и нулевая цена лицензий. И это само по себе уже агромадный плюс для небогатых контор.
Так что зачем ее с Майкрософтом да Ораклом так упорно сравнивать? Они не конкуренты даже, т.к. на постгресе много не попилишь и экспертизу не приведешь с крутыми сертификатами (чтобы прикрыть мягкое место). Принципиально разные ниши.
Так что зачем ее с Майкрософтом да Ораклом так упорно сравнивать? Они не конкуренты даже, т.к. на постгресе много не попилишь и экспертизу не приведешь с крутыми сертификатами (чтобы прикрыть мягкое место). Принципиально разные ниши.
Есть и платные инкарнации Postgres с весьма вкусными плюшками и позиционирующие себя именно как конкурента «суровому энтерпрайзу»
Справедливости ради замечу, что многие вкусные плюшки работают и с бесплатной версией, но там их нужно добавлять вручную. В этом смысле коробочное решение, да еще с поддержкой, для бизнеса гораздо «вкуснее».
Ну, для полноты картины можно дать ещё вот эту ссылку: PGXN — кто чувствует в себе силы контролировать дополнительные приблуды для Postgres — найдут много любопытного и полезного.
>она легко вставит пустую строку "" в колонку с запретом на добавление пустых значений;
Проверил на MS SQL Server 2005 и вылезла ошибка:
«Msg 515, Level 16, State 2, Line 1
Cannot insert the value NULL into column 'text1', table 'TestSQLBase.dbo.nullz'; column does not allow nulls. INSERT fails.
The statement has been terminated.»
{На видео время 01:55}
Базу создал новую, настройки по умолчанию.
Проверил на MS SQL Server 2005 и вылезла ошибка:
«Msg 515, Level 16, State 2, Line 1
Cannot insert the value NULL into column 'text1', table 'TestSQLBase.dbo.nullz'; column does not allow nulls. INSERT fails.
The statement has been terminated.»
{На видео время 01:55}
Базу создал новую, настройки по умолчанию.
Речь таки про «MySQL, будучи недостаточно строгой СУБД», я думаю к MS SQL эта претензия не была адресована.
Аааа, пардон — перепутал два слова на М. :)
Значит ли это, что Microsoft SQL Server, в отличие от MySQL является продуктом, недостаточно дружелюбным к пользователю?
Разве это каким-то образом вытекает из вышестоящего обсуждения?
Я бы наверно наоборот заключил — предсказуемое и ожидаемое поведение — это более чем дружелюбное и благонамеренное отношение к пользователю.
А MySQL в старых версиях откровенно потакали ошибочному коду, в результате чего, мне доводилось переписывать код, прекрасно работавший в версии 3.х, но вылетавший в 5.1 с ошибкой. Кстати, там была и вышеперечисленная с кавычками — так что, похоже кое-что исправили несколько поломав совместимость.
Я бы наверно наоборот заключил — предсказуемое и ожидаемое поведение — это более чем дружелюбное и благонамеренное отношение к пользователю.
А MySQL в старых версиях откровенно потакали ошибочному коду, в результате чего, мне доводилось переписывать код, прекрасно работавший в версии 3.х, но вылетавший в 5.1 с ошибкой. Кстати, там была и вышеперечисленная с кавычками — так что, похоже кое-что исправили несколько поломав совместимость.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Поприветствуйте вашего старого нового друга