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

Ответ 1

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

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

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

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

Случай с ORM

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

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

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

Сначала легко написать новый код, связанный с БД. И, может быть, потому, что у вас есть большой проект, управление в первые недели (потому что позже это приведет к дополнительным проблемам - прочитайте The Mythical Man-Month, если заинтересованы в деталях) решает нанять больше людей. И вы в конечном итоге предпочитаете людей с навыками 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-уровневому вложенному циклу с запросами на каждом уровне.

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

Ответ 2

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

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

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

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

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

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

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

Ответ 3

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

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

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

Ответ 4

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

Является ли 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, а затем на основе тестовых примеров, настроить критические модули скорости, чтобы использовать прямой доступ к данным.