Оптимизация базы данных с несколькими JOIN

Question

Во-первых, некоторые подробности о веб-сайте и структуре базы данных -

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

В моей базе данных около 20 таблиц.любой пользователь, который регистрируется на моем сайте, «добавляет» в таблицу пользователей что-то вроде 4000 строк - количество слов на моем сайте.У меня серьезная проблема, когда пользователь фильтрует слова (что-то вроде слова «поиск», но в соответствии с char / s & category / s & group / s и т. Д. У меня есть 9 JOINs в моем sql-запросе, и это занимает что-то вроде 1 MINдля отображения результатов ..

Цель JOIN - внутри пользователей таблицы (где у каждого пользователя 4000 строк / каждая строка = слово) есть объединения в этом стиле:

$this->db->join('users', 'sentences.id = users.sentence_id' ,'left');

То же самое с ассоциациями, группами, изображениями, связями между словами и т. д. Таблица пользователей включает в себя id предложений, ассоциаций, групп ... и с JOIN существует связь.

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

Я использую MySQL.

Answer 1

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

Есть несколько вещей, которые вы можете сделать.

Схема проектирования

Возможно, вы захотите пересмотреть дизайн / запрос схемы, если вам нужно 9 объединений, чтобы добиться того, что вы делаете!

Судя по всему, ваши таблицы очень нормализованы, возможно, в 3-й нормальной форме? В этом случае рассмотрите возможность денормализации ваших таблиц в более крупную, чтобы избежать объединений (объединения обходятся дороже, чем полное сканирование таблиц!). Об этом много онлайн-документации, однако это всегда обходится дорого, поскольку это увеличивает сложность разработки и избыточность данных. Также, денормализуя свои таблицы, вы избегаете объединений и можете лучше использовать индексы.

Также я считаю, что MyISAM - единственный механизм хранения в MySQL, который поддерживает индексы FULL TEXT. Однако он не имеет транзакций, имеет блокировку уровня таблицы и не имеет MVCC, поэтому это зависит от того, что вам нужно.

Ресурсы

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

Я также предлагаю ознакомиться с официальной документацией по выбранному вами хранилищу. Это важно, так как каждый механизм хранения ОЧЕНЬ РАЗЛИЧНЫЙ ! InnoDB полностью отличается от MyISAM, который также полностью отличается от PBXT. У каждого двигателя есть свои преимущества, и вам нужно будет решить, какой из них соответствует вашей ситуации.

Answer 2

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

Создание баз данных для работы с естественным языком является очень сложной задачей, и по этому вопросу проводится много исследований.Вы смотрели в цепи Маркова?Сделали ли вы шаг назад и подумали о вычислительной сложности того, что вы пытаетесь сделать?Если вы придете к одному и тому же выводу из девяти объединений, то будет справедливо сказать, что проблема недостаточно масштабируема для приложений реального времени.

В целом, я считаю, что попытка хранилища данных в Google App Engineиндексировать атрибуты для вас, с неявной масштабируемостью.Если вы работаете с базой данных на небольшом веб-сервере, вы можете получить лучшие результаты при ее развертывании с более полной СУБД.Однако я бы рассматривал это только в качестве крайней меры.