D.4 Epinions.com
Целью эксперимента с Epinions.com являлось испытание нашей системы на сценарии, который трудно поддается разделению. Выявлялась эффективность системы при обнаружении важных корреляций между данными, которые не видны на уровне схемы или запросов. Наша схема базы данных Epinions.com включает четыре отношения: users, items, reviews и trust. Отношение reviews представляет связи n-к-n между пользователями (users) и товарами (items) (связываются отзывы пользователей и рейтинги товаров). Отношение trust представляет связи n-к-n между парами пользователей, указывая, что они другу другу доверяют. Данные были предоставлены Паоло Масса (Paolo Massa) из группы разработчиков Epinions.com. Поскольку рабочую нагрузку нам не предоставили, мы создали запросы, примерно соответствующие функциональности этого Web-сайта:
| Q1: | для заданных пользователя и товара выбрать рейтинги, заданные пользователями, которым он доверяет; |
| Q2: | выбрать список пользователей, которым доверяет данный пользователь; |
| Q3: | для заданного товара выбрать взвешенное среднее всех рейтингов; |
| Q4: | для заданного товара выбрать 10 наиболее популярных отзывов; |
| Q5: | выдать 10 наиболее популярных отзывов данного пользователя; |
| Q6: | вставить/изменить профиль пользователя; |
| Q7: | вставить/изменить метаданные товара; |
| Q8: | вставить/изменить отзыв; |
| Q9: | обновить информацию о доверии пары пользователей друг к другу. |
Для получения разделения вручную были привлечены студенты, действовавшие в качестве администраторов базы данных. Найти хорошее разделение оказалось непросто, поскольку запросы опирались на связи n-к-n с конфликтующими требованиями к группировке таблиц и кортежей. Например, при выполнении запроса Q1 будут производиться обращения к одному разделу, если данные разделены по товарам, а рейтинги и доверительные отношения сохраняются вместе с товарами. В то же время при выполнении запроса Q2 будут производиться обращения к одному разделу, если данные разделены по пользователями, и доверительные отношения сохраняются вместе с пользователями. Предложенное студентами решение заключалось в оптимизации запросов, наиболее часто встречавшихся в рабочей нагрузке (Q1 и Q4), путем разделения таблиц items и reviews на основе одной и той же хэш-функции, и репликации таблиц users и trust в каждом узле.
