main

Конфиги и неймспейсы

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

Конфиг и неймспейсы. С первым всё более-менее понятно, со вторым есть несколько вариантов реализации.

Вариант первый.

Сделать их тупо фильтром к общей базе, т.е. дописывать к запросу "AND path LIKE 'bla-bla%'". Из плюсов - динамическая конфигурация, минимальная стоимость реализации. Из минусов - замедление любой выборки, срач в списке тэгов.

Вариант второй

Вариация предыдущего, вместо LIKE использовать числовой индекс и вынести пару индекс - путь в отдельную таблицу. Из плюсов - выборка тормозить не будет, но появится головняк с поддержанием в актуальном состоянии этой таблицы.

Таблица в базе -- s_namespaces:

| id | name  | prefix                             |
| :: | ::    | :::                                |
| 17 | films | /srv/ftp/pub/video/films           |
| 39 | pics  | /srv/ftp/pub/pictures              |
| 42 | demo  | /srv/ftp/pub/pictures/demotivators |

Обращаю внимание на вложенный ns demo. Неявно, создаётся ещё один - default с префиксом /.

Изменения в s_files:

| id | **ns** | ... |
| NNN | 17 | ... |

Вариант третий

Каждому неймспейсу - по базе, внутри базы - хранить относительный путь. Из плюсов - логически правильно.

Минусов же куча:

  • требует включенное автосоздание базы,
  • нужен механизм миграции данных между ns,
  • если посмотреть шире, на (my|pg)sql - концепция ставится с ног на голову, поскольку в sqlite база - это один файл, в прочих же - один файл - таблица. Общеизвестной практикой является выделение прав на операции внутри одной базы, права на создание/удаление базы - резко снижает безопасность всего сервера БД.

В теории, разруливание запросов решается либо поиском только в неймспейсе1, либо несколькими запросами (два и более).

Реализация может быть такой:

Секции конфига:

[namespace]
shortname = films
prefix = /srv/ftp/pub/video/films

[namespace]
shortname = pics
prefix = /srv/ftp/pub/video/films

Добавление/удаление неймспейсов реализуется примерно так:

  • при запуске, достаём из базы список
  • начинаем парсить конфиг, смотрим на то, что определено там. (в приведённом конфиге отсутствует определение для demo)
  • ищем следующий ближайший по пути ns, для нас это будет pics
  • переносим записи о файлах, тегах, добавляем уникальные теги в список
  • удаляем запись об этом ns из базы
  • удаляем базу для этого ns

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

Итого

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

Сейчас в базе 400k тегированных файлов(всего - 625k), размер самой базы - 150Mb, и оно не тормозит. Выборка половины базы - 22с, из них большая часть уходит на snprintf. Выборка уже по 2м тегам - меньше половины секунды, с учётом того же snprintf.

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

  1. не обновил базу после изменения - ССЗБ ↩

xa-tags devel