Comments 4
Для редкого префикса запрос за шардом равен запросу за товаром: k-анонимность равна единице. Лечится это укрупнением ключа для разреженных префиксов (три цифры вместо четырёх) или добиванием файлов до общего размера. Пока не сделано — и это, пожалуй, главный недостаток текущей схемы.
Категорически непонятно, в чём экономия дробить 429 КиБ на шарды. Кажется, это сделано больше ради спортивного интереса. Вероятно, разница скачивания файла в ~1КБ и в ~500КБ будет в пределах сотен миллисекунд. Будет больше расходов на пинг и сетевые запросы. И тоже самое касается вопроса анонимности. Вроде как что то и есть, но в итоге всё равно стремится к нулю.
Если следовать такой логики, можно попробовать:
Добавить ETag на файлы. А если коды обновляются раз в несколько недель, то можно и кэшировать на дни, а не на час.
Допустим, мы хотим анонимности на уровне, что бы не знать, какой именно из ~10-100 товаров отсканировал человек. Вместо того, что бы запрашивать файлы с размером в 1-10 товаров, клиент может всегда запрашивать N случайных файлов. Размер среднего файла у вас указан как 1,4 КБ, что примерно равно MTU. Отсюда могу предположить, что время отдачи ~10 мелких файлов (в пределах ~1кб по http2), будет равно времени отдачи одному среднему файлу.
Согласен: при общем размере 429 КиБ это самое спорное место схемы. Шарды появились из предположения «один скан — один маленький запрос», но без замера времени первого скана на типичной мобильной сети это именно гипотеза, а не доказанная экономия. Целый файл при этом заметно проще и даёт настоящую приватность, а версия в URL плюс долгий immutable-кэш убирает цену на повторных посещениях. ETag тоже поможет, хотя при проверке свежести всё равно останется сетевой round trip.
Запрос настоящего шарда вместе с N случайными — интересный промежуточный вариант: сервер будет знать только то, что нужный префикс находится среди N. Но такая защита быстро слабеет на повторных сканах — наборы можно пересекать, размеры и популярность шардов сильно различаются, а случайный файл иногда окажется не килобайтным, а одним из тяжёлых. Если сохранять нарезку, я бы скорее склеивал редкие префиксы в группы близкого размера или дополнял ответы до фиксированного размера.
Так что да: пока замеры не покажут заметный выигрыш первого скана, 1387 шардов больше похожи на переусложнение. Для базы в несколько сотен килобайт один файл, вероятно, честнее.
Куча технических мелочей, но какая задача решалась и с какой целью её стоило бы решать не понятно.
Да, я начал с механизма раньше, чем показал сам сценарий. Он простой: человек один раз сканирует код камерой, а интерфейсу нужно показать название товара. Полный код можно отправить во внешний товарный API — тогда его оператор получает код, IP и время. Можно скачать справочник целиком. Мы выбрали третий вариант: наружу уходит только префикс, а браузер забирает один небольшой фрагмент базы.
Но у этого решения было ещё одно предположение: что для короткой сессии «один код и закрыли» начальная загрузка 429 КиБ достаточно существенна, чтобы ради неё усложнять схему. В статье это не подтверждено замерами. Поэтому техническая задача описана, а ответ на более важный вопрос — зачем здесь нужна такая сложность — действительно остался недоказанным. Эту развилку следовало поставить до устройства файлов.
Отдали базу штрихкодов статикой: 1,9 МБ, 1387 шардов, медиана в одну строку