Why Connected Data is More Useful

We live in an era where the world is more connected than ever before and the trajectory is such that data relationships will only continue to increase with no signs of slowing down. Connected data is the key to your business succeeding and growing in today’s connected world. Leading enterprises will be the ones that utilize relationship-centric technologies to leverage connections from their internal operations and supply chain to their customer and user interactions. This ability to utilize connected data to understand all the nuanced relationships within their organization will propel them forward as they act on more holistic insights.

Connected Data is Essential

If you want a complete picture of your organization you’ll need a flexible data model with which to unify all existing internal databases and any external data sources with their unique data structures. When your data is connected with contextually relevant relationships and leveraged across an organization, it can lead to new growth opportunities, cost savings through efficiencies, accelerated agreements, and higher levels of customer satisfaction. Here are the main benefits of having connected data in today’s business:

• Increased Visibility
  Connecting clients, resources, projects, and financial data into a single database designed for relationship-centric querying allows internal personnel to gain real-time access to connected data that provides more complete visibility and actionable strategy as personnel build new products, interact with existing 

Read More......

Graph Advantage: Network and IT Operations

Network and IT operations are increasingly complex in their distribution and operation. Data complexity is a function of structure, size and connectedness. It doesn’t take an organization long to reach a point where non-graph databases just don’t keep up with constantly evolving components and topology of the network infrastructure. Network outages and failures are detrimental to any organization so being a step ahead of potential failures is a huge advantage.

Challenges in Network and IT Operations

Enterprises are facing an increasing number of challenges as network complexity continues to increase. Here are a few examples of such challenges:

• Network troubleshooting
  Regardless if it involves network changes, increasing security access or enhancing infrastructure usages, the interdependencies of the network elements involved are highly intricate, which makes it very hard to troubleshoot.
Cause-and-effect analysis
Relationships within different nodes in the network are neither hierarchical nor linear. This makes it challenging to quickly determine dependence of sub-groups of network elements on one another. The more systems being brought together, the more complex these relationships 
Read More......

When Your Data Is Not a Graph

I often get asked at the Neo4jtrainings and meetups about which types of data or use cases a graph database doesn’t handle. While graph data structure models the world we live in exceptionally well there are some use cases and scenarios where your data is not a graph – or more likely not ONLY a graph.

The Neo4j graph database is used for many use cases and influences the situations of current world leaders by representing effectively how these are connected, allow fraud rings and networks to be surfaced through their common connections, enables business analyst to understand the relationships within their data for better business insights, and help users increase their chances of finding pertinent documents within a network.

Any of these connected data examples benefits tremendously from a native graph database like Neo4j. At the same time, there are other scenarios where your data is not a graph.

Not Only a Graph Rather than Not a Graph

Here are a examples to help you think through data and understand if you’re dealing with data that would benefit from being represented as a graph:

• When data entities have no contextual importance via their connections with other data entities
  For instance, if you’re building some kind of calculator, the housing medium for your numbers, equations, and base data won’t likely be taking advantage of powerful contextual relationships.
  Another scenario could if you’re tracking your personal budget each month and simply want to

Read More......

Getting Acquainted with an Unknown Graph

Finding your way around an unknown graph can seem a bit ambiguous at first due to Neo4j being schema-free. Especially if you’re newer to graph databases and used to a relational database where you would simply open the ERD and have a look through the tables. Just because Neo4j is schema-free doesn’t mean that schema-like elements are not present. The Neo4j graph database schema elements are composed of Label Names, Relationship Types, Indexes and Constraints on Property Keys. Let’s look at some techniques for getting aquatinted with an unknown graph.

Initial Unknown Graph Exploration

Here are a few quick tips to help build out the initial mental model of connections within the graph to get you started:

• To observe the graph schema, the easiest area to look into is the browser panel in Neo4j. From there, you’ll be able to observe Label Names, Relationship Types and Property Keys. Each one can be clicked and will immediately load a maximum of 25 associated results. These results can provide a basic starting point to help you navigate your way through the graph.
• To understand the Indexes and Constraints applied to the graph database, which will begin to

Read More......

Graph Advantage: Building a Smarter Data Lake

