Drupal: многие поля / типы контента равны * множеству * таблиц и после некоторой точки делают MySQL очень медленным

Question

По мере того, как я создаю все больше и больше полей и типов контента, я вижу, что Drupal создает огромное количество таблиц (> 1k) в MySQL, и после определенного момента моя система становится очень медленной.

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

Как вы справляетесь с этим? Как вы масштабируете Drupal?

Answer 1

Если бы огромное количество таблиц стало узким местом в производительности базы данных, я бы согласился с Римианом. Вы можете определить свои собственные типы контента программно, а затем разработать собственную модель типов контента, используя Node API.

Документация по API и пример того, как это сделать: http://api.drupal.org/api/drupal/developer--examples--node_example--node_example.module/6

Поток кода в основном:

• Заставьте Drupal распознавать ваш тип контента
• Определите поля, которые необходимо заполнить с помощью API форм
• Определите, как должна вести себя каждая из функций Node API (просмотр, загрузка, сохранение и т. Д.).

Это позволяет вам контролировать, как вещи хранятся, но все же дает вам (и всем добавленным модулям) возможность использовать систему хуков для вызовов API Node.

Очевидные недостатки отсутствуют во всех функциях / модулях, которые напрямую зависят от CCK для их функциональности. Но при таблицах> 1 тыс. (Что предполагает огромное количество типов контента и полей), кажется, что вы уже на том уровне пользовательской работы.

Answer 2

Модуль devel предлагает инструмент мониторинга производительности, который покажет вам все выполненные запросы, организованные по времени, показывая, какие хуки и модули вызвали их и т. Д.

Только не работайте на производстве.

Answer 3

Я работал на сайте Drupal 5 с более чем миллионом узлов, и это было серьезной проблемой.

Если вы масштабируете Drupal до уровня предприятия, рассмотрите возможность не использовать CCK для своих полей и разрабатывать свои.собственная модель контента с помощью API узла.Это на самом деле довольно просто.