Drupal Performace разница между полем cck и текстом?

Как вы думаете, в чем будет разница в производительности?

20 000 узлов

Каждый узел имеет поле Link. Количество значений варьируется от 50 до 200. Ссылки не будут иметь заголовка.

OR

20 000 узлов

Каждый узел будет иметь ссылки в поле тела в виде простого текста с отфильтрованным HTML. Как так:

http://link1.com
http://link2.com
http://link3.com
http://link4.com
http://link5.com
http://link6.com
http://link7.com
http://link8.com
http://link9.com
http://link10.com

performance drupal drupal-6 cck
person picxelplay    schedule 13.11.2010    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Это действительно зависит от того, как / что вы собираетесь их использовать. Я сомневаюсь, что вы собираетесь отображать 20 000 узлов одновременно. Трудно сказать много о производительности без конкретного варианта использования, и даже в этом случае вы должны учитывать кэширование и многое другое.

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

Еще одна вещь, о которой следует помнить, это то, что использование полей CCK даст вам дополнительную гибкость, если оно хорошо интегрируется с представлениями. Таким образом, вы можете легко вытащить ссылки и отформатировать их по-разному.

person googletorp    schedule 13.11.2010
comment
Я думаю, мой вопрос был больше о масштабировании базы данных. Я действительно должен был сравнить два в базе данных, а затем сравнить общее количество запросов каждого, прежде чем задавать этот вопрос. Возможно, вы не отображаете 20 000 узлов одновременно, но это может быть диапазон 1-3 000, умноженный на количество запросов... это может быть большой разницей. Я посчитаю, а потом опубликую ответ. Спасибо, что заставили меня думать о моем вопросе иначе, чем я думал изначально. - person picxelplay; 13.11.2010
comment
@picxelplay Вопрос касается не только базы данных, но и очень сильно зависит от того, как вы отображаете узел. Если вы делаете полное отображение узла, вы сделаете node_load. При этом поле CCK/body не имеет значения, и если вы выведете 1k, вы получите очень медленную страницу. Отображение полных узлов предназначено для отображения одного фрагмента контента, а не списка, содержащего тысячи узлов. Это то, что я имел в виду, не имея возможности измерить это на сайте drupal, поскольку разница в нагрузке ничтожно мала по сравнению с тем, что еще происходит при загрузке и рендеринге узла. - person googletorp; 13.11.2010
comment
Также имейте в виду, как кэширование может изменить / помочь в этой ситуации. Drupal может кэшировать страницы в зависимости от ваших настроек. У вас также есть возможность кэшировать вещи самостоятельно в коде несколькими способами, и ваша БД также может иметь встроенное кэширование. - person mpdonadio; 13.11.2010
comment
Вы говорите о выполнении нескольких (1k) node_loads одновременно? Я имел в виду, если бы у вас было 1 тыс. пользователей, одновременно просматривающих 1 тыс. узлов. Я не думаю, что здесь можно было бы использовать поле cck Link. Я просто проводил некоторые тесты, и как только вы нажимаете «Добавить другой элемент» около 30 раз, каждый раз становится все медленнее и медленнее. Помещая ссылки в единую область тела/текста, они по-прежнему могут использоваться представлениями. Кроме того, вы избавляете себя от необходимости иметь более 2 000 000 строк в этой таблице для поля ссылки cck. - person picxelplay; 14.11.2010
comment
@picxelplay, если вы хотите выполнять 1 тыс. запросов в секунду, вы не хотите использовать представления или CCK. Вам потребуется намного больше пользовательского кода. Как правило, я думаю, что вы получите больше производительности при отказе от просмотров, чем при отказе от CCK. Но CCK не так полезен с представлениями. Другое дело, что важнее всего ваша стратегия кэширования. - person googletorp; 15.11.2010
comment
Ха-ха, нет, никакие представления не будут использоваться вообще. Это даже не потребует представлений в любом виде, форме или форме. Я только что поднял это, потому что ты сделал это раньше. Здесь мы находимся на двух разных страницах. - person picxelplay; 16.11.2010