БД для высокопроизводительной маркировки нескольких объектов

Question

Я проектирую базу данных для социального приложения и пытаюсь определить, будет ли мой подход: 1) работать хорошо и 2) правильно нормализоваться?

Мое исследование производительности запросов тегов и дизайна БД показало, что единственная таблица тегов с полнотекстовым поиском дает наилучшую производительность.

Смотрите это: http://tagging.pui.ch/post/37027746608/tagsystems-performance-tests

Я знаю, что мог бы (и должен с чистой точки зрения нормализации) поместить теги в отдельную таблицу с ключом для каждого тега, но производительность будет снижаться по мере увеличения базы данных (согласно связанной статье). Поиск по тегам является ключевым компонентом моего приложения и должен хорошо работать.

Приведенная ниже структура иллюстрирует базовый подход, который я разработал, который использует таблицу метаданных моста, и я ожидаю, что с помощью этой единственной таблицы будет создано множество других «таблиц объектов», но я предлагаю лишь пару, чтобы дать идею:

Таблица пользователей: UserID PK, UserName и т. Д.

Таблица блогов: BlogID PK, UserID FK, BlogTxt и т. Д.

Таблица фотографий: PhotoID PK, UserID FK, PhotoPath и т. Д.

Таблица метаданных: MetadataID PK, UserID FK, ObjectTable (сообщения или блоги), ObjectID FK (PostID или BlogID), теги (tag1, tag2, tag3)

В дополнение к вышеупомянутым вопросам мне также интересно знать, есть ли лучшие альтернативы. Я новичок в дизайне БД, поэтому прошу прощения за любое серьезное невежество по поводу правильного способа сделать это. Большое спасибо.

Answer 1

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

Это на самом деле неверно ...

Наилучшая производительность, которую вы можете получить, - это переключиться на ядро ​​базы данных, которое имеет тип массива и сканирование растровых индексов, сохранить совокупность ваших тегов в столбце int [] массив , используя триггеры, и добавитьсоответствующий индекс (gin, gist, rtree) для него.

Это позволяет писать запросы (синтаксис Postgres ниже), такие как:

create index on posts using gin (tags);

-- bitmap AND/OR index scan on posts
-- has 1 or 2 or 3 or any of 4, 5, 6 without 7 or 8
select *
from posts
where tags && array[1,2,3]
or tags && array[4,5,6] and not tags && array[7,8]

Вышеприведенное исключит любую потенциальную оптимизацию, которую выможно подумать об использовании MySQL.