Структура БД книг

Если повесить индексы, то такая структура вполне бодро работает. Откуда инфа про большую задержку?

Плюс определённый смысл имеет структура типа key-value-type, т.е. одна таблица это у Вас книги, вторая таблица сшивает книги-свойства, третья таблица свойства (ID, значение, тип - например 1, драма, жанр; 2, толстой, автор и т.д.), что позволяет уменьшить общее количество таблиц объединяемых для выборки.

Проблема в том, что на странице со списком книг по жанрам выводятся разные блоки: последние добавленные книги, случайные книги. Все это напрягает БД и сервер. Если бы трафа было мало, то и пофиг, но траф идет хороший.

Общее время генерации страницы 0.25-0.5 секунд, что очень много, я считаю

Я конечно понимаю, что распределённые базы это круто, но может быть сделать всё в 1 таблице?

Если какие-то списки юзаются часто, например вывод всех авторов, то просто их по крону обновлять.

Ну ещё выход кэшировать страницы т.е. запоминать, что ищут пользователи и запоминать id книг, которые подходят и уже потом выдавать ему информацию.

---------- Добавлено 27.08.2012 в 21:54 ----------

Ну ещё вариант это конечно, это настроить mysql, может быть там размер кэша мелкий.

Так же нужно посмотреть, какие там запросы идут и их надо как-то поправить.

LEOnidUKG, а как в одну таблицу вместить книгу, у которой много авторов, жанров и издательств?

Как потом выводить книги по определенному автору?

0.25-0.5 время генерации страницы это ни о чем не говорящие цифры. Из 0.25 секунды 0.15 может уходить на коннект к БД и еще 0.9 на пхп код, а на запросы к БД допустим 0.01 секунды. Тогда ускорять выборки из БД - ну совсем бессмысленное дело.

Меряйте само время выполнения запросов. Если будет маленькое - то БД вообще не при чем. Если будет большое - показывайте структуру таблиц с индексами и сами запросы со временем их выполнения, а так же explain обязательно сделайте.

От способа построения запросов тоже много зависит, например, если Вам надо выбирать книги какого-то жанра, то в 90% случаев выгоднее будет начать с таблицы жанров, а если надо выбирать просто последние книги прицепляя к ним жанр для информации - разумнее начать с таблицы книг.

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

"Случайные" же книги при большом количестве книг в базе и выборке вида order by rand() - может быть запросов сжирающим 99% времени по отношению к остальным, т.к. такой запрос перетряхивает всю базу... случайные книги надо очень вдумчиво выбирать, если выбираете тем способом который мы предположили - переделывайте.

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

Ну тогда кэш таблица для поиска. Я так понял, что только в нём проблема?

Так же, как написали выше, вы уверены, что это БД тормозит?

Последние книги кеширую.

Случаные книги не жрут ресурса, проверил. Там идет выборка по случайным ID: берем максимальный ID книг и выбираем случайно штук 100 ID, тупо в цикле с помощью mt_rand(1, maxID). Потом убираю дубли ID и вывожу штук 10 книг из этого массива.

Жрет ресурс выборка списка книг по жанрам, при одновременном использовании сортировки

Select name_book, f.id_book, opis_book, year_book From books b, rurbric_book rb where rb.id_book=f.id_book and id_rubric=10 order by year_book DESC Limit 10,10

Индекс в таблице books на year_book стоит, в таблице rubric_book на id_book

Если убрать order by, то нормально работает, быстро

Select name_book, f.id_book, opis_book, year_book From books b, rurbric_book rb where rb.id_book=f.id_book and id_rubric=10 order by year_book DESC Limit 10,10

Какой-то странный у Вас запрос, где, например, таблица для которой альяс f прописан?

В остальном - попробуйте не на декартовом произведении делать, а на left join-ах, будет быстрее, т.к. меньше данных будет ворошиться изначально. Учитывая Ваш странный запрос прямой пример привести трудно, но если синтетику, то допустим

select books.book_name from category_book left join books on books.id_book=category_book.id_book where category_book.id_category=10 order by books.year_book limit 0,10

Несколько избыточна структура, можно попробовать упростить:

Книги

ID книги

ID жанра

ID автора

ID издателя

Название

Год написания

Краткое содержание

Жанры

ID жанра

Название жанра

Издатели

ID издателя

Имя издателя

Авторы

ID автора

Имя автора

Запрос:

f вместо b написал:) Очепятка

С left join также все, не лучше. Время генерации страницы 0.102 сек, без order by 0.01

---------- Post added 27-08-2012 at 20:22 ----------

vavenko, тогда лишние данные будут в таблице Книги

Будет много книг "Чук и Гек", но с разными жанрами, авторами, издателями

P.s. если прикинуть, что в среднем на одну книгу приходится 2 жанра, 1.5 автора и 3 издательства (цифры от балды, но примерно так и есть), то на таблицу из 100.000 книг будет записей 900.000

---------- Post added 27-08-2012 at 21:17 ----------

P.p.s. добавил STRAIGHT_JOIN и все летает