СТРУКТУРА ДАННЫХ ДЛЯ ХРАНЕНИЯ ИНФОРМАЦИИ В СОЦИАЛЬНЫХ СЕТЯХ

Предложена структура данных для хранения «постов» в социальных сетях с небольшим количеством пользователей. Перед разработчиками стоит задача выбора удобной и эффективной системы хранения информации. Созданные в работе структуры данных учитывают особенности no-SQL и SQL хранилищ данных. Производительность каждой из предложенных моделей проверяется на запросах разной сложности к базам данных разной структуры. Эффективность предложенных структур проверяется на конкретных данных.

Данные в социальных сетях представляют собой текстовые сообщения различных пользователей, которые вывешиваются(post up) на страничках членов сети или стра­ничках сообществ сети. Поэтому такие сообщения называют «постами». Посты при­надлежат страничкам пользователей или сообществам сети. Данные постов не требуют синхронизации. Помимо страничек в социальных сетях, которые мы рассматриваем, существует понятие «новостная лента». «Новостная лента» - это подборка «постов» ав­торов, на которые подписан пользова­тель, отфильтрованная по дате. Между авторами в сети существуют отноше­ния «подписка» и «друг». Авторы- «друзья» могут комментировать сообщения друга, а авторы-«подписчики» могут лишь просматривать сообщения определённого пользователя сети.

Задача заключается в выборе спо­соба хранения «постов», который обес­печивал бы минимальное время фор­мирования странички пользователя сети или минимальное время формирования «но­востной ленты».

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

Впервые термин NoSQL был употреблён в 1998 году Карло Строззи (Carlo Strozzi) для обозначения своей базы данных, не поддерживавшей язык запросов SQL. В совре­менном значении термин был выдвинут в 2009-м, когда Йохан Оскарссон (Johan Oskarsson) решил организовать встречу разработчиков для обсуждения распределенных баз данных. Сам акроним NoSQL принято расшифровывать как «Not only SQL». Это должно означать, что сообщество разработчиков NoSQL не позиционирует нереляци­онные хранилища как универсальное решение и подразумевает использование реляци­онных моделей хранения данных там, где это имеет смысл. Разработчики NoSQL хра­нилищ опираются на теорему Брюера.

Теорема Брюера или CAP теорема (акроним от Consistency, Availability, Partition tolerance)[1] заключается в следующем - невозможно создать распределенный веб­сервис, удовлетворяющий сразу трём требованиям: согласованности (consistency), до­ступности (availability) и устойчивости к разделению на части (partition tolerance).

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

Согласованность и устойчивость к разделению при отсутствии доступности - такой подход обеспечивает согласованность данных в ущерб доступности (в редких случаях да­же в ущерб сохранности последних совершенных транзакций - см. Redis). Такой подход используют продукты BigTable, HBase, MongoDB, MemcacheDB, BerkeleyDB и другие.

Доступность и устойчивость к разделению при отсутствии согласованности - к этому классу относятся системы, направленные на быструю обработку больших объемов данных в условиях, когда появление этих данных на всех узлах системы в опреде­ленном порядке не имеет большого значения. Главными представителями этого класса являются потенциально согласованные (eventually consistent) системы, такие как Cassandra, Dynamo, Voldemort, CouchDB, SimpleDB и другие.

В дальнейшем будем рассматривать реляционную БД - Postgres и нереляционное хранилище MongoDB, т. к. для рассматриваемых социальных сетей не требуется разде­ление на узлы.

MongoDB - это документо-ориентированное нереляционное хранилище данных, использующее для хранения данных формат BSON - расширение формата JSON (JSON - JavaScript Object Notation, BSON - Binary JSON)[2]. Каждый экземпляр сервера MongoDB содержит несколько баз данных. Каждая база данных состоит из коллекций. Коллекция содержит в себе документы. Документы являются наборами полей, пред­ставляющих из себя пары ключ-значение. Структура данных лишена схемы. Так, один
документ может иметь разные поля, а поля документа с одинаковым именем не обяза­тельно будут иметь один тип.

Сравним организацию данных в реляционной базе и в MongoDB.

Реляционная модель социальной сети содержит сущности: Users (user and commu­nity), UserToUser (для описания связей между пользователями), Post (реализована связь, отражающая иерархическую зависимость между постами - посты в ответ на другие по­сты). Такая модель позволяет формировать достаточно широкий набор запросов разной сложности.

Для работы с MongoDb используется Orm(Object-relational mapping) Google.morphia. ORM - технология программирования, которая связывает базы дан­ных с концепциями объектно-ориентированных языков программирования, создавая «виртуальную объектную базу данных». В случае использование Google.morphia доста­точно создать ряд объектов, описав их с помощью соответствующих классов. В каждом классе есть поля и методы работы с ними, а также обрабатываются возникающие в процессе работы исключительные ситуации согласно модели, приведенной в [3].

Модель в MongoDB представляет собой набор следующих сущностей:

@Entity("users")
public class User {
   @Id private ObjectId userId;
   @Property("user_name") private String
name;
   @Embedded private Wall userWall;
   @Reference(ignoreMissing = true)
private List<User> friends;
}
public abstract class AbstractPost {
   @Id private ObjectId id;
   @Property ("text") private String text;
   @Property ("author") private ObjectId author;
   @Property ("parent") private ObjectId redactor;
}
Entity("posts")
   @Indexes({
   @Index(name = "wall_id_index", value =
"wall_id"),
   @Index(name = "author_id_index", value =
"author")} )
public class Post extends AbstractPost {
   @Property("theme") private String theme;
   @Property("wall_id") private ObjectId
wallId;}

