Но как и у любого хэша, встает вопрос того насколько хороша сама функция

Та что в carbon-relay быстро перестала нас устраивать

Мы реализовали одну из более равномерных, но там тоже возникли те же проблемы

Собственно на картинке выше - разница между самым загруженным и свободным серверов составляет несколько тысяч метрик в секунду.

В худшем случаи разница может быть до 20%

Тогда мы начали искать что-нибудь получше

Мы нашли Whitepaper от Google про jump hash

И буквально тремя строчками кода сделали распределение практически идеально совпадающим

Время шло, люди пользовались графитом

И стали делать много странных запросов

Даже более того - начали использовать графит под мониторинг

И производительности graphite-web в нашем случаи под нашей нагрузкой перестало хватать

И мы переписали нужные куски опять же на Го

Этим сократили время ответа пользователям с 15с до 0.8с

В начале были ответы только json'ом, но позже появился и png

(недавно реализовали noscript)

То что фронтэнд стал быстрее позволило нам делать более сложные запросы

например мы стали рекомендовать людям не делать пре-агреграцию на carbon-c-relay

а делать сразу по данным в интерфейсе

Стало проще добавлять сложную математику