On 13.02.2015 00:47, garryg wrote:
> расчитываем на 30000 запросов в секунду. Сайт не новостной, типа > блогинга + обмен сообщениями.
30K запросов к аппсерверу в секунду? Это реально очень-очень много, если
каждую секунду хотя бы в течении часа. А если хотя бы 1% из них на
запись — то у вас точно будут проблемы с БД.
G>>>с базой данных так же более менее ясно (MySQL or Postgress), вот только реплицировать ли её... B>>Для массивных апдейтов Postgress лучше. Так как он версионнник, там конкуренция разруливатся лучше. Но это оффтоп. MySQL классно использовать в NoSQL стиле.
G>Вот поэтому еще и не определились, Мулкул или Постгрю.
Ну, у Postrge тоже есть NoSQL расширение, если нужно.
И зато там хоть как-то продумана репликация и восстановление из коробки, лучше, чем у MySQL.
Впрочем, я не в курсе, что там Percona напилила для MySQL, может и можно пользоваться.
G>>>3. И что с Базой Данных, реплицировать её ли, если да, то как с ней после работать... G>Пожалуй лишним небудет сделать реплику, да же со стороны безопасноти данных (в случае краха базы).
Э, зависит от того, какой SLA требуется. Надо понимать, что даже две девятки — это минимум два разнесенных ДЦ, а это уже много сложностей с репликацией. В общем, там много всяких сложностей )
G>Большое спасибо за подробное пояснение, будем учить и вникать
Но вообще странно, что на проект с такой нагрузкой взяли человека без опыта нагруженных систем вообще...
Я бы сказал, что проект обречен )
Ну или ищите консультантов по всем вопросам — от архитектуры до системного администрирования и настройкам БД.
Здравствуйте, garryg, Вы писали:
G>планируем в компании разработку сайта и одним из требования высокая нагрузка (посещаемость 30к+ пользователей в пике 50к — 70к). G>Но что-то мне подсказывает такой нагрузки держать не будет сайт (хоть сайт и простой по функциональности, регистрация/авторизация/просмотр статей, отправка/прием сообщений)...
Во дела...
Ты ничего видимо и сам ещё не знаешь о задаче, характере нагрузки, структуре БД, и т.п., но уже что-то тебе там подсказывает...
G>И почитав статьи, стало быть люди пишут про некоторые архитектуры, которые используют несколько инстанцев на которые перенаправляет лоад-балансер. G>Но толи статьи плохие попадались, либо это все так неоднозначно, ни каких конкретных архитектур ненашел, одна "вода".
Не всё в производительности определяется только архитектурой.
G>3. И что с Базой Данных, реплицировать её ли, если да, то как с ней после работать...
Репликация -- обычено способ повышения надёжности. Нужна надёжность 99% -- реплицируй. Не нужна -- можно не реплицировать.
Если ты имеешь в виду другие виды репликации -- то это уже зависит от приложения, там всё будет диктоваться логикой приложения.
G>4. И с какими неожиданными моментами можно сталкнуться (чего ожидать)?
Пока всё приложение не будет реализовано, ты не будешь знать все подробности.
Увы.
Здравствуйте, hrensgory, Вы писали:
H>On 13.02.2015 00:47, garryg wrote:
>> расчитываем на 30000 запросов в секунду. Сайт не новостной, типа >> блогинга + обмен сообщениями.
H>30K запросов к аппсерверу в секунду? Это реально очень-очень много, если H>каждую секунду хотя бы в течении часа. А если хотя бы 1% из них на H>запись — то у вас точно будут проблемы с БД.
Думаю это пиковая нагрузка, и на неё надо расчитываать...
Тут что еще с логирование делать пока ума не приложу
G>>>>с базой данных так же более менее ясно (MySQL or Postgress), вот только реплицировать ли её... B>>>Для массивных апдейтов Postgress лучше. Так как он версионнник, там конкуренция разруливатся лучше. Но это оффтоп. MySQL классно использовать в NoSQL стиле.
G>>Вот поэтому еще и не определились, Мулкул или Постгрю.
ДФ>Ну, у Postrge тоже есть NoSQL расширение, если нужно. ДФ>И зато там хоть как-то продумана репликация и восстановление из коробки, лучше, чем у MySQL. ДФ>Впрочем, я не в курсе, что там Percona напилила для MySQL, может и можно пользоваться.
G>>>>3. И что с Базой Данных, реплицировать её ли, если да, то как с ней после работать... G>>Пожалуй лишним небудет сделать реплику, да же со стороны безопасноти данных (в случае краха базы).
ДФ>Э, зависит от того, какой SLA требуется. Надо понимать, что даже две девятки — это минимум два разнесенных ДЦ, а это уже много сложностей с репликацией. В общем, там много всяких сложностей )
G>>Большое спасибо за подробное пояснение, будем учить и вникать ДФ>Но вообще странно, что на проект с такой нагрузкой взяли человека без опыта нагруженных систем вообще... ДФ>Я бы сказал, что проект обречен ) ДФ>Ну или ищите консультантов по всем вопросам — от архитектуры до системного администрирования и настройкам БД.
Спасибо за ободряющие слова, мысли о консультанте тоже посещали...
Некоторый опыт с нагруженными системами есть, но этот проект обещается быть более серьезный.
А насчет "взяли человека", сказали: -"Нннадаа сдЕлать!!!"
Здравствуйте, MasterZiv, Вы писали:
MZ>Здравствуйте, garryg, Вы писали:
G>>планируем в компании разработку сайта и одним из требования высокая нагрузка (посещаемость 30к+ пользователей в пике 50к — 70к). G>>Но что-то мне подсказывает такой нагрузки держать не будет сайт (хоть сайт и простой по функциональности, регистрация/авторизация/просмотр статей, отправка/прием сообщений)...
MZ>Во дела... MZ>Ты ничего видимо и сам ещё не знаешь о задаче, характере нагрузки, структуре БД, и т.п., но уже что-то тебе там подсказывает...
ТЗ еще в глаза не видел, но описание уже получил, и вот решил заранее начать разбираться с данной темой что бы встретить не спустыми руками.
G>>И почитав статьи, стало быть люди пишут про некоторые архитектуры, которые используют несколько инстанцев на которые перенаправляет лоад-балансер. G>>Но толи статьи плохие попадались, либо это все так неоднозначно, ни каких конкретных архитектур ненашел, одна "вода".
MZ>Не всё в производительности определяется только архитектурой.
Согласен, от реализации очень много зависит.
G>>3. И что с Базой Данных, реплицировать её ли, если да, то как с ней после работать...
MZ>Репликация -- обычено способ повышения надёжности. Нужна надёжность 99% -- реплицируй. Не нужна -- можно не реплицировать. MZ>Если ты имеешь в виду другие виды репликации -- то это уже зависит от приложения, там всё будет диктоваться логикой приложения.
Надежность + для работы в read only режиме.
G>>4. И с какими неожиданными моментами можно сталкнуться (чего ожидать)?
MZ>Пока всё приложение не будет реализовано, ты не будешь знать все подробности. MZ>Увы.
КОнечно, но хотелось бы по возможности с узить круг и размер граблей
