HABO3

Пользователь

Регистрация: 03.08.2021

Сообщения: 909

Рейтинг: 894

HABO3

Регистрация: 03.08.2021

Сообщения: 909

Рейтинг: 894

Суть: щас с товарищами делаем проект, нацеленный на мощную нагрузку с большим количеством файлов, запросов и т.д. Проект включает в себе больше 10 крупных системных разветвлений. Что собственно логично, для оптимизации ресурсов, необходимо 100% сделать разделение серверов. Один большой компонент, к примеру, БД - свой сервер. Была составлена схема.

 

Вопрос следующий: на основе этой схемы, какие минусы можете выделить? Меня лично смущает то, что любой вид запроса будет проходить через главный сервер, от которого идет ответвление. То есть, по идее, он больше всех подвержен нагрузке. Адекватного решения не придумал. Какие могут быть варианты на этот счёт?

 

Если нужно: для  SPA будет использоваться VueCLI, все остальные серверы будут работать на Laravel (PHP) / nginx. База данных: PostgreSQL. Дистрибутив: Slackware

 

 

Схема

astanavitesb

Пользователь

Регистрация: 03.06.2022

Сообщения: 1310

Рейтинг: 648

Нарушения: 180

astanavitesb

Регистрация: 03.06.2022

Сообщения: 1310

Рейтинг: 648

Нарушения: 180

Тут врятли кто то поможетBatPepe.png?1598625919 проще гуглить про кластеризацию серверов(незнаю поможет ли этоroflanBuldiga.png?1616515169)

haHAA

Пользователь

Регистрация: 25.03.2017

Сообщения: 1079

Рейтинг: 726

haHAA

Регистрация: 25.03.2017

Сообщения: 1079

Рейтинг: 726

img
HABO3 сказал(а):

Какие могут быть варианты на этот счёт?

Нажмите, чтобы раскрыть...

раббит не справится хочешь сказать?

HABO3

Пользователь

Регистрация: 03.08.2021

Сообщения: 909

Рейтинг: 894

HABO3

Регистрация: 03.08.2021

Сообщения: 909

Рейтинг: 894

haHAA сказал(а):

раббит не справится хочешь сказать?

Нажмите, чтобы раскрыть...

Флаппинг же есть. Если я не ошибаюсь, в их оф.доке сказано, что из за флаппинга при ~500 запросах в секунду он начнет лагать

haHAA

Пользователь

Регистрация: 25.03.2017

Сообщения: 1079

Рейтинг: 726

haHAA

Регистрация: 25.03.2017

Сообщения: 1079

Рейтинг: 726

img
HABO3 сказал(а):

Флаппинг же есть. Если я не ошибаюсь, в их оф.доке сказано, что из за флаппинга при ~500 запросах в секунду он начнет лагать

Нажмите, чтобы раскрыть...

Ты если собираешься разрабатывать систему промышленных масштабов, то тебе нужны опытные архитектор и девопс

HABO3

Пользователь

Регистрация: 03.08.2021

Сообщения: 909

Рейтинг: 894

HABO3

Регистрация: 03.08.2021

Сообщения: 909

Рейтинг: 894

haHAA сказал(а):

Ты если собираешься разрабатывать систему промышленных масштабов, то тебе нужны опытные архитектор и девопс

Нажмите, чтобы раскрыть...

 

Это понятно, у нас состав не инженеры Гугла, только три прогера. Нам необходимо сделать самый минимум: сделать так, чтобы проект не слег при первой серьезной нагрузке и чтобы ресурсы сервера не били критично по кошельку, ибо большая часть нашего бюджета будет идти на рекламу. Естественно все на одну систему ставить не рационально, разветвление хоть какое то нужно

MEDI_OFF

Пользователь

Регистрация: 19.07.2018

Сообщения: 53

Рейтинг: 16

MEDI_OFF

Регистрация: 19.07.2018

Сообщения: 53

Рейтинг: 16

img

Ну для начала бы понять конкретно в цифрах, много это сколько вы ожидаете, сколько запросов на чтение, на запись, примерные темпы роста, какой объем информации в БД будет, хотя бы приблизительные цифры, от чего можно оттолкнуться.

