24 апреля мы провели онлайн-митап MySQL@Scale, посвященный проблемам масштабируемости MySQL. Участвовали спикеры из Avito, Badoo и ECOMMPAY: Андрей Аксенов (автор Sphinx, лид инфраструктуры поиска), Евгений Кузовлев (CIO ECOMMPAY), Владимир Федорков (MySQL эксперт/DBA в ECOMMPAY) и Николай Королев (MySQL эксперт/DBA в Badoo).
Митап вышел длинным, поэтому мы решили публиковать его частями, и начать с конца — с очень интересной на наш взгляд дискуссии о популярности MySQL и PostgreSQL, причинах роста популярности PostgreSQL, ORM, impedance mismatch, фрактальных индексах, гневе, отрицании, торге и настройке автовакуума и прочих проблемах выбора СУБД разработчиками гостевых книг на NodeJS. Внимание! Имеется не очень цензурная лексика, ряд некорректных обобщений были заменены, а любые совпадения случайны и ни в коем случае не носят оскорбительного характера.
Алексей Рыбак: Возьмём MySQL vs PostgreSQL, не столько просто холивар, сколько вполне измеряемую и видимую вещь. Есть аналитика, я смотрел не только на один показатель. Сейчас в голове вспоминаю две вещи. У нас есть группа в Facebook, про управление и разработку большими проектами. Там несколько тысяч человек. Я проводил опрос PostgreSQL или MySQL, в том числе, кто сloud, не-сloud использует, потому что это тоже такая новая тема, очень горячая в последние несколько лет.
И выяснилось, что Postgres (слегка) опережает MySQL, и для меня это было в принципе достаточно какой-то новой историей, потому что казалось, что пропорция должна быть другой. И есть опросы, которые проводят на конференциях HighLoad, они публиковались. У меня нет прямо системного сравнения год к году, но там прямо четко прослеживалось, что Postgres в какой-то момент по числу ответов на вопрос “какая ваша основная база данных” догнал и перегнал MySQL.
У меня был разговор с Петей Зайцевым. Достаточно давно, может быть, года два назад, он приезжал в Москву. Это, в основном, всё Петины мысли. Мысли такие, что, во-первых, было сделано очень много по внедрению разного рода менеджмент-решений или операторов в cloud-истории. И первоначальный гэп между выбором MySQL или Postgres, он как бы нивелировался, в том смысле, что если у MySQL всё было проще – взял, и оно заработало, то у Postgres должна была быть куча танцев с бубнами сначала для того, чтобы эта штука зажила. А в cloud environment у тебя что: кнопку нажал – все появилось. То есть, с одной стороны, убрался этот гэп. Потом некий общий perception в плане лицензий, проприетарный, не проприетарный, бла-бла-бла, тоже повлияло. Грубо говоря, если совсем упростить, если мне все равно делать это одной кнопкой, я выберу то, что более свободно, ну, или говорят, что “свободно”. По факту не понятно, но, тем не менее. То, что упаковано в идеологически более правильную коробку. Это одна история.
А вторая история заключается в том, что конкретно для России, поскольку я опираюсь на данные все-таки не мировые, а российские, может быть, в мире история немножко другая. Там была такая история, что постгрессники в какой-то момент достаточно сильно объединились, и стали очень сильно пиариться. И создали рабочие группы, и конференции, и уже несколько лет существует компания, которая фактически делает enterprise-решение российское.
Как вы считаете, во-первых, в России, в мире происходит этот ребалансинг между MySQL и Postgres, и, если да, то в чем его причины, насколько его причины, которые я обозначил, они рациональны, разумны, может быть, есть другие причины?
Евгений Кузовлев: Я, честно говоря, никогда не задумывался о том, что облако как бы сглаживает все отличие, наверное, потому что у меня всё on-premise. Для меня облака, это вещи, которые, скажем там, что-нибудь на «амазончик» быстренько давайте засетапим, тогда это для меня облака. Поэтому, с этой стороны я как-то никогда не рассматривал. Но здесь, действительно, сложность снижается.
Раньше, условно, лет восемь назад, для того, чтобы просто у тебя Postgres заработал, надо было настолько с бубном потанцевать, что прямо вот мама не горюй. А MySQL ты ставил из коробки и он у тебя работал. Может быть, не восемь, может быть, лет 10-12 назад. Действительно, эта сложность в Postgres была сильно снижена, и точка такого входа эксплуатационного и разработческого, она была сравнена с MySQL в каком-то плане.
Но я, например, для себя, мы решали такую задачу, я постарался подойти, и стараюсь подойти максимально отстраненно. Нам нужно было, когда мы стартовали DWH, подобрать движок под денормализованную таблицу. При этом там никакой аналитики нет, аналитика там немножко на другом уровне. Там просто чисто хранение. Нужна была революционная СУБД, чтобы обеспечить, соответственно, анализ сравнения данных.
И мы подходили к этому вопросу MySQL или Postgres, и при том, что эксплуатационные ресурсы достаточно высококвалифицированные, мы выбирали. И у меня, например, сложилось такое впечатление, что Postgres, он такой, знаешь, академический. Как написано в учебнике, так он и будет работать. А MySQL, он какой-то достаточно легкий и с кучей хаков. Но при этом, эти хаки работают в 99% случаев. И сколько бы ребята из Postgres не давали синтетические бенчмарки, в реальных ситуациях, которые покрывают 99% реального использования баз данных, MySQL у обычных пользователей выигрывает.
И плюс, реально, черт подери, это прямо огромный плюс MySQL, что у него нет автовакуума. Потому что настроить эту штуку в Postgres, это не каждый сможет. А как только пользователи…
Владимир Федорков: Звучит подло (по отношению к инженерам — прим. АР).
Евгений Кузовлев: А как только пользователи упираются в автовакуум, они начинают испытывать дичайшие проблемы. То есть просто так ни с фига получить деградацию системы процентов на 60, такое себе, это…
Алексей Рыбак: Нет, просто с козырей зашел.
Евгений Кузовлев: Ну, прости. Сразу выложил как бы на стол. При этом я знаю, безусловно, у нас есть Postgres. У нас его достаточно много. У нас проблем с автовакуумом, слава Богу, нет. Но я в своей карьере прошел все эти случаи – гнев, отрицание, торг и настройка автовакуума. Но это такое болезненное ощущение, я вам скажу. Вот MySQL не доставляет столько боли.
При этом я дико бешусь из-за того, что в MySQL у меня нет возможности… Я хочу, но, вот у меня есть B-tree индекс и все. И хоть ты тресни! Я, не знаю, не могу построить просто…
Алексей Рыбак: Хэш-индексы есть.
Евгений Кузовлев: Есть. Но, давай сравним количество индексов, которые у нас есть в MySQL, и количество индексов, которые у нас есть в Postgres. Это несравнимо. При этом в обратную сторону можно сказать и про движки таблиц. У MySQL у нас есть движок таблиц, ты хочешь, не знаю, пойдешь, возьмешь какую-нибудь TokuDB, и будешь радостно в одном проценте случаев наслаждаться и в 99% случаев не понимать, зачем ты его взял…
Андрей Аксёнов: Фракталами обмазаться.
Алексей Рыбак: Ну, погоди, с движками тоже это обман. Раньше, когда это было придумано, это казалось прикольной штукой. Но по факту-то, ничего особо не прижилось.
Андрей Аксёнов: Почему не прижилось? InnoDB прижился.
Алексей Рыбак: Нет, я имею в виду, помимо InnoDB. То есть InnoDB стал просто стандартом. А все остальные истории с колоночными штуками, с какими-то более специфичными штуками, типа Toku. Ты прав, даже не знаю, где этот процент. То есть движки оказалась такой сомнительной штукой.
Евгений Кузовлев: Знаешь, человеческая психология, она такова, что иногда сама возможность выбора важнее самого выбора. MySQL это дает.
Алексей Рыбак: Люди не выбирают MySQL против Postgres, потому что там есть разные движки. Мне кажется, это последнее…
Владимир Федорков: Потому что, когда люди выбирают MySQL против Postgres, если есть хоть кто-то в компании, кто за Postgres, он будет выбран, потому что это религия.
Алексей Рыбак: MySQL тоже религия.
Владимир Федорков: Нет, ни в коем случае.
Андрей Аксёнов: Еще один немаловажный момент никто не набросил, под названием “контингент дорос". Требования натурально доросли в определенном слое. Изначальный вопрос вспомним, почему процент Postgres растет, процент этой вашей убогой подделки под названием MySQL снижается неуклонно. И, конечно же, в итоге в принципе все равно та планета, затопчут динозавры и MongoDB всех победит. Но это еще в более будущем. Но webscale все же важно, потому что реально требования, которые приложения предъявляют, они меняются во времени, – раз, и в один прекрасный момент и Postgres дорос, со своей стороны, и набор требований от разработчиков дорос с их стороны.
Алексей Рыбак: Слушай, я не верю, прости. Скажи, давай конкретно…
Андрей Аксёнов: Давай конкретно. Смотри, 1995 год…
Алексей Рыбак: Компании, которые изначально запустили продукты webscale, которые предназначены, тех же чуваков… Господи, вылетело из головы! Только что называл… Сейчас, вот кто победит всех…
Андрей Аксёнов: Mongo победит.
Алексей Рыбак: Mongo, да-да-да, sorry, да. Значит, у Mongo изначально было две вещи. Первое, объектный store, не думай, короче, ORM, просто пиши, сохраняй и ничего не надо, SQL знать не надо, короче, все. Это привело одних чуваков, у них требования не изменились, они просто: да, а так можно было, SQL не учить, вау! Классно как! Просто сказал: сохрани объект, и он мне куда-то уехал, класс! Это первое.
Второе, что? Про fault tolerance не думай, мы изначально умеем в несколько ДЦ и так далее. Сначала это был marketing bullshit. Потом они чего-то подкрутили, и в принципе, я так понимаю, что в последних версиях сейчас (работает и) много где действительно в больших инсталляциях используется Mongo.
Я к тому, что вот это хороший пример, когда у тебя выходит на рынок, на другой рынок, прощупав эти две возможности, что, во-первых, народ, который вырос в парадигме программирования на объектных языках, вообще ему вот этот impedance mismatch, это фундаментальная история. Для них проще использовать инструменты, которые говорят: да просто сохрани “в меня”, я тебе все сделаю. И одновременно, из коробки такие вещи, связанные с очередью, и еще чем-то.
Здесь я бы понял, несмотря на то, что опять же говорю, ты троллил, ты поставил это, как некий такой гиперболизированный, условно говоря, кейс, фантастику какую-то. Тем не менее, вот этот кейс, он говорит ровно об этом, что можно выйти с таким продуктом, найти такую нишу, и он взлетит, попрет, взорвет. А что такое предложил Postgres, или как изменились и какие требования, что Postgres вдруг, согласно твоей логике, стал настолько привлекательным, не понимаю.
Андрей Аксёнов: Я еще раз повторяю. Доросли с обоих сторон; Postgres по определенным параметрам, с одной стороны, и разработчики по определенным параметрам, с другой стороны. Еще раз, 1995 год. Ты разработчик. Ты сидишь в Б… (Атырау), зарабатываешь 15 долларов, и это в год. И ты пишешь c***** (никчемную) гостевую книгу на Perl. И тут у тебя встает процесс выбора – какую же базу данных выбрать. Удивительно, но и MySQL, и Postgres уже есть. А если их нет, то они появятся в 1996 году. Но ты, с*** (самка семейства псовых), разработчик гостевой книги на Perl в Б… (Сызрани)! У тебя задача вот такого масштаба, ты их решаешь.
Единственный бенчмарк, о котором ты можешь подумать, это сколько «на круг» запросов в секунду ты прососешь. А «на круг» запросов в секунду в этот момент Postgres просасывает в четыре с половиной раза меньше. Просто вот так, just because f*** you. После этого ты смотришь: ну, да, но в Postgres транзакции, а в MySQL 3,23 MyISAM. Но, честно говоря, транзакции для моей гостевой книги мне н**** (вовсе) не нужны. Решительно выбираем MySQL.
Теперь прошло немного времени, 25 лет. Ты в принципе, по-прежнему живешь в Б… (Туймазы), пишешь ты уже не на Perl, а на NodeJS, зарплата у тебя проиндексировалась, потому что просто долларовая инфляция, и теперь составляет 15 долларов, помножить на инфляцию, – 45, и это в месяц. Проблемы у тебя те же самые, плюс 100500 пакетов в NodeJS. А этим 100500 пакетам NodeJS надо куда-то весь свой стейт хранить, сложные запросы про пакетный менеджер и так далее.
И вот у тебя внезапно требования твои, которые ты прикукоживаешь к базе данных, немного подросли. Ты, например, почему-то без транзакций жить не можешь и не хочешь. Какое удивительное совпадение! Джоины тебе по-прежнему нужны. Вот некоторые про какие-то индексы странные начинают задумываться, а не только лишь автоматическим B-tree, такие: о, блин! А было бы неплохо географический индекс иметь, R-tree какой-нибудь, или, допустим, спаси Господи, фрактальные деревья.
Это изменился набор требований со стороны разработчиков, раз. И с другой стороны, Postgres, который в годы древние натурально просто феерично тормозил на простеньких «кругах» (запросов), которые в тупую и были нужны всем подряд, он сильно улучшился за истекший небольшой срок в 25 лет, со своей стороны. И вот так они и встретились внезапно, и все больше и больше народу с удивлением обнаруживает, что, оп! Ты глянь! А Postgres-то как бы не так плох, оказывается! И несколько лучше на мои требования укладывается. Моя гипотеза ровно вот такая, что, грубо говоря, в момент старта MySQL…
Алексей Рыбак: Слушай, но я не понимаю, где лучше? В чем лучше-то? Я понимаю, что они сравнялись в чем-то, но в чем лучше, я не понимаю.
Андрей Аксёнов: Так они оба хуже.
Алексей Рыбак: Чем Mongo?
Андрей Аксёнов: Конечно, чем, в кавычках, «Mongo». Но это тема для целого отдельного разговора, и целая отдельная ветка разговора под названием «а где же светлое будущее».
Владимир Федорков: Нет светлого будущего. База данных – зло. Как только ты выбираешь базу данных, ты подписываешь себе смертный приговор. Не используйте базы данных. Файлы пишите.
Алексей Рыбак: /dev/null! Пишите в /dev/null, друзья, dev/null is web scale.
Андрей Аксёнов: Да. Ну, ладно, можно и в /dev/null упереться в принципе по перформансу, мы умеем.
Алексей Рыбак: Ладно, друзья. Все уже, наверное, очень устали. Мы говорим уже больше двух часов.
Андрей Аксёнов: А по-настоящему интересные вопросы, так и не затронули.
Николай Королёв: Только начали.
Алексей Рыбак: Серьезно? Вы хотите продолжить?
Андрей Аксёнов: Я еще и виски не налил.
Алексей Рыбак: А вот это большой вопрос, почему ты этого не сделал.
Андрей Аксёнов: Не подготовился, конечно…
Владимир Федорков: Так сказали, что трансляция, трансляция, ничего нельзя, матом нельзя, бухать нельзя.
Алексей Рыбак: А! Друзья! Все, кто сидел на трансляции, спасибо вам большое, что вы были с нами. Мы начинаем неофициальную часть, где же тут выключается… Сейчас… убираю Live stream. Спасибо всем большое, спасибо нашим гостям, – Владимир, Андрей, Евгений, Николай. Stream выключаем, до свидания, до новых встреч.
(конец записи)
Полную запись митапа можно посмотреть на youtube:
В ближайшее время мы также опубликуем другие части, посвященные инфраструктуре, паттернам масштабирования/отказоустойчивости и состоянию эко-системы MySQL.
Если вам нравится такой формат, то уже в эту пятницу состоится очередной митап, посвященный контейнерной инфраструктуре, на него ещё есть места. Участвуют: Евгений Потапов (CEO «ITSumma»), Дмитрий Столяров (CTO «Флант»), Денис Ремчуков (aka Eric Oldmann, COO argotech.io, ex – РАО ЕЭС России), Андрей Федоровский (CTO «News360.com») и Иван Круглов (системный инженер, ex – Booking.com). Поговорим об инструментах, проблемах и перспективах контейнеров и Kubernetes в современной инфраструктуре.
Ещё у нас есть упомянутая фейсбук-группа «Управление и разработка крупных IT-проектов», канал @feedmeto с интересными публикациями из корпоративных (преимущественно забугорных) техно-блогов, и канал автора @rybakalexey про управление разработкой в продуктовых компаниях.
Митап вышел длинным, поэтому мы решили публиковать его частями, и начать с конца — с очень интересной на наш взгляд дискуссии о популярности MySQL и PostgreSQL, причинах роста популярности PostgreSQL, ORM, impedance mismatch, фрактальных индексах, гневе, отрицании, торге и настройке автовакуума и прочих проблемах выбора СУБД разработчиками гостевых книг на NodeJS. Внимание! Имеется не очень цензурная лексика, ряд некорректных обобщений были заменены, а любые совпадения случайны и ни в коем случае не носят оскорбительного характера.
Алексей Рыбак: Возьмём MySQL vs PostgreSQL, не столько просто холивар, сколько вполне измеряемую и видимую вещь. Есть аналитика, я смотрел не только на один показатель. Сейчас в голове вспоминаю две вещи. У нас есть группа в Facebook, про управление и разработку большими проектами. Там несколько тысяч человек. Я проводил опрос PostgreSQL или MySQL, в том числе, кто сloud, не-сloud использует, потому что это тоже такая новая тема, очень горячая в последние несколько лет.
И выяснилось, что Postgres (слегка) опережает MySQL, и для меня это было в принципе достаточно какой-то новой историей, потому что казалось, что пропорция должна быть другой. И есть опросы, которые проводят на конференциях HighLoad, они публиковались. У меня нет прямо системного сравнения год к году, но там прямо четко прослеживалось, что Postgres в какой-то момент по числу ответов на вопрос “какая ваша основная база данных” догнал и перегнал MySQL.
У меня был разговор с Петей Зайцевым. Достаточно давно, может быть, года два назад, он приезжал в Москву. Это, в основном, всё Петины мысли. Мысли такие, что, во-первых, было сделано очень много по внедрению разного рода менеджмент-решений или операторов в cloud-истории. И первоначальный гэп между выбором MySQL или Postgres, он как бы нивелировался, в том смысле, что если у MySQL всё было проще – взял, и оно заработало, то у Postgres должна была быть куча танцев с бубнами сначала для того, чтобы эта штука зажила. А в cloud environment у тебя что: кнопку нажал – все появилось. То есть, с одной стороны, убрался этот гэп. Потом некий общий perception в плане лицензий, проприетарный, не проприетарный, бла-бла-бла, тоже повлияло. Грубо говоря, если совсем упростить, если мне все равно делать это одной кнопкой, я выберу то, что более свободно, ну, или говорят, что “свободно”. По факту не понятно, но, тем не менее. То, что упаковано в идеологически более правильную коробку. Это одна история.
А вторая история заключается в том, что конкретно для России, поскольку я опираюсь на данные все-таки не мировые, а российские, может быть, в мире история немножко другая. Там была такая история, что постгрессники в какой-то момент достаточно сильно объединились, и стали очень сильно пиариться. И создали рабочие группы, и конференции, и уже несколько лет существует компания, которая фактически делает enterprise-решение российское.
Как вы считаете, во-первых, в России, в мире происходит этот ребалансинг между MySQL и Postgres, и, если да, то в чем его причины, насколько его причины, которые я обозначил, они рациональны, разумны, может быть, есть другие причины?
Евгений Кузовлев: Я, честно говоря, никогда не задумывался о том, что облако как бы сглаживает все отличие, наверное, потому что у меня всё on-premise. Для меня облака, это вещи, которые, скажем там, что-нибудь на «амазончик» быстренько давайте засетапим, тогда это для меня облака. Поэтому, с этой стороны я как-то никогда не рассматривал. Но здесь, действительно, сложность снижается.
Раньше, условно, лет восемь назад, для того, чтобы просто у тебя Postgres заработал, надо было настолько с бубном потанцевать, что прямо вот мама не горюй. А MySQL ты ставил из коробки и он у тебя работал. Может быть, не восемь, может быть, лет 10-12 назад. Действительно, эта сложность в Postgres была сильно снижена, и точка такого входа эксплуатационного и разработческого, она была сравнена с MySQL в каком-то плане.
Но я, например, для себя, мы решали такую задачу, я постарался подойти, и стараюсь подойти максимально отстраненно. Нам нужно было, когда мы стартовали DWH, подобрать движок под денормализованную таблицу. При этом там никакой аналитики нет, аналитика там немножко на другом уровне. Там просто чисто хранение. Нужна была революционная СУБД, чтобы обеспечить, соответственно, анализ сравнения данных.
И мы подходили к этому вопросу MySQL или Postgres, и при том, что эксплуатационные ресурсы достаточно высококвалифицированные, мы выбирали. И у меня, например, сложилось такое впечатление, что Postgres, он такой, знаешь, академический. Как написано в учебнике, так он и будет работать. А MySQL, он какой-то достаточно легкий и с кучей хаков. Но при этом, эти хаки работают в 99% случаев. И сколько бы ребята из Postgres не давали синтетические бенчмарки, в реальных ситуациях, которые покрывают 99% реального использования баз данных, MySQL у обычных пользователей выигрывает.
И плюс, реально, черт подери, это прямо огромный плюс MySQL, что у него нет автовакуума. Потому что настроить эту штуку в Postgres, это не каждый сможет. А как только пользователи…
Владимир Федорков: Звучит подло (по отношению к инженерам — прим. АР).
Евгений Кузовлев: А как только пользователи упираются в автовакуум, они начинают испытывать дичайшие проблемы. То есть просто так ни с фига получить деградацию системы процентов на 60, такое себе, это…
Алексей Рыбак: Нет, просто с козырей зашел.
Евгений Кузовлев: Ну, прости. Сразу выложил как бы на стол. При этом я знаю, безусловно, у нас есть Postgres. У нас его достаточно много. У нас проблем с автовакуумом, слава Богу, нет. Но я в своей карьере прошел все эти случаи – гнев, отрицание, торг и настройка автовакуума. Но это такое болезненное ощущение, я вам скажу. Вот MySQL не доставляет столько боли.
При этом я дико бешусь из-за того, что в MySQL у меня нет возможности… Я хочу, но, вот у меня есть B-tree индекс и все. И хоть ты тресни! Я, не знаю, не могу построить просто…
Алексей Рыбак: Хэш-индексы есть.
Евгений Кузовлев: Есть. Но, давай сравним количество индексов, которые у нас есть в MySQL, и количество индексов, которые у нас есть в Postgres. Это несравнимо. При этом в обратную сторону можно сказать и про движки таблиц. У MySQL у нас есть движок таблиц, ты хочешь, не знаю, пойдешь, возьмешь какую-нибудь TokuDB, и будешь радостно в одном проценте случаев наслаждаться и в 99% случаев не понимать, зачем ты его взял…
Андрей Аксёнов: Фракталами обмазаться.
Алексей Рыбак: Ну, погоди, с движками тоже это обман. Раньше, когда это было придумано, это казалось прикольной штукой. Но по факту-то, ничего особо не прижилось.
Андрей Аксёнов: Почему не прижилось? InnoDB прижился.
Алексей Рыбак: Нет, я имею в виду, помимо InnoDB. То есть InnoDB стал просто стандартом. А все остальные истории с колоночными штуками, с какими-то более специфичными штуками, типа Toku. Ты прав, даже не знаю, где этот процент. То есть движки оказалась такой сомнительной штукой.
Евгений Кузовлев: Знаешь, человеческая психология, она такова, что иногда сама возможность выбора важнее самого выбора. MySQL это дает.
Алексей Рыбак: Люди не выбирают MySQL против Postgres, потому что там есть разные движки. Мне кажется, это последнее…
Владимир Федорков: Потому что, когда люди выбирают MySQL против Postgres, если есть хоть кто-то в компании, кто за Postgres, он будет выбран, потому что это религия.
Алексей Рыбак: MySQL тоже религия.
Владимир Федорков: Нет, ни в коем случае.
Андрей Аксёнов: Еще один немаловажный момент никто не набросил, под названием “контингент дорос". Требования натурально доросли в определенном слое. Изначальный вопрос вспомним, почему процент Postgres растет, процент этой вашей убогой подделки под названием MySQL снижается неуклонно. И, конечно же, в итоге в принципе все равно та планета, затопчут динозавры и MongoDB всех победит. Но это еще в более будущем. Но webscale все же важно, потому что реально требования, которые приложения предъявляют, они меняются во времени, – раз, и в один прекрасный момент и Postgres дорос, со своей стороны, и набор требований от разработчиков дорос с их стороны.
Алексей Рыбак: Слушай, я не верю, прости. Скажи, давай конкретно…
Андрей Аксёнов: Давай конкретно. Смотри, 1995 год…
Алексей Рыбак: Компании, которые изначально запустили продукты webscale, которые предназначены, тех же чуваков… Господи, вылетело из головы! Только что называл… Сейчас, вот кто победит всех…
Андрей Аксёнов: Mongo победит.
Алексей Рыбак: Mongo, да-да-да, sorry, да. Значит, у Mongo изначально было две вещи. Первое, объектный store, не думай, короче, ORM, просто пиши, сохраняй и ничего не надо, SQL знать не надо, короче, все. Это привело одних чуваков, у них требования не изменились, они просто: да, а так можно было, SQL не учить, вау! Классно как! Просто сказал: сохрани объект, и он мне куда-то уехал, класс! Это первое.
Второе, что? Про fault tolerance не думай, мы изначально умеем в несколько ДЦ и так далее. Сначала это был marketing bullshit. Потом они чего-то подкрутили, и в принципе, я так понимаю, что в последних версиях сейчас (работает и) много где действительно в больших инсталляциях используется Mongo.
Я к тому, что вот это хороший пример, когда у тебя выходит на рынок, на другой рынок, прощупав эти две возможности, что, во-первых, народ, который вырос в парадигме программирования на объектных языках, вообще ему вот этот impedance mismatch, это фундаментальная история. Для них проще использовать инструменты, которые говорят: да просто сохрани “в меня”, я тебе все сделаю. И одновременно, из коробки такие вещи, связанные с очередью, и еще чем-то.
Здесь я бы понял, несмотря на то, что опять же говорю, ты троллил, ты поставил это, как некий такой гиперболизированный, условно говоря, кейс, фантастику какую-то. Тем не менее, вот этот кейс, он говорит ровно об этом, что можно выйти с таким продуктом, найти такую нишу, и он взлетит, попрет, взорвет. А что такое предложил Postgres, или как изменились и какие требования, что Postgres вдруг, согласно твоей логике, стал настолько привлекательным, не понимаю.
Андрей Аксёнов: Я еще раз повторяю. Доросли с обоих сторон; Postgres по определенным параметрам, с одной стороны, и разработчики по определенным параметрам, с другой стороны. Еще раз, 1995 год. Ты разработчик. Ты сидишь в Б… (Атырау), зарабатываешь 15 долларов, и это в год. И ты пишешь c***** (никчемную) гостевую книгу на Perl. И тут у тебя встает процесс выбора – какую же базу данных выбрать. Удивительно, но и MySQL, и Postgres уже есть. А если их нет, то они появятся в 1996 году. Но ты, с*** (самка семейства псовых), разработчик гостевой книги на Perl в Б… (Сызрани)! У тебя задача вот такого масштаба, ты их решаешь.
Единственный бенчмарк, о котором ты можешь подумать, это сколько «на круг» запросов в секунду ты прососешь. А «на круг» запросов в секунду в этот момент Postgres просасывает в четыре с половиной раза меньше. Просто вот так, just because f*** you. После этого ты смотришь: ну, да, но в Postgres транзакции, а в MySQL 3,23 MyISAM. Но, честно говоря, транзакции для моей гостевой книги мне н**** (вовсе) не нужны. Решительно выбираем MySQL.
Теперь прошло немного времени, 25 лет. Ты в принципе, по-прежнему живешь в Б… (Туймазы), пишешь ты уже не на Perl, а на NodeJS, зарплата у тебя проиндексировалась, потому что просто долларовая инфляция, и теперь составляет 15 долларов, помножить на инфляцию, – 45, и это в месяц. Проблемы у тебя те же самые, плюс 100500 пакетов в NodeJS. А этим 100500 пакетам NodeJS надо куда-то весь свой стейт хранить, сложные запросы про пакетный менеджер и так далее.
И вот у тебя внезапно требования твои, которые ты прикукоживаешь к базе данных, немного подросли. Ты, например, почему-то без транзакций жить не можешь и не хочешь. Какое удивительное совпадение! Джоины тебе по-прежнему нужны. Вот некоторые про какие-то индексы странные начинают задумываться, а не только лишь автоматическим B-tree, такие: о, блин! А было бы неплохо географический индекс иметь, R-tree какой-нибудь, или, допустим, спаси Господи, фрактальные деревья.
Это изменился набор требований со стороны разработчиков, раз. И с другой стороны, Postgres, который в годы древние натурально просто феерично тормозил на простеньких «кругах» (запросов), которые в тупую и были нужны всем подряд, он сильно улучшился за истекший небольшой срок в 25 лет, со своей стороны. И вот так они и встретились внезапно, и все больше и больше народу с удивлением обнаруживает, что, оп! Ты глянь! А Postgres-то как бы не так плох, оказывается! И несколько лучше на мои требования укладывается. Моя гипотеза ровно вот такая, что, грубо говоря, в момент старта MySQL…
Алексей Рыбак: Слушай, но я не понимаю, где лучше? В чем лучше-то? Я понимаю, что они сравнялись в чем-то, но в чем лучше, я не понимаю.
Андрей Аксёнов: Так они оба хуже.
Алексей Рыбак: Чем Mongo?
Андрей Аксёнов: Конечно, чем, в кавычках, «Mongo». Но это тема для целого отдельного разговора, и целая отдельная ветка разговора под названием «а где же светлое будущее».
Владимир Федорков: Нет светлого будущего. База данных – зло. Как только ты выбираешь базу данных, ты подписываешь себе смертный приговор. Не используйте базы данных. Файлы пишите.
Алексей Рыбак: /dev/null! Пишите в /dev/null, друзья, dev/null is web scale.
Андрей Аксёнов: Да. Ну, ладно, можно и в /dev/null упереться в принципе по перформансу, мы умеем.
Алексей Рыбак: Ладно, друзья. Все уже, наверное, очень устали. Мы говорим уже больше двух часов.
Андрей Аксёнов: А по-настоящему интересные вопросы, так и не затронули.
Николай Королёв: Только начали.
Алексей Рыбак: Серьезно? Вы хотите продолжить?
Андрей Аксёнов: Я еще и виски не налил.
Алексей Рыбак: А вот это большой вопрос, почему ты этого не сделал.
Андрей Аксёнов: Не подготовился, конечно…
Владимир Федорков: Так сказали, что трансляция, трансляция, ничего нельзя, матом нельзя, бухать нельзя.
Алексей Рыбак: А! Друзья! Все, кто сидел на трансляции, спасибо вам большое, что вы были с нами. Мы начинаем неофициальную часть, где же тут выключается… Сейчас… убираю Live stream. Спасибо всем большое, спасибо нашим гостям, – Владимир, Андрей, Евгений, Николай. Stream выключаем, до свидания, до новых встреч.
(конец записи)
Полную запись митапа можно посмотреть на youtube:
В ближайшее время мы также опубликуем другие части, посвященные инфраструктуре, паттернам масштабирования/отказоустойчивости и состоянию эко-системы MySQL.
Если вам нравится такой формат, то уже в эту пятницу состоится очередной митап, посвященный контейнерной инфраструктуре, на него ещё есть места. Участвуют: Евгений Потапов (CEO «ITSumma»), Дмитрий Столяров (CTO «Флант»), Денис Ремчуков (aka Eric Oldmann, COO argotech.io, ex – РАО ЕЭС России), Андрей Федоровский (CTO «News360.com») и Иван Круглов (системный инженер, ex – Booking.com). Поговорим об инструментах, проблемах и перспективах контейнеров и Kubernetes в современной инфраструктуре.
Ещё у нас есть упомянутая фейсбук-группа «Управление и разработка крупных IT-проектов», канал @feedmeto с интересными публикациями из корпоративных (преимущественно забугорных) техно-блогов, и канал автора @rybakalexey про управление разработкой в продуктовых компаниях.
