Что использовать в качестве БД для поиска/агрегирования по тегам?
Есть задача:
- несколько миллионов, в перспективе, миллиардов записей.
- у каждой записи есть от нуля до сотни тегов и несколько значимых полей (набор тегов ограничен, но медленно расширяется)
- необходимо очень быстро находить первые (по времени/убыванию id) 10-20 тысяч записей по набору тегов (если подходящих записей меньше, то находить все)
- скорость поиска очень важна
- скорость добавления не важна
- размер базы с индексами скорее важен (для десктопной версии), чем нет (иначе логично было бы создать запись в реляционной бд с полем на каждый тег и индексом на него - искало бы быстро, а остальное неважно
Есть ли готовая система, легко ставящаяся и настраиваемая (притом под и под линухом и виндой)?
Понятно, что можно относительно легко замутить своё блекджек с поэтессами, но не очень хочется.
Всё не так страшно (MSSQL, mysql,postgres - сгодится):
1. создайте таблицу НАБОРОВ тегов с ID-шниками самих тегов и с ID-самого набора.
2. К каждой записи при добавлении - ставьте нужный ID-шник набора тегов.
3. При выборке по тегам - получаете из таблицы набора нужные ID-шники подходящих наборов.
4. По этим наборам - делаете выборку из основной таблицы с любым нужным фильтром и сортировкой.
Таким образом, Вы ускорите поиск, т.к. не нужно будет проверять уже сами теги и обращаться к другим таблицам для сопоставления (пересечения).
Ну фактически вы предлагаете вместо встроенного индекса БД строить искусственный индекс.
Не думаю, что это даст приемлемый размер базы. И точно будет медленнее поиска по одной таблице с сотней индексов на каждый тег.
Интересная идея искать именно по наборам. Но тегов около ста. Если решать задачу в лоб, то комбинаций тегов уже будет 2^100. Сохранять их будет как-то дорого. Можно, правда и не сохранять - id тега, может обозначать бит в неком числе, по которому можно построить индекс.
mclander: 2^100 - включая перестановки, а если предварительно упорядочивать - то будет меньше в разы.
Если у Вас уже в кортеже есть набор ID-шников для тегов этого набора ("родное" JSON поле для mysql 5.7+), то поиск нужного вхождения тегов в это множество будет выполняться через индекс этого JSON-поля очень быстро ("подкапотными" средствами оптимизации mysql).
Вообщето 2^100 это число без перестановок. С перестановками 100!, что немного больше числа атомов в наблюдаемой Вселенной) Конечно столько комбинаций не будет (их не может быть больше записей в основной таблице), но не хочется проектировать систему, которая может внезапно выйти за пределы вычислительных мощностей отдельного десктопа)
Простой