По схеме вообще не понятно что это такое, что за кольцевая зависимость Главный сервер ходит что бы распределить запросы, а те в свою очередь ходят в него зачем то, что за файловый слот, где вообще на схеме хоть какой то клиент, крч такая схема вообще не понятная никому кроме вас, и если вы ее еще захотите разработчику показать то врятли что то нормальное выйдет

Готов немного помочь на халяву, так сказать по дотерскому братству

haHAA

Пользователь

Регистрация: 25.03.2017

Сообщения: 1079

Рейтинг: 726

haHAA

Регистрация: 25.03.2017

Сообщения: 1079

Рейтинг: 726

img
HABO3 сказал(а):

сделать так, чтобы проект не слег при первой серьезной нагрузке и чтобы ресурсы сервера не били критично по кошельку, ибо большая часть нашего бюджета будет идти на рекламу

Нажмите, чтобы раскрыть...

- хочу много данных обрабатывать

- не хочу много тратить на сервер

- не хочу чтобы система упала при первой же нагрузке

- не хочу архитектора и девопса

MEDI_OFF сказал(а):

Ну для начала бы понять конкретно в цифрах, много это сколько вы ожидаете, сколько запросов на чтение, на запись, примерные темпы роста, какой объем информации в БД будет, хотя бы приблизительные цифры, от чего можно оттолкнуться.

По схеме вообще не понятно что это такое, что за кольцевая зависимость Главный сервер ходит что бы распределить запросы, а те в свою очередь ходят в него зачем то, что за файловый слот, где вообще на схеме хоть какой то клиент, крч такая схема вообще не понятная никому кроме вас, и если вы ее еще захотите разработчику показать то врятли что то нормальное выйдет

 

Готов немного помочь на халяву, так сказать по дотерскому братству

Нажмите, чтобы раскрыть...

+ не понял каким образом сервер "для разработки" соединен с "продом"

тут явно намешаны сервера(облака) и кластеры вместе

HABO3

Пользователь

Регистрация: 03.08.2021

Сообщения: 909

Рейтинг: 894

HABO3

Регистрация: 03.08.2021

Сообщения: 909

Рейтинг: 894

MEDI_OFF сказал(а):

Ну для начала бы понять конкретно в цифрах, много это сколько вы ожидаете, сколько запросов на чтение, на запись, примерные темпы роста, какой объем информации в БД будет, хотя бы приблизительные цифры, от чего можно оттолкнуться.

По схеме вообще не понятно что это такое, что за кольцевая зависимость Главный сервер ходит что бы распределить запросы, а те в свою очередь ходят в него зачем то, что за файловый слот, где вообще на схеме хоть какой то клиент, крч такая схема вообще не понятная никому кроме вас, и если вы ее еще захотите разработчику показать то врятли что то нормальное выйдет

Нажмите, чтобы раскрыть...

 

У нас есть разрабы, это очень упрощенная схема.

 

Если вкратце: SPA, dev, nonAuth, API сервера отправляют запрос на главный сервер, тот их распределяет по другим серверам: бд, файловый сервер. На этих серверах происходит запрос - ответ отправляется назад на главный сервер, а он возвращает ответ уже какому то одному серверу из четырех. Выбор сервера зависит от вида запроса (не имеется ввиду post/get и т.д). 

 

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

 

По цифрам сложно сказать, но бд будет очень объемная, придется много хранить в тех же логах, не только из технической необходимости, сколько из за законодательства. Количество запросов в секунду, после первой волны рекламы, оцениваем в 500-1200

 

 

haHAA сказал(а):

- хочу много данных обрабатывать

- не хочу много тратить на сервер

- не хочу чтобы система упала при первой же нагрузке

- не хочу архитектора и девопса

Нажмите, чтобы раскрыть...

 

Будь у нас бюджет, который это позволял бы, над этим бы никто не парился. Да и где взять архитектора и девопса? На фрилансе чтоли? Они пойдут только под ТД на белую зарплату, а у нас ещё не всё готово, чтобы фирму открывать

MEDI_OFF

Пользователь

Регистрация: 19.07.2018

Сообщения: 53

Рейтинг: 16

MEDI_OFF

Регистрация: 19.07.2018

Сообщения: 53

Рейтинг: 16

img
HABO3 сказал(а):

 

У нас есть разрабы, это очень упрощенная схема.

 

