Текст: BeeOML

Все мы знаем, что MySQL называется реляционной базой данных, а многие другие механизмы хранения называются нереляционными базами данных, GDB, которую мы здесь обсуждаем, — одна из них. По иронии судьбы MySQL называют реляционной базой данных, но на самом деле она не очень дружелюбна для работы с ассоциациями. Небольшой небрежный оператор соединения — это медленный запрос.Студенты DBA часто смотрят на оператор соединения и часто предлагают не использовать его, если мы можем. Хранение структуры графа в GDB (базе данных графов) само по себе представляет отношения ассоциации и может хорошо решать эти проблемы.

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

Что такое ГБД

Полное название Graph Database — нереляционная база данных, которая использует структуру данных графа для семантического запроса, использует «узлы», «направленные ребра» и «атрибуты» для представления и хранения данных. Давайте сначала передадим изображение, чтобы интуитивно почувствовать его.На рисунке ниже каждая плотная точка — это каждый пользователь «Пользователь», а связь между точками представляет собой отношение внимания «Внимание»:

Сравнивая с MySQL, мы можем лучше понять некоторые понятия существительных в данных графа, а именно:

База данных имен	имя сущности	имя объекта	данные объекта	Запрос синтаксиса
GDB	метка	Узел, край (узел, край)	имущество	Cypher
MySQL	Таблица	записывать	поле	SQL

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

бизнес-семантика	SQL	Cypher
Опросить 10 пользователей	select * from users limit 10;	match (a:users) return a limit 10;
Запрос для пользователей с меткой «очевидно»	выберите t.* из пользователей как tinner, присоединитесь к user_tag_relation как utr по utr.userId= t.userIdinner присоединитесь к user_tag как u по u.tagId= utr.tagId, где u.tag_name= 'star'	match (t:users)-[utr:usesr_tag_relation]->(u:user_tag), где u.tag_name = 'star' возвращает t
легенда	ER-диаграмма:	Структура диаграммы:

В приведенном выше синтаксисе (t:users)-[utr:usesr_tag_relation]->(u:user_tag) очень похож на структуру графа, круглые скобки () рассматриваются как узлы, квадратные скобки [] рассматриваются как ребра, ( )-[] ->() может очень ярко выразить структуру хранения.

Зачем использовать ГБД

Как упоминалось в предисловии, некоторые предприятия сообщества очень подходят для реализации GDB. Ниже перечислены два распространенных типа бизнеса:

Кому-нибудь, на кого я подписан, понравился этот контент?
Люди, на которых я подписан Другие люди, на которых я подписан в течение определенного периода времени.

Мы имеем дело с решением MySQL и решением GDB соответственно, а затем сравним их преимущества и недостатки, и тогда мы сможем получить ответ на этот раздел. Пример данных описан ниже в виде графика.

Кому-нибудь, на кого я подписан, понравился этот контент?

Общая схема MySQL:

Найти всех подписчиков (существующий кеш набора): выберите followUserId из user_follow, где userId = {$userId}
Запросите, понравилось ли что-то этим пользователям: выберите * из content_light, где userId в { $followUserId} and contentId in {$ contentId}

- Следует отметить, что в запросе, в случае большого массива, индекс часто дает сбой.Причина в том, что если стратегия индекса MySQL обнаруживает, что индекс нужно запрашивать слишком много раз при оценке, он может быть не таким быстрым. как сканирование таблицы напрямую. Это также причина, по которой студенты DBA рекомендуют не превышать 200 запросов.

GDB-решение:

Запишите структуру узлов и ребер согласно легенде: match (u1:User) -[:Attention]->(u2:User)-[:Light]->(c:Content) где u1.userId = { $userId} and c.contentId in {$ contentIds} return u2.userId , c.contentId;

Сравнение схемы:

В решении MySQL, когда есть много «пользователей, за которыми я следую» (в Dewu много людей, которые подписаны более чем на 1000 человек), существует риск медленной проверки. В решении GDB оператор запроса краток и эффективен, а эффективность запроса также высока.Так называемое «без изображения и без доказательств», следующее изображение представляет собой фактические данные (без кеша Redis):

