Производительность RedBean ORM [закрыто]

Я чувствую, что ответ Tereško это не совсем правильно.

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

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

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

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

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

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

Я отличаюсь от @tereško здесь-ORMs может сделать запросы к базе данных легче писать и легче поддерживать. На мой взгляд, есть большая работа, посвященная движению и доктрине, - воспользуйтесь ими! Есть ряд сравнений производительности в интернете, и проверить NotORM также (я не использовал его, но они делают некоторые сравнения с доктриной, если я правильно помню).

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

обновить 2018

Propel 2 все еще находится в alpha через несколько лет и нуждается в ряде крупных проектов рефакторинга, которые, к сожалению, не были выполнены. Хотя сопровождающие говорят, что эта Альфа хороша для использования в производстве, так как она имеет хороший охват испытаний, они теперь начали на Propel 3. К сожалению, на момент написания этой статьи у этого еще не было никаких релизов, несмотря на то, что репозиторий был годом старый.

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

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

является ли RedBean ORM медленным?

Ну, это зависит от того, как вы используете его. В некоторых сценариях это быстрее, чем традиционный запрос, потому что 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-3x быстрее, чем писать 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] );

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

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

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

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