Хеш-таблица(мапа) — одна из самых популярных структур данных, потому что поиск по ключу происходит за O(1). Причем ключ может быть любым любым типом, элементы которого можно сравнивать (Comparable Trait).

Я столкнулся с тем, что мапа не такая быстрая по бенчмаркам на языке GO, хотя теоретическая сложность алгоритма О(1).

Давайте рассмотрим следующую задачу и способы ее решения.

Вступление

Схема разделение секрета, ключа или пароля не новая, но во всех спецификациях, которые я встречал есть главный недостаток — доли и сам секрет различимы по структуре или длине. To есть по каждой доле разделяемого секрета можно было сказать это "доля", а не настоящий секрет.

Хотелось бы посмотреть в другую сторону и сделать совершенную схему, в которой

• восстановить секрет можно только имея $$ из $$ долей $$
• длина доли и секрета была одной и той же
• у доли не было бы структуры, то есть доля была похожа на случайную последовательность байт
• каждая доля сама по себе были бесполезные. Более того, количество долей меньших $$ тоже были бесполезными и не раскрывали искомого секрета
• длина искомого секрета могла быть любой
• при утере долей, меньших $$, можно было разделить секрет на доли заново, а после этого уничтожить оставшиеся доли. Тем самым секрет никогда не будет восстановлен по утерянным долям.

Хотелось бы поделиться опытом оптимизации данных с целью уменьшения расходов на ресурсы.

В системе рано или поздно встает вопрос об оптимизации хранимых данных, особенно если данные хранятся в оперативной памяти, как это БД Redis.

Как временное решение, можно увеличить RAM тем самым можно выиграть время.

Redis это no-sql база данных, профилировать ее можно с помощью встроенной команды redis-cli --bigkeys, которая покажет кол-во ключей и сколько в среднем занимает каждый ключ.

Объемными данными оказались исторические данные типо sorted sets. У них была ротация 10 дней из приложения.

Проект в продакшене, поэтому оптимизация никак не должна была сказаться на пользователях.

Данные из себя представляли события измененияцены / даты доставки у оффера. Офферов было очень много – порядка 15000 в каждом фиде (прайслисте).

Рассмотрим следующий пример данных события по офферу: