Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

Несколько примитивных запросов взамен одного большого для загрузки связей в ORM

Anna | 31.05.2014 | нет комментариев

Сразу оговорюсь, это не обучающий пост и не провозглашение новой парадигмы )), скорее решение, к которому я пришел, и хочется его обсудить в широкой и Добросовестной дискуссии.
Сейчас к сути, представьте, что есть некая ORM, написанная на PHP, в которой описана модель Posts, имеющая связи многие-ко-многим через промежуточные таблицы с другими моделями: Comments, Tags, Categories. Вопрос в том, каким методом отменнее поднимать связанные данные, всё сразу либо с отложенной загрузкой?

В сообществе БД господствует суждение, что данные отменнее поднимать одним запросом с кучей join’ов, мол СУБД мудрая, она сама разберет, как стремительней каждого это сделать и чем поменьше запросов к базе тем отменнее. В моей же практике были случаи, когда на высоконагруженных планах с огромными таблицами несколько примитивных запросов трудились стремительней, чем один огромный с несколькими объединениями.
Со стороны ORM подъем всех данных одним запросом тоже не наилучший вариант, потому что, примерно неизменно, будут подыматься лишние данные, которые в этом месте не необходимы (либо даже могут воспрепятствовать, и тогда их еще придется удалять из комплекта), либо нужно иметь комплект способов как бы findWithComments, findWithCategoriesAndTags, findWithAllRelations с неотвратимым дублированием.
Таким образом, имеем три метода загрузки связей (способы модели):

  • Один способ find($id), тот, что неизменно загружает все данные в одном запросе.
  • Несколько способов find($id), findWithComments($id), findWithTagsAndCategories($id) …
  • Способ find($id), тот, что загружает только нынешнюю модель очевидные способы для загрузки связей getComments(), getTags()… при чем последние способы работают идентично, как для одного объекта, так и для коллекции объектов (схоже на Composite).

Если говорить о проектировании какой-то многофункциональной ORM, конечный вариант мне представляется больше верным, причем иного подхода ORM не должна разрешать. Расскажу о превосходствах.

  • Кеширование на ярусе БД. Маленькие доли данных обязаны Почаще браться из кеша (из-за переиспользования их в различных запросах), чем крупные уникальные запросы.
  • Кеширование на ярусе приложения. Как правило, данные из различных таблиц имеют различную скорость протухания, если применять 1-й метод, то доводиться ориентироваться на данные, которые стремительней каждого становятся неактуальными. Если применять 3-й метод, то для всякой модели дозволено указывать собственное время жизни кеша, плюс это дает больше эластичное (по-модельное) управление очищением кеша (по событию либо в ручную).
  • При росте объемов данных либо числа запросов мы имеем готовую архитектуру для вертикального шардинга БД.
  • В всяком случае мы можем загружать только те данные, которые нам необходимы.
  • Готовая зодчество для смешанного применения SQL и noSQL, скажем какие-то модели мы можем перенести в mongo либо redis, переписав для этого предварительно предсказуемое число способов.

Слабое звено такой грубой изоляции моделей — как делать эластичный поиск сразу по многим критериям, скажем постов по тегам и категориям.
В всеобщем, приглашаю к дискуссии, какие еще есть минусы, может кто-то приходил / уходил от такого решения, применяли бы вы такую ORM в ваших планах?

Источник: programmingmaster.ru

Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB