DK
Size: a a a
2020 December 26
Э
Принцип распределения и «компилятор php”
напишу тогда "обработчик пыхэпэ" 😄
DK
В данной архитектуре нет и намёка на redundancy
DK
Плюс не ясно какие приложения используют какие хранилища, если
DK
В данной архитектуре нет и намёка на redundancy
Что произойдёт если у d103 кончится память если вдруг в память редис попадёт слишком много данных?
Э
Что произойдёт если у d103 кончится память если вдруг в память редис попадёт слишком много данных?
out of memory? Можно же будет ограничить поставку данных, установить лимиты?
DK
На каком моменте постря поймёт что ее злейший враг-это MySQL?
Э
На каком моменте постря поймёт что ее злейший враг-это MySQL?
mysql для хранения двух старинных баз, после переезда он удалится оттуда
Э
Плюс не ясно какие приложения используют какие хранилища, если
В s104 лежат большие файлики по несколько гигабайт, ссылку на который даёт бекенд. На серверах фронта и бека лежит только код приложения, ничего больше
DK
out of memory? Можно же будет ограничить поставку данных, установить лимиты?
Вопрос - зачем закладывать такие риски в архитектуру и делать редис зависимым от MySQL, Postgres и наоборот
DK
Как происходит балансировка нагрузки / redundancy в каждом из tier-ов?
Э
редис изначально планировал на b102, но поняв, что редис не надо будет клонировать, а масштабировать как бд - вынес его к субд
DK
Короче co-hosting это плохо
Э
У тебя есть какие-то решения, которые заслужили твоё доверие?
DK
У тебя есть какие-то решения, которые заслужили твоё доверие?
В смысле? Все зависит от требований. Начиная от выноса redis отдельно, заканчивая облачными провайдерами
Н
Ребят, привет. Впервые планирую архитектуру для компании. Задача разбить задачи по разным серверам, изолировать их друг от друга и общатся по сети. При увелечении нагрузки сможем клонировать b102 в b106
Префиксы в названии обозначают задачу (front, back, database, monitoring, storage)
Префиксы в названии обозначают задачу (front, back, database, monitoring, storage)
я за 1 виртуалка = 1 сервис, чтобы не огрести от конкурентности ресурсов
DK
Но вообще, меня смущает наличие такого количества технологий в такой маленькой инфраструктуре.
DK
А Если что-то легаси, его надо отдельно держать, и это должно на архитектуре тоже отразится
DK
я за 1 виртуалка = 1 сервис, чтобы не огрести от конкурентности ресурсов
Как минимум так. Но может и не так, если требования redundancy отличаются можно все приложение оставить на одном хосте
DK
Но вообще, меня смущает наличие такого количества технологий в такой маленькой инфраструктуре.
В частности, интересует цель наличия Redis, MySQL, Postgres, MongoDB