Если вкратце: SPA, dev, nonAuth, API сервера отправляют запрос на главный сервер, тот их распределяет по другим серверам: бд, файловый сервер. На этих серверах происходит запрос - ответ отправляется назад на главный сервер, а он возвращает ответ уже какому то одному серверу из четырех. Выбор сервера зависит от вида запроса (не имеется ввиду post/get и т.д). 

 

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

 

По цифрам сложно сказать, но бд будет очень объемная, придется много хранить в тех же логах, не только из технической необходимости, сколько из за законодательства. Количество запросов в секунду, после первой волны рекламы, оцениваем в 500-1200

 

 

Нажмите, чтобы раскрыть...

Опять же у меня вопросов возникает больше чем ответов)

1. БД очень объемная - это сколько? 100 Петабайт или 10 гигов, пиши лучше конкретные цифры

2. Каким образов считали RPS(Количество запросов в секунду)? Есть подозрение что вы сильно завышаете цифры

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

Тут очень долго описывать, если есть желание можем в дискорде голосом

haHAA сказал(а):
Нажмите, чтобы раскрыть...

Не совсем понял что ты имеешь ввиду) В тексте и схеме ни слова не было про кластеры и облака

Karasiq

Пользователь

Регистрация: 17.03.2020

Сообщения: 170

Рейтинг: 81

Karasiq

Регистрация: 17.03.2020

Сообщения: 170

Рейтинг: 81

AWS?

MEDI_OFF

Пользователь

Регистрация: 19.07.2018

Сообщения: 53

Рейтинг: 16

MEDI_OFF

Регистрация: 19.07.2018

Сообщения: 53

Рейтинг: 16

img
Karasiq сказал(а):

AWS?

Нажмите, чтобы раскрыть...

Как же прикалывают такие сообщения XD

Karasiq

Пользователь

Регистрация: 17.03.2020

Сообщения: 170

Рейтинг: 81

Karasiq

Регистрация: 17.03.2020

Сообщения: 170

Рейтинг: 81

MEDI_OFF сказал(а):

Прикалывают такие сообщения XD

Нажмите, чтобы раскрыть...

И в чем он не прав?

HABO3

Пользователь

Регистрация: 03.08.2021

Сообщения: 909

Рейтинг: 894

HABO3

Регистрация: 03.08.2021

Сообщения: 909

Рейтинг: 894

MEDI_OFF сказал(а):

Опять же у меня вопросов возникает больше чем ответов)

1. БД очень объемная - это сколько? 100 Петабайт или 10 гигов, пиши лучше конкретные цифры

2. Каким образов считали RPS(Количество запросов в секунду)? Есть подозрение что вы сильно завышаете цифры

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

Тут очень долго описывать, если есть желание можем в дискорде голосом

 

 

Нажмите, чтобы раскрыть...

 

1) Точных цифр нет, потому что все зависит от успеха пиара. Она может провалиться, быть более менее нормальной, а может стать вообще успешной. Если кампания провалится, записей в бд через ~2 месяца может быть на 2-4гб, что мало, по нашим меркам. Но речь идёт о гигабайтах, конечно. 

 

2) Это оптимистичные цифры. Брали на разбор какие-либо крупные проекты, которые массово светились на Ютубе. Через аналитику запросов проверяли их, записывали значения в период их пиар кампании, следили за динамикой до/после. На их основе и на основе нашего бюджета составили примерные цифры.

 Те цифры, что я назвал, должны быть во время пиар кампании где то на кульминации. Опять же, они оптимистичные

 

3) Я не спорю, что представление может быть низкоуровневым, у нас среди всех первый опыт в построении такой архитектуры, работаем по учебнику. У нас нет цели создать аналог Ютуба/Гугла. Мы не ставим заоблачные приоритеты. Наша задача - создать необходимый минимум, который позволит нам стартовать и в случае необходимого нам успеха, мы могли бы дополнять и развивать имеющуюся архитектуру, а не заново сносить и строить по новой.

MEDI_OFF

Пользователь

Регистрация: 19.07.2018

Сообщения: 53

Рейтинг: 16

MEDI_OFF

Регистрация: 19.07.2018

Сообщения: 53

Рейтинг: 16

img
Karasiq сказал(а):

И в чем он не прав?

Нажмите, чтобы раскрыть...

А в чем он прав? Написал AWS и все? Есть подозрения что человек ни разу им не пользовался а просто слышал краем уха что есть такое