Приведенная модель использует аннотированные объекты и DAO(data access object) подход, предоставляющий абстрактный интерфейс к базе MongoDb. Вся конфигурация задается аннотациями, XML файлы не используются.

В работе была сымитирована социальная сеть, имеющая 100000 user^. Каждый user имел в среднем по 50 друзей и 100 подписчиков. В post’ах было сделано в среднем по 70 сообщений на страничку каждого пользователя.

Генерация такой модели в Postgres достаточно длинная процедура. Важно пра­вильно сформировать ключи и индексы во всех трех таблицах. Для таблицы UserToUser создаем индекс по двум полям user1,user2. Для таблицы Post создаем индекс по вла­дельцу «стены» и индекс по автору «поста».

В MongoDB формирование модели занимает несколько минут за счет того, что набо­ры данных можно писать сначала с оперативную память, а затем скидывать на диск. Для этого использовалась JDK 1.8 и следующие настройки VM -d64 -Xms512m -Xmx4g.

Рассмотрим ряд типичных запросов, необходимых для формирования странички пользователя.

Для поиска всех «постов» пользователя с id = 100054 с учетом иерархии исполь­зовался следующий рекурсивный запрос:

WITH RECURSIVE temp1 ( "id","parentPost","authorId","subject","content",PATH, LEVEL ) AS (
SELECT T1."id",T1."parentPost",T1."authorId", T1."subject",T1."content", CAST (T1."id" AS VARCHAR
(50)) as PATH, 1 FROM "socialNework".post T1 WHERE T1."parentPost" IS NULL and T1."ownerId"
= 100054
   union select T2."id",T2."parentPost", T2."authorId", T2."subject",T2."content", CAST ( temp1.PATH ||'-
>'|| T2."id" AS VARCHAR(50)) ,LEVEL + 1 FROM "socialNework".post T2 INNER JOIN temp1 ON(
temp1."id"= T2."parentPost") where T2."ownerId" = 100054 )
   select * from temp1 ORDER BY PATH LIMIT 100

Получился следующий результат:

Рис. 1. Результат рекурсивного запроса

В MongoDB этот результат получается с использованием запроса: db.test.find({{wall_id :”100054”},{parent: 'branch_root_id'}}); Время выполнения этого запроса в среднем 70мс.

Результаты тестирования отражены в таблице 1.

Таблица 1. Среднее время выполнения запросов

Для нагрузочного тестирования использовалось приложение Apache JMeter.

План тестирования:

1. Thread group создаёт 100 потоков и выполняет 5 циклов.
2. Созданные потоки соединяются с базой данных с помощью JDBC-драйвер.
3. Потоки делают по одному запросу на формирование странички user^ к postgres и mongoDB.
4. Данные запросов отображаются на графике и в агрегированном отчете.

Таблица 2. Время выполнения запроса под нагрузкой

Качественные показатели по работе с БД отражены в таблице 3.

Таблица 3. Качественное сравнение БД

Результаты эксперимента позволяют сделать вывод о том что, производитель­ность Postrges и MongoDB при формировании странички пользователя и новостной ленты в социальных сетях небольшой размерности примерно одинакова. Поэтому, если у разработчиков сети есть привязка к реляционной базе в силу каких либо причин, например исторических, то не стоит переходить на модные в настоящий момент NoSQL БД. Если такой привязки нет и в команде нет специалистов SQL, то есть смысл воспользоваться MongoDB, так как формирование запросов в такой БД проще и связь с БД осуществляется с использованием непосредственно объектов, т.е. пропадает необ­ходимость в создании слоя DAO.

Авторы считают, что в данной работе новыми являются следующие положения и результаты:

1. Модель структуры данных для хранения «постов» в социальных сетях, реализованная для Postgres и MongoDB. Оценка производительности БД с помощью созданной модели.
2. Программный продукт, который реализует модель БД, и позволяет рассчитать различные параметры Postgres и MongoDB при использовании их в социальных сетях

Литература

1. Brewer Eric A. Towards robust distributed systems // Proceedings of the XIX annual ACM symposium on Principles of distributed computing. - Portland, OR: ACM, 2000. Т. № 7.
2. Кристина Чодороу, Майкл Дирольф MongoDB: The Definitive Guide. - O’Reilly Media, 2010. - 216 с.
3. Волушкова А.Ю. Анализ работы с исключениями в различных языках программирования // Образовательные ресурсы и технологии. 2014. № 1. С. 62-67

Авторы статьи

Вера Львовна Волушкова, канд.техн.наук, доц., Тверской государственный университет
Александра Юрьевна Волушкова, студент, Московский авиационный институт

Аннотация статьи на английском

Structure of data for information storage in social networks

Vera Lvovna Volushkova, Candidate of Technical Sciences, Associate Professor Tver state university

Authors: Alexandra Yurevna Volushkova, student Moscow Aviation Institute

The structure of «posts» for storage in social networks with a small amount of users is offered. The developers face the problem of choosing an effective system of information storage. The data struc­tures created in the work consider features of no-SQL and SQL storages of data. Productivity of each models is checked on inquiries of different complexity to databases of different structure. The efficien­cy of the offered structures is checked on concrete data.

Key words: databases, NoSQL databases, MongoDB.

Текст статьи в формате PDF

Вас заинтересует / Intresting for you:

Перспективные системы хранения... 1553 просмотров Денис Mon, 18 Mar 2019, 12:00:18

Технологии создания базы данны... 2681 просмотров Денис Tue, 19 Mar 2019, 11:20:45

Анализ современных технологий ... 1153 просмотров Александров Попков Mon, 18 Mar 2019, 03:22:01

Применение интеллектуального а... 1487 просмотров Денис Fri, 22 Mar 2019, 10:03:30