какой самый эффективный способ в таком битмапе: 101011101000110
определить, что 1 находится на позициях: 1,3,5,6,7,9,13,14
?
итерацией там аж 2 for + 1 if получается

забыл упомянуть, что 64 битами тут не ограничивается
строка может иметь более миллиона 0/1

а сколько может быть индексов в таком векторе?
у меня скорее наоборот - 1 вектор с индексами (но на лям индексов), а не 255

ну а так если:

Dima Tизбыточность в 256 раз
опять накурился
Я бы для начала поковырял откуда это недоразумение взялось и там бы порядок навел.
отсюда
порядок там не навести
можно кое-что улучшить, например, ф-ю в постгрю перенести, чтобы не гонять туда огромный список ID
ну и вроде всё.

L.OtujktdЯ бы сделал буфер размером с макс.длину строки и работал бы с ним(записывал/читал бы результат), и никаких stl-классов
вот только операция одноразовая

я спрашиваю здесь, потому что тут самые эффективные алгоритмы

maytonНапомнило мой топик https://www.sql.ru/forum/1242903/tyapnichnyy-poisk-tovarov-po-naboru-atributov
ну так эта тема про решение твоей проблемы
а советы фронтендеров с фреймворками для меня имеют нулевую ценность, поэтому у меня в их разделе 0 тем

maytonДавайте обсудим недостатки решения которое приведено в статье https://habr.com/ru/post/261137/
если что не устраивает, есть ещё монга и эластик
но как по мне решение идеальное
на самом деле тут редис то вроде и не нужен (надо тестить)
в постгре можно ф-ю держать, она также в памяти отработает

maytonПостгрес никогда не считался быстрой системой. Такова его архитектура. Поэтому. Есть у меня сомнения.

По поводу редиски я не против но нужен внятный механизм расширения бизнес модели этих фасетов
и классификаторов.

Вангую что девочка-контент-менеджер магазина просто ушатает эту систему постоянно (2-3) раза в час
закидывая туда новые типы товаров и их атрибутов поиска.

Если механика расширения (на ходу!) изначально заложена то гуд. Если нет - то система будет постоянно
ребилдится и как следствие недоступна.

Вангую также что девочка закинет туда 100500 классов (из Экцеля ага) просто так на всякий случай.
на будущее. И эти пустые атрибуты навсегда займут место в битовой маске. И не будет никакой
возможности в будущем их утрамбовать обратно.

К каким последствиям приведет пустое неиспользованое захватывание бит в маске вы можете
посчитать. Это память сервера Redis. А память обычно очень быстро кончается.

Вот теперь давайте обсуждать эти поинты. И если эти сценарии невозможны - то почему.
там есть один нюанс, которого в статье нет
нужна агрегация
потому что только агрегация даст последовательную цепочку ID, которым соответствуют позиции 01 в битмапе (они же последовательно идут)
иначе неизбежны пробелы.
с одной стороны доп.костыль, а с другой - нет никаких проблем с обновлением в любой точке
чё угодно можно выкинуть, чё угодно вставить
и никакие девки не страшны
лишние атрибуты конечно надо выкидывать, а как ещё
только вот атрибуты хранятся в справочнике и их можно автоматически включать в фильтр

памяти там 625 КБ
авторплюсы такого решения:
1) Жрёт мало памяти. У нас > 50000 товаров, около 100 значений фильтров, то есть 50000 * 100 = 5 000 000 бит = всего 625 килобайт памяти.
2) Очень быстро. Сложность побитовой операции O(N), тем не менее, строки у нас не миллионами байт измеряются, а перемножить пару-тройку битмапов ио 50000 бит — задача пары микросекунд для процессора. Overall, в худшем случае (перемножение всех фильтров), замеряя разницу времени в PHP до отправки команды в REDIS и после получения результата — 40мс (это с доп. функцией из п.3, далее). Вполне реалтаймовая генерация страницы, для веба пойдёт. Если кажется много — просьба кешируйте результат, но нас это удовлетворило вполне.
maytonПостгрес никогда не считался быстрой системой. Такова его архитектура. Поэтому. Есть у меня сомнения.
во1, это не так. Откуда такое заявление взялось?
во2, речь про операции в памяти. Мелкая таблица с атрибутами измеряется в килобайтах и будет в памяти всю дорогу. Накинуть на неё операцию AND - займёт, по идее, столько же, сколько и в редиске.
Вопрос только в алгоритмах, но там же стандартная библиотека должна быть.
maytonНо почему за более чем 20 лет эволюции, Postgres не предоставил нам коробочного решения для фасетного поиска?
ты же говорил, что любитель послушать лекции по постгре, так там Бартунов регулярно говорит, что людей мало, людей не хватает, люди вы где, ау?, люди, дайте людей!, вэлком люди, у нас куча задач, нужны люди, люди, ЛЮДИ11!
через одну повторяет
maytonКстати в одном из семинаров по постргресу главный постгресщик рассказывал историю возникновения JSONB.
До этого был другой подход. Просто в хранении списка ключевых слов и в текстовом индексировании. Я думаю
что это может быть то что нужно полудуху. Пускай он погуглит по легаси-плагинам. Или опять-же JSONB+index.
я про JSONB ещё года 2 назад всё изучил и тесты с монгой видел
JSONB не то.

PetroNotC SharpmaytonSELECT * from TOVAR where contains(hashtags,'Samsung','HDMI',......и еще штук 20 атрибутов)надо еще доказать что это долго.
Пример
(мусор удалён)
вы там с Димой один косяк на двоих чтоли курите
вот так фильтр выглядит: /?f=ap:5_3_5;bh:28_99_33;ck:7_9_22

maytonЯ думаю что поиск в БД по списку денормализованных атрибутов - не согласуется с чистой теорией.
Это даже не 1НФ. Но есть потребности бизнеса в том чтобы искать какую-то хрень например
денормализация и поиск по ID - это самый быстрый вариант что-то найти

maytonна это ЛЮДИ нужны, а их нет. Сам такой поиск у них не в приоритете.
FTS и так есть. И кстати, в постгресе редиску тоже можно прикрутить.
также как у них есть битмапы на любую длину и операции по ним.

Ну и пускай нужны. Я-то тут причем?

По поводу FTS. Насколько я понимаю он потребности фасетного поиска не покрывает.
Если-бы покрывал - господин на хабре не стал-бы писать статью про Редисочный поиск.