Добрый день, коллеги. Готовимся к запуску одного проекта, к сожалению, по NDA не могу рассказать что за проект, позже, после старта, напишу пост, но появилась проблема.
К моменту старта мы ожидаем высокие нагрузки и нам немного сложно оценить необходимую инфраструктуру под них. В пике мы ожидаем ~5 млн MySQL запросов в минуту (60% Select / 40% Insert). Запросы по себе довольно простые т.е. без сложных выборок и т.д. Подскажите пожалуйста оборудование, которое все это переварит. Нам предложили 2 8-и гиговых кор 2 дуо под веб и 3 8-и гиговых кор 2 дуо под базу данных.
серваки под веб, их или много, или мало — непонятно насколько «много» там будет логики?
непонятная цифра в 5 кк запросов к мускулю настораживает — правильно ли она высчитана?
если у вас минимальный прирост записей в 2 кк, то подумайте разумно, через сколько месяцев вы тупо упретесь в размер дисков?
я конечно все понимаю, но вы походу хотите догнать и перегнать ФБ, так что над архитектурой надо ОЧЕНЬ хорошо думать.
пусть меня тут забьют фанаты мускула, но он для такого без кувалды и напильника ну никак не подходит.
и в свете вышесказанного вам какието модные AIXы нужны.
на всякий случай поздравляю с заказом — вы там стоко опыта отгребете, что мне аж не по себе
Ну до FB само собой далеко, да и нагрузка будет пиками, а не равномерная, и у меня задача пережить пик без падения. Логика там по большому счету простая и тупая, не думаю о большой нагрузке в смысле логики. Так в принципе все нормально будет жить на простом вайтбоксе.
Хочу всех поблагодарить за помощь в понимании проблемы с стороны куда копать.
Процессор у вас ниразу не будет узким местом, база сразу же упрется в диск.
Если три сервера значит есть какой-то балансировщик или используется шардинг данных?
Какой объем базы и движек? Кол-во записей по табличкам, хотя бы порядок 1-20G,20-50G,100G
Есть ли какое то кэширование кроме кэша запросов в mysql
100% Тут все упреться сразу же в диск, тем более на простых выборках.
Если нагрузка будет действительно такой которую вы описали, то 4x SSD Intel X25e 32G RAID10 + 4 ядра + 16/32 оперативы. Тогда есть шанс, что взлетить, после вдумчивого тюнинга mysql.
Про диск все верно, скорее всего, при означенных нагрузках придется заюзать раундробин через любой вменяемый пулер и вопрос сведется к мощности фронтэнда, разбрасывающего запросы, при этом придется писать через тот же пулер. Чипсет у машинок должен быть серверным, а так без разницы, корки или ксеоны. Брать под веб-фронтэнд сервы, близкие по ресурсоемкости к машинам бэкенда в большинстве случаев смысла не имеет.
> Мы не упремся в лимит цикла записей ssd?
Берите с запасом по размеру раза в 2-3. Т.е. чтобы побольше места было свободно. Тогда упретесь лет через 10-20 )
В своё время столкнулся с похожей на вашу проблемой. Лечились тонкими настройками конфигурации MySQL методом ненаучного тыка, делали денормализацию таблиц и иногда отказывались от индексов, спасло.
Если размер базы всего 10г, имеет смысл ее целиком запихнуть в память. Имели опыт с виртуальным диском, внутри которого жил мускуль, все крутилось в памяти и держало очень высокие нагрузки, порядка 5млн инсертов в сутки и это в те времена, когда п4 считался мощным сервером. Для надежности была репликация в слейв, который уже жил на обычном винте.
Простая выборка = процессор практически не используется.
Дальше зависит от размера базы. Если база эдак 20-30 гиг — берете 32гб памяти, кэш почти на всю и x2 ssd в raid1.
Если база 50гб и более — тоже самое, только х4 ssd и raid10.
Про веб сказать что то сложно т.к. это зависит от того, что у вас там и как оно написано.
У вас в анкете: «Друзья: rbkmoney». Ребят, если это биллинг, побьётся у вас база после очередного падения, потом до второго пришествия не разгребёте, кто кому сколько должен :)
Да, бросьте это ерунда, ну проспамились ребята по хабру. Мне не жалко, возможно даже когда-то буду пользоваться их услугами если пароль вспомню. Не в этом дело :)
Если убытки совсем серьёзные, можно вложиться и портировать всё на Оракл.
Если денег на это не хватит, можно перевезти всё на PostgreSQL, он лучше Мускуля масштабируется.
Возможно, комбинация Постгреса и noSQL-базы.