В чем мотивация использования AWS если вообще еще не понятно что нужно ТС'у

Ты понимаешь какие вообще трудозатраты и требование к специалистам для того что бы поднять распределенное приложение в облаке (не важно какое - AWS, Azure, Яндекс и т.д.) Хотя у чела в теме отписано что в ресурсах они ограничены

Проблемы с оплатой AWS из РФ (Опять же из темы понятно что возможно будет открываться фирма и + еще одну проблему ты только что подкинул им написав эти три буквы)

Почему именно AWS? Есть много других облачных провайдеров, почему именно на AWS пал выбор

Поэтому меня и улыбнуло это, что человек скорее всего некомпетентен в данном вопросе, но написал "AWS?", еще и со знаком вопроса, как будто, ну типо все очевидно же

Karasiq

Пользователь

Регистрация: 17.03.2020

Сообщения: 170

Рейтинг: 81

Karasiq

Регистрация: 17.03.2020

Сообщения: 170

Рейтинг: 81

ОП, твой главный сервер ничего не перенаправляет, просто вы хотите захостить дб и фс отдельно. Это нормально, но все клиенты будут ждать ответа от хоста, то есть твоего главного сервера, а он будет ждать ответы от остальных. Чтобы он ничего не ждал, нужно делать все асинхронно через MQ или тратиться на кластеры, балансеры и т. д. Я с MQ не работал никогда, но уверен у какой то Kafka хвати мощи все это вывезти на одном брокере. А вообще сначала оцените нагрузку, которую вы получите по факту, а потом уже решайте инфраструктурные проблемы.

 

MEDI_OFF сказал(а):

А в чем он прав? Написал AWS и все? Есть подозрения что человек ни разу им не пользовался а просто слышал краем уха что есть такое

В чем мотивация использования AWS если вообще еще не понятно что нужно ТС'у

Ты понимаешь какие вообще трудозатраты и требование к специалистам для того что бы поднять распределенное приложение в облаке (не важно какое - AWS, Azure, Яндекс и т.д.) Хотя у чела в теме отписано что в ресурсах они ограничены

Проблемы с оплатой AWS из РФ (Опять же из темы понятно что возможно будет открываться фирма и + еще одну проблему ты только что подкинул им написав эти три буквы)

Почему именно AWS? Есть много других облачных провайдеров, почему именно на AWS пал выбор

Поэтому меня и улыбнуло это, что человек скорее всего некомпетентен в данном вопросе, но написал "AWS?", еще и со знаком вопроса, как будто, ну типо все очевидно же

Нажмите, чтобы раскрыть...

Я юзал и настраивал лоад балансер в EC. А что если что-то сложно, то все, не юзаем? Нетривиальные задачи требуют нетривиальных решений. Оплата да, тут сыглы. Ну не знает, пусть узнает, господи.

MEDI_OFF

Пользователь

Регистрация: 19.07.2018

Сообщения: 53

Рейтинг: 16

MEDI_OFF

Регистрация: 19.07.2018

Сообщения: 53

Рейтинг: 16

img
HABO3 сказал(а):

 

1) Точных цифр нет, потому что все зависит от успеха пиара. Она может провалиться, быть более менее нормальной, а может стать вообще успешной. Если кампания провалится, записей в бд через ~2 месяца может быть на 2-4гб, что мало, по нашим меркам. Но речь идёт о гигабайтах, конечно. 

 

2) Это оптимистичные цифры. Брали на разбор какие-либо крупные проекты, которые массово светились на Ютубе. Через аналитику запросов проверяли их, записывали значения в период их пиар кампании, следили за динамикой до/после. На их основе и на основе нашего бюджета составили примерные цифры.

 Те цифры, что я назвал, должны быть во время пиар кампании где то на кульминации. Опять же, они оптимистичные

 

3) Я не спорю, что представление может быть низкоуровневым, у нас среди всех первый опыт в построении такой архитектуры, работаем по учебнику. У нас нет цели создать аналог Ютуба/Гугла. Мы не ставим заоблачные приоритеты. Наша задача - создать необходимый минимум, который позволит нам стартовать и в случае необходимого нам успеха, мы могли бы дополнять и развивать имеющуюся архитектуру, а не заново сносить и строить по новой.

Нажмите, чтобы раскрыть...

