get next key

[netch80]

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

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

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

Comments

[lionet.livejournal.com]

Облегчение контракта упрощает смену бэкендов, например. Там же несколько бэкендов поменялось с тех пор, как ввели. Некоторые бэкенды (bitcask?) вообще ключ не пускают в индекс, а хранят хэш от него.

[netch80.livejournal.com]

> Облегчение контракта упрощает смену бэкендов, например.

Никто не мешает какие-то операции просто не допускать в зависимости от включенного бэкенда.

А чрезмерное упрощение контракта приводит к потере важной функциональности.

[gul-kiev.livejournal.com]

Минимальное кеширование результатов не очень совместимо с шардингом - можно отдать неактуальный результат, и это может быть критично.
Собственно, запросы ко всем шардам вызывают ту же проблему даже без кеширования: на момент отдачи результата он может уже быть неактуален, рушится транзакционность.

[netch80.livejournal.com]

> Минимальное кеширование результатов не очень совместимо с шардингом - можно отдать неактуальный результат, и это может быть критично.

Для базы стиля Riak некоторая неактуальность результата существует всегда, это не RDBMS с двухфазной фиксацией стиля Oracle. Так что эту проблему однозначно можно перенести на клиента. Начинает операцию в какой-то момент - пусть будет готов получать данные только от этого момента, а если нет - пусть перезапускает операцию.

> Собственно, запросы ко всем шардам вызывают ту же проблему даже без кеширования: на момент отдачи результата он может уже быть неактуален, рушится транзакционность.

Не-а. Аналог шардинга есть и у ведущих RDBMS (в качестве обобщённого указания можно применять Oracle), и им это не мешает. А если идеальная транзакционность не нужна, то см. выше.

[gul-kiev.livejournal.com]

> Начинает операцию в какой-то момент - пусть будет готов получать данные только от этого момента, а если нет - пусть перезапускает операцию.

Так ведь кеширование get_next_key может дать результат не от момента начала операции, а более старый. На первом шарде данные обновились, а второй об этом не узнал и на запрос выдал устаревший закешированный результат.

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

[netch80.livejournal.com]

> Так ведь кеширование get_next_key может дать результат не от момента начала операции, а более старый.

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

> Это, как я понимаю, вообще главная проблема шардинга и реплик. С одной стороны, для констистентного ответа надо бы знать актуальную информацию с других шардов, а с другой - если их на каждый запрос опрашивать, теряется смысл шардинга.

Для наиболее массовых операций, таких, как чтение по конкретному ключу, запись по ключу, шардинг распределяет сразу в нужную точку. А вот шаги вперёд-назад - тут да, есть тонкости.

[netch80.livejournal.com]

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

[ospf-ripe.livejournal.com]

IMHO на getnext нет достаточно высокого спроса, поэтому и нет предложения. К тому же тем, кому принципиально не хватает key-value часто живут на SQL.

[netch80.livejournal.com]

У меня тут несовместимость требований. По заметной части их - нужен SQL, по другой части - нечто, что выживает в режиме "чуть меньше половины нод отвалилось, и надо всё равно сохранить, а потом прочитать с живых нод". Второе, по известным данным, более-менее нормально умеет только Riak. Который тупое key-value, и со странностями чуть более чем во всём.

[anonim-legion.livejournal.com]

Прошло 4 года. Уж не Dinect ли это был?

[netch80.livejournal.com]

Если вопрос про фирму - это была Massive Solutions.

[anonim-legion.livejournal.com]

Да, о фирме. Благодарю за ответ.

Полез в гугл, на первой же странице нашел замечательное:
------
Отзыв о работе в massive solutions / город Киев / Черный список ...
https://antijob.net/black_list/massive_solutions/
Рейтинг: 1% - ‎Автор рецензии: Анонимный пользователь
30 окт. 2013 г. - Мало того, что платили в среднем ниже, чем на рынке. Так еще и задолжали зарплаты всем. Кормили обещаниями, как всё у нас будет ...
------

[netch80.livejournal.com]

Ну, реально так и было. Правда, того, что выплачивалось (чуть больше половины обещанного), мне хватало с головой и выше - ушёл тогда, когда совсем уже стало безнадёжно. Может, автор постинга изначально на какие-то относительные копейки соглашался (я не опознаю, кто это мог быть). Проекты были очень интересные, много дали в плане развития.

[netch80.livejournal.com]

А вот про "ниже чем в среднем на рынке" (не сразу заметил) - врёт, мне кажется. Всем, про кого знал, назначалось выше рынка. (Потому и задержки не были большой проблемой.) Так что ещё больше интересно, кто это писал... что-то тут нечисто...