Comments 11
> мы использовали общую практику развертывания программного обеспечения: плановая двухчасовая остановка в период наименьшего трафика
Вам очень повезло, что у вас вообще есть минимум трафика. К примеру, у нас «минимум трафика» представляет из себя трафик в 2 раза меньше, чем в пике. То есть, планово останавливать сервис на 2 часа нельзя никогда.
Вам очень повезло, что у вас вообще есть минимум трафика. К примеру, у нас «минимум трафика» представляет из себя трафик в 2 раза меньше, чем в пике. То есть, планово останавливать сервис на 2 часа нельзя никогда.
Бывают ли у вас изменения схемы данных? Если да, то как вы их внедряете?
Данные пользователей у нас расшардены по маленьким (1-10к пользователей) табличкам. Альтерятся они прямо «на живую», и каждый альтер идет несколько секунд. Код, соответственно, заранее подготавливается к тому, чтобы уметь работать с обеими версиями схемы одновременно. Если это не полтзовательские данные, то pt-online-schema-change, если таблица большая и важная, либо просто alter, если данных мало или мы можем подождать
Извините за дубль, мобильное приложение хабра странно отправляет комментарии, что они некоторое время не отображаются на странице (репликация :)?)
Если у вас код может работать с обеими версиями БД — почему не поднимать копии нужных таблиц на момент миграции?
Я, скорее всего, не очень понял вопрос, но например pt-online-schema-change на момент альтера собственно создает копию таблицы и постепенно наполняет её данными, причём с помощью триггеров обеспечивается дублирование изменений, произошедших в исходной таблице, чтобы данные были консистентны. Как вы понимаете, это сильно увеличивает нагрузку на базу.
В нашем случае альтеры на каждую из табличек идут быстро, поэтому для подавляющего большинства пользователей это происходит незаметно. И поскольку самих данных может быть очень много, это позволяет делать альтеры максимально быстро и без создания лишних копий данных.
В нашем случае альтеры на каждую из табличек идут быстро, поэтому для подавляющего большинства пользователей это происходит незаметно. И поскольку самих данных может быть очень много, это позволяет делать альтеры максимально быстро и без создания лишних копий данных.
Данные пользователей у нас расшардены на небольшие (1-10к пользователей) таблички. При необходимости делать альтер, сначала подготавливается код таким образом, чтобы он мог работать с обеими версиями схемы одновременно (на момент перехода), а потом непосредственно выполняется альтер. Альтер делается блокирующим, но он идет весьма быстро, поскольку таблички небольшие. Если требуется проальтерить схему у таблиц, которые не расшардены таким образом, то это делается либо с использованием утилиты pt-online-schema-change от Перконы, либо тоже «на живую», если блокирующий альтер в этом случае не затрагивает пользователей. Обычный альтер обычно идет сильно быстрее онлайн-варианта, поэтому мы его часто используем.
Не кажется, что в данном случае SQL не самое лучшее решение. Были ли эксперименты с другими хранилищами?
Я бы не стал путать SQL и «автоматический шардинг. Проекты вроде vitess и cockroachdb как раз служат примером обратного.
Одной из основных (но не единственной) причин для выбора MySQL было отсутствие вменяемых вльтернатив на момент создания сервиса (2006 год). Еще одна причина — MySQL обеспечивает транзакции и надежность хранения данных при условии исполтзования InnoDB, и транзакциями мы пользуемся очень часто. Обычно NoSQL решения не предоставляют ни транзакций, ни джойнов, поэтому это явно не способствует ускорению разработки. Мы пробовали MongoDb для одного проекта, и вроде как особых проблем с монго не испытывали. Тем не менее, сейчас MongoDb мы не используем, потому что тот проект „не полетел“. Наша архитектура почти вся построена на MySQL и сишных демонах, и с точки зрения поддержки, как мне кажется, сложно придумать что-то лучше для хайлоад-проекта с многолетней историей.
Одной из основных (но не единственной) причин для выбора MySQL было отсутствие вменяемых вльтернатив на момент создания сервиса (2006 год). Еще одна причина — MySQL обеспечивает транзакции и надежность хранения данных при условии исполтзования InnoDB, и транзакциями мы пользуемся очень часто. Обычно NoSQL решения не предоставляют ни транзакций, ни джойнов, поэтому это явно не способствует ускорению разработки. Мы пробовали MongoDb для одного проекта, и вроде как особых проблем с монго не испытывали. Тем не менее, сейчас MongoDb мы не используем, потому что тот проект „не полетел“. Наша архитектура почти вся построена на MySQL и сишных демонах, и с точки зрения поддержки, как мне кажется, сложно придумать что-то лучше для хайлоад-проекта с многолетней историей.
Понятно, просто по расскажу сложилось впечатление, что вы мучаетесь и вас что-то не устраивает.
Раз все хорошо, то вопросов нет.
Раз все хорошо, то вопросов нет.
Я бы сказал, что в большой системе наличие схемы — это скорее плюс, чем минус. Да, выполнение альтеров (неатомарное в пределах кластера) создает нам проблемы при автоматической миграции пользователей, к примеру, но без схемы было бы еще хуже. В целом, MySQL подходит под наши условия очень хорошо и отказываться мы от него не собираемся в ближайшем будущем.
Sign up to leave a comment.
Масштабируя до 100 миллионов: архитектура, определяемая уровнем сервиса