入门指南：利用Neo4j构建强大应用

需积分: 18 50 浏览量更新于2024-07-21 1 收藏 2.31MB PDF 举报

《开始探索 Neo4j：构建应用的图形数据库指南》是一本旨在为读者介绍图数据库及其在实际应用中的价值的入门书籍。作者克里斯·克莱默(Chris Kemper)以通俗易懂的方式，带领读者从安装 Neo4j 起步，逐步深入到构建包含 Neo4j 的完整应用，涵盖了数据模型、Cypher 查询语言、数据管理、数据导入导出、以及如何利用 Neo4j 的强大功能来创建关系和优化应用程序性能。章节一：图形数据库简介，帮助读者理解图数据模型的基本概念，以及为何在处理复杂关联数据时，相比于传统的关系型数据库，Neo4j 更具优势。章节二：初次接触 Neo4j，介绍了这个开源平台的基础架构，包括其核心组件和设计理念，以及它在社交媒体和电子商务领域的广泛应用案例。章节三：快速上手 Neo4j，讲解了安装和配置步骤，让读者能够搭建起自己的开发环境，并了解如何与 Neo4j 进行基本交互。章节四：Cypher 的探索，Cypher 是 Neo4j 的查询语言，章节中会详细介绍其语法和用法，让读者能够高效地操作和查询图数据。章节五至六：数据管理的关键环节，涉及如何设计和维护数据模型，以及如何通过 Cypher 进行数据导入和导出，确保数据的完整性和一致性。章节七：深入查询技巧，展示如何使用 Cypher 执行复杂的查询，包括路径查找、推荐系统和计算最短路径等场景。章节八：实战应用，通过一个完整的项目，将前面学到的知识结合起来，展示如何构建一个依赖 Neo4j 的实用应用。章节九：部署与扩展，讨论如何将 Neo4j 应用部署到生产环境中，以及可能遇到的挑战和最佳实践。本书不仅提供了理论知识，还辅以实例和最佳实践，使读者能够充分利用 Neo4j 动态的、面向连接的特性，为自己的应用程序增添强大的图形计算能力。无论是初学者还是对图数据库感兴趣的开发者，都能在《Beginning Neo4j》中找到所需的信息，开始在 Neo4j 的世界中创造和扩展应用。

Chapter 1 ■ IntroduCtIon to Graph databases

A database system allows you to interact with the data stored within it via a predetermined language,

dictated by the type of database. The main job of a DBMS is to provide a way for the user to interact with the

data stored in it. These interactions can be categorized into four primary sections:

• Data definition – Any action that modifies the organization of the data within the

database

• Update - When an action manipulates the actual data stored within the databases

is classed as an update, which includes creating, updating, and deleting data. In the

case of inserting or deleting data, this is classed as an update to the database itself as

you’re changing the data structure in some way by either adding or removing data.

• Retrieval - Data is stored in a database in most cases to be reused. When data is

selected from the database to be used in another application, that’s a retrieval.

• Administration – The remaining actions of user management, performance

analysis, security, and all of the higher-level actions are classes as administration.

Database Transactions

Depending on your knowledge of databases the idea of transactions may be a new concept. It’s one of

those things you may know about, but not know the correct words to explain it. A database transaction

is essentially a group of queries that all have to be successful for them to be applied. If one query within

a transaction fails, the whole thing does. Database transactions have two main purposes, both involving

consistency, just in different ways.

The first purpose of a database transaction is to ensure that all queries within a transaction are actually

executed, which can be very important. Say you’re creating a user and inserting a record for it into the

database. There are cases when the ID of an inserted row will be used in queries that follow it. One use is

permissions or roles, where a user’s id would traditionally be used to make the relation. If that initial creation

of the user fails, maybe due to not being unique, the subsequent queries will also fail since they depend on

the result of the failed query. Depending on how the application is set up, if these queries were run without

using the transaction incomplete data may be added to the database (so potentially a set of permissions for

a non-existent user) or for the application to fail unexpectedly. To avoid this, you can run all of the queries

within a transaction, so if any query fails, then any queries that have already run (within the transaction) are

reverted, and the query ends, which means your data is untouched.

The second purpose of a database transaction concerns two actions happening at the same time: if a

database is being queried simultaneously by multiple sources, then there is the potential the data integrity

may be compromised. For example, if you were querying the database, but also performing an update

on some of the data being queried at the same time, what would happen? To make this example more

informative, let’s say we’re querying a list of users by name, but one of the users is online changing their

name. Depending on the timing of the query (without transactions) there’s a chance you could get the data

before or even after the change; there isn’t any guarantee. Using transactions though, the update would

only be committed and then available to query after it and all other queries within said transaction were

successful. So in this case, the updated name wouldn’t be available until all of the needed queries within the

