>>> a = 1
>>> b = '1'
>>> hasattr(a, '__add__')
True
>>> hasattr(b, '__add__')
True
>>> a + a
2
>>> b + b
'11'
>>> a + b
Traceback (most recent call last):
File "", line 1, in TypeError: unsupported operand type(s) for +: 'int' and 'str'
У скайпа была ещё одна киллер-фича — синхронизация истории. Переходишь с машины на машину, приходишь с работы домой, а всё на месте, можно продолжать общаться, не переспрашивая собеседника о чём говорили.
Наслушавшись сказок на ночь (по вкусу — насмотревшись ужастиков) — можно дойти до того, что без света не спится ;-)
Честно сказать, не вижу проблемы в детальном знании одного из неотъемлемых инструментов разработки. Не боги горшки обжигают. Если разработчика не смущает изучение языка и среды разработки, тестирование и профилирование кода приложения, почему его должно смущать оное в отношении активно используемого хранилища данных? Причём это вполне касается и MySQL/Mongo/(далее по списку) — в MySQL что-ли настраивать и профилировать нечего? Такое же хранилище, с теми же фундаментальными компромиссами «диск/память/процессор». ИМХО, системного администратора это касается куда в меньшей мере, чем самого разработчика, решающего, что, где и как в базе.
А крутой DBA — это уже для крупных команд и проектов, где пошло расслоение по классам фронтендщиков, и он в не меньшей степени разработчик, поскольку его мнение а-ля «вот здесь всё переделываем, а транзакцию с блокировками организовываем по такому-то сценарию, а вот здесь добавляем скрипт обслуживания данных, иначе через неделю всё загнётся» — прямое руководство к действию и смене планов, как и мнение СЕОшника, или специалиста по UX.
Понятно, что узкий специалист будет лучше разбираться в вопросе, на котором специализируется, но если уж команда не может себе позволить узкого специалиста и всё зависит от «инициативы снизу» (со стороны абсолютно не заинтересованного временного сотрудника), а не целесообразности для бизнеса… ну, что я могу сказать, так тоже бывает — сплошь и рядом. Всякое встречается, как от недостаточности, так и от избытка инициативы.
Ну и как всегда: «самая короткая дорога та, которую знаешь» и «работает — не трожь». Хотя хороший навигатор не помешал бы.
Если честно, как-то так сложилось, что я изначально его не использую, благо в Postgres есть широкий выбор альтернатив, например hstore + contstraint на значение. Но конкретно бизнес-логика приложения и логика базы — это всё-таки очень разные вещи. В конкретном приложении может быть значительно меньше опций (а точнее в бизнес-роли), чем в самой базе.
Разным приложениям и ролям может быть доступно разное подмножество статусов. Разница именно в этом. Причём о некоторых деталях хранения в базе приложению вообще знать не обязательно. База точно так же может прятаться за интерфейсом из хранимок и вьюшек, как и серверное ПО за внешнее API, что позволяет некоторую гибкость (как всегда ценой некоторого усложнения). Доводилось сталкиваться примерами, когда вся база была спрятана за хранимками. Сам я предпочитаю «абстрагироваться» в отдельных случаях, вроде хранения журналов бизнес-транзакций и конфиденциальной информации — как одна из контр-мер против ошибки в приложении или sql-инъекции на непривелигированном аккаунте.
Задача базы — хранение данных, желательно в целостном виде :-) Подключение клиента с несоответствующей версией с ошибкой в логике сохранения данных или, хуже того, зоопарк клиентов (совсем ужас — зоопарк разработчиков) — это проблема, если сама база не контролирует вопрос. Это особенно болезненная тема в СУБД, поощряющих нестрогое обращение с данными и не предоставляющих инструменты контроля целостности, вроде Mongo. В результате приложения превращаются в «китайскую вермишель» if-ов на все варианты сохранения документов, но проблему это не решает. В общем, грустная история, поскольку этот нестрогий подход очень импонирует начинающим разработчикам, не желающим «возиться со схемой данных» — гремучая смесь.
Избыточное обобщение приводит к обратному эффекту — люди говорят одно, Вы спорите с чем-то другим, в результате кто с кем спорит и зачем, что самое главное, непонятно :-)
Стартапы — да, наверно самая неосознанная в выборе (хотя все ли?) категория. Но у крупного бизнеса свои заморочки. Смена платформы, особенно, если это смена или переобучение решающей части технических специалистов, в то время как само применение технологии уже проникло на множество взаимосвязанных уровней — может быть неприемлема (хоть в силу дороговизны процесса, хоть в силу религиозных убеждений ядра команды, что тоже нельзя исключать). Радикальная перетряска в этом вопросе скорее ожидаема, если перед бизнесом начинает маячить вопрос убытков и/или банкротства (наверно это мощный мотиватор для поиска альтернатив коммерческим СУБД), но это уже совсем другая история, редко касающаяся гигантов и монополистов в некоторой сфере. Никто ведь не утверждает, что MySQL абсолютно бесполезен. А вот что будет прибыльней для компании уровня Facebook — MySQL или Postgres, мы вряд ли когда-либо узнаем, поскольку при наличии одного, у нас нет аналогичной компании для сравнения.
При этом мы можем наблюдать, что Postgres так же прекрасно используется в нагрузках/масштабах уровня фейсбука/твиттера (например, Instagram, Skype), но не можем сравнить — выгоднее/эффективнее это или нет.
«утверждение [...] хорошо чем-то подтверждать»
Ну вот например один из источников, из которого в своё время почерпнул я: https://www.insight-it.ru/highload/2010/arkhitektura-facebook/
Да, время идёт, это уже далёкий 2010, судя по URL.
> мне не известен ни один пример перехода интернет-гиганта с MySQL на PostgreSQL
«Мне не известен» ≠ «нет в природе».
Повторюсь — для гигантов это недостаточно корректная постановка вопроса, когда много внутренних проектов и сервисов, и у каждого своя технология.
http://habrahabr.ru/post/26289/ — новый сервис в Yahoo — это пример или не пример?
http://habrahabr.ru/post/269463/#comment_8626975 — Рамблер, вот даже в теме отметился, интернет-гигант или не гигант?
http://www.nixp.ru/news/12845.html — Яндекс вот понемногу Постгрес вместо Оракла внедряет — Яндексу «тесновато». Сложно сказать, как бы он чувствовал себя в рамках MySQL, но определённо пару лет назад интернет-гигант сделал выбор не в его пользу.
Так что, это скорее вопрос неосведомлённости, а не отсутствия факта + сложность перехода на фоне того, что MySQL, удачно инкорпорировав высококлассную стороннюю разработку — уверенно занял нишу. Насколько его применение «на самом деле» было оправдано и нужен ли был сам MySQL как оболочка над InnoDB, это уже вопрос догадок и допущений, на который лучше отвечать со ссылкой на первоисточники из соответствующих компаний, не полагаясь, однако, на их полную объективность.
> не [достаточно] лучше
В общем, я именно об этом: «не ремонтируй то, что не поломано»
Наверно вместо этого комментария стоило бы уже статью написать, но он слишком специфичен как ответ. Заранее приношу извинения за этот приступ графомании :-)
> Это не критика PostgreSQL и не попытка каких-либо сравнений
Разумеется сама статья — не критика или попытка сравнений. Но тема статьи о том как правильно говорить о «MySQL vs Postgres». Без этого не было бы и статьи.
Но, Вы поднимаете тему не менее однобоко (со стороны одного из лагерей, причём с позиции наиболее «заинтересованной» его части — разработчиков), не до конца понимая или как-то по-своему понимая/интерпретируя утверждения (что явно заметно в следующей статье).
В конечном итоге те, кто глубоко себя посвящает одной из двух конкурирующих платформ/технологий, во второй типично будут разбираться значительно хуже и заблуждаться. Поэтому я и утверждаю, что «разборы мифов» и «разборы разборов» — не продуктивны и будут порождать новые мифы, а значительно продуктивнее было бы совместными усилиями сделать сводную таблицу возможностей и подводных камней с исследованиями и пруфами (но не уверен, что эта идея наберёт достаточное количество заинтересованных сторонников среди тех, кто «в теме», «профит» с этого предприятия крайне ограничен).
> который был выпущен… сегодня
И только сейчас начинает появляться в репозиториях ведущих дистрибутивов, а станет дефолтом в LTS и на хостингах…
Буду говорить только за себя ))
Я перешёл на Postgres, когда в модных книжках уже был MySQL 5.0, на горизонте маячил 5.1, а на хотинге было событием встретить что-то отличное от «тройки». Конечно, тот факт, что в MySQL что-то хорошее появляется и сама эта СУБД развивается — он со всех сторон положительный: конкуренция ускоряет развитие, а Postgres включился в гонку сразу на всех уровнях и направлениях — и с MySQL, и с Oracle, и с решениями типа Mongo, постепенно адаптируя их сильные стороны.
С поддержкой актуальных версий MySQL на типовых хостингах наверняка ситуация улучшилась, да и выделенное железо перестало быть недоступной по цене экзотикой, хотя бы в формате «облака» или VPS, где можно всё сделать «как правильно». Но, лично для меня с выходом 5.7 мало что меняется.
Я использую возможности Postgres, которые ещё неизвестно когда появятся в MySQL и появятся ли вообще, как Вы пишете «сообществу это не нужно» («не очень-то и хотелось» ) и при этом мне доступен широкий простор того, что я ещё могу и планирую использовать в Postgres. MySQL все эти годы так или иначе находился в позиции «догоняющего», при том, что некоторые возможности, возможно даже появились и раньше, чем в Postgres (тот же UPSERT), а для некоторого круга задач MySQL возможно даже чем-то лучше (Key/Value режим InnoDB с HandlerSocket). Я даже не исключаю, что ради последнего согласился бы пополнить «длинный список», поскольку с некоторого времени формально InnoDB — это таки уже MySQL ))
Но в целом, в целом… долгие годы разработчики MySQL вообще не ставили перед собой задачу «догнать и перегнать»…
Когда-то я сам думал в рамках минимализма: «пусть инструмент и с ограниченными возможностями, но главное, что он в хороших руках». В определённый момент, поймав себя на том, что изобретаю транзакции, принял решение о переходе с MyISAM на InnoDB. Потом добравшись до Postgres и вкусив, понял, что назад — дороги нет. Конечно, «никогда не говори «никогда»», но всё же: MySQL не в состоянии предложить того, что Postgres делает играючись. А key-value… есть для этого специализированные решения, которые с разгромным счётом уделают и Postgres, и InnoDB с HS, но при этом в Postgres к ним есть стандартный интерфейс (как и к MySQL) прямо из базы (какие там, кстати, перспективы у SQL/MED в MySQL?).
Но это, разумеется, всё оффтопик. Просто для лучшего понимания.
А «не оффтопик» из этого следующий: поскольку я, как и многие, кто будет критиковать или занимать нейтральную позицию в отношении MySQL, но при этом использовать другие СУБД (читай Mongo, Postgres и дальше по списку) — наверняка будем пользоваться в своих суждениях либо неактуальной информацией, либо особенно важными конкретно для нас слабыми местами MySQL/сильными сторонами других СУБД. Поэтому, если Вы хотите бороться с мифами (читай «евангелизировать MySQL для соответствующей (ангажированной) аудитории»), то как минимум Вам так же необходимо понимать и избавляться от своих заблуждений и мифов в отношении этой аудитории. Соответственно аргументы типа «раз нет, значит это не нужно» («конечно не нужно, ведь есть же %DBMS_NAME%, где всё в шоколаде»), «ряд компаний используют» (с любой DBMS со стажем можно составить немаленький список солидных компаний так или иначе её использующих, а у визави за редким исключением есть опыт перехода с MySQL на нечто для него лучшее и «забывания этого кошмара» ;-)) — аргументами совершенно не являются. Более того с этой позиции в мифах — именно Вы, полагая, что пытаетесь просветить «не разобравшихся в вопросе» (это конечно совершенно не касается детских заблуждений и откровенно устаревших утверждений, но в остальном — самая суть).
Ну и в довесок Вам там ещё комментарий во второй теме :-)
Впору выпускать памятку «как не надо критиковать неправильно критикующих» )))
«Длинный список использующих MySQL компаний ничего не значит, потому что они используют MySQL как key-value хранилище»
«Но, если начать копать, то выясняется, что MySQL там з_а_ч_а_с_т_у_ю используется как key-value хранилище».
Я, конечно, понимаю, что взаимоисключающие параграфы разных источников сковались в одну болванку, но всё же, лучше от этого не становится, это больше похоже на борьбу с ветряными мельницами (от которой сами же вроде пытаетесь отговорить), тем более, что следом сами же подтверждаете мой тезис про Facebook и Twitter: «ибо специфика у них такая».
Сам по себе тезис: «Длинный список использующих MySQL компаний ничего не значит» вполне верен в контексте того, что он не доказывает, что эти конторы, имея опыт использования MySQL не выбрали бы тогда или теперь другую СУБД, не обязательно Postgres (и это никак не проверить — «история не любит сослагательное наклонение»), а тем более в контексте «есть много разных сервисов, для каждого — что-то своё». То есть сама постановка вопроса бессмысленна без всех этих уточнений.
В то же время этот длинный список вполне можно интерпретировать и в духе «даже с MySQL можно жить и зарабатывать» (список потенциальных набросов можно долго продолжать, но я надеюсь идея понятна).
Длинный список компаний использующих некоторую СУБД на самом деле задаёт не верхний предел «это лучшая в совокупности характеристик СУБД», а нижний «это не фундаментальный фактор риска для бизнеса — другие достигали успеха, а естественный отбор не убивает тех, кто эту СУБД выбрал, за стабильностью платформы внимательно следят и вкладываются многие, рынок труда изобилует специалистами по данной технологии». Бизнес, на самом деле, интересуют немного другие вещи, чем те, о которых могли бы спорить технические специалисты.
Автовакуум не просто так по дефолту не самый агрессивный.
— в разные время суток/дни недели нагрузка может быть сильно разная, можно процедуры вакуума настроить в соответствии: потерпеть распухание днём/в будни и агрессивно почистить ночью/в выходные (вплоть до vacuum full, если ожидается период простоя), но даже отстающий в пиках нагрузки автовакуум будет «нагонять» в периоды спада активности.
— транзакции нужно заканчивать как можно быстрее — это важнее, чем «чистить за собой», поскольку увязание транзакций в блокировках может на корню убить производительность и базы, и приложения в пики нагрузки.
С Postgres нужно понять сначала одну существенную вещь: это НЕ та СУБД, что «настроил и забыл». Postgres — это набор инструментов, граничащий с понятием «фреймворк» в языках программирования. С этого момента наступает просветление и понимание как с ним работать и раскрываются горизонты возможностей. А комплект дефолтных настроек нужен только для одного — убедиться, что демон стартует ;-)
Этот подход не слишком дружественный к новичкам, но значительно более дружественный к профессионалам. Из-за этого и недопонимание, и холивары. Когда про какие-то возможности говорят «здесь это не нужно», в контексте MySQL или Postgres имеют в виду очень разные вещи. В MySQL ориентируются на одно, в Postgres — на другое. Если совсем уже вульгарно: кому-то мыльница, кому-то — профессиональная камера. (На самом деле не хочу сказать, что MySQL — это конкретно «мыльница» — всё-таки за прошедшие годы таки много сделано и определённые фичи — таки круты, а нишу «мыльниц» прочно заняла Mongo; MySQL — это сейчас скорее «крепкий середнячок»).
Логика базы и бизнес-логика приложения — «это разные люди».
Это особенно заметно когда одно приложение может работать с несколькими базами, а в одну базу пускают несколько существенно разных приложений и живых пользователей.
Тут получается немножко другая однобокость. Поскольку в статье собрана распространённая неверная критика, может сложиться впечатление («ореол»), что вся критика со стороны postgresql-коммьюнити необоснована, растёт из седой старины и т.д. Но, уже из комментариев видно, что на самом деле критика критики опирается местами на неопределённое будущее, а людям в этом случае критикуемые вопросы крайне болезненны сейчас.
На самом деле, тут нужно действительно «пилить» статью-сравнение двух баз в духе «вот так на самом деле прямо здесь и сейчас». Но это уже скорее хорошая статья для энциклопедии.
Автор ссылается на ряд крупных контор, которые используют MySQL, в духе «видите — это реальность, а не legacy». Но, если начать копать, то выясняется, что MySQL там зачастую используется как key-value хранилище. И в принципе было всё-равно, что будет так использоваться в этой роли — кандидатов много, просто MySQL уже был и именно с этой ролью справлялся неплохо, поэтому остался как наследие (история Facebook, Twitter — про других не так наслышан).
Тот же HandlerSocket — с одной стороны индульгенция MySQL — «у нас возможно и такое», с другой — HandlerSocket по-сути отодвигает весь слой MySQL в сторону как ненужный тормозящий хлам, а пускает нас во внутренности движка InnoDB, который на самом деле может сильно больше, чем MySQL ему позволяет.
С обратной стороны — логически некорректно говорить, что в Postgres только один движок, а «финт ушами» вроде HandlerSocket невозможен. Движков на самом деле несколько, но они конкурируют не за роль основного управляющего, а за роль реализаторов специфических запросов и функций. Postgres не менее расширяемый «хранилищами», просто это расширение идёт на другом уровне и более структурировано (те же: колоночное хранилище в памяти или обработчики запросов с вычислениями на GPU) — нет жёсткого ограничения «если используешь это, то нельзя использовать то». И само основное хранилище вполне себе расширяемо — новые типы данных, новые типы индексов, встраиваемые языки — всё это по сути можно создавать (и оно так и создаётся) как плагины. Что-то всем нужное и стабильное — пойдёт в апстрим «из коробки», что-то будет оформлено как комплект стандартных дополнений, что-то придётся искать или создавать самому и встраивать с прямыми руками и напильником.
Поэтому в принципе уже сама постановка вопроса MySQL vs PostgreSQL изначально некорректна, как некорректно сравнивать «широкое с гибким» )) Соответственно все «холивары» идут мимо и скатываются в нечто унылое.
Корректней было бы сравнивать конкретные «фичи» и их комплексы в проекции на решаемые задачи в целом. Сравнить не только наличие фич, но и возможность разные фичи связывать, использовать, настраивать. Интересно рассматривать «бутылочные горлышки», из-за которых важные задачи не решаются и приходится менять целую платформу.
Мы на самом деле видим много отзывов в духе «как я перешёл на Postgres, потому что мне не хватило того-то» и «меня в MySQL всё устраивает, всего хватает», обратные — в природе встречаются настолько редко, что это куда больше создаёт «ореол» MySQL — «пластмассовой машинки в песочнице», из которой дети вырастают и пересаживаются в «автомобиль» Postgres и «выезжают на автобан».
Смысл именно во внутренней структуре, поскольку иначе — хороших результатов не добиться никакими инструментами, доступными разработчику. А если разработчику связать руки, то можно долго вздыхать, что дело не делается.
Ну вот этот самый HandlerSocket [http://yoshinorimatsunobu.blogspot.com/2010/10/using-mysql-as-nosql-story-for.html] наглядно продемонстрировал, что абстракция, повешенная над движком InnoDB, замедляет доступ по ключу на порядок и всё упирается в процессор сильно раньше. То есть, InnoDB конечно быстрый движок, но не его скорость является бутылочным горлышком. В то же время Postgres имеет меньше лишних абстракций. Поэтому теоретические построения «кто кого» пусты и холиварны. А вот практические результаты всегда интересно знать с привязкой к условиям эксперимента.
Тезис был про невосполнимость утраты SHOW TABLES при переходе с MySQL.
Как видим, общего, на самом деле, больше, чем различий и не так всё страшно.
Если же обсуждать «в MySQL тоже есть», то по поводу автодополнения выше уже прошлись и похоже ситуация за те 7 лет, что я не пользовался им, мало изменилась, что на самом деле факт неприятный, но делает наличие SHOW TABLES и прочих подобных команд востребованным. Вместе с тем это воспитывает соответствующий стиль работы, ломать который тяжело и в итоге поднимается вопрос, «в %СУБД не хватает SHOW TABLES».
Теперь же пару слов про схему.
В документации висит такой комментарий и никто не спешит опровергать, хотя прошло уже шесть лет.
Hans-Henrik Stærfeldt on February 20 2009
The implementation of INFORMATION_SCHEMA can have serious impact on performance of the server. If you have many tables, and query into INFORMATION_SCHEMA without limitations on the schema and if possible the table itself, performance is severely impacted while the query runs.
Здесь на хабре кажется тоже статья пробегала на эту тему. Речь, если не изменяет память шла про версию 5.5 и альфу 5.6, в которой не предвиделось положительных сдвигов. В документации к 5.7 этот вопрос частично затрагивается, упоминается просадка производительности при запросе информации по нескольким базам и рекомендуется такие запросы тюнить.
Наверно это не критичная особенность, утверждать «всё плохо» не буду, хотя ряд ограничений на использование information_schema накладывает.
Наверно стоит добавить, что в особо запущенных случаях таки можно глянуть и в сторону хранимок на Python, Tcl, R, где можно не просто с переменными развернуться во всю ширь, но и со сложными алгоритмами и динамическими запросами. Это, конечно, не совсем то же самое, что выполнение произвольного запроса с переменными вот прямо из консоли, но, кажется, случаи, где это действительно нужно, беспощадно стремятся к нулю, а в реальном приложении — масса вариантов на выбор.
Наивный вопрос: зачем на самом деле нужны переменные? Насколько хорошо запросы с переменными поддаются оптимизации? Документация сразу честно предупреждает, что далеко не всё с переменными просто и интуитивно, есть ряд ограничений.
Я, конечно, не совсем в теме, но краем уха слышал о проблемах с использованием переменных при репликации, возможно это неактуальная информация (или звон совсем не там был, надеюсь кто-то просветит?)
Такие вот вопросы.
В общем, если посмотреть на проблему немного шире, Postgres силён своей расширяемостью — есть вот такие «переменные» http://www.garret.ru/imcs/user_guide.html :-)
Наверно можно что-то попроще и полаконичней нарисовать, если есть такая необходимость.
Внешнее решение хорошо ровным счётом до того момента, пока оно без особых затрат на синхронизацию (к сожалению, я не в курсе, как сфинкс стыкуется с базой) полностью вписывается в решаемую задачу. Как только нужно больше — возвращаемся к тому, с чего начали, но при этом объём задачи уже сильно вырос, а опыт её решения — не накоплен, и что-то даже пошло в бизнес-модели и ломать/перестраивать становится тяжело и дорого. Хуже того, когда это тиражируемая система — приходится поддерживать сразу два варианта, поскольку не во всех экземплярах замена возможна. В общем, как всегда — в каждом случае своя цена, компромиссы и перспективы, которые нужно стратегически спланировать :-)
>>> a = 1
>>> b = '1'
>>> hasattr(a, '__add__')
True
>>> hasattr(b, '__add__')
True
>>> a + a
2
>>> b + b
'11'
>>> a + b
Traceback (most recent call last):
File "", line 1, in TypeError: unsupported operand type(s) for +: 'int' and 'str'
ещё на один шаг дальше:
И с каждым таким шагом отладка становится всё веселее и веселее
Честно сказать, не вижу проблемы в детальном знании одного из неотъемлемых инструментов разработки. Не боги горшки обжигают. Если разработчика не смущает изучение языка и среды разработки, тестирование и профилирование кода приложения, почему его должно смущать оное в отношении активно используемого хранилища данных? Причём это вполне касается и MySQL/Mongo/(далее по списку) — в MySQL что-ли настраивать и профилировать нечего? Такое же хранилище, с теми же фундаментальными компромиссами «диск/память/процессор». ИМХО, системного администратора это касается куда в меньшей мере, чем самого разработчика, решающего, что, где и как в базе.
А крутой DBA — это уже для крупных команд и проектов, где пошло расслоение по классам фронтендщиков, и он в не меньшей степени разработчик, поскольку его мнение а-ля «вот здесь всё переделываем, а транзакцию с блокировками организовываем по такому-то сценарию, а вот здесь добавляем скрипт обслуживания данных, иначе через неделю всё загнётся» — прямое руководство к действию и смене планов, как и мнение СЕОшника, или специалиста по UX.
Понятно, что узкий специалист будет лучше разбираться в вопросе, на котором специализируется, но если уж команда не может себе позволить узкого специалиста и всё зависит от «инициативы снизу» (со стороны абсолютно не заинтересованного временного сотрудника), а не целесообразности для бизнеса… ну, что я могу сказать, так тоже бывает — сплошь и рядом. Всякое встречается, как от недостаточности, так и от избытка инициативы.
Ну и как всегда: «самая короткая дорога та, которую знаешь» и «работает — не трожь». Хотя хороший навигатор не помешал бы.
Разным приложениям и ролям может быть доступно разное подмножество статусов. Разница именно в этом. Причём о некоторых деталях хранения в базе приложению вообще знать не обязательно. База точно так же может прятаться за интерфейсом из хранимок и вьюшек, как и серверное ПО за внешнее API, что позволяет некоторую гибкость (как всегда ценой некоторого усложнения). Доводилось сталкиваться примерами, когда вся база была спрятана за хранимками. Сам я предпочитаю «абстрагироваться» в отдельных случаях, вроде хранения журналов бизнес-транзакций и конфиденциальной информации — как одна из контр-мер против ошибки в приложении или sql-инъекции на непривелигированном аккаунте.
Задача базы — хранение данных, желательно в целостном виде :-) Подключение клиента с несоответствующей версией с ошибкой в логике сохранения данных или, хуже того, зоопарк клиентов (совсем ужас — зоопарк разработчиков) — это проблема, если сама база не контролирует вопрос. Это особенно болезненная тема в СУБД, поощряющих нестрогое обращение с данными и не предоставляющих инструменты контроля целостности, вроде Mongo. В результате приложения превращаются в «китайскую вермишель» if-ов на все варианты сохранения документов, но проблему это не решает. В общем, грустная история, поскольку этот нестрогий подход очень импонирует начинающим разработчикам, не желающим «возиться со схемой данных» — гремучая смесь.
Стартапы — да, наверно самая неосознанная в выборе (хотя все ли?) категория. Но у крупного бизнеса свои заморочки. Смена платформы, особенно, если это смена или переобучение решающей части технических специалистов, в то время как само применение технологии уже проникло на множество взаимосвязанных уровней — может быть неприемлема (хоть в силу дороговизны процесса, хоть в силу религиозных убеждений ядра команды, что тоже нельзя исключать). Радикальная перетряска в этом вопросе скорее ожидаема, если перед бизнесом начинает маячить вопрос убытков и/или банкротства (наверно это мощный мотиватор для поиска альтернатив коммерческим СУБД), но это уже совсем другая история, редко касающаяся гигантов и монополистов в некоторой сфере. Никто ведь не утверждает, что MySQL абсолютно бесполезен. А вот что будет прибыльней для компании уровня Facebook — MySQL или Postgres, мы вряд ли когда-либо узнаем, поскольку при наличии одного, у нас нет аналогичной компании для сравнения.
При этом мы можем наблюдать, что Postgres так же прекрасно используется в нагрузках/масштабах уровня фейсбука/твиттера (например, Instagram, Skype), но не можем сравнить — выгоднее/эффективнее это или нет.
«утверждение [...] хорошо чем-то подтверждать»
Ну вот например один из источников, из которого в своё время почерпнул я: https://www.insight-it.ru/highload/2010/arkhitektura-facebook/
Да, время идёт, это уже далёкий 2010, судя по URL.
> мне не известен ни один пример перехода интернет-гиганта с MySQL на PostgreSQL
«Мне не известен» ≠ «нет в природе».
Повторюсь — для гигантов это недостаточно корректная постановка вопроса, когда много внутренних проектов и сервисов, и у каждого своя технология.
http://habrahabr.ru/post/26289/ — новый сервис в Yahoo — это пример или не пример?
http://habrahabr.ru/post/269463/#comment_8626975 — Рамблер, вот даже в теме отметился, интернет-гигант или не гигант?
http://www.nixp.ru/news/12845.html — Яндекс вот понемногу Постгрес вместо Оракла внедряет — Яндексу «тесновато». Сложно сказать, как бы он чувствовал себя в рамках MySQL, но определённо пару лет назад интернет-гигант сделал выбор не в его пользу.
Так что, это скорее вопрос неосведомлённости, а не отсутствия факта + сложность перехода на фоне того, что MySQL, удачно инкорпорировав высококлассную стороннюю разработку — уверенно занял нишу. Насколько его применение «на самом деле» было оправдано и нужен ли был сам MySQL как оболочка над InnoDB, это уже вопрос догадок и допущений, на который лучше отвечать со ссылкой на первоисточники из соответствующих компаний, не полагаясь, однако, на их полную объективность.
> не [достаточно] лучше
В общем, я именно об этом: «не ремонтируй то, что не поломано»
> Это не критика PostgreSQL и не попытка каких-либо сравнений
Разумеется сама статья — не критика или попытка сравнений. Но тема статьи о том как правильно говорить о «MySQL vs Postgres». Без этого не было бы и статьи.
Но, Вы поднимаете тему не менее однобоко (со стороны одного из лагерей, причём с позиции наиболее «заинтересованной» его части — разработчиков), не до конца понимая или как-то по-своему понимая/интерпретируя утверждения (что явно заметно в следующей статье).
В конечном итоге те, кто глубоко себя посвящает одной из двух конкурирующих платформ/технологий, во второй типично будут разбираться значительно хуже и заблуждаться. Поэтому я и утверждаю, что «разборы мифов» и «разборы разборов» — не продуктивны и будут порождать новые мифы, а значительно продуктивнее было бы совместными усилиями сделать сводную таблицу возможностей и подводных камней с исследованиями и пруфами (но не уверен, что эта идея наберёт достаточное количество заинтересованных сторонников среди тех, кто «в теме», «профит» с этого предприятия крайне ограничен).
> который был выпущен… сегодня
И только сейчас начинает появляться в репозиториях ведущих дистрибутивов, а станет дефолтом в LTS и на хостингах…
Буду говорить только за себя ))
Я перешёл на Postgres, когда в модных книжках уже был MySQL 5.0, на горизонте маячил 5.1, а на хотинге было событием встретить что-то отличное от «тройки». Конечно, тот факт, что в MySQL что-то хорошее появляется и сама эта СУБД развивается — он со всех сторон положительный: конкуренция ускоряет развитие, а Postgres включился в гонку сразу на всех уровнях и направлениях — и с MySQL, и с Oracle, и с решениями типа Mongo, постепенно адаптируя их сильные стороны.
С поддержкой актуальных версий MySQL на типовых хостингах наверняка ситуация улучшилась, да и выделенное железо перестало быть недоступной по цене экзотикой, хотя бы в формате «облака» или VPS, где можно всё сделать «как правильно». Но, лично для меня с выходом 5.7 мало что меняется.
Я использую возможности Postgres, которые ещё неизвестно когда появятся в MySQL и появятся ли вообще, как Вы пишете «сообществу это не нужно» («не очень-то и хотелось» ) и при этом мне доступен широкий простор того, что я ещё могу и планирую использовать в Postgres. MySQL все эти годы так или иначе находился в позиции «догоняющего», при том, что некоторые возможности, возможно даже появились и раньше, чем в Postgres (тот же UPSERT), а для некоторого круга задач MySQL возможно даже чем-то лучше (Key/Value режим InnoDB с HandlerSocket). Я даже не исключаю, что ради последнего согласился бы пополнить «длинный список», поскольку с некоторого времени формально InnoDB — это таки уже MySQL ))
Но в целом, в целом… долгие годы разработчики MySQL вообще не ставили перед собой задачу «догнать и перегнать»…
Когда-то я сам думал в рамках минимализма: «пусть инструмент и с ограниченными возможностями, но главное, что он в хороших руках». В определённый момент, поймав себя на том, что изобретаю транзакции, принял решение о переходе с MyISAM на InnoDB. Потом добравшись до Postgres и вкусив, понял, что назад — дороги нет. Конечно, «никогда не говори «никогда»», но всё же: MySQL не в состоянии предложить того, что Postgres делает играючись. А key-value… есть для этого специализированные решения, которые с разгромным счётом уделают и Postgres, и InnoDB с HS, но при этом в Postgres к ним есть стандартный интерфейс (как и к MySQL) прямо из базы (какие там, кстати, перспективы у SQL/MED в MySQL?).
Но это, разумеется, всё оффтопик. Просто для лучшего понимания.
А «не оффтопик» из этого следующий: поскольку я, как и многие, кто будет критиковать или занимать нейтральную позицию в отношении MySQL, но при этом использовать другие СУБД (читай Mongo, Postgres и дальше по списку) — наверняка будем пользоваться в своих суждениях либо неактуальной информацией, либо особенно важными конкретно для нас слабыми местами MySQL/сильными сторонами других СУБД. Поэтому, если Вы хотите бороться с мифами (читай «евангелизировать MySQL для соответствующей (ангажированной) аудитории»), то как минимум Вам так же необходимо понимать и избавляться от своих заблуждений и мифов в отношении этой аудитории. Соответственно аргументы типа «раз нет, значит это не нужно» («конечно не нужно, ведь есть же %DBMS_NAME%, где всё в шоколаде»), «ряд компаний используют» (с любой DBMS со стажем можно составить немаленький список солидных компаний так или иначе её использующих, а у визави за редким исключением есть опыт перехода с MySQL на нечто для него лучшее и «забывания этого кошмара» ;-)) — аргументами совершенно не являются. Более того с этой позиции в мифах — именно Вы, полагая, что пытаетесь просветить «не разобравшихся в вопросе» (это конечно совершенно не касается детских заблуждений и откровенно устаревших утверждений, но в остальном — самая суть).
Ну и в довесок Вам там ещё комментарий во второй теме :-)
«Длинный список использующих MySQL компаний ничего не значит, потому что они используют MySQL как key-value хранилище»
«Но, если начать копать, то выясняется, что MySQL там з_а_ч_а_с_т_у_ю используется как key-value хранилище».
Я, конечно, понимаю, что взаимоисключающие параграфы разных источников сковались в одну болванку, но всё же, лучше от этого не становится, это больше похоже на борьбу с ветряными мельницами (от которой сами же вроде пытаетесь отговорить), тем более, что следом сами же подтверждаете мой тезис про Facebook и Twitter: «ибо специфика у них такая».
Сам по себе тезис: «Длинный список использующих MySQL компаний ничего не значит» вполне верен в контексте того, что он не доказывает, что эти конторы, имея опыт использования MySQL не выбрали бы тогда или теперь другую СУБД, не обязательно Postgres (и это никак не проверить — «история не любит сослагательное наклонение»), а тем более в контексте «есть много разных сервисов, для каждого — что-то своё». То есть сама постановка вопроса бессмысленна без всех этих уточнений.
В то же время этот длинный список вполне можно интерпретировать и в духе «даже с MySQL можно жить и зарабатывать» (список потенциальных набросов можно долго продолжать, но я надеюсь идея понятна).
Длинный список компаний использующих некоторую СУБД на самом деле задаёт не верхний предел «это лучшая в совокупности характеристик СУБД», а нижний «это не фундаментальный фактор риска для бизнеса — другие достигали успеха, а естественный отбор не убивает тех, кто эту СУБД выбрал, за стабильностью платформы внимательно следят и вкладываются многие, рынок труда изобилует специалистами по данной технологии». Бизнес, на самом деле, интересуют немного другие вещи, чем те, о которых могли бы спорить технические специалисты.
— в разные время суток/дни недели нагрузка может быть сильно разная, можно процедуры вакуума настроить в соответствии: потерпеть распухание днём/в будни и агрессивно почистить ночью/в выходные (вплоть до vacuum full, если ожидается период простоя), но даже отстающий в пиках нагрузки автовакуум будет «нагонять» в периоды спада активности.
— транзакции нужно заканчивать как можно быстрее — это важнее, чем «чистить за собой», поскольку увязание транзакций в блокировках может на корню убить производительность и базы, и приложения в пики нагрузки.
С Postgres нужно понять сначала одну существенную вещь: это НЕ та СУБД, что «настроил и забыл». Postgres — это набор инструментов, граничащий с понятием «фреймворк» в языках программирования. С этого момента наступает просветление и понимание как с ним работать и раскрываются горизонты возможностей. А комплект дефолтных настроек нужен только для одного — убедиться, что демон стартует ;-)
Этот подход не слишком дружественный к новичкам, но значительно более дружественный к профессионалам. Из-за этого и недопонимание, и холивары. Когда про какие-то возможности говорят «здесь это не нужно», в контексте MySQL или Postgres имеют в виду очень разные вещи. В MySQL ориентируются на одно, в Postgres — на другое. Если совсем уже вульгарно: кому-то мыльница, кому-то — профессиональная камера. (На самом деле не хочу сказать, что MySQL — это конкретно «мыльница» — всё-таки за прошедшие годы таки много сделано и определённые фичи — таки круты, а нишу «мыльниц» прочно заняла Mongo; MySQL — это сейчас скорее «крепкий середнячок»).
Это особенно заметно когда одно приложение может работать с несколькими базами, а в одну базу пускают несколько существенно разных приложений и живых пользователей.
На самом деле, тут нужно действительно «пилить» статью-сравнение двух баз в духе «вот так на самом деле прямо здесь и сейчас». Но это уже скорее хорошая статья для энциклопедии.
Автор ссылается на ряд крупных контор, которые используют MySQL, в духе «видите — это реальность, а не legacy». Но, если начать копать, то выясняется, что MySQL там зачастую используется как key-value хранилище. И в принципе было всё-равно, что будет так использоваться в этой роли — кандидатов много, просто MySQL уже был и именно с этой ролью справлялся неплохо, поэтому остался как наследие (история Facebook, Twitter — про других не так наслышан).
Тот же HandlerSocket — с одной стороны индульгенция MySQL — «у нас возможно и такое», с другой — HandlerSocket по-сути отодвигает весь слой MySQL в сторону как ненужный тормозящий хлам, а пускает нас во внутренности движка InnoDB, который на самом деле может сильно больше, чем MySQL ему позволяет.
С обратной стороны — логически некорректно говорить, что в Postgres только один движок, а «финт ушами» вроде HandlerSocket невозможен. Движков на самом деле несколько, но они конкурируют не за роль основного управляющего, а за роль реализаторов специфических запросов и функций. Postgres не менее расширяемый «хранилищами», просто это расширение идёт на другом уровне и более структурировано (те же: колоночное хранилище в памяти или обработчики запросов с вычислениями на GPU) — нет жёсткого ограничения «если используешь это, то нельзя использовать то». И само основное хранилище вполне себе расширяемо — новые типы данных, новые типы индексов, встраиваемые языки — всё это по сути можно создавать (и оно так и создаётся) как плагины. Что-то всем нужное и стабильное — пойдёт в апстрим «из коробки», что-то будет оформлено как комплект стандартных дополнений, что-то придётся искать или создавать самому и встраивать с прямыми руками и напильником.
Поэтому в принципе уже сама постановка вопроса MySQL vs PostgreSQL изначально некорректна, как некорректно сравнивать «широкое с гибким» )) Соответственно все «холивары» идут мимо и скатываются в нечто унылое.
Корректней было бы сравнивать конкретные «фичи» и их комплексы в проекции на решаемые задачи в целом. Сравнить не только наличие фич, но и возможность разные фичи связывать, использовать, настраивать. Интересно рассматривать «бутылочные горлышки», из-за которых важные задачи не решаются и приходится менять целую платформу.
Мы на самом деле видим много отзывов в духе «как я перешёл на Postgres, потому что мне не хватило того-то» и «меня в MySQL всё устраивает, всего хватает», обратные — в природе встречаются настолько редко, что это куда больше создаёт «ореол» MySQL — «пластмассовой машинки в песочнице», из которой дети вырастают и пересаживаются в «автомобиль» Postgres и «выезжают на автобан».
Как видим, общего, на самом деле, больше, чем различий и не так всё страшно.
Если же обсуждать «в MySQL тоже есть», то по поводу автодополнения выше уже прошлись и похоже ситуация за те 7 лет, что я не пользовался им, мало изменилась, что на самом деле факт неприятный, но делает наличие SHOW TABLES и прочих подобных команд востребованным. Вместе с тем это воспитывает соответствующий стиль работы, ломать который тяжело и в итоге поднимается вопрос, «в %СУБД не хватает SHOW TABLES».
Теперь же пару слов про схему.
В документации висит такой комментарий и никто не спешит опровергать, хотя прошло уже шесть лет.
Hans-Henrik Stærfeldt on February 20 2009
The implementation of INFORMATION_SCHEMA can have serious impact on performance of the server. If you have many tables, and query into INFORMATION_SCHEMA without limitations on the schema and if possible the table itself, performance is severely impacted while the query runs.
Здесь на хабре кажется тоже статья пробегала на эту тему. Речь, если не изменяет память шла про версию 5.5 и альфу 5.6, в которой не предвиделось положительных сдвигов. В документации к 5.7 этот вопрос частично затрагивается, упоминается просадка производительности при запросе информации по нескольким базам и рекомендуется такие запросы тюнить.
Наверно это не критичная особенность, утверждать «всё плохо» не буду, хотя ряд ограничений на использование information_schema накладывает.
Я, конечно, не совсем в теме, но краем уха слышал о проблемах с использованием переменных при репликации, возможно это неактуальная информация (или звон совсем не там был, надеюсь кто-то просветит?)
Такие вот вопросы.
В общем, если посмотреть на проблему немного шире, Postgres силён своей расширяемостью — есть вот такие «переменные» http://www.garret.ru/imcs/user_guide.html :-)
Наверно можно что-то попроще и полаконичней нарисовать, если есть такая необходимость.