Спустя некоторое время экспериментов с HurriCache я пришёл к важному выводу: чтобы существующие проекты могли попробовать решение с минимумом изменений, нужен способ быстрого входа без переписывания кода.

Строгая типизация в HurriCache — осознанный выбор. Мы явно создаём скаляры (целые числа, числа с плавающей точкой, байтовые массивы) и контейнеры (List, Vector, Queue, OrderedSet, HashSet, SortedMap, HashMap) без ленивого приведения типов. Это даёт предсказуемость поведения и контроль над памятью, но повышает порог входа: нельзя просто взять и «подставить» HurriCache вместо Redis, не меняя семантику работы с данными.

Чтобы решить эту проблему, мы добавили RESP‑коннектор, совместимый с Redis‑клиентами. И сразу столкнулись с фундаментальными различиями моделей данных: то, что в Redis «просто строка», в HurriCache требует явного типа и стратегии создания.

Около 5 лет назад я участвовал в миграции OCS с Oracle на Apache Ignite и обновлении стека самого чарджинга. Это была огромная по масштабам задача, так как она существенно меняла не только основную базу данных, но и систему доставки CDRs и модернизировала стек. Задача была выполнена. Хочу рассказать об одной интересной проблеме, которая связана с NATS — его решили использовать как очередь для экспорта CDRs в Hadoop.

В старой версии OCS Oracle выполнял роль временного хранилища CDRs, и особых проблем не было — связка работала годами. Так как от Oracle отказались, было решено модернизировать доставку CDRs и использовать NATS. NATS согласно документации был современным и дешёвым решением, а документация обещала отсутствие серьёзных проблем. В реальности же NATS никто не тестировал — просто посмотрели документацию, сделали небольшой стресс‑тест и решили: идём в NATS, тем более там есть поддержка кластера и, как казалось тогда, это должно работать без проблем. Сказано — сделано.

HurriCache это распределенная key-value база данных с поддерожкой как простых типов ключ значение так и конейнеров, блокировок, работы с atomics и многое другое. HurriCache может работать как standalone так и в кластере. В данной статье не буду сравнивать ее ни с каким либо продуктом, просто расскажу о том что умеет решение а остальные выводы пускай сделают пользователи.

Некоторое время назад мне пришла задача спроектировать высокопроизводительный балансировщик нагрузки для протокола Diameter. Через 3 месяца задача исчезла, так как как оказалось слишком долго и дорого, но в итоге балансировщик был сделан и имеется его MVP которое готово к установке как на реальное железо так и в облаке. В итоге продукт получился неплохим, и он с лихвой выигрывал имееющееся решение в той компании, по производительности был выигрыш раз в 6 по ресурсам раз в 100. Но суть не в этом, а в том что балансировщик был кластерным и умел хранить сессии в Redis. Решение было сделано, оно показало работоспособность, все хорошо, но меня не устраивала производительность. В тот момент я столкнулся с очень интересной проблемой - по каким то причинам я не мог пробить барьер в 5-7К Diameter Transactions per second. В принципе 5-7К TPS было неплохо, но проблемным участком как показал анализ был Redis. Проведя немного времени я смог добиться приемлемого результать и производительность поднялась до 20К TPS но там были другие проблемы.