Size: a a a

2020 December 10

KN

Konstantin Nazarov in Tarantool
Илья Ермолин
я же правильно понимаю, что в этом примере все имя приводится к 3 байтам (через or).
соответственно чем длиннее строка - тем менее избирателен индекс... (у длинной строки все биты буду в 1 выставлены)
нет, там делается аналог bloom filter
источник

KN

Konstantin Nazarov in Tarantool
каждая подпоследовательность из 3-х символов в строке приводится к одному из битов внутри битовой строки
источник

KN

Konstantin Nazarov in Tarantool
битовая строка ограничена
источник

KN

Konstantin Nazarov in Tarantool
Илья Ермолин
я же правильно понимаю, что в этом примере все имя приводится к 3 байтам (через or).
соответственно чем длиннее строка - тем менее избирателен индекс... (у длинной строки все биты буду в 1 выставлены)
на практике достаточно повысить избирательность в 100 раз (7 бит) чтобы сделать сканирование больших коллекций за разумное время
источник

KN

Konstantin Nazarov in Tarantool
есть способы как сделать еще лучше за счет стемминга например
источник

KN

Konstantin Nazarov in Tarantool
но я хотел код который уместится на 1-2 страницы
источник

ИЕ

Илья Ермолин... in Tarantool
вопросов нет - отлично получилось.
Все же по коду получается что не каждая подпоследовательность из 3-х символов в строке приводится к одному из битов внутри битовой строки
А просто они друг с другом через битовый OR объединяются
   local res = 0
  for i = 1,#str-2 do
     local c1 = string.sub(str, i, i)
     local c2 = string.sub(str, i+1, i+1)
     local c3 = string.sub(str, i+2, i+2)

     local val = string.byte(c1) * 10000 +
        string.byte(c2) * 100 + string.byte(c3)
     res = bit.bor(res, bit.lshift(1ULL, val%64))
  end

берется 3 байта по очереди.
объединяются в одно число со сдвигами (умножениями).
Потом результат - это OR от предыдущей итерации + текущее значение
источник

ИЕ

Илья Ермолин... in Tarantool
но как заготовка и пример использования битового инндекса - очень красиво!
источник

MF

Michael Filonenko in Tarantool
к одному bit.lshift(1ULL, val%64)
источник

ИЕ

Илья Ермолин... in Tarantool
Понял - круто
источник

KN

Konstantin Nazarov in Tarantool
Илья Ермолин
вопросов нет - отлично получилось.
Все же по коду получается что не каждая подпоследовательность из 3-х символов в строке приводится к одному из битов внутри битовой строки
А просто они друг с другом через битовый OR объединяются
   local res = 0
  for i = 1,#str-2 do
     local c1 = string.sub(str, i, i)
     local c2 = string.sub(str, i+1, i+1)
     local c3 = string.sub(str, i+2, i+2)

     local val = string.byte(c1) * 10000 +
        string.byte(c2) * 100 + string.byte(c3)
     res = bit.bor(res, bit.lshift(1ULL, val%64))
  end

берется 3 байта по очереди.
объединяются в одно число со сдвигами (умножениями).
Потом результат - это OR от предыдущей итерации + текущее значение
я там перемудрил слегка, можно было просто guava hash взять
источник

KN

Konstantin Nazarov in Tarantool
получилось бы более равномерно
источник

KN

Konstantin Nazarov in Tarantool
от гуавы просто последние 64 бита взять
источник

KN

Konstantin Nazarov in Tarantool
или даже не так - меньше
источник

KN

Konstantin Nazarov in Tarantool
6 бит
источник

ИЕ

Илья Ермолин... in Tarantool
конструкцию осознал только с 3 подхода.
Отлично получилось.
источник
2020 December 11

R

R-omk in Tarantool
для vshard  есть потребность узнавать на  стораже   что бакет приехал / уезжает / уехал ,    

пока из того что придумал - повесить триггер на системный спейс..  

это нужно для того чтобы фоновые службы конфигурировать

в тикетах подобной фичи почему то не описано,     может были какието планые на это уже ?
источник

VS

Vladislav Shpilevoy in Tarantool
Не было
источник

VS

Vladislav Shpilevoy in Tarantool
Тут надо дизайнить само понятие бакета в юзерспейсе. Потому как сейчас у юзера ничего кроме bucket_id нет. Надо как-то аккуратно сделать, чтоб юзер мог смотреть статус, получателя, и все такое. Я не просто в спейсе ковырялся, в котором это еще и поменяться может
источник

VS

Vladislav Shpilevoy in Tarantool
Например, хранение статус бакета строкой - трата места. Но в юзерспейсе наверное надо показывать строкой будет все равно, даже если в _bucket поменяется
источник