A
и следовательно завязываясь на 1 инстанс вы уже допускаете архитектурную ошибку (
Size: a a a
2020 October 13
SC
Просто у меня инстансов приложений, по которым я собирался разбивать на спейсы, десятки тысяч. Это значит десятки тысяч Тарантулов? Звучит странно.
DS
да, тут только шардирование
KN
да, тут только шардирование
+
DS
вот только нужно прикинуть, влезут ли "жирные" инстансы в один бакет (хотя если там вся база 1тб, то наверное и бог с ним)
SC
Ну, допустим, шардирование будет, если поймём, что один инстанс не справляется. А что всё-таки со спейсами? Есть какой-то существенный выигрыш держать всё в одном спейсе (миллионы записей, лишний индекс по appId) по сравнению с кучей спейсов для каждого app-а?
KN
Ну, допустим, шардирование будет, если поймём, что один инстанс не справляется. А что всё-таки со спейсами? Есть какой-то существенный выигрыш держать всё в одном спейсе (миллионы записей, лишний индекс по appId) по сравнению с кучей спейсов для каждого app-а?
максимальное количество спейсов - где-то 65535
DS
при шардировании данных схема спейсов везде одинаковая
KN
я бы не рекомендовал. выигрыша мало по сравнению с multipart ключом
SC
я бы не рекомендовал. выигрыша мало по сравнению с multipart ключом
т.е. в пользу разных спейсов?
SC
при шардировании данных схема спейсов везде одинаковая
схема спейсов одинаковая
KN
т.е. в пользу разных спейсов?
нет, в пользу одного. выигрыша от разных спейсов нет, а менеджить один спейс проще чем много
KN
и сделайте шардинг сразу
KN
потом сложно будет
DS
схема спейсов одинаковая
ну я к тому что если если шардировать - то один большой спейс
KN
шардинг - по ID приложения например
A
потом сложно будет
а почему потом сложно?
KN
придется переписывать логику
KN
и делать миграции
KN
лучше сразу заложить (это опыт просто)