На сей раз вопрос решён окончательно. Разобрал исходники gelbooru, посмотрел схему бд.
Так вот, ребята тоже используют MATCH, полнотекстовые индексы и зверское кэширование результатов поиска.
Ещё раз погонял тесты - не стоит оно того. Трёхэтажные запросы, индексы и сервисные данные втрое превышающие полезную нагрузку, читать глазами - забудьте.
Надо будет дополнить данными, сделаю так:
id | ... | tags | <- исходная таблица
|-> ...
`->| ... | data | <- N'ая таблица
И все связи - по этому единственному ключу.
Добавил рекурсию ко всем основным операциям в режиме tool'а. В "dumb"-вариации заработало прям сразу с полпинка, аж сам в шоке.
В "smart" пришлось посидеть над багами, и я подозреваю, что выловил ещё не всё. Также, пришлось предварительно посидеть над рефакторингом функций, но это мелочи.
Кроме того, я ускорил некоторые операции, например случаи, когда из набора тегов ничего не удаляется, т.к. указанного тега нет, и базу обновлять не нужно.
Что приятно удивило -- "dumb"-версия работает очень быстро, обход двух тысяч файлов и добавление к ним одного тега - около двух сотых секунды. Ожидал где-то порядка 0.04-0.10 c. Удаление не до пустого набора - ~0.02с.
"smart"-версия уже помедленнее, порядка двух-трёх секунд. Но там не включены транзакции в базе, поэтому это нормально и ожидаемо.
Задался вопросом "как вынести часть кода в плагин"? После беглой пробежки по форумам и гуглу уяснил следующие способы (для чистого си):
→ Читать дальше...
Тридцать лет и три года Илья Муромец лежал на печи.
Такого бодуна Русь ещё не знала...
Вобщем, по части обновления бд не придумал ничего лучше, чем последовательно выбирать записи из базы с путями ниже определённой директории и сверять наличие на фс.
→ Читать дальше...
Бывают моменты, когда твоё внимание фиксируется на какой-то незначительной вещи и стопорит весь процесс. В этот раз в фокус внимания попал алгоритм генерации uuid'ов для файлов.
Вариант "отвлечься" - в моём случае не помогает. Попробуйю изложить в текстовом виде, авось голова прояснится.
→ Читать дальше...