Медленные SQL-запросы убивают ваш механизм рекомендаций

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

На самом деле, вам повезло, если они готовы ждать более нескольких секунд.

Тогда возникает вопрос: работает ли ваша реляционная база данных со скоростью, необходимой для того, чтобы предлагать пользователям соответствующие и полезные рекомендации? Если нет, то ваши медленные SQL-запросы могут быть виноваты.

В этой серии статей о напряжении SQL мы рассмотрим причины и способы устранения проблем с производительностью реляционных баз данных (RDBMS), в том числе перспективную альтернативу графовых баз данных .

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

Моделирование данных в реляционной базе данных по сравнению с базой данных графов

В реляционной базе данных моделирование данных для простого механизма рекомендаций требует создания нескольких таблиц. Вы должны создать отдельные таблицы для клиентов, заказов и продуктов, а также промежуточные таблицы JOIN, которые представляют, какие клиенты приобрели какие продукты в каком заказе.

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

С помощью этой простой модели базы данных вы можете легко спросить: «Какие еще продукты купили эти люди?»

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

Другими словами, в базе данных графов логическая модель — то, как мы думаем о проблеме — соответствует физической модели — способу хранения, запроса и визуализации данных в базе данных.

Для многих интересных проблем с данными, с которыми люди сталкиваются сегодня — особенно при создании соответствующих механизмов рекомендаций — недостаточно знать, что два объекта (продукты, пользователи, рейтинги, отзывы и т. Д.) Связаны между собой. В конце концов, реляционная база данных может сказать нам так много.

Также важно знать об этих связях данных : их значение, их значение и их сила, вес или качество. В нашем примере механизма рекомендаций это могут быть такие вопросы, как: какие продукты связаны и в чем сила этих отношений? Какие пользователи оставили качественные (или некачественные) отзывы о конкретном продукте? Сколько друзей друзей купили аналогичный продукт?

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

SQL-запросы против Запросы к базе данных графа

В отличие от запросов реляционного SQL, запросы к базе данных графа просты для написания и понимания.

Графовые базы данных часто имеют собственный синтаксис для таких запросов. В случае Neo4j этот синтаксис регулируется простым, но выразительным языком, называемым Cypher, который специально создан для обхода отношений данных.

Cypher-запросы намного проще, чем SQL-запросы. На самом деле, длинный запрос SQL часто может быть сжат на гораздо меньшее количество строк в Cypher.

Вот пример запроса Cypher для механизма гипотетических рекомендаций:

MATCH (u:Customer {customer_id:’customer-one’})-[:BOUGHT]->(p:Product)<- [:BOUGHT]-(peer:Customer)-[:BOUGHT]->(reco:Product) 
WHERE not (u)-[:BOUGHT]->(reco) 
RETURN reco as Recommendation, count(*) as Frequency 
ORDER BY Frequency DESC LIMIT 5; 

SELECT product.product_name as Recommendation, count(1) as Frequency 
FROM product, customer_product_mapping, (SELECT cpm3.product_id, cpm3.customer_id 
          FROM Customer_product_mapping cpm, Customer_product_mapping cpm2, Customer_product_mapping cpm3 
          WHERE cpm.customer_id = ‘customer-one’ 
          and cpm.product_id = cpm2.product_id 
          and cpm2.customer_id != ‘customer-one’ 
      and cpm3.customer_id = cpm2.customer_id 
      and cpm3.product_id not in (select distinct product_id 
          FROM Customer_product_mapping cpm 
          WHERE cpm.customer_id = ‘customer-one’) 
   ) recommended_products 
WHERE customer_product_mapping.product_id = product.product_id 
and customer_product_mapping.product_id in recommended_products.product_id 
and customer_product_mapping.customer_id = recommended_products.customer_id 
GROUP BY product.product_name 
ORDER BY Frequency desc