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 про управление разработкой в продуктовых компаниях.
