R
также для нас приоритет — высокий uptime при обновлениях и миграциях БД
Это же можно решить зеркалированием сервера просто
Size: a a a
2019 July 12
ТС
также для нас приоритет — высокий uptime при обновлениях и миграциях БД
это тоже имеет свои последствия при выборе техногий
ТС
Это же можно решить зеркалированием сервера просто
ну ок ))
ТС
(пошел зеркалировать свои сервера)
R
ну ок ))
Ну может не просто....) Но обычно так решают Uptime)
KТ
тут дело не в нагрузке.. а в росте объема данных
ТС
тут дело не в нагрузке.. а в росте объема данных
именно в твоем кейсе?
KТ
R
(пошел зеркалировать свои сервера)
Kubernetes вроде как должен же решать это на Изи)
KТ
вместо того чтобы делать мастер, слейв и еще там несколько узлов. кассандра как я понял она распределенная и без явного мастера
ТС
Kubernetes вроде как должен же решать это на Изи)
работу с данными пока никто не решил ИМХО
KТ
Kubernetes вроде как должен же решать это на Изи)
думаю не самая лучшая идея БД в контейнер пихать
ТИ
тут дело не в нагрузке.. а в росте объема данных
Ну рост объема обычные БД решают тоже.
R
А где можно в Кз поработать с highly scalable, distributed systems? Таир, у вас можно такой experience взять?)
KТ
Ну рост объема обычные БД решают тоже.
например
R
работу с данными пока никто не решил ИМХО
Сихронизация их?
Решения типа hadoop spark анау мынау не вариант?
Решения типа hadoop spark анау мынау не вариант?
ТС
работу с данными пока никто не решил ИМХО
серебряной пули в работе с данными пока нет, насколько мне известно, поэтому у нас команда решает это обратно-совместимыми инкрементами с миграцией данных на уровне приложения
R
серебряной пули в работе с данными пока нет, насколько мне известно, поэтому у нас команда решает это обратно-совместимыми инкрементами с миграцией данных на уровне приложения
Haystack Facebook?
ТС
т.е. грубо говоря, приложение берет на себя всю логику по обеспечению совместимости при апгрейдах, и принципиально не пользуется средствами хранилищ для этого
R
Миллиардные нагрузки решает + данных дофига и больше