Comments 86
Конечно, моё утверждение довольно субъективное, но ИМХО, «множество возможностей» — это просто особенность, а не конкурентное преимущество. В целом, конечно, неплохо, что на стороне СУБД есть возможность делать высокоуровневые операции, которые раньше выносились на приложение. Но это совсем не обязательно, и особых причин делать их именно на стороне СУБД как бы и нет. Т.е. разработчик, которому СУБД таких плюшек не даёт, и который это будет делать на уровне сервера приложений и/или клиента, не будет себя чувствовать хуже :)
Для примера, можно взять не сложный запрос: автоматически расставить полигонам зданий адреса по признаку их географической вложенности в полигоны страны, области, города; исключив при этом дома внутри промзон и города площадью меньше заданного значения.
Не соглашусь с Вами. Временами, сделать быстрее на БД — возможно, да и посмотреть наверно удобнее.
Только все это очень весело до того момента, пока проект не перевалит через некоторое пороговое значение своего размера и сложности. Потом начинаются неочевидные связи, черные ящики, вертикальное масштабирование и пр. Использование «множества возможностей» в итоге часто оборачиваются проблемами миграции на другие БД (например, при установке системы в банке, который имеет лицензию и поддержку альтернативной БД).
При всем моем уважении и любви к postgres — для меня это не более чем надежное ACID-хранилище, я сторонник логики в приложении почти всегда (за исключением разве что случаев обработки огромных массивов данных, чтобы не гонять их по сети).
Есть сферы применения БД, где манипуляция с данными крайне проста, прозрачна и имеет высокую производительность, в случае работы на уровне БД, и геоданные — одна из таких сфер, как мне кажется.
И все же — ваше сообщение скорее про OLAP-область, не OLTP?
Ни одна из этих баз данных сейчас не поддерживает CHECK ограничения
То есть как это? Check constraint даже в Sqlite есть, во встраиваемой БД.
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
При этом сравнить работу даже просто длинных строк — не так просто. Даже если выделить обсуждаемым СУБД одинаковые, допустим, виртуалки, как минимум встанут вопросы конфигурации серверов. Плюс отдельно — режимы работы: только вставка или вставка/обновление/удаление, количество последовальных чтений, количество одновременных чтений, количество одновременных чтений с одновременными же обновлениями/удалениями данных, то же самое — с проверкой достоверности (должен ли пользователь А видеть данные, которые пользователь Б начал удалять после того, как пользователь А начал их просматривать).
Возьметесь за такое сравнение? Я — нет, ибо недостаточно компетентен в MySQL/PostgreSQL для правильного написания теста под них.
Для сравнения, MySQL и MariaDB печально известны ограничением размера строк в 65,535 байт.Честно, не могу понять о каком ограничении тут идёт речь.
Я знаю про эту особенность, так что для меня абзац выглядит корректно и понятно.
Хотя вот про тип данных json в mysql честно не знаю. Может быть он тоже подвержен лимиту в 64кб, а может — его просто забыли на этой странице мануала упомянуть.
Касательно именно 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 не считается как максимальная длина строки.
JSONB обычно является предпочтительным форматом, поскольку требует меньше места для объектовНе подскажите сколько jsonb занимает в минимальном случае (пустое значение), т.е. сколько байт выделяется под jsonb в строке табличной части?
В mysql innodb для текста (пустое значение) это около 700-800 байт на строку таблицы.
Ведь если в табличной части хранится минимум, то вся остальная часть (при не пустом) храниться в отдельном хранилище, а это обычно медленнее чем хранение в таблице напрямую.
Разве есть какие-то проблемы с pgAdmin? Да и вообще, зачем он нужен при живом psql?
Что мешает сделать свежий и приятный интерфейс в стиле Robomongo для того же PostgreSQL?
Отношение к продукту будет уже совсем другое у новичков. Сейчас же я ощущаю, что работаю с чем-то морально устаревшим.
К PostgreSQL претензий вообще нет никаких, но люди реально акцентируют внимание на специфичных функциональных вещах, не сделав человеческими вещи, от которых зависит тоже очень многое.
Представьте себе, что вы поднялись на борт сияющего шикарной отделкой авиалайнера, оснащенного просторными, комфортабельными кожаными креслами с целым набором встроенной аудио- и видеотехники; в буфете вас ожидают отличная еда и напитки. Вы садитесь в свое кресло и смотрите в большой, чисто вымытый иллюминатор. Со вздохом предвкушения особенно приятного полета вы протягиваете руку к шкафчику впереди вас, чтобы поглядеть, что там. Сначала вы достаете весьма объемистую бутылку любимого напитка, а затем буклет с описанием этого замечательного воздушного лайнера.
В то время как двери закрываются и идут приготовления к взлету, вы усаживаетесь поудобнее и начинаете читать. Из буклета вы узнаете, что интерьер самолета создан трудами самых лучших в мире дизайнеров, что повара из пятизвездочных отелей лично составляли меню и готовили блюда и что в группу разработчиков самолета не были включены инженеры-авиаконструкторы, поскольку всемирно признанные дизайнеры сделали внешний вид самолета таким, что и без того создается впечатление авиалайнера, способного летать во много раз быстрее, чем любой другой.
Еще в буклете мелким шрифтом сообщается, что путешествие на этом самолете нередко даже в хорошую погоду сопровождается болтанкой и что достаточно регулярно с ним случаются катастрофы. Если же перелет обойдется без этих инцидентов, то в целом, как обещают авторы, ваше путешествие будет комфортным и интересным.
Теперь звук закрывающихся дверей внезапно принимает угрожающее значение, вы теряете спокойствие и чувствуете, что попали в ловушку. Вы начинаете думать, что именно этот рейс обречен и что вы предпочли бы сейчас сидеть в более жестком кресле, без любимого напитка и даже без бокового иллюминатора, лишь бы только самолет был оборудован хорошей и надежной техникой.
SSMS особенно в шелле от 15 студии ооочень приятен и удобен для работы с СУБД. pgAdmin очень отстает :( Там хотя бы убрать MDI интерфейс — это уже бы облегчило работу.
Это мнение разработчика, а не администратора. Работаю и с PG и с MSSQL одновременно.
Ваши аргументы действительно имеют место быть и никто с ними не будет спорить, но у предыдущего оратора основной тезис: «Есть проблемы, но продукт выглядит дорого.» А-ля для БД крайне необходимо не улучшать работу с данными, а запилить красивый интерфейс))) То есть не быть дорогой и рабочей без нареканий, а только выглядеть такой))))
— PostgreSQL лучше, чем другие OpenSource СУБД.
— Чем?
— Чем другие OpenSource СУБД.
(из старого анекдота)
1. распараллеливания одной SQL query по нескольким ядрам CPU;
2. хинтов в запросах (Oracle-like).
В самом постгресе хинтов не будет, по крайней мере пока OptimizerHintsDiscussion, но есть http://pghintplan.osdn.jp/pg_hint_plan.html
Select a as val1, b as val2, val1+val2 as sum_a_b From table;
[Err] ОШИБКА: колонка «val1» не существует
Я подозреваю, что комментарий возник в связи с тем, что MySQL как раз-таки позволяет оперировать алиасами в group by. Я сам сталкивался с этой печалью имени MySQL-«архитекторов», когда надо было код портировать, в котом трехъэтажная «регулярка» была в виде алиаса условием для group by! Пришлось переписывать, конечно. В тупую Посгрес не дает таки вещи переносить, и это, в общем-то, хорошо.
Что если на все 1600 колонок целого типа повесить b-tree не уникальные индексы?
Тогда к чему возможность столько колонок иметь?
С другой стороны, возможность заводить большое число колонок, никак не оправдывает дизайн схемы данных с большим количеством колонок в таблице в РСУБД. РСУБД для этого не предназначены. Для таких задач есть колоночные СУБД, например Cassandra или Teradata.
Хотя мысль, конечно, любопытная, написать подобную статью и покопаться в шкафу со скелетами.
Вещи из разряда «GUI кривой» я не считаю недостатком базы и всех программистов приучаю работать с psql.
Сравнивая с MySQL таких недостатков исчезающе мало и они если честно даже близко не перекрывают достоинств.
Если говорить о технических моментах, где MySQL с некоторыми оговорками впереди, то это
1. использование O_DIRECT
2. Поддержка NUMA-архитектур (по крайней мере перкона-сервером)
С пунктом 1 у MySQL не без купороса и есть шанс что в PostgreSQL в ближайшие годы поддержка O_DIRECT будет имплементирована прямее. Тут важно еще понимать, что MySQL в силу устройства своего сообщества осилил выкинуть поддержку зоопарка ОС, а PostgreSQL пока нет — им такие вещи сейчас внедрять проще.
Пункт 2 скорее тянет на пол-пункта тк поддержка далека от совершенства. Стандарты PostgreSQL просто не позволят закомитить такую полуфичу в основной Postgres, (EDB или ПгПро конечно могут себе позволить, но хорошо от этого их продуктам не будет)
А можно, пожалуйста, увидеть Топ 10 по сравнению с Oracle/DB2? Не писькомерства ради, а просто интересно такие вещи знать. Можно в виде отдельной статьи ;)
Приходите/приезжайте. Думаю, достаточно интересный рассказ получится.
1. https://habrahabr.ru/post/203320/
2. https://habrahabr.ru/post/203386/
3. https://habrahabr.ru/post/203484/
Маркетинговая манипуляция мнением относительно надёжности
Так что большое спасибо за крутую статью о Postgres!
PS: А половина комментаторов выше не правы, ставя другие БД в один ряд с постгресом ;-P
Не знаю, как по остальным СУБД, но если в статье содержится такое откровенное вранье, то доверия и к ней уже нет, и в целом Постгресу это не добавляет очков.
Как-то не убедительно. Столько возможностей и ни одной действительно необходимой. Вот хранение сетевых адресов, например. А что мешает хранить их в обычном виде? Или их кодировать можно и закинуть в int или char… В общем для рукожопов можно было еще искувственный интеллект в этот постгрэс еще влепить, чтобы он еще сам программы под себя писал. На мой взгляд лучше mysql/mariadb ничего нет, и ее возможностей даже больше, чем нужно, все остальное ручками хорошо пишется, а свистоперделки лишь делают СУБД более медленной.
Чем PostgreSQL лучше других SQL баз данных с открытым исходным кодом. Часть 1