Производительность RedBean ORM

@ tereško if tis possible, можете ли вы дать плюсы и минусы orm относительно чистого sql в соответствии с вашим опытом, а также я буду google тему в то же время. – Джайсон Юстус

Ну .. объяснить это в 600 символов было бы сложно.

Одна вещь, которую я должен уточнить: речь идет об ORM в PHP , хотя я уверен, что это относится и к некоторым Ruby ORM, и, возможно, к другим.

Короче говоря, вы должны избегать их, но если вам нужно использовать ORM, то вам будет лучше с Doctrine 2.x, это меньшее зло. (Реализует нечто похожее на DataMapper вместо ActiveRecord).

Случай против ОРМ

Основная причина, по которой некоторые разработчики любят использовать ORM, также самое худшее в них: в ORM легко сделать простую вещь с очень незначительными издержками. Это прекрасно.

1. Экспоненциальная сложность

Проблема возникает от людей к одному и тому же инструменту для всего. Если у вас есть проблема с молотом (..) . Это приводит к созданию технического долга .

Сначала легко написать новый код, связанный с БД. И, может быть, потому, что у вас есть большой проект, управление в первые недели (потому что позже это приведет к дополнительным проблемам – прочитайте «Мифический человек-месяц» , если он заинтересован в деталях) решает нанять больше людей. И вы в конечном итоге предпочитаете людей с навыками ORM над общим SQL.

Но, по мере продвижения проекта, вы начнете использовать ORM для решения все более сложных проблем. Вы начнете взламывать некоторые ограничения, и в итоге вы можете столкнуться с проблемами, которые просто не могут быть решены даже со всеми хаками ORM, которые вы знаете … и теперь у вас нет экспертов SQL, потому что вы их не наняли.

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

2. Производительность

Я уже упоминал, что даже простое использование ORM (работа с одиночной таблицей, без JOIN ) имеет некоторые затраты на производительность. Это связано с тем, что они используют подстановочный знак * для выбора данных. Когда вам нужен только список идентификаторов и названий статей, нет смысла извлекать контент.

ORM действительно плохо работают с несколькими таблицами, когда вам нужны данные, основанные на нескольких условиях. Рассмотрим проблему:

База данных содержит 4 таблицы: Projects , Presentations , Slides и Bulletpoints .

• В проектах много презентаций
• В презентациях много слайдов
• В слайдах много Bulletpoitns

И вам нужно найти контент со всех Bulletpoints в Slides помеченных как «важные» из 4 последних Presentations связанных с Projects с идентификаторами 2, 4 и 8.

Это простой JOIN для записи в чистом SQL, но в любой реализации ORM, которую я видел, это приведет к 3-уровневому вложенному циклу с запросами на каждом уровне.

PS есть другие причины и побочные эффекты, но они относительно незначительные. Не могу вспомнить ни одного другого важного вопроса прямо сейчас.

Я чувствую, что ответ Терешко не совсем прав.

Во-первых, он не затрагивает первоначальный вопрос. Это действительно случай с ОРМ, и я согласен с проблемами, описанными в его ответе. Вот почему я написал RedBeanPHP. Просто потому, что большинство ORM не облегчают вашу жизнь, это не значит, что понятие реляционной системы сопоставления объектов является ошибочным. Большинство ORM пытаются скрыть SQL, поэтому JOINs становятся настолько сложными; им необходимо повторно изобрести что-то подобное в объектно-ориентированной среде. Здесь RedBeanPHP отличается, поскольку он не скрывает SQL. Он создает читаемые, действительные SQL-таблицы, которые легко запросить. Вместо обработанного языка запросов RedBeanPHP использует простой старый SQL для записи и извлечения бобов. Вкратце; RedBeanPHP работает с SQL, а не против него. Это делает его намного менее сложным.

И да, производительность RedBeanPHP хороша. Как я могу быть так уверен? Поскольку в отличие от других ORM, RedBeanPHP различает режим разработки и режим производства. В течение цикла разработки база данных является текучей; вы можете добавлять записи, и они будут добавляться динамически. RedBeanPHP создает столбцы, индексы, угадывает типы данных и т. Д. Он даже растягивает столбцы, если вам понадобится больше байтов (более высокий тип данных) через некоторое время. Это делает RedBeanPHP чрезвычайно медленным, но только во время разработки, когда скорость не должна быть проблемой. После того, как вы закончите разработку, вы можете заморозить базу данных с помощью одного указателя режима R :: freeze (), и больше никаких проверок не выполняется. То, что вам осталось, – довольно простой уровень прямой базы данных на вашем рабочем сервере. И поскольку не так много сделано, производительность хорошая.

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

В нашей компании мы используем RedBeanPHP для встроенных систем, а также для финансовых бизнес-систем, поэтому, похоже, она довольно хорошо масштабируется.

Вместе я и сообщество RedBeanPHP искренне пытаются сделать мир ORM лучшим местом; вы можете прочитать заявление миссии здесь .

Удачи вам в вашем проекте, и я надеюсь, что вы найдете техническое решение, которое вы ищете.

Я отличаюсь от @ tereško здесь – ORM могут упростить запись запросов к базе данных и упростить их поддержку. По моему мнению, в Propel и Doctrine есть отличная работа – воспользуйтесь ими! В Интернете есть ряд сравнений производительности, а также проверить NotORM (я не использовал его, но они делают некоторые сравнения с Doctrine, если я правильно помню).

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

Кстати, я не знаю RedBean, но я мягко отношусь к мнению, что Propel быстрее, чем Doctrine, в большинстве случаев, поскольку классы предварительно сгенерированы. Я использовал Propel, когда это был единственный вариант и застрял с ним, хотя я, конечно, не прочь использовать Doctrine.

Я бы пошел с ситуацией «Лошади для курсов», в которой используется сочетание и совпадение обоих миров. Я создал несколько приложений большого масштаба, используя RedBean, поэтому мой комментарий будет сосредоточен исключительно на RedBean, а не на других ORM.

IS RedBean ORM SLOW?

Ну, это зависит от того, как вы его используете. В некоторых сценариях это быстрее, чем традиционный запрос, потому что RedBean кэширует результат в течение нескольких секунд. Повторное использование запроса приведет к результату быстрее. Посмотрите на журнал, используя R::debug(true); Он всегда показывает

 "SELECT * FROM `table` -- keep-cache" 

Сценарий 1: выборка всех (*)

В RedBean, если вы запрашиваете

 $result = R::findOne('table', ' id = ?', array($id)); 

Это представлено как

 $result= mysql_query("Select * from TABLE where id =".$id); 

Вы можете утверждать, что если таблица содержит несколько столбцов, почему вы должны запрашивать (*) .

Сценарий 2: один столбец

Получение одной колонки

 R::getCol( 'SELECT first_name FROM accounts' ); 

Как я упоминал «Лошади для курсов», разработчики не должны просто полагаться на FindOne, FindAll, FindFirst, FindLast но также тщательно разрабатывать то, что им действительно нужно.

Сценарий 3: Кэширование

Когда вам не нужно кэшировать, вы можете отключить на уровне приложения, что не является идеальной ситуацией

R::$writer->setUseCache(true);

RedBean предполагает, что если вы не хотите отключать кеширование на уровне приложения, вы должны использовать традиционный запрос с параметром no-cache, например $result = R::exec("SELECT SQL_NO_CACHE * FROM TABLE");

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

Сценарий 4: быстрое развитие

Использование ORM делает вашу разработку приложений очень быстрой, разработчики могут использовать ORM 2-3 раза быстрее, чем писать SQL.

Сценарий 5: Комплексные запросы и отношения

RedBean представляет собой действительно хороший способ реализации сложных запросов и отношений « one-to-many или « many-to-many

Обычный SQL для сложных запросов

 $books = R::getAll( 'SELECT book.title AS title, author.name AS author, GROUP_CONCAT(category.name) AS categories FROM book JOIN author ON author.id = book.author_id LEFT JOIN book_category ON book_category.book_id = book.id LEFT JOIN category ON book_category.category_id = category.id GROUP BY book.id ' ); foreach( $books as $book ) { echo $book['title']; echo $book['author']; echo $book['categories']; } 

ИЛИ RedBean способ обработки отношений «многие-многие»

 list($vase, $lamp) = R::dispense('product', 2); $tag = R::dispense( 'tag' ); $tag->name = 'Art Deco'; //creates product_tag table! $vase->sharedTagList[] = $tag; $lamp->sharedTagList[] = $tag; R::storeAll( [$vase, $lamp] ); 

Проблемы с производительностью

Аргументы, подобные ORM, обычно медленны, потребляют больше памяти и, как правило, делают приложение медленным. Я думаю, что они не говорят о RedBean.

Мы протестировали его с MySQL и Postgres, и, надеюсь, что производительность никогда не была узким местом.

Нельзя отрицать, что ORM добавляет небольшие накладные расходы и, как правило, делает ваше приложение медленнее (немного). Использование ORM – это прежде всего компромисс между временем разработки и чуть более медленной производительностью. Моя стратегия состоит в том, чтобы сначала создать приложение сквозным с помощью ORM, а затем на основе тестовых примеров, настроить критические модули скорости, чтобы использовать прямой доступ к данным.