Redis растровая стратегия разделения ключей

Question

Я собираю и архивирую МНОГО данных из API открытого источника данных Федеральной избирательной комиссии, который имеет уникальный идентификатор записи «sub_id», который представляет собой целое число из 19 цифр.

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

При чтении документации по растровым изображениям Redis максимальная длина хранилища составляет 2 ^ 32 (4294967296).

19-значное целое число теоретически может варьироваться в любом месте от 0000000000000000001 до 9999999999999999999. Теперь я знаю, что у рассматриваемого источника данных на самом деле нет 99 квинтиллионных записей, поэтому они явно малонаселенные и не последовательные. Из данных, которые в настоящее время хранятся в файле, максимальный идентификатор составляет 4123120171499720404, а минимальное значение - 1010320180036112531. (Я могу сказать идентификаторам дату на основе, поскольку в ключах 2017 и 2018 соответствуют датам записей, к которым они относятся, но я не могу воспроизвести остальную часть шаблона.)

Если я захочу сохранить позиции, которые я уже скачал, понадобятся ли мне 2328306436 различных растровых изображений redis? (9999999999999999999/4294967296 = 2328306436.54). Я мог бы, вероятно, разработать крошечный алгоритм определения с учетом 19-значной идеи деления на некоторую константу, чтобы определить, какой разделенный индекс растрового изображения нужно проверить.

Нет такой стратегии, которая кажется разумной, поэтому я думаю, что в корне неправильно понимаю некоторые аспекты этого. Я?

Answer 1

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

Однако на это трудно указатьлучшее решение, не зная, сколько различных sub_id с вашим набором данных.Если вы говорите о нескольких десятках миллионов, простого набора в Redis может быть достаточно.

Answer 2

Сколько есть "предметов"?Что такое "много"?

В любом случае.Линейный подход, который использует один бит для отслеживания каждого из 10 ^ 19 потенциальных элементов, требует как минимум 1250 петабайт.Это делает нецелесообразным (атм) хранить его в памяти.

Я бы порекомендовал вам самим узнать о вероятностных структурах данных в целом, и после того, как вы наткнулись на компромиссы, посмотрите на использование чего-то из RedisBloom набор инструментов.