Explore our thinking about Graph, Data, & AI

Neo4j, DataStax Graph and Janus property graph schema design decisions for vertex and edge definitions.

Connecting to Microsoft Cosmos DB with Apache TinkerPop Dropwizard.

Deep-learning convolutional generative adversarial neural network crushes web design.

Graphs and graph datasets are rich data structures that can be used uniquely to improve the accuracy and effectiveness of machine learning workflows. Some of the key interactions are graph analytics as features, semi supervised learning, graph based deep learning, and machine learning approaches to hard graph problems.

Utilizing Graph technology will allow you to see beyond individual data points and uncover difficult-to-detect patterns. Join us to learn how to maximize time and resources with Graph technology vs. traditional relational database platforms.

Learn how Graph Technology can help to identify risk and fraud patterns in order to quickly respond. Many new fraud rings use sophisticated measures for credit card and other methods of fraud. Utilizing Graph technology will allow you to see beyond individual data points and uncover difficult-to-detect patterns. Join us to learn how to maximize time and resources with Graph technology vs. traditional relational database platforms.

Dave and Ted discuss Graphday and their thoughts on DSE, Neo4j, Microsoft's CosmosDB, and JanusGraph.

In this blog post, I'll discuss the process of building a micro service that is backed by a graph database and the technologies leveraged to accomplish it. I'll be building this microservice in Java using Maven for its declarative dependency management and build process and Dropwizard for its straightforward architecture and configuration, and then connect everything up to an Apache Tinkerpop enabled Graph Database.

We get asked that question a lot given our early customer work with Titan evaluations, participation in the JanusGraph project and usage of Apache TinkerPop while concurrently being a premier DataStax Graph partner.

DataStax released 5.1, Neo4j released 3.2, Microsoft announces CosmosDB; there’s a lot of stuff happening in the graph database world. Looks like a prime time for some Gremlin training.

Companies across a variety of industries are trying to attain a holistic view of their customers. From creating a more personalized experience, to creating more timely and relevant support, to simply marketing to them more efficiently and effectively, there are tremendous gains to be had with a 360-degree view.

Do you remember the first time you saw a commercial about “the Cloud?” That was one of the pivotal moments for technology buzzwords going mainstream. It’s been a nonstop thrill ride since then: Web 2.0. Internet of Things. Big Data. Machine Learning. Like “the Cloud,” the term “machine learning” is thrown around a lot, but it’s not entirely clear who it is useful to. People who follow it are aware that machine learning techniques were used by Google to create an unstoppable Go playing machine, and that it allows computers to drive with abilities getting closer to human drivers by the day.

Congratulations! Your data is up and running in a graph database and you have big plans for this technology. But now the system is overtaxed and not performing properly. Don't worry- the database may not be the culprit. Proper user experience and visualization techniques can greatly improve performance and dynamic data interaction.

Webinar presentation on how to combine Graph databases with an iterative, user-driven approach and the latest UI tools to enable your team to start creating valuable user experiences with graph data.

This year at the Data Day 2017 conference in Austin,TX, keynote speaker Emil Eifrem declared 2017 the Year of Graph. Graph data storage certainly is becoming more mainstream, with a myriad of both commercial and open-source options currently available and maturing at an accelerated pace. But so what? Why should user experience practitioners, or anyone else that is not a database administrator, care about this trend in data storage technology?

A supernode is a vertex with a large number of edges. In graph theory, these high-degree vertices are known as hubs.

OrientDB is one of several popular graph data stores on the market today. It provides a multi-model approach with the powerful nature of a graph database and the flexibility of a document data store. If you have decided to build out your multi-tenant application on top of OrientDB, you are in luck as it has several built-in, out-of-the-box methods for handling multi-tenancy.

How do you handle customer #2? You delivered an MVP of some hosted software for customer #1. Your brother-in-law knows a guy who has a similar problem and after a lunch meeting, now you need to add customer #2 to your incubating SaaS tool. Of course customer #1 and customer #2 shouldn’t be able to see each other’s data, but you don’t necessarily want to install and configure everything all over again just because you added another customer.

