=Paper=
{{Paper
|id=None
|storemode=property
|title=NoSQL как подход к построению рекомендательных сервисов реального времени
(Building Real-Time Recommender Services with NoSQL)
|pdfUrl=https://ceur-ws.org/Vol-934/paper43.pdf
|volume=Vol-934
|dblpUrl=https://dblp.org/rec/conf/rcdl/Klemenkov12
}}
==NoSQL как подход к построению рекомендательных сервисов реального времени
(Building Real-Time Recommender Services with NoSQL)
==
https://ceur-ws.org/Vol-934/paper43.pdf
Применение NoSQL для построения рекомендательных
сервисов реального времени
© П.А. Клеменков
Московский Государственный Университет имени М.В. Ломоносова,
Москва
parser@cs.msu.su
• аналитика в реальном времени
Аннотация
• отложенная пакетная обработка логов досту-
В статье обсуждаются вопросы анализа па к веб-приложению
взаимодействия пользователя с веб-прило- У каждого из этих подходов есть преимущества и
жением, методы проведения подобного ана- недостатки, на которых стоит остановиться подроб-
лиза и их недостатки. Приводится реализа- ней.
ция новостного рекомендательного сервиса
с использованием существующих подходов. 2.1 Аналитика в реальном времени
Описывается новый подход к построению
Суть подхода заключается в том, что в ответ на
рекомендательных систем, работающих в
взаимодействие пользователя с веб-приложением
режиме, близком к режиму реального вре- специально установленный фрагмент кода (счетчик)
мени, с использованием технологии NoSQL.
генерирует определенные события, обрабатываемые
приложением-анализатором в реальном времени.
1. Введение Очевидно, что основным преимуществом подобной
Основным отличием приложений Веб 2.0 от их парадигмы является немедленное получение резуль-
более старых аналогов является анализ взаимодей- татов и их обновление. Однако методы, применяя-
ствия пользователя с приложением и использование емые при анализе данных в реальном времени
результатов этого анализа для модификации наиболее подходят для различных статистических
контента и его представления. Темпы развития сети расчетов (CTR, Churn Rate). При этом целые классы
Интернет диктуют создателям современных веб- приложений не могут быть реализованы предложен-
приложений необходимость очень быстро адапти- ными средствами.
ровать контент под предпочтения пользователей.
Наиболее востребованным решением этой задачи 2.2 Отложенная пакетная обработка логов
являются рекомендательные системы, способные доступа к веб-приложению
анализировать поведение пользователя, его склон- Этот подход строится на сборе логов доступа к
ности, и предлагать наиболее интересное напол- веб-приложеню и их последующей обработке боль-
нение. Проблема с подобными системами заключа- шими частями. Имея срез данных о взаимодействии
ется в том, что они недостаточно быстро реагируют пользователей с приложением за определенный
на постоянно изменяющийся поток входных данных. период, возможно строить сложные модели поведе-
Особенно подвержены этому новостные ресурсы. ния и применять их, например, для выдачи рекомен-
Такое поведение связано не столько с алгоритмами, даций. Современные фреймворки (напр. Apache
применяемыми для выявления пользовательских Hadoop) обеспечивают высокую производитель-
предпочтений, сколько с архитектурными особен- ность, реализуя потоковую обработку больших объе-
ностями той инфраструктуры и библиотек, которые мов данных с использованием метода параллельных
широко используются для подобного анализа. В вычислений MapReduce [6,9].
данной статье представляется подход к организации
новостного рекомендательного сервиса, призванного 3. Рекомендательный сервис проекта
максимально устранить задержки в пересчете реко-
мендаций и обеспечить работу в режиме, близком к Рамблер-новости
режиму реального времени. Рекомендательный сервис проекта Рамблер-
новости основывается на объединении пользовате-
2. Методы веб анализа лей в группы по схожести интересов и вычислении
Сегодня для анализа взаимодействия пользова- наиболее популярных среди групп новостей в
теля с веб-приложением применяются два основных заданном временном окне.
подхода:
281
3.1 Реализация сервиса
Суть алгоритма заключается в том, что все Рис. 1. Схема
пользователи идентифицируется уникальными иден-
тификаторами. Эти идентификаторы связываются с
каждым HTTP-запросом к новостным ресурсам
(если, конечно, запрос содержал заголовок Cookie с
корректным значением). Таким образом поведение
пользователя на сайте характеризуется подмножест-
вом логов доступа к веб-серверам. Подсчитав
схожесть каждого подмножества со всеми другими,
можно объединить пользователей в группы с
похожими предпочтениями.
В качестве меры схожести множеств естественно
использовать коэффициент Жаккарда. Однако про-
блема заключается в том, что время работы алгорит-
ма подсчета этого коэффициента на нескольких
миллионах множеств с сотнями и тысячами эле-
ментов являeтся неприемлемо большим. В качестве
оптимизации широко применяется вероятностный
алгоритм MinHash [5]. Основная идея этого работы первого этапа Hadoop реализации
алгоритма заключается в вычислении вероятности
равенства минимальных значений хеш-функций
элементов множеств. Очевидно, что чем больше Также необходимо отметить, что первоначальная
одинаковых элементов в двух сравниваемых реализация алгоритма имела еще один шаг, который
множествах, тем выше указанная вероятность. А так позволял строго отсечь необходимое количество
как вычисление сигнатуры множества (минимумов групп, но ради сокращения вычислений, им было
используемых хеш-функций) происходит только решено пренебречь.
один раз, а размер сигнатуры фиксирован, то
вычислительная сложность решаемой задачи резко
Рис. 2. Схема
сокращается.
Для вычисления новостных рекомендаций было
принято решение производить обработку логов
доступа веб-серверов Рамблер-новостей во
временном окне 5 дней. Средний объем логов за
указанный период составляет примерно 7 ГБ. Для
реализации алгоритма был выбран фреймворк
Hadoop, являющийся стандартом де-факто для
потоковой обработки больших объемов данных.
Алгоритм вычисления рекомендаций был
реализован в виде последовательности MapReduce
задач, разделенных на два этапа: подсчет групп
пользователей во временном окне 5 суток и подсчет
рекомендаций для групп во временном окне 5 часов.
Первый этап составляют следующие ступени (см.
рис. 1):
1. Фильтрация логов во временном окне 5
суток и генерация множества уникальных URL для
каждого идентификатора пользователя. работы второго этапа Hadoop реализации
2. Подсчет значений хеш-функций для всех
уникальных URL каждого пользователя и Второй этап разделен на следующие ступени (см.
вычисление минимума, который становится рис. 2):
идентификатором группы. 1. Фильтрация логов во временном окне 5
3. Подсчет численности групп и отсечение часов и генерация множества уникальных URL для
~100 групп с наибольшей численностью. Необхо- каждого идентификатора пользователя.
димо заметить, что порог отсечения вычисляется 2. Подсчет кликабельности новостей во всех
статистически, поэтому имеет место небольшая группах.
дисперсия количества групп. Однако на произ-
3. Отсечение заданного количества наиболее
водительность и поведение алгоритма это влияет
популярных новостей в каждой группе.
незначительно.
Получающиеся в результате отображения иден-
282
тификаторов в группы и групп в популярные новос- году для описания реляционной базы данных, не
ти загружаются в хранилище Redis, позволяющее использовавшей SQL. Он был вновь подхвачен в
запрашивать список рекомендаций для данного 2009 году и использован на конференциях
пользователя в реальном времени. приверженцами нереляционных баз данных.
Основной движущей силой развития NoSQL
3.2 Производительность хранилищ стали веб-стартапы, для которых
Приведенная реализация алгоритма использова- важнейшей задачей является поддержание
лась в продуктивном окружении проекта Рамблер- постоянной высокой пропускной способности
новости более полугода, показывая приемлемое хранилища при неограниченном увеличении объема
время работы. На Hadoop кластере из 8 узлов первая данных. Рассмотрим основные особенности NoSQL
ступень обсчитывалась примерно 7 минут, а вторая подхода, делающие его таким привлекательным для
3.5-4 минуты, при условии, что другие задачи не высоконагруженных веб-проектов [7,8]:
выполнялись параллельно. Необходимо отметить, 1. Исключение излишнего усложнения.
что важным фактором производительности Реляционные базы данных выполняют огромное
MapReduce задач является верный выбор количества количество различных функций и обеспечивают
мапперов и редьюсеров. Выбор количества мап- строгую консистентность данных. Однако для
перов производился фрейдистском автоматически. многих приложений подобный набор функций, а
Экспериментальным путем было выяснено, что также удовлетворение требованиям ACID являются
оптимальное количество редьюсеров в данной излишними.
конфигурации — 16. 2. Высокая пропускная способность. Многие
NoSQL решения обеспечивают гораздо более
3.3 Проблемы высокую пропускную способность данных нежели
Внимательно изучив получившуюся архитектуру традиционные СУБД. Например, колоночное
и приняв во внимание проблемы, возникшие при хранилище Hypertable, реализующее подход Google
реализации рекомендательного сервиса, можно Bigtable, позволяет поисковому движку Zvent
отметить следующие аспекты: сохранять около миллиарда записей в день. В
качестве другого примера можно привести саму
1. Загрузка логов в HDFS (Hadoop Distributed
Bigtable [3], способную обработать 20 петабайт
File System) и их обработка — две несвязанные
информации в день.
задачи. В нашем случае синхронизация логов
выполнялась с помощью утилиты rsync, а 3. Неограниченное горизонтальное масшта-
вычисление разности между файлами в директории бирование. В противовес реляционным СУБД,
синхронизации и файлами в HDFS, а также загрузка NoSQL решения проектируются для неограничен-
новых файлов — с помощью специально ного горизонтального масштабирования. При этом
написанного Makefile и shell-скриптов. добавление и удаление узлов в кластере никак не
сказывается на работоспособности и производи-
2. В Hadoop отсутствует возможность
тельности всей системы. Дополнительным преиму-
получать данные из разных источников. В
ществом подобной архитектуры является то, что
частности, результаты работы первого этапа
NoSQL кластер может быть развернут на обычном
алгоритма приходилось передавать в окружение
аппаратном обеспечении, существенно снижая
второй ступени второго этапа в виде файла в кеше
стоимость всей системы.
Hadoop. При том, что этот файл может иметь весьма
внушительный размер, MapReduce задачи на всех 4. Консистентность в угоду производи-
узлах могут столкнуться с проблемой нехватки тельности. При описании подхода NoSQL нельзя не
памяти. упомянуть теорему CAP. Следуя этой теореме,
многие NoSQL хранилища реализуют доступность
3. Задачи подсчета рекомендаций и их
данных (availability) и устойчивость к разделению
использования также не являются связанными и
(partition tolerance), жертвуя консистентностью в
выполняются разными инструментами. В нашем
угоду высокой производительности. И действи-
случае Hadoop и Redis.
тельно, для многих классов приложений строгая
4. Ну и самое главное — пакетный потоковый консистентность данных — это то, от чего вполне
режим работы Hadoop не позволяет хоть сколько- можно отказаться.
нибудь приблизиться к реальному времени пересче-
та результатов. 5. Классификация NoSQL хранилищ
Отсюда возникает вопрос: можно ли решить все
вышеперечисленные проблемы, воспользовавшись На сегодняшний день создано большое коли-
другим подходом? В следующей части статьи я чество NoSQL хранилищ. Все они основываются на
опишу архитектуру подобного решения с примене- четырех принципах из предыдущего раздела, но
нием NoSQL хранилищ данных. могут довольно сильно отличаться друг от друга.
Многие теоретики и практики создавали свои
4. Введение в NoSQL собственные классификации, но наиболее простой и
общеупотребительной можно считать систему, осно-
Термин NoSQL впервые был использован в 1998 ванную на используемой модели данных, предло-
283
женной Риком Кейтелем (Rick Cattel) [2]: 6. Построение рекомендательного
1. Хранилища ключ-значение. Отличитель- сервиса Рамблер-новостей с помощью
ной особенностью является простая модель данных
— ассоциативный массив или словарь, NoSQL
позволяющий работать с данными по ключу. Вспоминая недостатки реализации рекоменда-
Основная задача подобных хранилищ — макси- тельного сервиса на фреймворке Hadoop, можно
мальная производительность, поэтому никакая отметить, что NoSQL хранилища кажутся прием-
информация о структуре значений не сохраняется. лемым вариантом их устранения. NoSQL хранилища
2. Документо-ориентированные хранилища. обеспечивают высокую пропускную способность
Модель данных подобных хранилищ позволяет данных как при чтении, так и при записи. Из этого
объединять множество пар ключ-значение в следует, что логи доступа к веб-приложению можно
абстракцию, называемую «документ». Документы записывать непосредственно в базу данных. Важно
могут иметь вложенную структуру и объединяться в также отметить, что при использовании документо-
коллекции. Однако это скорее удобный способ ориентированных решений, логам можно придавать
логического объединения, т.к. никакой жесткой произвольный вид, не создавая жесткую схему. Это
схемы у документов нет и множества пар ключ- позволяет решать довольно интересную задачу
значение, даже в рамках одной коллекции, могут хранения и обработки структурированных логов. К
быть абсолютно произвольными. Работа с тому же механизм выборки документов по
документами производится по ключу, однако значениям атрибутов позволяет решать множество
существуют решения, позволяющие осуществлять аналитических задач.
запросы по значениям атрибутов. Большинство современных NoSQL решений
3. Колоночные хранилища. Этот тип кажется реализуют парадигму вычислений MapReduсe.
наиболее схожим с традиционными реляционными Наряду с фундаментальным свойством горизонталь-
СУБД. Модель данных хранилищ подобного типа ного масштабирования, это дает возможность пере-
подразумевает хранение значений как неинтерпрети- носить алгоритмы, предназначенные для фреймвор-
руемых байтовых массивов, адресуемых кортежами ков типа Hadoop на хранилища NoSQL, получая все
<ключ строки, ключ столбца, метка времени> [3]. дополнительные преимущества.
Основой модели данных является колонка, число Учитывая высокую пропускную способность
колонок для одной таблицы может быть операций чтения, задачу подсчета рекомендаций и
неограниченным. Колонки по ключам объединяются их использования, можно не разделять. Следова-
в семейства, обладающие определенным набором тельно обновленные рекомендации будут тут же
свойств. доступны потребителям, приближая сервис к требо-
4. Хранилища на графах. Подобные ваниям реального времени.
хранилища применяются для работы с данными, Далее следовало определиться с конкретным
которые естественным образом представляются продуктом, который можно было бы использовать
графами (напр. социальная сеть). Модель данных для реализации сервиса. Среди документо-ориен-
состоит из вершин, ребер и свойств. Работа с тированных баз данных первоначальный выбор пал
данными осуществляется путем обхода графа по на проект Apache CouchDB [1]. CouchDB работает с
ребрам с заданными свойствами. документами, представленными в формате JSON.
Таблица 1 Для работы с документами предоставляется REST
Классификация NoSQL хранилищ по модели данных API. Для построения запросов к документам
Тип Проекты CouchDB и их анализа применяются так называемые
«представления». По сути представление является
Хранилища ключ- Redis обычной MapReduce задачей, которая может
значение Scalaris сохранять результаты выполнения в базе. Интерес-
ной особенностью модели данных CouchDB
Tokio Tyrant
является то, что для индексации документов и
Voldemort представлений используются модифицированные B-
Riak деревья. Сохраняя все особенности и преимущества
стандартного B-дерева, B-деревья CouchDB
Документо- SimpleDB реализуют режим «только добавление». Это
ориентированные CouchDB означает, что любые операции вставки, модифи-
хранилища кации и изменения записываются в конец файла,
MongoDB
представляющего B-дерево на диске. Такая архитек-
Колоночные хранилища Bigtable тура дает два основных преимущества: высокая
HBase скорость записи и возможность исполнять
MapReduce задачи только на изменившихся данных.
HyperTable
Однако, при всех своих преимуществах, CouchDB не
Cassandra подходила для нашей задачи. Во-первых, проект не
поддерживает никакого языка запросов, что сильно
Хранилища на графах Neo4j
затрудняет выборку документов по определенным
284
критериям. Во-вторых, важным критерием выбора MongoDB. Возвращаясь к реализации первого этапа
была поддержка ссылок на другие документы. в разделе 3.1, можно отметить, что задачи фильтра-
Подобная возможность есть в CouchDB, но работает ции логов и подсчета значений хеш-функций для
она только на этапе эмиссии документа из map- них реализуются загрузчиком. Поэтому оставалось
задачи. К тому же, нет возможности создания перенести только подсчет минимальных значений
ссылок на документы из других баз. В-третьих, хешей и отсечение групп с заданной численностью
неоптимизированное JSON представление докумен- (см. рис. 3).
тов приводит к увеличению трафика между клиен-
том и хранилищем, чего хотелось избежать.
Рис. 3. Схема
Окончательный выбор пал на проект
MongoDB[4]. Обладая всеми преимуществами
CouchDB, это хранилище устраняет перечисленные
недостатки и предоставляет дополнительные
удобные возможности. Они будут упомянуты в
следующем разделе, описывающем реализацию
рекомендательного сервиса.
работы первого этапа NoSQL реализации
7. Реализация рекомендательного
сервиса Рамблер-новости Стоит обратить внимание, что из новой
Первая задача, которую предстояло решить — реализации пропал этап отсечения групп по
это запись логов в базу данных MongoDB. Первым численности. В первоначальной реализации
делом требовалось определить, какое количество отсечение делалось, главным образом, для
операций записи в секунду обеспечивала наша сокращения времени загрузки отображения
конфигурация. Стоит отметить, что тестовая <идентификатор пользователя → группа> в Redis.
конфигурация представляла кластер из двух узлов, При использовании NoSQL хранилища подобной
на каждом их которых был запущен демон mongod проблемы не возникает.
без репликации. На одном их хостов запускался Возвращаясь к цифрам, задача подсчета
демон mongos, обеспечивавший шардинг минимального хеша для суточных логов (2770695
документов. Для определения скорости записи был записей) заняла примерно 3 минуты 10 секунд. Это
разработан простой скрипт, производивший загрузку не сильно отличается от времени выполнения той же
суточных логов новостей в базу MongoDB. Лог задачи на Hadoop кластере, и почему это происходит
состоял из 2770695 записей. Среднее время записи вполне очевидно. Однако здесь нам на помощь
составило 18 минут 30 секунд. Таким образом приходит вся мощь MongoDB. Во-первых,
средняя скорость записи в представленной результаты MapReduce задач сохраняются в
конфигурации - 2496 операций/сек. Шардинг отдельной коллекции. Последующие вычисления
документов осуществлялся по атрибуту ruid можно производить только на добавленных с
(уникальный идентификатор пользователя). прошлого запуска логах, выполняя rereduce на
Подобный результат более чем достаточен для получившихся результатах. Во-вторых, мощный
нашего сервиса, т.к. среднее количество запросов в язык запросов MongoDB позволяет осуществить
секунду к веб-сайту Рамблер-новости существенно выборку логов, добавленных с момента последнего
меньше. Однако, загрузка логов из ротированных запуска задачи. В нашей архитектуре задача
лог-файлов нам совсем не подходила. Для сохранения времени последнего выполнения и
удовлетворения требования реального времени перезапуск вычислений возложена на загрузчик
необходимо было обеспечить загрузку логов в базу логов. Важно отметить, что высокая производитель-
сразу после обработки запроса веб-сервером. Для ность библиотеки ZeroMQ позволила не масштаби-
этого, с помощью библиотеки ZeroMQ, был ровать загрузчик логов, поэтому проблем с
разработан специализированный демон, синхронизацией времени не возникало. В-третьих,
агрегировавший логи с нескольких фронт-эндов MongoDB поддерживает создание и поддержание
новостей в хранилище MongoDB. Необходимо индексов на атрибутах документов, что существенно
отметить, что загрузчик логов не только производил ускоряет выборки. Сделав выводы из всего
их фильтрацию, представление в формате BSON и вышесказанного было принято решение перезапус-
запись в базу, но и подсчет значений хеш-функций кать задачу подсчета минимального хеша после
для каждого URL. Это было обусловлено двумя записи одной тысячи новых логов с выборкой по
факторами: снижением времени вычислений и атрибуту timestamp документа. Данная задача без
отсутствием приемлемых реализаций быстрого индекса завершалась в среднем через 3 сек, а с
хеширования в языке JavaScript (на нем реализуются индексом — через 400-500мс, что уже существенно
MapReduce задачи в MongoDB). приблизило нас к требованиям реального времени.
После того, как задача загрузки логов была Теперь перейдем ко второму этапу алгоритма —
решена, необходимо было перенести реализацию выработке рекомендаций. Здесь возникают три
алгоритма подсчета рекомендаций с Hadoop на основные проблемы: выборка логов в заданном
285
временном окне, дополнительная фильтрация и ввод 8. Проблемы, возникшие при реализации
данных из нескольких источников. Выборку логов в
заданном временном окне можно, как и на первом
сервиса рекомендаций
этапе, осуществлять запросом по атрибуту Естественно, при реализации сервиса возник
timestamp. Стоит отметить, что MongoDB реализует определенный набор трудностей, о которых важно
capped collections. Это коллекции с заранее упомянуть. Первая трудность — ротирование логов.
определенным объемом. Если объем коллекции Так как в MongoDB отсутствует механизм времени
достиг заданного порога, то новые значения жизни ключей, задачу ротирования логов
затирают старые. Это интересный подход к ротации, приходится решать периодическим запуском
но для нашей задачи он не подходит, т.к. количество отдельной MapReduce задачи. К тому же во всех
логов может меняться день ото дня. Дополнительная документах, требующих удаления, приходится явно
фильтрация осуществляется регулярными выраже- хранить метку времени жизни. Вторая трудность
ниями JavaScript, здесь нет никаких сложностей. заключается в том, что формат возвращаемых map-
Проблема ввода данных из нескольких источников задачей значений должен совпадать с форматом
решается с помощью механизма DBRef MongoDB. значений, возвращаемых reduce-задачей. Из-за этого
Он позволяет создавать ссылки на связанные приходится создавать довольно сложные структуры,
документы в виде вложенных документов и чего хотелось бы избежать. Третья трудность — это
получать к ним доступ при выполнении map-задач. специфическое устройство шардинга в MongoDB.
Удобная особенность DBRef следует из отсутствия Ключи распределяются по узлам не равномерно, а
схемы документов и других ограничений — группами. Из-за этого некоторые MapReduce задачи
ссылаться можно на несуществующие документы и на небольшом количестве документов выполняются
коллекции. Этим фактом пользуется загрузчик на одном узле, содержащем все ключи.
логов, создавая ссылки на группы, которых еще нет.
Таким образом, первые две ступени второго этапа 9. Заключение
получилось объединить в одну: map-задача
фильтрует выборку логов во временном окне 5 часов В результате проведенного эксперимента удалось
и возвращает пару , а reduce-задача создать рекомендательный сервис, время пересчета
подсчитывает количество кликов по каждой новости рекомендаций в котором на каждую тысячу новых
всех групп. Среднее время выполнения этой ступени логов составляет 1.5-2 секунды. Для проекта
— 350мс на той же тысяче логов. Третья ступень Рамблер-новости подобный результат является
была просто адаптирована для исполнения удовлетворительным, т.к. 1000 новых запросов к
MongoDB. Надо, правда, отметить, что отсечение сайту делается за чуть большее время. Стоит
заданного количества популярных новостей не отметить, что алгоритм MinHash, как таковой, не
производится. Эту задачу, с целью сокращения предназначен для подсчета рекомендаций в режиме
вычислений, было решено возложить на потреби- реального времени. Более того, эффективность
теля. Также следует сказать, что в последней новой реализации рекомендательного сервиса может
ступени используется функция finalize, позволя- оказаться ниже, чем предыдущая реализация с
ющая видоизменить результаты reduce-задачи. В помощью фреймворка Hadoop. Однако целью
нашем случае функция finalize производит данной работы было показать целесообразность
сортировку новостей в группах по числу кликов. применения NoSQL подхода к построению систем
анализа данных в режиме близком к режиму
реального времени. Сделанные выводы позволят
реализовать на описанной платформе более
подходящие рекомендательные алгоритмы, напри-
мер Covisitation [5]. Важным свойством приведен-
ной реализации является то, что задачи хранения и
анализа данных удалось объединить с задачей
предоставления доступа к результатам в единой
системе, избежав накладных расходов на переме-
щение данных из одного источника в другой и улуч-
шив общую производительность сервиса. Кроме
того, предложенный подход упрощает решение
повседневных задач сбора статистики о взаимо-
действии пользователя с веб-приложением путем
анализа структурированных логов мощным языком
запросов СУБД MongoDB. Можно утверждать, что
применение NoSQL подхода к решению подобного
класса задач является перспективным и может быть
Рис. 4. Схема работы второго этапа NoSQL использован в продуктивном окружении высокона-
реализации груженных веб-приложений.
286
Литература on Opearting Systems Design & Implementation,
vol. 6, p. 10-10, USENIX Association Berkeley,
[1] J. Chris Anderson, Jan Lehnardt, Noah Slater. CA, USA, 2004.
CouchDB: The Definitive Guide. O'Reilly Media, [7] Jaroslav Pokorny. NoSQL databases: a step to
2010. database scalability in web environment. Proce-
[2] Rick Cattel. Scalable SQL and NoSQL data stores. edings of the 13th International Conference on
ACM SIGMOD Record, 39(4), p. 12-27, ACM Information Integration and Web-based Applica-
New York, NY, USA, December 2010. tions and Services, p. 278-283, ACM New York,
[3] Fay Chang, Jeffrey Dean, Sanjay Ghemawat, NY, USA, 2011.
Wilson C. Hsieh, Deborah A. Wallach, Mike [8] Christof Strauch. NoSQL Databases.
Burrows, Tushar Chandra, Andrew Fikes, Robert http://www.christof-strauch.de/nosqldbs.pdf
E. Gruber. Bigtable: a distributed storage system [9] Jason Venner. Pro Hadoop. Apress, 1st edition,
for structured data. Proceedings of the 7th 2009.
USENIX Symposium on Operating Systems
Design and Implementation, vol. 7, p. 15-15, Building real-time recommendation services
USENIX Association Berkeley, CA, USA, 2006.
with NoSQL
[4] Kristina Chodorow, Michael Dirolf. MongoDB:
The Definitive Guide. O'Reilly Media, 2010. P.A. Klemenkov
[5] Abhinandan S. Das, Mayur Datar, Ashutosh Garg,
The paper discusses the analysis of user interacttion
Shyam Rajaram. Google news personalization: with a Web application, methods of conducting such an
scalable online collaborative filtering. Proceedings analysis, and their shortcomings. An implementation of
of the 16th international conference on World Wide the news recommendation service using existing appro-
Web, p. 271-280, ACM New York, NY, USA, aches is described. A new NoSQL approach to building
2007. recommendation systems that operate in near real time
[6] Jeffrey Dean, Sanjay Ghemawat. MapReduce: is proposed.
simplified data processing on large clusters.
Proceedings of the 6th conference on Symposium
287