transaction were successful.

Chapter 1 ■ IntroduCtIon to Graph databases

When you talk about a database transaction, it should be atomic, consistent, isolated, and durable, or

ACID. If a database transaction is truly ACID, then it works as it’s been explained here, in an all-or-nothing

fashion. The most important time for a transaction to abide by the ACID principles is when money is

involved. For instance, if you had a system in place to pay bills, which transferred money from one account

to another, and then made a payment, you’d want to ensure all of that happened without any errors. If the

bills account was empty, the money transfer from one account to the other would fail, but if the two actions

were run outside of a single transaction, you would still try to make the payment, even though no money

had been transferred. This is an example of when a query is executed, then subsequent queries depend

on the result of the first one, and in this case, you’d want both queries to be in one, ACID-compliant

transaction.

Principles used within ACID are relative to the CAP Theorem, also known as Brewer’s Theorem. Eric

Brewer (the theorem’s creator) stated that it is impossible for a distributed computer system (or database) to

simultaneously guarantee the following three conditions:

• Consistency (data is available to all nodes at the same time)

• Availability (each request receives a response about whether it was successful or

failed)

• Partition tolerance (the system can still operate despite losing contact with other

nodes due to network issues)

If a system of nodes (or databases) wants to be always available, and safe from failures, then it cannot

always have the most up-to-date data. For example, if you have a system of three nodes, each node would

be a copy of the last, so if one failed, you would have access to the other two. If you were to make a change

to one of the nodes, then the other two nodes would be unaware of the change. To combat this problem,

Eventual Consistency is implied, meaning that through some means, eventually, the change would be

mirrored across all three nodes. In relation to ACID, until a transaction has completed, the contents of

that transaction won’t be available to access within a database. Essentially, CAP, is ACID, but applied to a

distributed system.

Many database vendors rave about their software being fully ACID compliant, so this was just a quick

overview to show what that actually is. Although a lot of different systems support ACID, it’s not something

that just happens. In most cases you’ll need to show you want to start a transaction, which can be different

depending on the query language used, but the concept is the same. Once the transaction has been

initialized, the queries running within it are added. Then when it needs to be committed, this is added to the

query in the way the language requires it. There are cases when you simply don’t need transactions, so just

remember when you want to use a transaction, you’ll probably have to indicate it in the query, unless your

chosen database vendor has different rules.

Although transactions are used with the intention of rolling them back if they fail, this isn’t always the

desired outcome. In some cases, such as in MySQL, you need to explicitly say if you want to rollback a failed

transaction, and this can only be done before the transaction is committed. Each database vendor will have

its own rules when it comes to how transactions are handled, so if you want to use them just be sure to check

the official documentation to ensure you’re using them correctly.

Chapter 1 ■ IntroduCtIon to Graph databases

What is a Graph?

Trying to define what a graph actually is isn’t the easiest of tasks, as it has a variety of meanings depending

on the context. In a traditional sense, graphs are used to display how two or more systems of data relate

to each other. A basic example could be something as simple as, number of pies eaten over a certain time

period, or pies over time. The graph seen in Figure1-1 illustrates that very example, and shows a way of

representing pies over time.

If you were grading this graph it would be very a low one, there aren’t any units on the axis and the

origin hasn’t been marked with a value. Although it’s not the most imperative graph, it does still show

(assuming the units would increase from the graph origin) that as time goes on, more pies are eaten, then

after so long, the rate in which pies are eaten goes down. Graphs of this nature are normally called a bell

curve, or an inverted U, depending on the context, where a graph hits a maximum point, and curves on

either side, causing a bell shape.

The example used here was a graph showing pies over time, but there are of course many, many more

graphs and graph types out there. Graphs can range from the serious (Showing important data, company

growth), to the not so serious (I’m sure we’ve all seen some crude ones) but no matter the subject matter,

the graphs all share one common trend, a relationship. In our example the relationship is pies with time, but

you could equally have something like profits and time in a graph showing company growth. Getting this

relationship is the key part of what makes a graph a graph, and applying that to a mathematics-based graph

or to a graph database is the same concept.

When it comes to the mathematical graphs, you can have the different data systems relating using

various different graph types, such as a line graph, bar chart, or even a pie chart. Some very literal examples

of these can be seen in Figure1-2.

In graph databases, you wouldn’t necessarily see the data shown in any of those formats, although given

that graph nodes are represented by a relationship, they are still graphs. Regardless of the complexity of the

graph, even if it’s just a small, simple one, it can be translated to a graph database, to allow it to be queried

and analyzed.

Figure 1-1. A basic graph showing how pies are eaten over time

Chapter 1 ■ IntroduCtIon to Graph databases

Graph Theory

