1. Things Happen for A Reason
В одном из моих любимых фильмов, "Война шпионов", есть строчка "Вещи случаются не просто так", не знаю почему, я до сих пор под большим впечатлением от этой строчки, может быть, когда я увидел ее в время Когда произносится предложение, вспышка вдохновения или резонанс произведут такое глубокое впечатление. Почти с тех пор, независимо от того, делаю ли я что-то или думаю, я естественным образом шаг за шагом разрабатываю основные принципы извлечения и анализа вещей из лежащей в их основе логики.
Например, в последнее время я занимаюсь проектированием технической архитектуры продукта, почти половина времени уходит на разбор бизнес-процессов и требований, классификацию бизнеса, а затем на сопутствующие технические исследования. Среди них Neo4j является одной из основных ролей в техническом решении, и этот пост также содержит некоторые мысли о Neo4j, базе данных NoSQL, в этой архитектуре.
1.1 Neo4j
Как быстро разобраться в Neo4j В интернете много длинных текстов, но я не думаю, что они ясны и просты. Я думал о том, как заставить всех понять Neo4j самым быстрым и эффективным способом.Лучший способ - это обобщить следующие предложения:
- База данных NoSQL с открытым исходным кодом, собственная графовая база данных, разработанная в 2003 г. с использованием языков scala и java и выпущенная в 2007 г.;
- Одна из самых передовых баз данных графов в мире, обеспечивающая собственное хранение, поиск и обработку данных графов;
- Модель графа свойств принята для значительного улучшения и обогащения модели данных графа;
- Эксклюзивный язык запросов Cypher, интуитивно понятный и эффективный;
2. Neo4j Kernel
Графовых баз много, достаточно полный список есть на этой вики:List of graph databases, некоторые из них, кажется, не поддерживаются, некоторые являются традиционными базами данных NoSQL, но обеспечивают хранение структуры данных графа, а некоторые представляют собой выделенные базы данных графов, такие как Neo4j, но даже для специализированных баз данных графов базовая реализация, сценарии приложений и экология тоже очень разные.
Сегодня мы сосредоточимся на Neo4j, Мы в основном изучаем и глубоко понимаем Neo4j из следующих аспектов.
2.1 Native Graph Storage and Processing
Как мы упоминали ранее, на самом деле существует множество графовых баз данных, некоторые из которых представляют собой документоподобные базы данных NoSQL (предполагается, что они называются БД), которые также поддерживают хранение и извлечение структур графовых данных.Самая большая разница между базами данных этого типа и Neo4j заключается в том, что он подключается к Далее, мы собираемся поговорить о базах данных графов Native и Non-Native. Проще говоря, Neo4j — это собственная графовая база данных, а ADB — неродная графовая база данных.
Так называемая база данных собственных графов, которая обычно переводится на китайский язык как «база данных собственных графов», относится к базе данных, предназначенной для решения структуры данных графа с самого начала. Для студентов, которые понимают структуру данных, «родное» выражение здесь в основном имеет два аспекта:
- Хранение структур данных графа
- Обработка и запрос графических данных
Мы также говорим о Neo4j с этих двух точек зрения.
Хранение структур данных графа
Независимо от того, какая это база данных, mysql, sql server, mongo, neo4j и т. д., данные, хранящиеся в ней, в конечном итоге попадут в файловую систему. Здесь я представлю базу данных локального приложения.
Выше приведен файл базы данных моей локальной базы данных графа.Видно, что Neo4j делит свои файлы базы данных на четыре категории для классификации и хранения:
- Этикетка
- узел
- Атрибуты
- связь
На самом деле, согласно общему утверждению нашей теории графов, фактически для структуры данных графа необходимо хранить только узлы и отношения, как в следующих данных графа:
Но в реальной жизни структура нашего графа очень сложная, а объем данных очень большой, и нам часто нужно делать различные анализы, и даже кластерный анализ (кластерный анализ здесь не относится к кластеризации в машинном обучении). Модель класса, но относится к извлечению данных того же типа для отдельного анализа, подобно операции groupby). Таким образом, Neo4j хранит теги и атрибуты отдельно в файловой системе, чтобы обеспечить производительность во время поиска и анализа. Давайте рассмотрим визуальный пример, чтобы представить, что такое метка и что такое атрибут.
Вот реальный случай в нашем приложении, давайте взглянем на наше разделение тегов и атрибутов:
-- 这里咱们先看看这个语句表达的什么意思，这是 Neo4j 专用的查询语言 Cypher
-- 大家不要听到又要学一门新语言就打退堂鼓哈，哈哈哈，后面我们会简单讲讲这个语言的，两个字：简单
-- 下面这个查询语句含义如下：
-- step 1: 首先查询一个具有标签为 “沪深股市”，且有一个属性对 “{name: "sha_600610"}” 的节点，
-- step 2: 然后查找这个节点的所有双向关系
-- step 3: 在这些关系的中，要求另外一个节点具有 “人物_公司股东” 这个标签
-- step 4: 返回这个节点，以及满足要求的关系和相关节点
MATCH (node1:沪深股市 {name: "sha_600610"})-[relation]-(node2:人物_公司股东)
RETURN node1, node2, relation
Некоторые могут спросить, на самом деле не обязательно хранить теги и атрибуты отдельно, мы можем полностью хранить теги и атрибуты в узлах как метаинформацию узлов. Во-первых, в этом утверждении нет проблем с точки зрения теории и инженерной реализации. Но представьте себе граф с очень, очень большими узлами и отношениями, столкнетесь ли вы с некоторыми проблемами при выполнении вышеуказанного поиска? И как дизайн хранилища Neo4j решает эти проблемы? Эти два вопроса оставлены для размышления каждому, и вы можете обменяться мнениями в комментариях.
Обработка и запрос графических данных
Обработка графических данных осуществляется по тому же правилу четырех символов, что и в традиционных базах данных: CURD. А из-за специфики данных графа в большинстве случаев каждый узел в базе данных имеет связанное с ним отношение, и каждое отношение должно иметь два узла, связанных с этим отношением. Это требует, чтобы создание, обновление, чтение и удаление базы данных графа соответствовали принципу согласованности (или целостности транзакций). Я не видел, как Neo4j реализует базовый алгоритм ACID, Если вам интересно, вы можете взглянуть на этот доклад:Evolution of Neo4j with ACID transactions, HA cluster, and CRUD transactions.
Запрос к БД, неважно какая это БД, это самая основная функция.Для sql и nosql между простыми запросами большой разницы нет, только какие-то сложные запросы или условия запроса для конкретных сценариев будут специально подбирать какую-то БД. Например, наиболее распространенным является большинство современных веб-приложений, которые в основном включают следующие типы баз данных с точки зрения хранения:
- HDFS: хранит исходные файлы данных (немного неточно называть HDFS базой данных здесь, но я просто хочу выразить структуру хранения данных в общих приложениях, пожалуйста, не вникайте в это)
- MySQL: хранить данные ядра приложения
- Mongo: храните некоторые данные, которые не подходят для хранения реляционной базы данных, такие как изображения, документы и т. д.
- Redis: кешировать горячие данные, такие как пользовательские куки, счетчики в приложении и т. д.
Однако в практических приложениях часто появляются очень сложные операторы запроса, такие как следующие примеры:
-
В приложении APP мы хотим знать, сколько новых пользователей, добавленных вчера, продолжают входить в приложение сегодня. Расширение этого запроса заключается в проведении знакомого когортного анализа роста пользователей приложения. На следующих снимках экрана показан этот анализ. Диаграмма
-
В межличностной сети заданы два узла, запрашиваются кратчайшие пути этих двух узлов, и эти пути удовлетворяют определенным условиям? Это что, письменное слово? Скажем по-другому. В социальных сетях, если вы хотите встретиться с дочерью Трампа Иванкой, запросите кратчайший путь, чтобы добраться до Иванки, и каждый путь на этом пути индивидуален. Поверьте, это вполне возможно, и кем бы вы ни были, познакомиться с Иванкой можно через 6-7 человек, потрясающе. Студенты, которые не верят, могут узнать о теории шести степеней разделения.
Среди вышеперечисленных сложных запросов, особенно второй случай, нецелесообразно реализовывать с традиционными реляционными базами данных. Не только из соображений производительности, но и из соображений удобства использования разработчиками.Представьте, если такой запрос написан в sql, как должен быть написан этот оператор sql? Ниже приведен пример, показывающий сравнение между neo4j и sql для запроса.
2.2 Property Graph Model
Выше мы говорили о хранилище данных Neo4j, грубо разделенном на четыре категории: узлы, отношения, свойства и метки.Это инженерная реализация модуля хранения Neo4j, а теперь модель графа свойств, о которой мы собираемся поговорить, является теоретическим источником реализации данного проекта. Как скажут некоторые друзья, на самом деле просто хранить узлы и отношения, а затем другие метки, атрибуты и т. д. можно считать метаинформацией узлов и отношений для хранения. Это может быть реализовано в технике, но теоретически окажется, что такая эффективность будет очень низкой.
Проще говоря, модель графа свойств на самом деле является базовой моделью данных Neo4j, Эта модель данных способствует реализации модели хранения в четырех аспектах. Что такое модель графа свойств По сути, модель графа свойств состоит из двух основных элементов:
- узел:
- Каждый узел является сущностью в графе
- Каждый узел может содержать достаточное количество атрибутов в виде пар ключ-значение.
- Каждый узел может быть помечен меткой, эквивалентной классификационному стандарту для конкретной области знаний.
- связь:
- Каждое отношение может быть направленным, ненаправленным, именованным
- Каждое отношение должно иметь два соответствующих узла
Ниже приведена демонстрация модели графа свойств:
2.3 Cypher Language
Каждая база данных имеет свой собственный набор языков запросов или стандартов.Даже короли SQL, Sql Server и MySQL имеют различия в некоторых грамматических деталях, не говоря уже о нереляционных базах данных, таких как Mongo и Redis. У Neo4j тоже есть свой язык запросов Cypher. У некоторых друзей голова болит, когда они слышат, что им предстоит изучать новый язык программирования с Neo4j.Вообще-то я могу поделиться здесь собственным опытом.Больно,но пообщавшись с ним,я думаю,обычные люди смогут освоить Cypher всего за день или два, потому что семантика Cypher действительно лаконична и интуитивно понятна.
Для примера сравним запросы в MySQL и Neo4j прямо через код, я думаю, что даже новички в Neo4j без труда разберутся в этих запросах без написания комментариев.
<!-- 1. 全表扫描 -->
<!-- mysql -->
SELECT p.*
FROM products as p;
<!-- neo4j -->
MATCH (p:Product)
RETURN p;
<!-- 2. 查询价格最贵的10个商品，只返回商品名字和单价 -->
<!-- mysql -->
SELECT p.ProductName, p.UnitPrice
FROM products as p
ORDER BY p.UnitPrice DESC
LIMIT 10;
<!-- neo4j -->
MATCH (p:Product)
RETURN p.productName, p.unitPrice
ORDER BY p.unitPrice DESC
LIMIT 10;
<!-- 3. 按照商品名字筛选 -->
<!-- mysql -->
SELECT p.ProductName, p.UnitPrice
FROM products AS p
WHERE p.ProductName = 'Chocolade';
<!-- neo4j -->
MATCH (p:Product)
WHERE p.productName = "Chocolade"
RETURN p.productName, p.unitPrice;
<!-- 其他的写法 -->
MATCH (p:Product {productName:"Chocolade"})
RETURN p.productName, p.unitPrice;
<!-- 4. 按照商品名字筛选2 -->
<!-- mysql -->
SELECT p.ProductName, p.UnitPrice
FROM products as p
WHERE p.ProductName IN ('Chocolade','Chai');
<!-- neo4j -->
MATCH (p:Product)
WHERE p.productName IN ['Chocolade','Chai']
RETURN p.productName, p.unitPrice;
<!-- 5. 模糊查询和数值过滤 -->
<!-- mysql -->
SELECT p.ProductName, p.UnitPrice
FROM products AS p
WHERE p.ProductName LIKE 'C%' AND p.UnitPrice > 100;
<!-- neo4j -->
MATCH (p:Product)
WHERE p.productName STARTS WITH "C" AND p.unitPrice > 100
RETURN p.productName, p.unitPrice;
<!-- 6. 多表联合查询-->
<!-- mysql -->
SELECT DISTINCT c.CompanyName
FROM customers AS c
JOIN orders AS o ON (c.CustomerID = o.CustomerID)
JOIN order_details AS od ON (o.OrderID = od.OrderID)
JOIN products AS p ON (od.ProductID = p.ProductID)
WHERE p.ProductName = 'Chocolade';
<!-- neo4j -->
MATCH (p:Product {productName:"Chocolade"})<-[:PRODUCT]-(:Order)<-[:PURCHASED]-(c:Customer)
RETURN distinct c.companyName;
<!-- 7. -->
<!-- mysql -->
SELECT e.EmployeeID, count(*) AS Count
FROM Employee AS e
JOIN Order AS o ON (o.EmployeeID = e.EmployeeID)
GROUP BY e.EmployeeID
ORDER BY Count DESC LIMIT 10;
<!-- neo4j -->
MATCH (:Order)<-[:SOLD]-(e:Employee)
RETURN e.name, count(*) AS cnt
ORDER BY cnt DESC LIMIT 10
2.4 Ecosystem
Из-за сложности приложений и специализации технологий становится все труднее всесторонне и точно комментировать качество фреймворка, платформы или даже продукта. Однако, по моему собственному опыту, я думаю, что хороший фреймворк должен иметь идеальную окружающую среду. Это также то, что я часто говорю, среди наиболее распространенных фреймворков с открытым исходным кодом, neo4j и spark — это две команды с открытым исходным кодом, которые, я думаю, проделали лучшую работу, и они также являются двумя командами с открытым исходным кодом, в отношении которых я больше всего оптимистичен. Во-первых, многие вещи, которые они делают, рассматриваются с точки зрения пользователя, а не только с инженерной точки зрения, особенно команда spark, и они также создали свои собственные блоки данных платформы для публичного использования. Окружающая среда двух продуктов с открытым исходным кодом очень богата, что отражается в двух аспектах: степени интеграции с популярными фреймворками и богатстве их собственных периферийных инструментов разработки.
Например, на официальном сайте Neo4j есть место, где можно представить свою экосистему. Заинтересованные друзья, пожалуйста, перейдите сюда:Neo4j Ecosystem. Среди множества инструментов разработки меня больше всего поражает браузер Neo4j и neo4j Bloom, выпущенный в первой половине этого года.
neo4j browser
Браузер neo4j чем-то похож на верстак в mysql или RoboMongo в монго, грубо говоря, это клиент базы данных, но браузер neo4j очень дружелюбен и даже выглядит как зрелый продукт. Я помню, когда давным-давно я поделился с командой neo4j, люди в команде, незнакомые с neo4j, спросили меня, что это за продукт, и взаимодействие было очень хорошим. удивительный!
neo4j bloom
Говоря о neo4j Bloom, я все же не могу не похвалить команду neo4j.Хотя bloom не является специальным алгоритмом NB и не имеет каких-либо значительных инноваций, этот продукт фактически рассматривается на уровне пользователя.Дитя улучшило юзабилити , удобство и практичность neo4j на несколько оценок.
Когда дело доходит до расцвета, мы должны сказать, что продукты графа знаний, которые мы собираемся сделать, были запущены.Каждый граф, который мы делаем, имеет два основных момента:
- За картой, которую мы делаем, стоят многие отраслевые эксперты, и нам нужно спроектировать продукт в режиме, который поддерживает этих экспертов для изменения и обновления содержимого карты.
- Содержимое графика будет меняться со временем, и нам также необходимо поддерживать графики во временных рядах, например, графики, которые могут запрашивать определенный временной интервал узла.
Прежде всего, мы провели много исследований и обнаружили, что многие традиционные графические продукты очень сложны и трудны для использования при обновлении и модификации контента.Например, некоторые графические обновления предоставляют лист Excel в фоновом режиме для соответствующих специальностей. Персонал должен заполнить эту форму; для некоторых продуктов существует специально созданный фон управления контентом, и требуется много времени, чтобы научиться использовать этот фон управления. Самое важное заключается в том, что если этот режим используется для предоставления экспертам возможности изменять контент, в первую очередь мы должны позволить экспертам понять изменение мышления в процессе от шаблона Excel или фона управления контентом до сопоставления структуры контента, в противном случае это очень вероятно, что произойдет модификация контента неправильная ситуация.
Поэтому мы всегда хотели сделать продукт, который позволяет определенным учетным записям напрямую изменять график.Например, чтобы открыть разрешение на изменение учетной записи эксперта, эксперт может открыть ту же страницу продукта, что и обычный пользователь, и увидеть тот же продукт. содержимое, только учетная запись эксперта.При нажатии на узел графика вы можете получить разрешение на изменение узла и его отношения, чтобы модификация могла быть выполнена в режиме реального времени, что значительно повышает эффективность работы эксперта, а также экономит много работы по front-end и back-end разработке.
Вскоре после того, как мы составили этот план, я увидел статьи и видео о цветении, выпущенные neo4j, и был действительно поражен. В то время я напрямую пересылал статьи и видео в группу команды WeChat. Цветение, разработанное neo4j и нашим Предусмотренная модель продукта почти такая же.Он прямо хочет завершить то, что мы сделали, и это тоже сделано красиво.Одно лишь упоминание о взаимодействии цветения уже поставило многие отечественные картографические продукты в тупик.
Заинтересованные друзья могут сначала посмотреть этот видео опыт:Neo4j Bloom: Investigating Patterns in Financial Transactions
3. Neo4j and Knowledge Graph
С официальным выпуском поисковой системы на основе графов знаний компанией Google в 2012 году и открытием портала поиска графов знаний на Facebook в 2013 году граф знаний вызвал волну развития, и neo4j, как родная база данных графов, также открыла свою весну. Однако, с точки зрения обмена друзьями по трудоустройству, стартапов и продуктов графа знаний не так много по количеству, а также не хватает продуктов-блокбастеров по качеству, за исключением традиционных социальных сетей (в связи с этим, есть поиск отношений в фейсбуке и сетевой поиск в сети). На самом деле для этого есть две основные причины: во-первых, относительно мало специалистов, знакомых с графовыми базами данных и понимающих графы знаний, а во-вторых, порог для самой бизнес-абстракции относительно высок.
У Ге Ю есть известная фраза в «Мире без воров»: «Что самое дорогое в 21 веке? Таланты». После общения в индустрии мы действительно обнаружили проблему, над которой стоит задуматься, то есть, хотя разработка графов знаний ведется уже шесть или семь лет, на самом деле очень мало талантов, реально изучающих графовые базы данных. Это также база данных NoSQL.Почему вы часто слышите обсуждения технологий баз данных, таких как mongo и redis, но редко видите технические вопросы и ответы по neo4j? Мы думаем, что причина может заключаться в том, что базы данных, такие как mongo и redis, являются более общими технологиями, чем neo4j, то есть mongo и redis можно использовать в большинстве сценариев в различных приложениях, они не зависят от конкретного типа приложения. Neo4j отличается тем, что Neo4j больше ориентирован на хранение и запрос структур данных, связанных с графами, а сам neo4j должен использовать определенный язык запросов (cypher, мы также говорили о нем ранее), некоторым предприятиям и инженерам не хватает мотивации для использования эта новая технология. Таким образом, с этих двух точек зрения признание и популярность neo4j намного меньше, чем у mongo и nosql, таких как redis. Ниже приведена эффективность этих трех ключевых слов, которые я запрашивал в Google Trend с 2008 года, что очевидно.
Тем не менее, если вы посмотрите только на данные о тенденциях в Google для neo4j, они все еще медленно продвигаются к видению людей.
Когда дело доходит до графов знаний, на самом деле в этой области очень мало зрелых продуктов в стране и за рубежом.В дополнение к пулу технических талантов, о котором мы упоминали выше, самая большая проблема заключается в том, что порог абстракции нашего собственного бизнеса слишком высок. . Например, многие начинающие компании в финансовой сфере пытались описать и проанализировать компанию с помощью графов знаний, давайте посмотрим на скриншот следующего случая:
Приведенная выше карта финансовых знаний в мгновение ока кажется довольно полной, но если вы посмотрите на нее с точки зрения финансового профессионального инвестора, обнаружится множество проблем:
- На самом графике отсутствует информация о времени.Если данные на графике обновляются, как отразить это обновление на графике
- Дизайн карты несовершенен.После прочтения текстового содержания верхней и нижней частей этой карты предполагается, что ваш шейный спондилез можно вылечить на много лет, хахаха
- Дизайн карты несовершенен, у некоторых компаний есть только продукты, а дочерних компаний сотни, если они все отображаются на карте одновременно, визуальный эффект может быть неприемлемым.
- Недостаток базы для анализа, когда это похоже на соотношение между акционерным капиталом, данные пропорции не отображаются на карте, и сделать более подробный анализ невозможно.
Есть много других моментов, которые не будут перечисляться по одному, на самом деле я просто хочу сказать, что в области графа знаний, каким бы продуктом вы ни занимались, он должен быть тесно связан с самим бизнесом. вопрос специализации, а не профессионализма.В эпоху , это не просто применить технологию к продукту, и это называется инновацией, а использовать технологии для создания ценных вещей, которые раньше было трудно достичь.
4. Summary
Если бы мне пришлось резюмировать то, что я хотел сказать в этом посте, в нескольких предложениях, это было бы следующее:
- Все имеет причину и следствие, будь то действие или мышление, прежде чем найти основную логику, есть много места для раскопок и исследований;
- Займитесь техническим проектированием архитектуры. Если вы сможете ответить на следующие вопросы, ваша архитектура будет в порядке:
- [1] Как выглядит архитектурный план ваших аналогичных продуктов, и каковы их преимущества и недостатки
- [2] Каковы основные проблемы, которые в основном решает ваш продукт, и основные проблемы, с которыми вы сталкиваетесь?
- [3] По сравнению с аналогичными продуктами, какие преимущества имеет ваш проект технической архитектуры по сравнению с аналогичными продуктами и как он решает проблему, описанную во втором пункте выше.
- База данных графа - это, по сути, закрепление структуры данных графа, поиск решений и задавание вопросов внизу, Фактически, это компьютерное абстрактное выражение неструктурированных ассоциаций в реальном мире.
- Независимо от архитектуры или разработки, всегда верьте, что в этом мире нет лучшей технологии, есть только технология, наиболее подходящая для текущего сценария приложения.
5. Reference
- History of Databases and Graph Database
- What is the graph database?
- Семь мостов Кенигсберга
- keylines
- linkurio
- Graph_database
- 8 Solid Tips for Succeeding with Neo4j
- Graph Databases for Beginners: Native vs. Non-Native Graph Technology
- Neo4j Graph Storage
- An overview of Neo4j Internals
- Evolution of Neo4j with ACID transactions, HA cluster, and CRUD transactions
- How to Run a Cohort Analysis in Google Analytics
- Шесть степеней теории разделения
- Property Graphs Explained
- От SQL к шифру — практическое руководство
- Neo4j Ecosystem
- Neo4j Browser User Interface Guide
- Introducing Neo4j Bloom: Graph Data Visualization for Everyone
- Neo4j Bloom for Visualization - Pre-release Demo of Beer Graph
- Neo4j Bloom: Investigating Patterns in Financial Transactions
- Google Knowledge Graph
- Introducing Graph Search Beta