1

Тема: Распределённое приложение #2

Буквально через неделю запускаем приложение для ВКонтакте и с первых же дней предполагается высокая посещаемость, растущая в практически геометрической прогрессии до некоторой величины. По предварительным оценкам максимальный онлайн - не более 50 000 хостов.

Один из партнёров готов предоставить практически неограниченные вычислительные мощности. Это плюс. Минус в том, что опыта разработки такого рода проектов практически нет. Работал в команде над парой подобных, но там такие задачи были вне моей компетенции.

Хотелось бы получить совет от знающих людей по следующим вопросам:

- Репликация БД. Стоит ли разносить по нескольким серверам, если около 50% запросов - это insert и update. Остальные 50% - выборки, которые тут же кэшируются.

- Горизонтальное масштабирование фронтенда (применительно к symfony). Есть ли подводные камни? Как быть с сессиями (там по сути только user_id хранится). Есть ли возможность задать для них централизованное хранилище? Или лучше использовать альтернативный storage (другую БД или кэш).

Советы, пожелания, вопросы также принимаю с радостью.

2

Re: Распределённое приложение #2

все равно тут универсального решения нет
вам бы запустится и увидеть какая ситуация в реальности

по сути:

  • репликация существенно ничего не даст при таком соотношении чтения/записи

  • по поводу сессий - при горизонтальном расширении их нужно хранить или в базе другой или в мемкеше или в любом другом key-value хранилище, иные решения мне неизвестны

а вообще, это все очень интересно и я был бы рад если бы вы описали что у вас в итоге получится

3

Re: Распределённое приложение #2

Вообще, если "буквально через неделю запускаем" - то спрашивать что-либо уже поздно.

Касательно БД - не репликацией единой, что называется... Гораздо эффективнее, особенно при вашем соотношении, в первую очередь думать об оптимизации структуры данных и внесения в саму структуру распределенности. Тогда можно будет свободно делить нагрузку на любое количество серверов с небольшой потерей общего КПД. Успех в этом во многом зависит от задачи и структуры данных.

Не касаясь структуры данных, в вашем случае можете создать кластер, где один сервер будет принимать запросы на вставки/изменения, другой только на чтение. КПД такой системы вероятнее всего будет не шибко высоким, но два сервера в такой связке выдержат всяко больше одного, в первую очередь за счет разделения задач парсинга запросов и подготовки (работы оптимизатора).
Многое еще конечно зависит от выбранной базы данных. Кластер на мускуле - это заслуживающий отдельной книги геморрой.

В горизонтальном масштабировании скриптов никаких проблем нет, на каждом сервере спокойно создастся кеш конфигов и все будет работать как обычно. Сессии - в любом централизованном хранилище, лежащем на отдельном сервере (фс/мемкешд/бд/чтоугодно).