2016-01-07 2 views
2

Я вижу примеры в документации, где можно взять запись или поток записей из набора и выполнить некоторые действия. Я хотел бы взять запись, получить идентификатор из этой записи, найти этот идентификатор в другом наборе и вернуть содержимое бункера из второго набора. Это эффективно соединение, например.В Aerospike, можно ли «цепочка получает» с UDF?

function chained_get(rec) 
    if aerospike:exists(rec) then 
     local other_id = rec.other_id 
--  how to return the result of: 'SELECT some_bin FROM namespace.some_bin WHERE PK = other_id' 
    end 
    return result 
end 

Я понимаю, что было бы легко сделать на стороне клиента/приложения, но я хотел бы избежать сети «болтовня», если это возможно, и «цепи» запросы оздействуй Aerospike.

Возможно ли это?

ответ

3

Короткий ответ: нет, Aerospike Server не поддерживает такие объединения (пока?), Где сам сервер принимает активное участие. Но есть обходные пути для близких одиночных задержек в оба конца:

Проблема с соединением в распределенной базе данных состоит в том, что другая запись может быть на другом узле кластера. Но в зависимости от того, что вы пытаетесь сделать, очень вероятно, что вы можете сделать это с помощью других инструментов, предлагаемых Aerospike. Например, одна мощная функция - это функция вторичного индекса. Вы можете, например, иметь пользователя и набор заказов (записей). Чтобы избежать необходимости сначала искать пользователя, а затем выдавать пакетный доступ ко всем заказам, вы можете выдать пользователю get и запрос, который доставит вам все записи с идентификатором пользователя id = xyz в бункере, который индексируется параллельно и слияние на клиентском компьютере, боковая сторона. Недостатком является то, что все узлы получат запрос, потому что неизвестно, где расположены ордера, и что вам нужно примерно 45-70 байт ОЗУ на запись вторичного индекса. Тем не менее, вам следует проверить, работает ли это лучше, чем ваш вариант с двумя вариантами «туда и обратно», поскольку он зависит от приоритета запросов, среднего размера индекса и т. Д.

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

3

Запись UDF не может получить доступ к другим записям, а поток UDF может работать только с записями, передаваемыми из сканирования, или как результаты, сопоставляемые вторичным индексом запроса. JOINs могут быть реализованы на стороне приложения.

Смежные вопросы