Люди, на которых я подписан Другие, которые подписаны в течение 24 часов

Общая схема MySQL:

Найти всех подписчиков (существующий кеш набора): выберите followUserId из user_follow, где userId = {$userId}
подтаблица user_follow_xx для запроса этих следующих пользователей и других людей, на которых они подписаны

GDB-решение:

Запишите структуру узлов и ребер согласно легенде: match (u1:User)-[:Attention]->(u2:User)-[:24HAttention]->(u3:User) return u3;

Сравнение схемы:

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

Как использовать ГБД

изучение грамматики

Сайфер:neo4.com/docs/cypher…Больше похоже на SQL, более наглядное, простое для понимания и с меньшими затратами на обучение.
гремлин:tinkerpop-gremlin.cn/#traversalОн больше похож на ORM, он инкапсулирует множество связанных методов, а стоимость обучения высока.

Возникшие проблемы и решения

1. Проблема уникального индекса: чтобы обеспечить уникальность данных, мы обычно устанавливаем уникальные ограничения.

Синтаксис создания индекса: Create CONSTRAINT on (a:User) ASSERT a.userId IS UNIQUE - На практике индекс GDB Alibaba Cloud может дать сбой, и для обновления данных требуется специальный синтаксис: -- Аналогично MySQL при обновлении двойного ключа, для обновления, если он существует, и вставки, если он не существует: merge (n:User{userId: $userId}) on create set n.isAllowLike =$ isAllowLike on match set n.isAllowLike = $isAllowLike return n.userId as userId

1. Проблемы эффективности запросов второго уровня:

Старайтесь не использовать атрибуты вторичного запроса для сортировки, вы можете уменьшить порядок величины вторичного запроса в соответствии с бизнесом и сортировать по коду результата
Плохой пример: match (u:Пользователь)-[:Внимание]->(c:Пользователь)-[a:Внимание]->(t:Пользователь), где u.userId= $userId and a.createTime > {$ TTFtime} return c.userId as cUserId, t.userId as tUserId order by a.createTime desc

Пример хорошего случая: match (u:User)-[:Attention]->(c:User)-[a:TTFAttention]->(t:User) где u.userId=$userId возвращает c.userId как cUserId, t.userId как tUserId

будущие приложения

Ниже приведены несколько примеров для расширения сценариев применения.

График зависимости развертывания

Когда мы выпускаем версию, мы обычно организуем список релизов.Самая важная часть — прояснение зависимостей.Иногда проектов много, а зависимости сложны и зачастую их трудно четко выразить с помощью таблиц и других методов. Мы очень четко выражаем зависимости через GDB.

На следующем рисунке представлена схема развертывания определенной версии, которая имеет несколько характеристик:

Диаграмма развертывания становится «лесом».
Разные «деревья» в «Лесе» можно публиковать независимо друг от друга.

Через «направленное ребро» можно узнать зависимости «дерева».
Публикация должна начинаться с «корневого узла».

Портрет пользователя

Я сделал себе портрет пользователя, и благодаря схожести портретов разных пользователей я могу найти друзей-единомышленников.

График знаний

Хотите узнать об отношениях между главными семьями в «Игре престолов»? Этот вид графа знаний может быть очень удобен для поиска чьих-либо родственных связей.

Суммировать

В настоящее время служба GDB сообщества поддерживает сотни миллионов точек и граничных реляционных данных, сотни запросов в секунду и среднее RT около 28 мс, что хорошо поддерживает эту часть бизнес-сценария. Конечно, GDB точно не панацея, я считаю, что в этом мире нет лучшей технологии, есть только технология, наиболее подходящая для текущего сценария применения.

Из-за нехватки места в этом документе нет более подробного обсуждения с вами. Обсуждения в автономном режиме приветствуются. Наконец, я надеюсь, что эта статья может принести вам вдохновение и идеи, спасибо за чтение.

Если это полезно, вы можете оставить сообщение или подписаться на общедоступный аккаунт «Dewu Technology WeChat»!