get next key
Mar. 1st, 2014 11:00 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
netch80В разнообразных новых движках БД (которые принято называть NoSQL, хотя NoRel было бы адекватнее) обожают key-value подход, но изображают хэш - все ключи независимы. В Riak в принципе не вводили связь между соседними ключами. Этому есть какие-то конструктивные причины? Или это просто недоработка авторов, потому что им такого было не нужно?
Очень много задач удобно решаются с помощью операций типа "получить значение ключа, следующего за данным в порядке выбранной сортировки". BerkeleyDB это умела почти с рождения. SQL движки - тоже (пусть это и надо получить заклинаниями типа ORDER BY + LIMIT n, внутри всё равно исполняется проход по упорядочённому индексу). В случае неподдержки такого приходится заниматься закатом солнца вручную (например, с рисованием индексов своими силами).
Одно частичное возражение я вижу - шардинг. Его в некоторых случаях удобно делать через отдельные биты хэша ключа, в таком случае задача "найти следующий", если делается на локальных хранилищах, требует запроса ко всем шардам. Но это только удорожание операции, если она нужна, а не принципиальная невозможность; к тому же минимальное кэширование результатов лукапа делает цепочку таких getnext не дороже прохода по локальному хранилищу. Ещё какие-то причины?
Очень много задач удобно решаются с помощью операций типа "получить значение ключа, следующего за данным в порядке выбранной сортировки". BerkeleyDB это умела почти с рождения. SQL движки - тоже (пусть это и надо получить заклинаниями типа ORDER BY + LIMIT n, внутри всё равно исполняется проход по упорядочённому индексу). В случае неподдержки такого приходится заниматься закатом солнца вручную (например, с рисованием индексов своими силами).
Одно частичное возражение я вижу - шардинг. Его в некоторых случаях удобно делать через отдельные биты хэша ключа, в таком случае задача "найти следующий", если делается на локальных хранилищах, требует запроса ко всем шардам. Но это только удорожание операции, если она нужна, а не принципиальная невозможность; к тому же минимальное кэширование результатов лукапа делает цепочку таких getnext не дороже прохода по локальному хранилищу. Ещё какие-то причины?
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2014-03-01 01:55 pm (UTC)Так ведь кеширование get_next_key может дать результат не от момента начала операции, а более старый. На первом шарде данные обновились, а второй об этом не узнал и на запрос выдал устаревший закешированный результат.
Это, как я понимаю, вообще главная проблема шардинга и реплик. С одной стороны, для констистентного ответа надо бы знать актуальную информацию с других шардов, а с другой - если их на каждый запрос опрашивать, теряется смысл шардинга. Вот и получается, что набор возможных запросов оказывается ограничен теми, на которые может дать авторитетный ответ один шард самостоятельно.
no subject
Date: 2014-03-01 09:52 pm (UTC)Нет, я имел в виду вариант, когда кэширование начинает действовать только от начала операции, или по другим правилам, но тоже ограниченным во времени.
> Это, как я понимаю, вообще главная проблема шардинга и реплик. С одной стороны, для констистентного ответа надо бы знать актуальную информацию с других шардов, а с другой - если их на каждый запрос опрашивать, теряется смысл шардинга.
Для наиболее массовых операций, таких, как чтение по конкретному ключу, запись по ключу, шардинг распределяет сразу в нужную точку. А вот шаги вперёд-назад - тут да, есть тонкости.
no subject
Date: 2014-03-24 11:31 am (UTC)