Комментарии 41
Простите, честно не читал предыдущих статей про архитектуру Badoo, но из краткого описания, приведенного здесь, создается четкое впечатление, что большинство данных вообще никак не резервируется. Это такая специальная политика (фича) или упущение со стороны архитекторов (бага)?
У нас есть репликация данных в MySQL — мы реплицируем все DML-запросы с одного датацентра на другой, так что у нас всегда есть «горячий бэкап» данных в MySQL. Также мы делаем полный бэкап данных раз в неделю. Про фотографии, можно, подскажет antonstepanenko
Суммарно сколько информации (гигабайт, терабайт?) пришлось перекинуть между датацентрами?
Сами себе придумали проблему. Почему нельзя было неделю переносить каждую ночь по 1 млн. пользователей? В худшем случае пользователь, зашедший в 05.00 увидел надпись «Сервис обновляется» на 2-3 минуты…
Не совсем понимаю вас. Мы переносили по примерно одному миллиону пользователей в день (в это время у этих пользователей была ночь). Каждый из переносимых пользователей в течении 2-3 минут при попытке логина наблюдал надпись «Сервис недоступен».
«Как мы мигрировали миллионные страны за рабочий день» что то здесь не так
Рабочий день — это 8 часов плюс перерыв на обед. В статье исходя из этого была приведена примерная скорость — 170 000 пользователей в час. Где вы видите несоответствие?
Долго не могла понять смысл заголовка. Ребята — вы, наверное, прекрасные специалисты в своём деле, но нельзя же так коверкать русский язык. «Мигрировать» — это непереходный глагол, его нельзя использовать с существительным/местоимением в винительном падеже без предлога: невозможно кого-то мигрировать.
Далее, страны вы никуда не перемещали, перемещали пользователей — а это совсем не одно и то же. Ну и оборот «за рабочий день» подразумевает именно один-единственный рабочий день.
Правильным построением фразы было бы: «Как мы переносили между серверами по миллиону пользователей в день».
Далее, страны вы никуда не перемещали, перемещали пользователей — а это совсем не одно и то же. Ну и оборот «за рабочий день» подразумевает именно один-единственный рабочий день.
Правильным построением фразы было бы: «Как мы переносили между серверами по миллиону пользователей в день».
Если уж быть настолько принципиальным, тогда и пользователей они не переносили из одного дата-центра в другой, а только данные, касающиеся пользователей из определенной страны. Но суть из заголовка, думаю, ясна для людей из мира ИТ, ведь у них (и у нас) свой сленг…
1.А при чем тут сленг, если по-русски так нельзя говорить. Вообще нельзя.
2.Суть из заголовка ясна только после прочтения статьи. То есть НЕ ясна.
3. Если быть принципиальным как вы предлагаете, то слово миграция тут неуместно (это уже кроме того, что нарушены нормы языка), так как речь идет о переносе, а миграция — это переход
4. Нормально и понятно — Как мы переносили с сервера на сервер по миллиону учетных записей пользователей (аккаунтов) в день.
2.Суть из заголовка ясна только после прочтения статьи. То есть НЕ ясна.
3. Если быть принципиальным как вы предлагаете, то слово миграция тут неуместно (это уже кроме того, что нарушены нормы языка), так как речь идет о переносе, а миграция — это переход
4. Нормально и понятно — Как мы переносили с сервера на сервер по миллиону учетных записей пользователей (аккаунтов) в день.
Да, любителям русского языка суть статьи не ясна, с этим сложно спорить. Можно ли поподробнее про п.3? Потому что педивикия сообщает: «комп., жарг. переход с одной программной платформы на другую » ru.wiktionary.org/wiki/%D0%BC%D0%B8%D0%B3%D1%80%D0%B0%D1%86%D0%B8%D1%8F
Да, любителям русского языка суть статьи не ясна, с этим сложно спорить.
Речь шла о том, что:
1)из заголовка не понятно о чем речь. О сути статьи речи нигде не было? Или я что-то упустил? Тогда поправьте меня (с цитатами)
2)еще речь шла о том, что в русском языке нельзя мигрировать кого-то или что-то. Можно мигрировать куда-то или мигрировать «С» (откуда) «НА» (куда)
3)по пункту 3: ну вроде же подробнее некуда — я написал, что миграция — это переход, если иметь ввиду жаргон ИТ. В приведенной вами ссылке то же самое:
комп., жарг. переход с одной программной платформы на другую
Хотя миграция — это действительно уход на другую платформу. То есть это слово в заголовке употреблено некорректно.
Речь шла о том, что:
1)из заголовка не понятно о чем речь. О сути статьи речи нигде не было? Или я что-то упустил? Тогда поправьте меня (с цитатами)
2)еще речь шла о том, что в русском языке нельзя мигрировать кого-то или что-то. Можно мигрировать куда-то или мигрировать «С» (откуда) «НА» (куда)
3)по пункту 3: ну вроде же подробнее некуда — я написал, что миграция — это переход, если иметь ввиду жаргон ИТ. В приведенной вами ссылке то же самое:
комп., жарг. переход с одной программной платформы на другую
Хотя миграция — это действительно уход на другую платформу. То есть это слово в заголовке употреблено некорректно.
«2. Суть из заголовка ясна только после прочтения статьи» — вот здесь я грешным делом подумал, что речь идёт о сути статьи, но теперь я вижу, что ошибался. Здесь идёт речь просто у сути. Поправьте меня, если я не прав.
Компьютерный жаргон является частью русского языка?
Я как бы не спорю, с Вами в части, что Вам «Суть из заголовка ясна… То есть НЕ ясна»
Компьютерный жаргон является частью русского языка?
Я как бы не спорю, с Вами в части, что Вам «Суть из заголовка ясна… То есть НЕ ясна»
Есть два и более вариантов заголовка:
1.Как мы мигрировали миллионные страны за рабочий день (оригинальный, но некорректный)
2. Как мы переносили с сервера на сервер по миллиону учетных записей пользователей (аккаунтов) в день. (алтернативный)
1)нельзя мигрировать кого-то (это непереходный глагол).Можно мигрировать куда-то или мигрировать «С» (откуда) «НА» (куда)
2)из оригинального заголовка нельзя понять о чем статья
3)из альтернативного — можно, даже не читая статьи, так как в нем которотко изложена суть процесса
4)оригинальный заголовок «не дружит» с русским языком
5)в оригинальном заголовке некорректно употреблен термин миграция, так как это- ПЕРЕХОД, а суть статьи — ПЕРЕНОС (данных)
6)жаргон является частью языка, безусловно
1.Как мы мигрировали миллионные страны за рабочий день (оригинальный, но некорректный)
2. Как мы переносили с сервера на сервер по миллиону учетных записей пользователей (аккаунтов) в день. (алтернативный)
1)нельзя мигрировать кого-то (это непереходный глагол).Можно мигрировать куда-то или мигрировать «С» (откуда) «НА» (куда)
2)из оригинального заголовка нельзя понять о чем статья
3)из альтернативного — можно, даже не читая статьи, так как в нем которотко изложена суть процесса
4)оригинальный заголовок «не дружит» с русским языком
5)в оригинальном заголовке некорректно употреблен термин миграция, так как это- ПЕРЕХОД, а суть статьи — ПЕРЕНОС (данных)
6)жаргон является частью языка, безусловно
А расскажите пожалуйста поподробнее про существующую репликацию данных и фото между ДЦ
Ребята, я вас люблю!
PHP+MySQL в таком масштабе, подробнейшие образовательные проекты, статьи — спасибище!
PHP+MySQL в таком масштабе, подробнейшие образовательные проекты, статьи — спасибище!
А вы не думали мигрировать с MySQL на MariaDB? И если нет, то чем объясняется?
Думали, и пока думаем. Причины две: (1) стоимость перехода, риски и (2) неопределенность на рынке.
1) Badoo — проект с одним из крупнейших в мире кластеров БД — много сотен серверов. Поэтому стоимость любого проекта по миграции будет для нас очень высока.
2) Мы используем дистрибутив Percona. За последний год-полтора развернулась плотная борьба трех дистрибутивов MySQL. Три-четыре года назад (когда мы пересели на Percona) был вечно-тормозящий с патчами Oracle (заблудившийся в бранче 6.0, с массовым исходом окешихся и не очень сотрудников), странная Maria и слизанный с Oracle, но не тормозящий со сторонними патчами XtraDB. Теперь же многое поменялось. Сейчас мы видим, что Percona реально отстаёт. И очень хорошо набирает Oracle (я где-то читал, что у них уже работает под 200 человек над MySQL уже). У нас также есть свой патч (его сделал Костя Осипов, это фикс давнишней проблемы со вложенными пользовательскими блокировками), — этот патч, кстати, быстро приняла только Maria. Oracle и Percona тупят. То есть сигналы о том, что Maria хороша — они идут где-то последние полгода. Плюс неожиданная поддержка гигантов (вероятнее всего когда они поняли, что Oracle очень хорошо прёт). Но и Oracle не отстает. Так что скорее всего мы немного подождем, посмотрим, что происходит, как будет реагировать Percona. Для нас если уж делать переход, то года на три, а то и на пять. Очень важный шаг.
1) Badoo — проект с одним из крупнейших в мире кластеров БД — много сотен серверов. Поэтому стоимость любого проекта по миграции будет для нас очень высока.
2) Мы используем дистрибутив Percona. За последний год-полтора развернулась плотная борьба трех дистрибутивов MySQL. Три-четыре года назад (когда мы пересели на Percona) был вечно-тормозящий с патчами Oracle (заблудившийся в бранче 6.0, с массовым исходом окешихся и не очень сотрудников), странная Maria и слизанный с Oracle, но не тормозящий со сторонними патчами XtraDB. Теперь же многое поменялось. Сейчас мы видим, что Percona реально отстаёт. И очень хорошо набирает Oracle (я где-то читал, что у них уже работает под 200 человек над MySQL уже). У нас также есть свой патч (его сделал Костя Осипов, это фикс давнишней проблемы со вложенными пользовательскими блокировками), — этот патч, кстати, быстро приняла только Maria. Oracle и Percona тупят. То есть сигналы о том, что Maria хороша — они идут где-то последние полгода. Плюс неожиданная поддержка гигантов (вероятнее всего когда они поняли, что Oracle очень хорошо прёт). Но и Oracle не отстает. Так что скорее всего мы немного подождем, посмотрим, что происходит, как будет реагировать Percona. Для нас если уж делать переход, то года на три, а то и на пять. Очень важный шаг.
> Поэтому нам приходилось ждать окончания репликации для каждого пользователя, чтобы все работало корректно и данные были согласованы между собой
Поделитесь плз критерием, по которому Вы определяли окончание репликации
Поделитесь плз критерием, по которому Вы определяли окончание репликации
Про user_id, sequence_id.
Решение выглядит классно, но насколько я понял, sequence_id инкрементится в пределах пользователя. В таком случае на момент вставки, необходимо знать last_sequence_id(user_id). Насколько такой способ замедляет вставку в таблицы? Много ли делаете вставок?
Решение выглядит классно, но насколько я понял, sequence_id инкрементится в пределах пользователя. В таком случае на момент вставки, необходимо знать last_sequence_id(user_id). Насколько такой способ замедляет вставку в таблицы? Много ли делаете вставок?
last_sequence_id отлично генерируется каким-нибудь redis с гораздо большей скоростью, чем можно вставлять в mysql
В таблице, отвечающей за генерацию sequence_id, первичным ключём является (`sequence_id`,`class_id`,`user_id`), причём sequence_id — это автоинкремент. Соответственно, для генерации нового sequence_id нужно просто сделать INSERT INTO… (user_id,class_id) VALUES (123, 256). class_id — это, можно сказать, тип сиквенса.
А сколько у Вас данных на один сервер MySQL? Интересны предельные значения, которые выдерживает MySQL. Спасибо.
хмм, на сайте php-fpm.org написано
Andrei Nigmatulin is the original author of PHP-FPMпочему тогда вы заявляете что это разработка badoo? :)
Дада! Хотелось бы объяснений от официальных лиц компании!
Посмотрите внимательно профили этих людей, о которых там говорится :).
Андрей Нигматулин: habrahabr.ru/users/anight/
Антон Довгаль: habrahabr.ru/users/tony2001/
Андрей Нигматулин: habrahabr.ru/users/anight/
Антон Довгаль: habrahabr.ru/users/tony2001/
1) Андрей подписан на блог Badoo (как и еще сотни человек), и я не выгуглил чтобы было явно написано что он работает на badoo (прежде чем задать вопрос я погуглил, но не долго :).
2) согласно вики badoo появилась в 2006-ом, а согласно about php-fpm разработка началась в 2004-ом
собственно поэтому вопрос и возник :)
2) согласно вики badoo появилась в 2006-ом, а согласно about php-fpm разработка началась в 2004-ом
собственно поэтому вопрос и возник :)
Если это вас убедит, то вот профиль Тони на гитхабе: github.com/tony2001.
Да, оба этих человека работали в Баду с самого основания.
Да, оба этих человека работали в Баду с самого основания.
Я просто оставлю это здесь — habrahabr.ru/company/badoo/questions/466/
Ничего удивительного, если в крупных компаниях навроде нашей могут работать core разработчики языков, которыми мы пользуемся.
История такая:
Набор патчей с подобным функционалом начал делать Владимир Вологжанин еще в Мамбе, хотя идея была Андрея.
В какой-то момент Андрей это всё сам переписал и выложил под GPL.
Поскольку GPL несовместима с PHP License (верней наоборот, но не суть), я уговорил Андрея поменять на что-то более permissive, немного подправил и патч предложил в PHP Core.
Патч приняли и теперь оно живёт своей жизнью.
Все вышеупомянутые люди (включая меня) работают в Баду и сейчас, если вам интересно.
Набор патчей с подобным функционалом начал делать Владимир Вологжанин еще в Мамбе, хотя идея была Андрея.
В какой-то момент Андрей это всё сам переписал и выложил под GPL.
Поскольку GPL несовместима с PHP License (верней наоборот, но не суть), я уговорил Андрея поменять на что-то более permissive, немного подправил и патч предложил в PHP Core.
Патч приняли и теперь оно живёт своей жизнью.
Все вышеупомянутые люди (включая меня) работают в Баду и сейчас, если вам интересно.
вопросов больше не имею. спасибо за историческую справку :)
Я, ребят, наверное, сейчас немного нас всех подставлю, но это очень хороший кейс, самое интересное было в 2008-2009, когда проект фактически стал отходить к Майклу Шаддлу и умирать. Можете считать меня тщеславным ублюдком, мне всё равно — это просто очень хороший кейс для всех красноглазых заек. В 2009-м году если бы я вас не распинал и не выделил официально время внутри Badoo на порт fpm в ядро пхп (Антон Довгаль официально на работе имел проект номер один — перенос FPM в ядро PHP), — так вот сидели бы мы, вероятно, до сих пор с неподдерживаемым патчем, с собственным либевентом, и странным мейнтейнером микро-хостером, которому просто очень нужен process spawning. Ну и очень-очень большой вклад в проект сделал Jerom Loyet.
Вы полностью переносили данные из одной базы в другую? А бывает, наверное, когда требуется сбалансировать или перенести часть только? Боритесь ли вы как то с фрагментацией? Может быть она не столь существенна чтобы на нее обращать внимание?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы мигрировали миллионные страны за рабочий день