эффективное устранение старых документов - PullRequest
Новая
       28

эффективное устранение старых документов

1 голос
/ 03 мая 2020

Используя ArangoDB 3.6.x, у меня есть сценарий с непрерывными документами, поступающими в базу данных, и необходимостью непрерывного устранения старых. Каким может быть эффективный / простой алгоритм определения документов для устранения этих записей. Могу ли я использовать документ "_key" для выбора и исключения?

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

Я специально обращаю внимание на ArangoDB.

Спасибо, Жуан

1 Ответ

0 голосов
/ 06 мая 2020

Зависит от того, как вы квалифицируете «старые» документы. Если это по дате, то вы можете просто убедиться, что у каждого документа есть атрибут numberri c timestamp. Я использую функцию AQL DATE_NOW() или (new Date()).valueOf() в JavaScript. Затем просто добавьте индекс skiplist к атрибуту отметки времени, позволяя почти мгновенно сортировать и / или фильтровать по номерам, большим или меньшим, чем x. 

LET millisecondsAgo = (8 * 60 * 60 * 1000)  // 8 hours
FOR a IN collection_a
    FILTER a.timestamp < (DATE_NOW() - millisecondsAgo)
    REMOVE a IN collection_a

Если «старый» означает что-то еще, например, «существует ли этот документ в другой коллекции», тогда лучше всего иметь соответствующий ключ поиска. Это может быть атрибут _key или другой, но он должен быть уникальным. Я использую это для согласования «существующих» документов между коллекциями: 

FOR a IN collection_a
    FILTER LENGTH(
        FOR b IN collection_b
            FILTER b.uniqueKey == a.uniqueKey
            RETURN true
    ) == 0
    REMOVE a IN collection_a

Должен быть га sh индекс (называемый «постоянный индекс» в пользовательском интерфейсе, уникальный - это хорошо, но не обязательно) на collection_a и collection_b на uniqueKey. Затем запрос FOR b IN collection_b ... будет очень быстро совпадать с использованием индекса, возвращая true, если что-то будет найдено. Если не найдено ни одной записи, ничего не возвращается, поэтому возвращаемый массив имеет нулевую длину. Ха sh поиск ключей + вычисление длины очень маленького массива должно быть очень быстро.

...