Решардинг, если по хорошему, это процесс появления шарды (одной или нескольких её частей) в новом месте с последующим удалением шарды из старого места. Т.е. по определению, шарда должна быть доступна в любой момент этого процесса.
Если клиент воспользовался старой таблицей и шарды уже нет на том месте, то 404, видимо. Можно облегчить ему участь и попробовать поискать нужную шарду на той ноде, куда он попал (шанс, что там более новая таблица роутинга, достаточно велик), т.е. редирект на следущую ноду и так далее, до исчерпания TTL (как и в обычном роутинге).
Я не готов пока к column-based хранилищам, key-value со сложными индексами мне пока ближе.
Ну и в Vertica проблема, что за энтерпрайзом не разглядеть ничего. Дальше маркетолухных прессрелизов на их сайте пробраться не удалось. Видимо, я пока не готов к настолько Big Data :)
Comments 11
Reply
Вопрос: а что будет, если будет решардинг, а какой-то клиент будет пользоваться старой таблицей с меньшим числом шард?
Reply
Если клиент воспользовался старой таблицей и шарды уже нет на том месте, то 404, видимо. Можно облегчить ему участь и попробовать поискать нужную шарду на той ноде, куда он попал (шанс, что там более новая таблица роутинга, достаточно велик), т.е. редирект на следущую ноду и так далее, до исчерпания TTL (как и в обычном роутинге).
Reply
Reply
Reply
Reply
Ну и в Vertica проблема, что за энтерпрайзом не разглядеть ничего. Дальше маркетолухных прессрелизов на их сайте пробраться не удалось. Видимо, я пока не готов к настолько Big Data :)
Reply
Leave a comment