Neo4j is the most popular graph data store available today. It leverages graph technologies to help build modern high-performing applications, but it does not have any native multi-tenant support. However, you may have decided to build out your multi-tenant application and that Neo4j is the right graph data store to fit your needs. In any multi-tenant system, the trick (from a data-store side) really comes down to how to isolate one tenant’s data (physically or logically) from another tenant’s.

So you’re going to build a multi-tenant application and now it’s up to you to figure out how to make it all work. Ask any software engineer who has built one and they will tell you that multi-tenant applications are inherently more complicated than single-tenant applications. That complexity comes from the added overhead required to ensure that your tenants’ data are secured and isolated from one another (e.g., Tenant 1 can’t see Tenant 2’s customer list) and that large tenants don’t adversely affect other tenants in the same environment (e.g., Tenant 1 does not use all the resources, thereby slowing the performance for Tenant 2). The overhead caused by these requirements may take the form of either operational or developmental complexity, but the key to building an effective system in any multi-tenant scenario is to reduce that complexity.

DataStax Enterprise 5.0 contains much more than a version bump of its component pieces. In particular, DSE 5.0 includes the new graph database, DSE Graph. DSE Graph is an Apache TinkerPop enabled distributed property graph database that uses Apache Cassandra for storage, DSE Search for full text and geospatial search, and DSE Analytics for analytical graph processing.

Josh Perryman visited the Northwest in July 2016 for DataDay Seattle and gave an updated version of my Graph Database Shootout.

How can you retool your SQL talent to deploy on your graph project? According to Google Trends, interest in graph databases is increasing while SQL interest is level or even decreasing – but SQL searches are still 43 times more prevalent than graph.

Graph databases are a new paradigm for many folks. Hear Apache TinkerPop committer Ted Wilmes introduce graph topics and map them to their well-known SQL cousins.

The Austin Data Geeks & Austin Graphs Meet-ups invited Josh Perryman to do an encore presentation of our GraphDay presentation: Graph Database Engine Shoot-out.

A case study at Graph Day recounting a client study we did to see whether their database could be reorganized to offer improved query performance. We looked at graph databases (OrientDB, Titan, Neo4J) because they thought of their data as graph data, and relational (Postgresql) because that’s what their database already implemented.

‍We are in an era of unprecedented innovation in databases. Data-intensive companies are grappling with whether the many new options — NoSQL, Key-Value, Document, Column Family, Column-Oriented — are appropriate for them. The commercial success of Facebook and LinkedIn makes graph databases a hot area of investigation. Unlike many new databases, they are not a variation on or a simplification of relational databases. Instead they require new ways of thinking and modeling data. In return they can answer truly novel questions.

We are in an era of unprecedented innovation in databases. Data-intensive companies are grappling with whether the many new options — NoSQL, Key-Value, Document, Column Family, Column-Oriented — are appropriate for them. The commercial success of Facebook and LinkedIn makes graph databases a hot area of investigation. Unlike many new databases, they are not a variation on or a simplification of relational databases. Instead they require new ways of thinking and modeling data. In return they can answer truly novel questions.

We are meeting more people who are interested in looking into the world of graph databases. Palladium has executed proofs–of–concept for clients to help them explore this world. In this post we summarize what sorts of questions we feel like a proof of concept project can answer, and how we typically tackle them. For our presentation at Graph Day, we’ll be walking through one in particular, but really there are a variety of answers you may want.

In this post we summarize what sorts of questions we feel like a proof of concept project around graph databases can answer, and how we typically tackle them.

Everyone gets delusions of grandeur!” That’s what Han Solo said after being frozen in carbonite. I’ve been solving data problems for customers the last year and a half and am now getting back in graph DBMSs. We took a nice look at Titan last week, can’t wait to play with that some more. I’m going to give a bit of the same to Neo4j. All of this as prep for my talk at GraphDay 2016 in Austin, TX.

As part of the work we’re doing to refresh our graph database evaluation for a couple of clients (and our upcoming talk at Graph Day!) we took Titan 1.0out for a spin last week. We’ll be doing more in-depth explorations on some in-house and public datasets over the next few weeks, but here’s some preliminary impressions based on a contrast with the Titan we came to know a year ago or so.