If you were to simplify graph theory, you could say it was just that, the study of graphs, but there is a lot more

to it than that. Developers have been taking the principles of graph theory and applying them to databases.

Thanks to this hard work there are graph databases, that take relating data very seriously.

In a mathematical sense, graph theory is the study of structures used to model the relationship between

objects. In this context, a graph is made up of nodes (or vertices) and potentially edges connecting them. If

you wanted to demonstrate this visually, it can be done with an arrow to indicate that a node is connected

to another node. For example, if we had two nodes, A and B, to which A was connected to B with an edge, it

could be expressed as A ➤ B. The direction is shown here in that A is connected to B, but B is not connected

to A. If the edges that make up a graph don’t have an associated direction (e.g., A ➤ B is the same as B ➤ A),

then the graph is classed as undirected. If however, the orientation of the edge has some meaning, then the

graph is directed.

There are other applications for graph theory outside the world of mathematics. Since graph theory, at

its lowest level, describes how data relates to each other, it can be applied to a number of different industries

and scenarios where relating data is important. It can be used to map out chemical structures, create road

diagrams, even to analyze data from social networks. The applications for graph theory are pretty wide.

Origins

The first known paper on graph theory was written way back in 1736 called “Seven Bridges of Königsberg” by

Leonhard Euler, a brilliant mathematician and physicist, considered to be the pre-eminent mathematician

of the 18th century. He introduced a lot of the notation and terminology used within modern mathematics,

and published extensively within the fields of fluid dynamics, astronomy, and even music theory. Leonhard

Euler was an incredible man and helped further modern mathematics and other fields to where they

are today. If you have a chance to read up on him. Right now though, we will focus on “Seven Bridges of

Königsberg,” from which graph theory originated.

The city of Königsberg, Prussia (now Kaliningrad, Russia) was built on top of the Pregel River, and

included two large islands that were connected to each other and the mainland by seven bridges. The

problem was to see if it were possible to cross each of Königsberg’s seven bridges just once, and be able to

visit all the parts of the city. You can see an abstracted version of the problem in Figure1-3.

Figure 1-2. A comic from xkcd 688 showing some very literal, self-describing graphs

Chapter 1 ■ IntroduCtIon to Graph databases

After abstracting the problem into a graph, Euler noticed a pattern, based on the number of vertices and

edges. In the Königsberg graph, there are 4 vertices and 7 edges. In the literal sense, Euler noticed that if you

were to walk to one of the islands, and exit to another, you would use an entrance bridge, and an exit bridge.

Essentially, to be able to traverse a path across a graph without crossing an edge more than once, you need

an even number of edges.

Euler theorized that to traverse a graph entirely, by using each edge only once, depends on a node’s

degrees. In the context of a node or vertex, degrees refers to the amount of edges touching the node. Euler

argued that if you were to traverse a graph fully (using an edge only once), you can have either 0, or 2 nodes

of odd degrees. This was later proven by Carl Hierholzer, and traversing a graph in this way is known as an

Eulerian path or Euler walk in Euler’s honor.

Graph Databases

Using graph theory as a basis, graph databases store data in the form of nodes (vertices), edges, and

properties. When creating a node, you would give this node properties, then any edges used could also have

properties. This helps build up a graph of data that is related directly to the data, rather than in rows with

join tables as you would in a relational database.

Visually, you could interpret a graph database as a kind of web. Although you can have a graph database

without any edges, more often than not, it will have them, and lots of them. A good example of a graph

database in the physical world would be a crime diagram from a TV show, or of course in real life if you

happen to have seen one.

With the crime diagram, suspects are related to other suspects, or the victim, and various bits of

evidence are related for various reasons. This could be easily replicated in a graph database format, as it’s

just a big graph. The nodes in this case would be your evidence items and suspects, and they could connect

together for various reasons, which would be logged via properties. Those who know of Breaking Bad, may

remember Figure1-4, but for those that haven’t seen the show, or can’t remember this particular scene, it’s a

crime diagram used in the show, which reminds me, SPOILER ALERT!

Figure 1-3. The 7 bridges of Königsberg, abstracted into a graph format

剩余161页未读，继续阅读

ramissue

粉丝: 354

入门指南：利用Neo4j构建强大应用

Beginning Neo4j(Apress,2016)

neo4j初始数据,演示数据

neo4j-getting-started-4.0.pdf

Manning.Neo4j.in.Action.2014.12.pdf

错误: 找不到或无法加载主类 org.neo4j.server.startup.Neo4jCommand 原因: java.lang.ClassNotFoundException: org.neo4j.server.startup.Neo4jCommand

org.neo4j.cypherdsl

simrank. neo4j

java.lang.ClassNotFoundException: org.neo4j.driver.Session

最新资源