1. Тогда у вас должно быть 3 набора цифр, хотя бы примерных, просто может сейчас так оказаться что вы оверинжинирингом занимаетесь, и вам не понадобиться то что вы себе там сейчас надумали в принципе

2. Размер бд в 2-4гб это вообще смешно, ты ее всю в оперативке держать сможешь, даже если учитывать что в при успешном сценарии вы ожидаете в 10 раз больше выхлопа, типо бд 20-40 гигов, это вообще не проблема, даже учитывая темпы роста на 40 гигов в месяц, через год в вас БД дай Бог 0.5Тб будет, что в принципе очень не много и 1 любой сервер с SSD это переварит спокойно

3. RPS надо посчитать не исходя из конкурентов и каких то виде на ютубе, а понимать количество своих пользователей, сколько будет примерно активных в течении для, сколько примерно генерит запросов каждый юзер, для этого надо понимать ваш домен, можете хоть с головый цифры взять эти, главное что бы они были, а так еще раз скажу, что есть большая вероятность вам просто самих себя передумать

Karasiq

Пользователь

Регистрация: 17.03.2020

Сообщения: 170

Рейтинг: 81

Karasiq

Регистрация: 17.03.2020

Сообщения: 170

Рейтинг: 81

Еще хочу добавить, что реляционные бд не особо про хайлоад, так что будьте осторожны.

MEDI_OFF

Пользователь

Регистрация: 19.07.2018

Сообщения: 53

Рейтинг: 16

MEDI_OFF

Регистрация: 19.07.2018

Сообщения: 53

Рейтинг: 16

img
Karasiq сказал(а):

Я юзал и настраивал лоад балансер в EC. А что если что-то сложно, то все, не юзаем? Нетривиальные задачи требуют нетривиальных решений. Оплата да, тут сыглы. Ну не знает, пусть узнает, господи.

Нажмите, чтобы раскрыть...

Опять же, что значит "настраивал лоад балансер в EC", если ты типо работал с AWS то ты должен во первых понимать что настройка балансера там варьируется от "kubectl apply" на уже написанный кем то конфиг до самых тонких моментов с настройками непосредственно на железке стека TCP/IP и реализации своих протоколов, ну и так же ты должен понимать что лоадбалансер это капля в море от того что там есть в AWS, так что аргумент тип "настраивал лоад балансер в EC" вообще опять же абсолютно ничего не говорит о твой компетенции

Что именно настраивал? Что за ним стояло? Какие правила балансировки и почему юзал, все это ты почему то решил оставить за кадром

Ну хочу что бы ты думал что прям камень в твой огород, просто если ты реально хочешь помочь, то и отписывай нормальные ответы, а не просто "AWS?" который вообще никак ничем не поможет никому. А если ты так по рофлу вкинул то хотя бы потом на это намек дай, что бы другие челы поняли что коммент не серьезный и не стоит питать надежд

Karasiq сказал(а):

Еще хочу добавить, что реляционные бд не особо про хайлоад, так что будьте осторожны.

Нажмите, чтобы раскрыть...

Еще один коммент который заставляет орнуть (могу и тут подискутировать)

Zacateca

Пользователь

Регистрация: 22.12.2017

Сообщения: 34137

Рейтинг: 13333

Нарушения: 25

Zacateca

Регистрация: 22.12.2017

Сообщения: 34137

Рейтинг: 13333

Нарушения: 25

Ну это как-то так наверное должно выглядеть

Спойлер

Я не разбираюсь в теме совсем, но наверное нужен какой-нибудь task scheduler или брокер,  который будет раскидывать задачи по серверам, тк ты не сможешь заранее знать, какой сервер будет нагружен, а какой нет в определенные моменты. Плюс не решена проблема масштабирования и выхода из строя одного из серверов.

Максим Феофилов

Пользователь

Регистрация: 06.09.2018

Сообщения: 93

Рейтинг: 19

Максим Феофилов

Регистрация: 06.09.2018

Сообщения: 93

Рейтинг: 19

Можно и мне вмешаться.

Я пробежал глазами. Не всё осознал. Но на вскидку накидаю идей на подумать.

1)Точно ли пиар предполагает, что все пользователи пойдут дальше регистрации и будут пользоваться вашим кор функционалом?

Если нет, а большая часть отвалиться на лендинге \ регистрации \ привязке карты, и т.д.

Начни с размещения статичного контента с cdn. Это решит дёшево и сердито большую часть проблем

