Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 86
> У Постгреса множество возможностей
Конечно, моё утверждение довольно субъективное, но ИМХО, «множество возможностей» — это просто особенность, а не конкурентное преимущество. В целом, конечно, неплохо, что на стороне СУБД есть возможность делать высокоуровневые операции, которые раньше выносились на приложение. Но это совсем не обязательно, и особых причин делать их именно на стороне СУБД как бы и нет. Т.е. разработчик, которому СУБД таких плюшек не даёт, и который это будет делать на уровне сервера приложений и/или клиента, не будет себя чувствовать хуже :)
Конечно, моё утверждение довольно субъективное, но ИМХО, «множество возможностей» — это просто особенность, а не конкурентное преимущество. В целом, конечно, неплохо, что на стороне СУБД есть возможность делать высокоуровневые операции, которые раньше выносились на приложение. Но это совсем не обязательно, и особых причин делать их именно на стороне СУБД как бы и нет. Т.е. разработчик, которому СУБД таких плюшек не даёт, и который это будет делать на уровне сервера приложений и/или клиента, не будет себя чувствовать хуже :)
Я думаю, что всё таки разработчик, пишущий аналог «возможностей» на уровне логики приложения, а не базы, в итоге будет себя чувствовать хуже, чем разработчик, который просто будет использовать эту возможность в базе. Предлагаю вам попробовать сравнить, например, производительность пространственных запросов геоданных PostgreSQL/PostGIS и «геоданных» в MySQL.
Для примера, можно взять не сложный запрос: автоматически расставить полигонам зданий адреса по признаку их географической вложенности в полигоны страны, области, города; исключив при этом дома внутри промзон и города площадью меньше заданного значения.
Для примера, можно взять не сложный запрос: автоматически расставить полигонам зданий адреса по признаку их географической вложенности в полигоны страны, области, города; исключив при этом дома внутри промзон и города площадью меньше заданного значения.
Вы ведь программист баз данных, верно?
Не соглашусь с Вами. Временами, сделать быстрее на БД — возможно, да и посмотреть наверно удобнее.
Только все это очень весело до того момента, пока проект не перевалит через некоторое пороговое значение своего размера и сложности. Потом начинаются неочевидные связи, черные ящики, вертикальное масштабирование и пр. Использование «множества возможностей» в итоге часто оборачиваются проблемами миграции на другие БД (например, при установке системы в банке, который имеет лицензию и поддержку альтернативной БД).
При всем моем уважении и любви к postgres — для меня это не более чем надежное ACID-хранилище, я сторонник логики в приложении почти всегда (за исключением разве что случаев обработки огромных массивов данных, чтобы не гонять их по сети).
Не соглашусь с Вами. Временами, сделать быстрее на БД — возможно, да и посмотреть наверно удобнее.
Только все это очень весело до того момента, пока проект не перевалит через некоторое пороговое значение своего размера и сложности. Потом начинаются неочевидные связи, черные ящики, вертикальное масштабирование и пр. Использование «множества возможностей» в итоге часто оборачиваются проблемами миграции на другие БД (например, при установке системы в банке, который имеет лицензию и поддержку альтернативной БД).
При всем моем уважении и любви к postgres — для меня это не более чем надежное ACID-хранилище, я сторонник логики в приложении почти всегда (за исключением разве что случаев обработки огромных массивов данных, чтобы не гонять их по сети).
Ну а всё таки, известны ли вам случаи манипуляции с пространственными данными на стороне клиента, а не на уровне геоданных в БД?
Есть сферы применения БД, где манипуляция с данными крайне проста, прозрачна и имеет высокую производительность, в случае работы на уровне БД, и геоданные — одна из таких сфер, как мне кажется.
Есть сферы применения БД, где манипуляция с данными крайне проста, прозрачна и имеет высокую производительность, в случае работы на уровне БД, и геоданные — одна из таких сфер, как мне кажется.
С такими типами данных не работал.
И все же — ваше сообщение скорее про OLAP-область, не OLTP?
И все же — ваше сообщение скорее про OLAP-область, не OLTP?
Зависит исключительно от задачи. Если задача на лету вытащить адрес из базы по клику мышкой на карте, то это чистый OLTP, а если посчитать суммарную статистику и нормализовать данные по каким то глобальным критериям, то это уже будет OLAP. Пример на 3 комментария выше — скорее ближе к OLAP, да, если производится заполнение свойств большому количеству объектов, а если это задача геокодинга и нужны свойства одного объекта, то это будет чистый OLTP.
Ни одна из этих баз данных сейчас не поддерживает CHECK ограничения
То есть как это? Check constraint даже в Sqlite есть, во встраиваемой БД.
Могу дать пруф про mysql: http://dev.mysql.com/doc/refman/5.7/en/create-table.html
The CHECK clause is parsed but ignored by all storage engines.
Ни одна из этих баз данных сейчас не поддерживает CHECK ограничения
> То есть как это?
Вот-вот. Из-за таких вот такие формулировок статья выглядит мягко говоря маркетинговой чухней. Исходя из этого категорического утверждения, Firebird тоже не поддерживает CHECK-и, а пробегаясь дальше по тексту — так же не поддерживает ACID. Да, прямо об этом не написано, но формилируется именно так.
Или еще вот пассаж: то что у PostgreSQL поддерживаются большые строки — это большой плюс и вообще «фи» остальным, которые «только 64 кб». Стыдливо замалчивая при этом TEXT для mysql и BLOB SUB_TYPE 1 для firebird. Но зато рядом
как известно любому администратору баз данных, стоит с опаской относиться к слишком большим и неограниченным возможностям. Мы советуем руководствоваться здравым смыслом при создании таблиц и добавлении индексов
«Грустно все это»©
Стыдливо замалчивая при этом TEXT для mysql
Сравните работу с TEXT у MySQL и Postgresql. У MySQL это настоящий сборник ограничений. Читаем документацию в PG:
The storage requirement for a short string (up to 126 bytes) is 1 byte plus the actual string, which includes the space padding in the case of character. Longer strings have 4 bytes of overhead instead of 1. Long strings are compressed by the system automatically, so the physical requirement on disk might be less. Very long values are also stored in background tables so that they do not interfere with rapid access to shorter column values.
и
Tip: There is no performance difference among these three types [CHAR, VARCHAR, TEXT], apart from increased storage space when using the blank-padded type, and a few extra CPU cycles to check the length when storing into a length-constrained column
В общем и целом я лямку за Firebird тяну если что :) Но упоминаю возможности всех серверов, так как пытаюсь быть более объективным, чем автор статьи. Честно признаюсь, что об ограничениях TEXT для MySQL не в курсе; для Firebird-овского BLOB SUB_TYPE 1 — в курсе.
При этом сравнить работу даже просто длинных строк — не так просто. Даже если выделить обсуждаемым СУБД одинаковые, допустим, виртуалки, как минимум встанут вопросы конфигурации серверов. Плюс отдельно — режимы работы: только вставка или вставка/обновление/удаление, количество последовальных чтений, количество одновременных чтений, количество одновременных чтений с одновременными же обновлениями/удалениями данных, то же самое — с проверкой достоверности (должен ли пользователь А видеть данные, которые пользователь Б начал удалять после того, как пользователь А начал их просматривать).
Возьметесь за такое сравнение? Я — нет, ибо недостаточно компетентен в MySQL/PostgreSQL для правильного написания теста под них.
При этом сравнить работу даже просто длинных строк — не так просто. Даже если выделить обсуждаемым СУБД одинаковые, допустим, виртуалки, как минимум встанут вопросы конфигурации серверов. Плюс отдельно — режимы работы: только вставка или вставка/обновление/удаление, количество последовальных чтений, количество одновременных чтений, количество одновременных чтений с одновременными же обновлениями/удалениями данных, то же самое — с проверкой достоверности (должен ли пользователь А видеть данные, которые пользователь Б начал удалять после того, как пользователь А начал их просматривать).
Возьметесь за такое сравнение? Я — нет, ибо недостаточно компетентен в MySQL/PostgreSQL для правильного написания теста под них.
По-моему с абзацем про размеры строк что-то не так.
Для сравнения, MySQL и MariaDB печально известны ограничением размера строк в 65,535 байт.Честно, не могу понять о каком ограничении тут идёт речь.
Речь про вот это ограничение: http://dev.mysql.com/doc/refman/5.7/en/column-count-limit.html
Я знаю про эту особенность, так что для меня абзац выглядит корректно и понятно.
Я знаю про эту особенность, так что для меня абзац выглядит корректно и понятно.
То есть это проблема для тех, кому хранить строки в TEXT или BLOB религия не позволяет?
Вроде того. Я не представляю ситуаций, когда строка данных без учёта типов blob и text не помещается в 64кб. Для этого надо делать что-то довольно странное.
Зачем странное, можно просто сериализовать набор объектов и сложить в базу, а потом оттуда прочитать и десериализовать ;)
Ну так это органично blob будет, ну или text. На них лимит размера строки не распространяется. Надо пытаться именно в огромные varchar'ы писать или что-нибудь в этом духе.
Хотя вот про тип данных json в mysql честно не знаю. Может быть он тоже подвержен лимиту в 64кб, а может — его просто забыли на этой странице мануала упомянуть.
Хотя вот про тип данных json в mysql честно не знаю. Может быть он тоже подвержен лимиту в 64кб, а может — его просто забыли на этой странице мануала упомянуть.
Почему 64Кб? В InnoDB размер строки не может превышать половину страницу -значит 32кб.
64кб — общий лимит. Каждый storage engine может налагать свои более строгие ограничения.
Касательно именно innodb и его максимального размера строки — там вообще всё как-то очень сложно. Зависит от версии СУБД, ROW_FORMAT, innodb_page_size и примечаний в разных частях мануала. Но вы пропустили маленькую деталь:
http://dev.mysql.com/doc/refman/5.7/en/innodb-restrictions.html
varchar в innodb не считается как максимальная длина строки.
Касательно именно innodb и его максимального размера строки — там вообще всё как-то очень сложно. Зависит от версии СУБД, ROW_FORMAT, innodb_page_size и примечаний в разных частях мануала. Но вы пропустили маленькую деталь:
The maximum row length, except for variable-length columns (VARBINARY, VARCHAR, BLOB and TEXT), is slightly less than half of a database page for 4KB, 8KB, 16KB, and 32KB page sizes. For example, the maximum row length for the default innodb_page_size of 16KB is about 8000 bytes. For an InnoDB page size of 64KB, the maximum row length is about 16000 bytes. LONGBLOB and LONGTEXT columns must be less than 4GB, and the total row length, including BLOB and TEXT columns, must be less than 4GB.
http://dev.mysql.com/doc/refman/5.7/en/innodb-restrictions.html
varchar в innodb не считается как максимальная длина строки.
Есть еще LONGTEXT — 4 Гб.
Массивы в FB есть http://www.firebirdsql.org/file/documentation/reference_manuals/fblangref25-en/html/fblangref25-datatypes-bnrytypes.html#fblangref25-datatypes-array
JSONB обычно является предпочтительным форматом, поскольку требует меньше места для объектовНе подскажите сколько jsonb занимает в минимальном случае (пустое значение), т.е. сколько байт выделяется под jsonb в строке табличной части?
В mysql innodb для текста (пустое значение) это около 700-800 байт на строку таблицы.
Пусть сначала приведут в человеческое состояние весь свой кроссплатформенный UI в лице pgAdmin, репликацию, в потом уже участвуют в номинациях лучшая БД и.т. п
А что не так с репликацией?
Разве есть какие-то проблемы с pgAdmin? Да и вообще, зачем он нужен при живом psql?
Разве есть какие-то проблемы с pgAdmin? Да и вообще, зачем он нужен при живом psql?
А у других есть что-то приличное?
У firebird-a есть IBExpert. Не является частью собствено firebird, коммерческий (но бесплатен для тех у кого локаль win1251; на линуксе под вайном работает нормально).
SQL Server Management Studio как пример. Есть проблемы, но продукт выглядит дорого.
Что мешает сделать свежий и приятный интерфейс в стиле Robomongo для того же PostgreSQL?
Отношение к продукту будет уже совсем другое у новичков. Сейчас же я ощущаю, что работаю с чем-то морально устаревшим.
К PostgreSQL претензий вообще нет никаких, но люди реально акцентируют внимание на специфичных функциональных вещах, не сделав человеческими вещи, от которых зависит тоже очень многое.
Что мешает сделать свежий и приятный интерфейс в стиле Robomongo для того же PostgreSQL?
Отношение к продукту будет уже совсем другое у новичков. Сейчас же я ощущаю, что работаю с чем-то морально устаревшим.
К PostgreSQL претензий вообще нет никаких, но люди реально акцентируют внимание на специфичных функциональных вещах, не сделав человеческими вещи, от которых зависит тоже очень многое.
Вам ответит Джеф Раскин:
Представьте себе, что вы поднялись на борт сияющего шикарной отделкой авиалайнера, оснащенного просторными, комфортабельными кожаными креслами с целым набором встроенной аудио- и видеотехники; в буфете вас ожидают отличная еда и напитки. Вы садитесь в свое кресло и смотрите в большой, чисто вымытый иллюминатор. Со вздохом предвкушения особенно приятного полета вы протягиваете руку к шкафчику впереди вас, чтобы поглядеть, что там. Сначала вы достаете весьма объемистую бутылку любимого напитка, а затем буклет с описанием этого замечательного воздушного лайнера.
В то время как двери закрываются и идут приготовления к взлету, вы усаживаетесь поудобнее и начинаете читать. Из буклета вы узнаете, что интерьер самолета создан трудами самых лучших в мире дизайнеров, что повара из пятизвездочных отелей лично составляли меню и готовили блюда и что в группу разработчиков самолета не были включены инженеры-авиаконструкторы, поскольку всемирно признанные дизайнеры сделали внешний вид самолета таким, что и без того создается впечатление авиалайнера, способного летать во много раз быстрее, чем любой другой.
Еще в буклете мелким шрифтом сообщается, что путешествие на этом самолете нередко даже в хорошую погоду сопровождается болтанкой и что достаточно регулярно с ним случаются катастрофы. Если же перелет обойдется без этих инцидентов, то в целом, как обещают авторы, ваше путешествие будет комфортным и интересным.
Теперь звук закрывающихся дверей внезапно принимает угрожающее значение, вы теряете спокойствие и чувствуете, что попали в ловушку. Вы начинаете думать, что именно этот рейс обречен и что вы предпочли бы сейчас сидеть в более жестком кресле, без любимого напитка и даже без бокового иллюминатора, лишь бы только самолет был оборудован хорошей и надежной техникой.
Представьте себе, что вы поднялись на борт сияющего шикарной отделкой авиалайнера, оснащенного просторными, комфортабельными кожаными креслами с целым набором встроенной аудио- и видеотехники; в буфете вас ожидают отличная еда и напитки. Вы садитесь в свое кресло и смотрите в большой, чисто вымытый иллюминатор. Со вздохом предвкушения особенно приятного полета вы протягиваете руку к шкафчику впереди вас, чтобы поглядеть, что там. Сначала вы достаете весьма объемистую бутылку любимого напитка, а затем буклет с описанием этого замечательного воздушного лайнера.
В то время как двери закрываются и идут приготовления к взлету, вы усаживаетесь поудобнее и начинаете читать. Из буклета вы узнаете, что интерьер самолета создан трудами самых лучших в мире дизайнеров, что повара из пятизвездочных отелей лично составляли меню и готовили блюда и что в группу разработчиков самолета не были включены инженеры-авиаконструкторы, поскольку всемирно признанные дизайнеры сделали внешний вид самолета таким, что и без того создается впечатление авиалайнера, способного летать во много раз быстрее, чем любой другой.
Еще в буклете мелким шрифтом сообщается, что путешествие на этом самолете нередко даже в хорошую погоду сопровождается болтанкой и что достаточно регулярно с ним случаются катастрофы. Если же перелет обойдется без этих инцидентов, то в целом, как обещают авторы, ваше путешествие будет комфортным и интересным.
Теперь звук закрывающихся дверей внезапно принимает угрожающее значение, вы теряете спокойствие и чувствуете, что попали в ловушку. Вы начинаете думать, что именно этот рейс обречен и что вы предпочли бы сейчас сидеть в более жестком кресле, без любимого напитка и даже без бокового иллюминатора, лишь бы только самолет был оборудован хорошей и надежной техникой.
Ну вы уж нагнали страху. SQL Server шикарная СУБД, ток цена кусается и блин нет JSON полноценного как в PG :)
SSMS особенно в шелле от 15 студии ооочень приятен и удобен для работы с СУБД. pgAdmin очень отстает :( Там хотя бы убрать MDI интерфейс — это уже бы облегчило работу.
Это мнение разработчика, а не администратора. Работаю и с PG и с MSSQL одновременно.
SSMS особенно в шелле от 15 студии ооочень приятен и удобен для работы с СУБД. pgAdmin очень отстает :( Там хотя бы убрать MDI интерфейс — это уже бы облегчило работу.
Это мнение разработчика, а не администратора. Работаю и с PG и с MSSQL одновременно.
Утрирование цитированием Раскина — это же весело :)
Ваши аргументы действительно имеют место быть и никто с ними не будет спорить, но у предыдущего оратора основной тезис: «Есть проблемы, но продукт выглядит дорого.» А-ля для БД крайне необходимо не улучшать работу с данными, а запилить красивый интерфейс))) То есть не быть дорогой и рабочей без нареканий, а только выглядеть такой))))
Ваши аргументы действительно имеют место быть и никто с ними не будет спорить, но у предыдущего оратора основной тезис: «Есть проблемы, но продукт выглядит дорого.» А-ля для БД крайне необходимо не улучшать работу с данными, а запилить красивый интерфейс))) То есть не быть дорогой и рабочей без нареканий, а только выглядеть такой))))
У Sybase есть Sybase Central — лучшее из того, что видел для управления БД.
— PostgreSQL лучше, чем другие OpenSource СУБД.
— Чем?
— Чем другие OpenSource СУБД.
(из старого анекдота)
Ложка дёгтя: за 20 лет развития из коробки до сих пор нет (и мне очень этого не хватает):
1. распараллеливания одной SQL query по нескольким ядрам CPU;
2. хинтов в запросах (Oracle-like).
1. распараллеливания одной SQL query по нескольким ядрам CPU;
2. хинтов в запросах (Oracle-like).
«Распараллеливание» запросов будет в 9.6, подробнее можно у Hubert'a почитать depesz.com
В самом постгресе хинтов не будет, по крайней мере пока OptimizerHintsDiscussion, но есть http://pghintplan.osdn.jp/pg_hint_plan.html
В самом постгресе хинтов не будет, по крайней мере пока OptimizerHintsDiscussion, но есть http://pghintplan.osdn.jp/pg_hint_plan.html
То есть Вы все эти 20 лет ждали эти две фичи, и за столь долгий срок даже не промелькнуло и мысли хоть как-то поучаствовать в разработке этого, без преувеличения, замечательного OpenSource продукта? =)
Вот вы знаете, может, я просто не сталкивался с подобными проектами, но я очень подозрительно отношусь к продукту, которому надо рутинно менять одно хранилище на другое. Я имею ввиду какой-то сервис, который предоставляет услугу, считает деньги за эту услугу, разработчки каждый день решают «хотелки» от коммерции разной степени адекватности и т.д.
Здесь вы правы. Но такой продукт будет либо очень «средний по больнице», и в процессе эксплуатации все равно придется лезть в недра или звать сантехников, которые умеют в них ковыряться) Грабли на нагрузках и объемах неизбежно повылазят уже после внедрения. А до тех пор — какая-то усредненная функциональность, более-менее решаемая ORM'ом с сомнительной степенью эффективности.
Вот что точно доставляет неудобство в PostgreSQL, так это невозможность использования в запросе значений вычисляемых в этом же запросе полей. Поясню:
Select a as val1, b as val2, val1+val2 as sum_a_b From table;
[Err] ОШИБКА: колонка «val1» не существует
Select a as val1, b as val2, val1+val2 as sum_a_b From table;
[Err] ОШИБКА: колонка «val1» не существует
Решается вложенными селектами, но это действительно неудобно когда вложенность доходит уровней до 5.
Это не неудобство Posgre, это общее свойство всех запросов, и объясняется очень просто: для обращения к алиасу нужно, чтобы он существовал в момент выполнения этого запроса. Т.к. все поля селекта присваиваются одновременно (можно считать, что каждой поле в своем потоке присваивается), то и алиаса не существует. По той же причине нельзя их в Where и OrderBy использовать — селект выполняется последним, и поэтому ОН может использовать алиасы, из, например, from, а наоборот — нет.
В order by можно, а вот в группировке, например, — нельзя.
Я подозреваю, что комментарий возник в связи с тем, что MySQL как раз-таки позволяет оперировать алиасами в group by. Я сам сталкивался с этой печалью имени MySQL-«архитекторов», когда надо было код портировать, в котом трехъэтажная «регулярка» была в виде алиаса условием для group by! Пришлось переписывать, конечно. В тупую Посгрес не дает таки вещи переносить, и это, в общем-то, хорошо.
Я подозреваю, что комментарий возник в связи с тем, что MySQL как раз-таки позволяет оперировать алиасами в group by. Я сам сталкивался с этой печалью имени MySQL-«архитекторов», когда надо было код портировать, в котом трехъэтажная «регулярка» была в виде алиаса условием для group by! Пришлось переписывать, конечно. В тупую Посгрес не дает таки вещи переносить, и это, в общем-то, хорошо.
А как происходит работа с индексами, с большими таблицами?
Поясните, свой вопрос, пожалуйста :) Про индексы можете почитать переводы наших статей про explain, там частично эта тема затрагивается. Про большие таблицы — на крупных инсталляциях проблемы с их обслуживанием могут возникнуть, зависит от совокупной ситуации на вашей базе (объем и количество таблиц, интенсивность записи и т.д.), но это тема для отдельной статьи про эксплуатацию.
Что если на все 1600 колонок целого типа повесить b-tree не уникальные индексы?
[ирония]Тогда у вас что-то не так с архитектурой приложения.[/ирония]
В теории вставка или модификация (смотря какая) каждой строки будет происходить в среднем в 1600 раз медленнее, чем без индексов. На деле, пока всё это будет помещаться в буферы — быстрее, а потом медленее.
Боюсь, что в такой постановке задачи, проблемы будут у любой РСУБД, т.к. они не ориентированы на таблицы с таким числом колонок. В рамках РСУБД такие таблицы обычно преобразовываются по модели Entity–attribute–value (EAV).
Тогда к чему возможность столько колонок иметь?
Количество колонок варьируется от типа данных на колонках. Поэтому можно иметь от 250 до 1600 колонок. Такая возможность обусловлена размерами страницы в 8 Кб.
С другой стороны, возможность заводить большое число колонок, никак не оправдывает дизайн схемы данных с большим количеством колонок в таблице в РСУБД. РСУБД для этого не предназначены. Для таких задач есть колоночные СУБД, например Cassandra или Teradata.
С другой стороны, возможность заводить большое число колонок, никак не оправдывает дизайн схемы данных с большим количеством колонок в таблице в РСУБД. РСУБД для этого не предназначены. Для таких задач есть колоночные СУБД, например Cassandra или Teradata.
Когда слово берёт специалист, мне хочется услышать не только о сильных сторонах продукта, но даже в большей степени о слабых.
Это может показаться ответом наивного фанбоя, но я вот посидел честно и подумал о своем опыте интенсивной работы с ПГ в крупных проектах и не могу вспомнить чего-то такого масштабно плохого, от чего были большие боли и страдания, по сравнению с моим опытом от работы с MySQL и NoSQL решениями. Мелких придирок могу накидать, выше коллеги, например, писали про невозможность использовать alias сложносочиненного выражения в group by. Но я это считаю больше решением из разряда bad design. Такие вещи правильно отцепить в CTE / подзапрос.
Хотя мысль, конечно, любопытная, написать подобную статью и покопаться в шкафу со скелетами.
Вещи из разряда «GUI кривой» я не считаю недостатком базы и всех программистов приучаю работать с psql.
Хотя мысль, конечно, любопытная, написать подобную статью и покопаться в шкафу со скелетами.
Вещи из разряда «GUI кривой» я не считаю недостатком базы и всех программистов приучаю работать с psql.
Я могу накидать таких недостатков много десятков, тк давно и плотно работаю с postgresql. Но восновном это будут недостатки в сравнении с Oracle/DB2 а не с MySQL.
Сравнивая с MySQL таких недостатков исчезающе мало и они если честно даже близко не перекрывают достоинств.
Если говорить о технических моментах, где MySQL с некоторыми оговорками впереди, то это
1. использование O_DIRECT
2. Поддержка NUMA-архитектур (по крайней мере перкона-сервером)
С пунктом 1 у MySQL не без купороса и есть шанс что в PostgreSQL в ближайшие годы поддержка O_DIRECT будет имплементирована прямее. Тут важно еще понимать, что MySQL в силу устройства своего сообщества осилил выкинуть поддержку зоопарка ОС, а PostgreSQL пока нет — им такие вещи сейчас внедрять проще.
Пункт 2 скорее тянет на пол-пункта тк поддержка далека от совершенства. Стандарты PostgreSQL просто не позволят закомитить такую полуфичу в основной Postgres, (EDB или ПгПро конечно могут себе позволить, но хорошо от этого их продуктам не будет)
Сравнивая с MySQL таких недостатков исчезающе мало и они если честно даже близко не перекрывают достоинств.
Если говорить о технических моментах, где MySQL с некоторыми оговорками впереди, то это
1. использование O_DIRECT
2. Поддержка NUMA-архитектур (по крайней мере перкона-сервером)
С пунктом 1 у MySQL не без купороса и есть шанс что в PostgreSQL в ближайшие годы поддержка O_DIRECT будет имплементирована прямее. Тут важно еще понимать, что MySQL в силу устройства своего сообщества осилил выкинуть поддержку зоопарка ОС, а PostgreSQL пока нет — им такие вещи сейчас внедрять проще.
Пункт 2 скорее тянет на пол-пункта тк поддержка далека от совершенства. Стандарты PostgreSQL просто не позволят закомитить такую полуфичу в основной Postgres, (EDB или ПгПро конечно могут себе позволить, но хорошо от этого их продуктам не будет)
Привет, Илья! Да, это то, что мы успели обсудить за 5 минут общения на Percona Live. Но список отличий этими двумя пунктами не исчерпывается. Я собираюсь развернуто поговорить на эту тему на DevConf: http://devconf.ru/ru/offers/offer/127
Приходите/приезжайте. Думаю, достаточно интересный рассказ получится.
Приходите/приезжайте. Думаю, достаточно интересный рассказ получится.
Я собираюсь подробно поговорить на эту тему на DevConf: http://devconf.ru/ru/offers/offer/127
Было бы неплохо, если бы вы еще и про оптимизацию PostgreSQL написали
Куда уж больше…
1. https://habrahabr.ru/post/203320/
2. https://habrahabr.ru/post/203386/
3. https://habrahabr.ru/post/203484/
1. https://habrahabr.ru/post/203320/
2. https://habrahabr.ru/post/203386/
3. https://habrahabr.ru/post/203484/
В нашем блоге есть переводы хороших статьей Депеша про Explain! :)
> это поддержка пользовательских объектов и их поведения…. Это делает Постгрес невероятно гибким и надежным.
Маркетинговая манипуляция мнением относительно надёжности
Маркетинговая манипуляция мнением относительно надёжности
А почему всегда приводятся и сравниваются максимальные размеры, но никогда не приводятся минимальные? Ну например — сколько байт реально физически на диске будет занимать запись с единственным битовым полем в PostgreSQL и других сравниваемых СУБД? То есть, насколько велик overhead при использовании очень больших таблиц с очень короткими записями?
Разве это имеет какое-то практическое значение? У вас все равно в реальной жизни не будет таблицы с единственным битовым полем. Там как минимум будет еще какой-либо первичный ключ. А если для какой-то задачи вам потребуется такая таблица без первичного ключа, значит, вы неправильно спроектировали хранилище данных.
Услышав или прочитав слово PostgreSQL каждый раз вспоминаю легендарную миграцию Oracle -> Postgres для ArcGIS for Server на предыдущем месте работы, когда удалось перенести всю обработку геоданных с двух мощных физических серверов на один относительно слабый виртуальный инстанс и при этом увеличить количество одновременно работающих с базой сотрудников с 5 до 50 =)
Так что большое спасибо за крутую статью о Postgres!
PS: А половина комментаторов выше не правы, ставя другие БД в один ряд с постгресом ;-P
Так что большое спасибо за крутую статью о Postgres!
PS: А половина комментаторов выше не правы, ставя другие БД в один ряд с постгресом ;-P
В Firebird массивы есть, причем они есть со времен InterBase 3, сделаны в 80-х годах прошлого века для Boeing.
Не знаю, как по остальным СУБД, но если в статье содержится такое откровенное вранье, то доверия и к ней уже нет, и в целом Постгресу это не добавляет очков.
Не знаю, как по остальным СУБД, но если в статье содержится такое откровенное вранье, то доверия и к ней уже нет, и в целом Постгресу это не добавляет очков.
Как-то не убедительно. Столько возможностей и ни одной действительно необходимой. Вот хранение сетевых адресов, например. А что мешает хранить их в обычном виде? Или их кодировать можно и закинуть в int или char… В общем для рукожопов можно было еще искувственный интеллект в этот постгрэс еще влепить, чтобы он еще сам программы под себя писал. На мой взгляд лучше mysql/mariadb ничего нет, и ее возможностей даже больше, чем нужно, все остальное ручками хорошо пишется, а свистоперделки лишь делают СУБД более медленной.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Чем PostgreSQL лучше других SQL баз данных с открытым исходным кодом. Часть 1