Our client’s legacy system held graph-like data in a relational database, but new customers’ data sizes were crippling performance and scale. As part of an overall architectural rejuvenation, we evaluated migrating their data to graph and relational schemas to determine if query performance and scalability could be improved. With representative data in hand, we designed alternate relational schemas, graph database designs, and triple store designs, benchmarking performance and noting subjective measures such as ease of use and fluency of the query language. Vendors included PostgreSQL, Neo4J, Titan, and AllegroGraph. Follow-up studies included other vendors. The results surprised us, leading to a hybrid relational and graph recommendation. We have implemented the first milestone over the last year. Follow-up work shows that graph DB vendors have come a long way even in that time. This methodology and information in this case study should be useful to teams choosing a database engine, whether graph or relational, for their next project.Our client’s legacy system held graph-like data in a relational database, but new customers’ data sizes were crippling performance and scale. As part of an overall architectural rejuvenation, we evaluated migrating their data to graph and relational schemas to determine if query performance and scalability could be improved. With representative data in hand, we designed alternate relational schemas, graph database designs, and triple store designs, benchmarking performance and noting subjective measures such as ease of use and fluency of the query language. Vendors included PostgreSQL, Neo4J, Titan, and AllegroGraph. Follow-up studies included other vendors. The results surprised us, leading to a hybrid relational and graph recommendation. We have implemented the first milestone over the last year. Follow-up work shows that graph DB vendors have come a long way even in that time. This methodology and information in this case study should be useful to teams choosing a database engine, whether graph or relational, for their next project.

What do my users want to do with Big Data? How do they want to visualize it, interact with it and manage it? How big is my data, really? How much data can a human deal with at one time, and how much data should we process at one time? How can the UX accommodate data sources that respond at different rates?

Turning from the open-source Titan to the commercial AllegroGraph was like stepping out of my 1998 4Runner and taking a spin my boss’s BMW. It was fast. It was sleek. It had all of the modern thingamajiggies that come with new, well-engineered solutions built by companies with the resources to do it well.

In this third post we look at how the application’s graph data fit into another property graph database: Titan.

In this second post we look at how the application’s graph data fit into a leading graph database: Neo4j. Quite well actually.

We talk about data, and how several data concepts such as “Big Data” and “NoSQL” are currently in the vogue. But just as all politics is local, all data is ultimately specific to its own subject domain. Data is not all the same, and so we shouldn’t expect that the general data tools will be the best tools when working with any particular set of data. Choose the right tools with the best fit for your data and you’ll spend more time in analysis and realizing the value of your data, and less time working around the restrictions of your tools.

This post explores Actimize Complement

This post explores Deploying Machine Learning Systems

This post explores Entitlements

This post explores Graph For IoT

This post explores Graph For Supply Chain

This post explores how humans and machine learning can interact with one another.

This post explores Keeping Humans in the Machine Learning Loop

This post explores Linear Regression in Machine Learning

This post explores ML Ops

This post explores Machine Learning CI/CD Pipelining

This post explores Machine Learning For Oil & Gas (Part 1)

This post explores Machine Learning For Oil & Gas (Part 2)

This post explores Machine Learning For Supply Chain

This post explores Machine Learning For Structured Finance.

This post explores Machine Learning for Supply Chain & Logistics

This post explores Model Interpretability

This post explores SAP | APO Lightning Talk

This post explores Supernodes

This post explores transportation, auto, and infrastructure.

This post explores UX Design for Data Products

This post explores What is a Data Product?

How has the storage reservoir of CO2 changed over time?

Bringing Visibility to a Complex Data Lake

Can you predict and plan for the flu? Expero built a data product including a long term forecast for modeling the spread of influenza-like illness across the United States using a cutting edge deep learning model.

Expero designed a distributed high-performance computer and rendering system, enabling terabyte data to be interactively processed at 10 frames per second on existing compute clusters with users in a remote web browser-based reactive user experience.

Tasktop legacy client-server platform had a steep learning curve for deploying integrations. In addition to moving to the web, Tasktop wanted to enable a broader, less skilled user audience to configure and deploy integrations. Expero created a novel user experience for the new web-based platform that has far exceeded Tasktop’s user adoption goals!

Use machine learning to forecast crop growth.