2)Если говорить о скалабилити, есть горизонтальное и вертикальное. 

Если упрожняешься в систем дизайне, не забывай про шардинг. 

 

3)Дизайнить систему, без конкретных цыфр - смерти подобно. 

MEDI_OFF

Пользователь

Регистрация: 19.07.2018

Сообщения: 53

Рейтинг: 16

MEDI_OFF

Регистрация: 19.07.2018

Сообщения: 53

Рейтинг: 16

img
Zacateca сказал(а):

Ну это как-то так наверное должно выглядеть

Спойлер

Я не разбираюсь в теме совсем, но наверное нужен какой-нибудь task scheduler или брокер,  который будет раскидывать задачи по серверам, тк ты не сможешь заранее знать, какой сервер будет нагружен, а какой нет в определенные моменты. Плюс не решена проблема масштабирования и выхода из строя одного из серверов.

Нажмите, чтобы раскрыть...

Очень сомневаюсь что даже приблизительно это будет так выглядеть

Знать можно если настроить мониторинги и проводить аналитику, до масштабирования еще дорасти надо, но заложить фундамент можно и нужно конечно исходя из задач и требований, но соблюдать баланс, что бы не мучаться на первых этапах, а я тут у ТС'а еще цифр конкретных кроме размера БД который непонятно опять же как он считал, не получил

Zacateca

Пользователь

Регистрация: 22.12.2017

Сообщения: 34137

Рейтинг: 13333

Нарушения: 25

Zacateca

Регистрация: 22.12.2017

Сообщения: 34137

Рейтинг: 13333

Нарушения: 25

MEDI_OFF сказал(а):

Очень сомневаюсь что даже приблизительно это будет так выглядеть

Знать можно если настроить мониторинги и проводить аналитику, до масштабирования еще дорасти надо, но заложить фундамент можно конечно, но соблюдать баланс, что бы не мучаться на первых этапах

Нажмите, чтобы раскрыть...

ну какое задание, такое и решение.

Никаких цифр нет, данных по географии серверов нет, по критичности компонентов инфраструктуры тоже.

Плюс для всего этого ещё нужно понять на каком уровне идёт разработка системы - на этапе концептуального проектирования или на этапе пересборки из того что есть физически в наличии и уже как-то работает.

MEDI_OFF

Пользователь

Регистрация: 19.07.2018

Сообщения: 53

Рейтинг: 16

MEDI_OFF

Регистрация: 19.07.2018

Сообщения: 53

Рейтинг: 16

img
Максим Феофилов сказал(а):

Можно и мне вмешаться.

Я пробежал глазами. Не всё осознал. Но на вскидку накидаю идей на подумать.

1)Точно ли пиар предполагает, что все пользователи пойдут дальше регистрации и будут пользоваться вашим кор функционалом?

Если нет, а большая часть отвалиться на лендинге \ регистрации \ привязке карты, и т.д.

Начни с размещения статичного контента с cdn. Это решит дёшево и сердито большую часть проблем

2)Если говорить о скалабилити, есть горизонтальное и вертикальное. 

Если упрожняешься в систем дизайне, не забывай про шардинг. 

 

3)Дизайнить систему, без конкретных цыфр - смерти подобно. 

Нажмите, чтобы раскрыть...

1. Про CDN скажу что и про все другие технологии что тут советовали, инструменты выбираться должны подходящие исходя из задач и требований, а тут еще это рано

2. До масштабов где юзается шардинг еще дорасти надо, исходя из размера БД который отписал ТС там еще очень далеко, так что то же самое что и первый мой ответ, все исходя из задач и требований

3. Тут сыглы на 100%

Renderhauer

Пользователь

Регистрация: 14.12.2013

Сообщения: 15092

Рейтинг: 15962

Renderhauer

Регистрация: 14.12.2013

Сообщения: 15092

Рейтинг: 15962

MEDI_OFF сказал(а):

2. Каким образов считали RPS(Количество запросов в секунду)? Есть подозрение что вы сильно завышаете цифры

Нажмите, чтобы раскрыть...

как инженер по нагрузочному тестированию заявляю, что 500 - 1200 - далеко не самые большие цифры HAhaa.png

хотя конечно от транзакций и системы сильно зависит

недавно написал заглушку, которая держит 90к тпс кста Okayg.png