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: 2016-11-26 08:17 pm (UTC)Полез в гугл, на первой же странице нашел замечательное:
------
Отзыв о работе в massive solutions / город Киев / Черный список ...
https://antijob.net/black_list/massive_solutions/
Рейтинг: 1% - Автор рецензии: Анонимный пользователь
30 окт. 2013 г. - Мало того, что платили в среднем ниже, чем на рынке. Так еще и задолжали зарплаты всем. Кормили обещаниями, как всё у нас будет ...
------
no subject
Date: 2016-11-27 12:29 pm (UTC)no subject
Date: 2016-11-27 02:03 pm (UTC)