get next key

[netch80]

В разнообразных новых движках БД (которые принято называть NoSQL, хотя NoRel было бы адекватнее) обожают key-value подход, но изображают хэш - все ключи независимы. В Riak в принципе не вводили связь между соседними ключами. Этому есть какие-то конструктивные причины? Или это просто недоработка авторов, потому что им такого было не нужно?

Очень много задач удобно решаются с помощью операций типа "получить значение ключа, следующего за данным в порядке выбранной сортировки". BerkeleyDB это умела почти с рождения. SQL движки - тоже (пусть это и надо получить заклинаниями типа ORDER BY + LIMIT n, внутри всё равно исполняется проход по упорядочённому индексу). В случае неподдержки такого приходится заниматься закатом солнца вручную (например, с рисованием индексов своими силами).

Одно частичное возражение я вижу - шардинг. Его в некоторых случаях удобно делать через отдельные биты хэша ключа, в таком случае задача "найти следующий", если делается на локальных хранилищах, требует запроса ко всем шардам. Но это только удорожание операции, если она нужна, а не принципиальная невозможность; к тому же минимальное кэширование результатов лукапа делает цепочку таких getnext не дороже прохода по локальному хранилищу. Ещё какие-то причины?

Comments

[netch80.livejournal.com]

Кстати, ещё вариант - совсем не требовать функциональности курсора, но сделать запрос типа get_around(key, order_type, n_from_each), где order_type - одно из '>', '>=', '<', '<=', n_from_each - сколько ближайших брать с каждого шарда. Дальше пусть клиент сортирует и разбирается, сколько из этих данных ему нужно на ближайшее время.