Coldfusion ORM Большие столы

Question

Скажем, если у меня большой набор данных, в таблице более миллиона записей, а база данных нормализована, поэтому есть внешние ключи и прочее. Я правильно настроил отношения и получаю список первого объекта applications = EntityLoad("entityName"), но из-за связей и прочего страница загружается за 24 секунды, даже когда я ограничиваю количество отображаемых записей до 5, требуется ужасно долго грузиться.

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

Answer 1

Вы рассчитываете только время, чтобы получить данные, или вы, возможно, делаете CFDUMP или визуально что-то еще, что может быть медленным. Другими словами, вы сами обернули EntityLoad в тег cftimer, чтобы убедиться, что он является виновником?

Answer 2

При определении моделей сложных доменов с помощью Hibernate - иногда вам нужно настроить отображение для повышения производительности. Это особенно верно, если вы имеете дело с наследованием (не уверен, сколько наследования в вашей модели). Конечная цель состоит в том, чтобы ваш запрос извлекался из как можно меньшего числа таблиц, при этом сохраняя модель вашего домена. Это может потребовать использования расширенных отображений наследования (подробнее об этом через секунду).

Регистрация SQL

Как упомянул Терри, вам нужно быть уверенным, что вы можете регистрировать фактический SQL, который передается в вашу базу данных (да, вы не совсем ушли от SQL с ORM). Вот отличная статья о настройке ведения журнала для Hibernate в CF9 от Rupesh:

http://www.rupeshk.org/blog/index.php/2009/07/coldfusion-orm-how-to-log-sql/

ФАЙЛЫ С КАРТОЧКАМИ HIBERNATE

В любое время, когда вы хотите сделать что-то помимо базового, вы должны быть уверены, что смотрите на фактические файлы отображения Hibernate, сгенерированные для ваших CFC. Обязательно установите следующее со всеми вашими параметрами гибернации в Application.cfc:

savemapping = true

Хотя свойства cfproperty позволяют вам определять многие аспекты сопоставления, на самом деле есть некоторые вещи, которые можно сделать только в файлах сопоставления Hibernate (и для этого существует множество ресурсов сообщества.

Карта наследования

Как я упоминал ранее, Hibernate предоставляет различные стратегии наследования для отображения. Это таблица на иерархию, таблица на подкласс, таблица на конкретный класс и неявный полиморфизм. Вы можете прочитать больше об этих типах в документах CF9 в разделе Advanced Mapping> Inheritance Mapping или в документации Hibernate (поскольку объяснение каждого из них может занять вечность).

Знание того, как отображаются ваши таблицы, очень важно при наследовании (и именно в этом случае Hibernate может генерировать ОГРОМНЫЕ запросы, если вы не настраиваете свои настройки).

Это то, о чем я могу подумать - если вы можете дать некоторую дополнительную информацию о вашей доменной модели - мы можем посмотреть, что еще можно сделать, чтобы настроить ее.

Answer 3

Первое, что я хотел бы сделать, это включить ведение журнала SQL в вашем Application.cfc. Добавьте logSQL = true в This.ormSettings.

Это должно позволить вам получить SQL, который генерирует ORM. Запустите его в анализаторе. Посмотрите, делает ли ORM SQL что-то сумасшедшее. Посмотрите, пропустили ли вы индекс или что-то в этом роде.

Также вы делаете пейджинг, о котором Рэй говорит здесь: http://www.coldfusionjedi.com/index.cfm/2009/8/14/Simple-ColdFusion-9-ORM-Paging-Demo?

Если вы не пытались использовать ORMExecuteQuery и HQL для включения подкачки.

Это мои мысли.

Answer 4

Фейсал, мы столкнулись с этим с Linq (c # orm).

Нашим решением было создание простых объектов без реляционных данных. Например, наряду с пользователями у нас был объект SimpleUsers, который имел мало общего или не имел отношения к любому другому объекту и имел ограниченный набор столбцов.

Могут быть и другие способы справиться с этим, но этот подход чрезвычайно помог со скоростью запроса.

Answer 5

Есть большая вероятность, что Hibernate делает это для кеширования. Справедливое сравнение, на мой взгляд (все, пожалуйста, не стесняйтесь добавлять) делает:

EntityLoad ("entity_name") аналогично выполнению выбора * из TABLE

Итак, в этом случае, что может сделать Hibernate для создания экземпляра памяти и ее кэширования определенным образом, ваш сервер базы данных может сделать это аналогично, когда вы отправляете такую ​​обширную инструкцию SQL.

В последние несколько недель я чрезвычайно интересовался ORM, и это выглядит очень полезным делом.

По этой причине, есть ли связь, в которой вы когда-нибудь загрузите все 500 000 записей? Я предполагаю, что нет.

У меня есть одна большая таблица журналирования, на которую я буду атаковать, и я обнаружил, что хорошие вещи для SQL должны быть там. Например, пометьте поля, которые являются индексами, как таковые, это невероятно ускорит его при поиске. Я уверен, что ORM может справиться с этим.

Помимо этого:

• Найдите отличные форумы, ресурсы и учебники Hibernate, чтобы вы могли изучать Hibernate. На самом деле это не столько проблема Coldfusion -> ORM, сколько то, что Hibernate может сделать самостоятельно. Я заказал несколько книг Hibernate, которые я жду, чтобы увидеть, как они.
• Также, похоже, существует невероятное количество ресурсов Hibernate, где вы можете перенести решения Hibernate для повышения производительности в сферу Coldfusion. Возможно, я делаю это слишком просто, но я вижу реализацию CF-ORM как обертку с некоторой генерацией кода, чтобы сэкономить нам время.
• Взгляните на реализацию фильтров для сокращения ваших данных в вызове EntityLoad ().
• Как рекомендуется в других потоках, включите ведение журнала sql и посмотрите, что генерируется sql. Скорее всего, это может быть не то, что вам нужно. Проверьте HQL, чтобы увидеть, можете ли вы сформировать лучшее утверждение.
• Самое главное, поделиться тем, что вы найдете. Я добровольно сделаю то же самое, потому что вы соблазнили меня попробовать это в свободное время немного раньше, чем планировалось.