Organizations today are amassing data at faster rate than ever before into their data lakes and often that data lake is where that data remains. Enterprises are looking for effective ways to utilize the huge volumes and varying data they’ve been collecting in their data lakes in order to respond to competitive pressures, regulations and provide empirical business guidance. It’s time to build a smarter data lake and let your data drive your organization forward.

What is a Data Lake?

For those that may not know, a data lake is a storage medium that houses large volumes of raw data in its native format until it’s needed by the organization. Common implementations today utilize Hadoop, which is effective at storing massive amounts of data. When a business-related question is being brought up, the data lake can be queried for pertinent data, and a smaller dataset can be reviewed to address the question. Most operations require long-running map-reduce jobs where large amounts of data are operated on to make a determination or drive updates.

While data lakes have become a powerful means to addressing challenges of data aggregation and integration as enterprises are increasingly collecting data from all their cloud, mobile and Internet of Things (IoT) data sources. The major downside to this approach is that none of the data lake interaction is real-time by default. Layers must be added on top of the data lake to make this interaction real-time.

There is a transition happening within the enterprise, driven by the desire to get more from their data. The question being asked is, now that we have all this data, how do we utilize it to further our business objectives?

Graph Brings Your Data Lake to Life

The most effective NoSQL technology pairing to help enterprises avoid building
Read More......

systemd Neo4j service on Ubuntu

systemd ships as the default process manager on Ubuntu 15; get the neo4j systemd service file to install and learn about the configuration. systemd has a lot of great features and I encourage you to check it out as it’s a big improvement IMO from SystemV and Upstart. If you’ve started working with systemd to manage your neo4j process, then you

might have stumble through the new setup. Here are a couple things I found helpful and some config that might get you moving along faster. I won’t go into detail on how to install services with systemd but it basically breaks down into these steps:

1.  Save service file:   /lib/systemd/system/neo4j.services 
2.  Reload config:  sudo systemctl daemon-reload 
3.  Enable on startup:  sudo systemctl enable neo4j.service 

Service file for systemd and neo4j

For those simply looking for a working neo4j.service file one is shown below. The rest of the writeup goes into detail how to install this service file and why some of the properties are set the way they are. This configuration assumes you have linked the neo4j script into /etc/init.d/neo4j and that your neo4j installation is at /opt/neo4j e.g. NEO4J_HOME=/opt/neo4j. The file below should be located at:

/lib/systemd/system/neo4j.services

[Unit] Description=Neo4j Management Service

[Service] Type=forking
User=neo4j
ExecStart=/etc/init.d/neo4j start
ExecStop=/etc/init.d/neo4j stop
ExecReload=/etc/init.d/neo4j restart
RemainAfterExit=no
Restart=on-failure
PIDFile=/opt/neo4j/data/neo4j-service.pid
LimitNOFILE=60000
TimeoutSec=600

[Install] WantedBy=multi-user.target

Show more

Backwards compatibility of systemd service for neo4j

From all my readings (and experience) systemd is backwards compatible with SystemV. This means that running services such as service neo4j start should continue to work if you have linked the neo4j process into

Read More......

Relationship Direction in Cypher is Important

The relationship direction between two nodes is required for Cypher write queries, but can be ignored on Cypher read queries. Cypher is a graph database declarative and textual query language by Neo4j, which supported by a larger group as OpenCypher to make Cypher the SQL for graph databases. Cypher looks a bit like ASCII art in it’s representation of graph-related traversal patterns, which makes it quite intuitive and fun to use in querying graphs.

Direction can be specified in Cypher via the use of ‘<' and '> as part of a relationship pattern. Here’s an example:

1	(jack)-[:KNOWS]->(jill)

1	(jack)<-[:KNOWS]-(jill)

Relationship Direction for Writes and Reads

When a relationship is being made in Neo4j 2.3.x utilizing the Cypher query language, it requires that the direction of the relationship to be specified. This means that whenever you’re creating data within a graph via a MERGE or CREATE statement, you must always specify a direction for such relationship because Neo4j always stores a relationship with a direction. It is also beneficial because it ensures a clean and consistent data layout in the graph for your read queries.

Querying data in the graph may seem flexible in that Cypher doesn’t require specifying a direction, but it should only be done through careful consideration to the density of OUTGOING and INCOMING relationships. The important part here is that when you’re not specifying a direction for the relationship you’re matching with the 

Read More......