19 июня 2012 в 1:19
Решил разработать свой сайт на базе Drupal. Разумеется, один из главных вопросов - организация БД. Ознакомился с работой инструмента CCK и обнаружил, что для каждого поля создается отдельная таблица в БД. Сразу возник вопрос о эффективности такого подхода в плане производительности. Насколько это будет работоспособно при нескольких миллионах записей в таблицах и более или менее сложных запросах к ним?
Комментарии
1.9 млн записей, время генерации страниц практически не изменилось, как-будто там всего 1-2 ноды, пострадал немного вьювс(при довольно сложных и редких представлениях), пришлось его учить напрямую обращаться к нужным мне таблицам, что не так уж сложно и гайдов на эту тему как грязи.
А вообще, сами подумайте, что лучше, когда одна здоровенная таблица с миллионами записей, и что будет при попытке вывести из неё хоть немного данных, или несколько мелких таблиц, которые соединяются в одну только при не обходимости(при этом потери производительности при правильных запросах незаметны)?
Поцаны. а я мерседес купил. Только вот теперь не знаю, потянет ли мериновский дизель возить по 4-5 мешков картохи каждый день? )
Газель от Мерседеса чтоли? Ну не знаю... Судзуки возит и по 9 мешков...
Семерка в этом плане гибче..
Можно "написать" свою "сущность"(entity), которая будет хранить свои поля в одной или нескольких связанных таблицах БД.
Можно "написать" "поле" для имеющихся сущностей которое будет состоять из нескольких "подполей",которые храняться в одной или нескольких связанных таблицах БД.
... и еще куча вариантов в зависимости от задач и фантазии-))
ключевые слова: drupal 7,Field API, Entity API
http://drupal.org/project/examples
в школах 5 лет назад изучали друпал ?
«Ищите, и обрящете, толцыте, и отверзется» (ищите, и найдете; стучите, и вам откроют).(c)В Евангелии от Матфея
До чего древняя мудрость... а до сих по актуальна-)))
Это не лично вам... так... в общем...
Нет, мне в отличии от Вас с этим не повезло, в мое школьное время PHP еще не существовало, не говоря уже про CMS на нем. А если Вам интересна причина написания предыдущего комента - все очень просто, 5 лет назад подобное сэкономило бы мне уйму времени.
Друпал 7) Скачал с drupal.org cck-7.x-2.x-dev (я так понимаю, это что-то типа беты) вроде бы заработала) Win - XP SP3, Денвер - Denwer3_Base_2010-11-07_a2.2.4_p5.3.1_m5.1.40_pma3.2.3. Набор модулей - CKE, Views, Panels.
Предметная логика сайта похожа на автомобильную тематику и все, что с ней связано. Т.е. есть ряд подчиненных таблиц Марки->Модели->Запчасти с весьма внушительным набором полей каждая и ряд таблиц с различной дополнительной информацией, например, значения, которые изменяются периодически (цены и т.п). И вот возникает вопрос: насколько быстро все это будет работать при использовании стандартных механизмов CCK...
Привлекательным моментом считаю отсутствие необходимости заморачиваться над интерфейсом админки - все стандартно, во всяком случае, я сделал такой вывод. Конечно, написание запросов при такой организации данных несколько усложнится за счет кучи соединений, но если это единственный минус, то с ним можно смириться. А вот если окажется, что на больших размерах таблиц запросы будут критично тормозить, то лучше от этого отказаться и искать другие варианты.
Возникают сомнения, что соединения с несколькими таблицами будут быстро работать при наличии большого количества записей во всех таблицах. Даже если выбирать одну запись.
учитывая возможности работы с полями в Д, кучка таблиц - оптимальный вариант.
Если выбрать записи с простыми критериями в фильтрах, простенькой сортировкой и т.д. то на производительности не скажется ни как, сколько бы там связанных таблиц не было, однако, даже если таблица всего 1, но у вас идет несколько LIKE фильтров, также куча сортировок и еще GROUP BY для полного счастья, то тормоза будут нереальные, если Вы про это(сам друпал такого слава богу не делает, однако подобную выборку можно сотворить во вьювс или в своем модуле).
элементарная логика.
Если просто материал - то нет смысла бить его на разные таблицы.
Но у нас есть вьюс и еще куча варианта для вывода отдельных полей и обработки.
отсюда следует:
для вывода поля модуль лезет в базу, ищет таблицу конкретного поля и оттуда выкапывает нужную строку.
все просто.
Если будет одна таблица модулю нужно:
сперва найти таблицу ноды, потом уже в ней выкапывать нужные строки.
Выходит путь таки длиннее.
Есть модуль devel - он может генерить ноды автоматически. Не помню, можно ли там задать произвольное число, но что мешает это сделать? Набросай нужную структуру, это займёт полчаса, нагенери миллион нод (это займёт много времени, особенно на винде), и увидишь _реальную_ картину.
элементарно "прикрепить" к ноде неопределенное кол-во картинок, это уже связь "один-ко-многим", подобное одной таблицей не реализуешь..
А вообще, как заметил товарищ выше - запрос запросу рознь..
Когда и десяток простых запросов выполняются быстрее чем один сложный..
Все зависит от конкретной задачи..
Поэтому и оптимизацию, обычно проводят уже при эксплуатации..
К тому-же скорость-количество запросов к БД не единственная причина "тормозов" сайта..
Есть еще куча других, и довольно таки не маловажных..
Это зависит (с).
Нужно знать объем данных: горизонтальный (число полей) и вертикальный (число записей), а так же принцип работы с ними — что это за данные и что вы с ними будете делать.