Exchange Market Blog Series,  Part 2: Designing an Exchange Market with the Help of “My Little Pony”

Exchange Market Blog Series, Part 2: Designing an Exchange Market with the Help of “My Little Pony”

This is the second installment in a blog series examining exchange markets and how they are a good use case for using a graph database.

Civilization has designed exchange markets since the first early humans made stone tools and others recognized their value. In fact, non-monetary exchange markets predate all other markets by such a great deal of time that you might say that we are inherently predisposed towards them. Of course, transacting in exchange markets can be extremely difficult, because value is subjective, and we have a tendency to overvalue what we have. Successfully making a trade often involves tedious work to first find potential participants and then convince them to close the deal.

This challenge is well illustrated in an episode of the animated show, “My Little Pony: Friendship is Magic™,” titled “Trade Ya!” where one of the ponies named Rainbow Dash wants to trade for a rare book held by a book seller. In the Rainbow Falls Traders Exchange, no money is used. Instead, the ponies must trade only for goods or services. Rainbow Dash brings her most valuable possession, her lucky horseshoe, to trade for a first edition copy of the Daring Do book. Unfortunately, the book seller does not find her horseshoe valuable, so the rest of the episode involves Rainbow Dash going from vendor to vendor to enact a series of trades starting with her “valuable” horseshoe and ending with the rare book.

New and Notable Features of IG 3.4

New and Notable Features of IG 3.4

Submitted by nquinn on April 6, 2015 - 10:51am   Introduction InfiniteGraph’s 3.4 release provides many performance enhancements that affect various operations, from adding data to performing navigation queries. Most enhancements are behind the scenes and can be leveraged through existing API methods, but some enhancements are available only through new API. Some notable API enhancements include: A built-in result handler called a PathCollector that can optimize complex navigations by collecting results into an array instead of iterating over the results as they are found A transaction policy called PreloadCacheForHandlesPolicy that optimizes object access when using methods on the Vertex interface These methods can lead to a huge performance boost in certain circumstances, as described below. Path Collector There are two approaches for handling the results of navigational queries. You can iterate over results as they are encountered, or you can collect the results and examine them when the navigation is complete. The iterative approach is preferred when the graph database is a backend engine to a visualization or web application that presents results to the user in real-time. Alternately, in many analytic applications, the entire result set is preferred over iterative results. If you want the entire result set or if you simply want to optimize the navigation as much as possible, you can use a new type of built-in result handler called a PathCollector. An iterating built-in or custom result handler will allow you to utilize the default asynchronous behavior of the navigation engine. This will be useful in two cases: long running navigations in which any results are preferred over the entire set navigation results are...
Building a Recommendation Engine Using a Graph Database

Building a Recommendation Engine Using a Graph Database

Submitted by nquinn on April 6, 2015 - 12:51pm Introduction A very common use case for Graph Databases is to support client applications that provide suggestions for their customers or rate products or services based on user behavior or preference. For the InfiniteGraph 3.4 release, we built a Podcast Recommendation Sample using the features available in IG 3.4 and previous releases. A recommendation engine is typically built using a graph database for three reasons: Recommendations use multiple factors that have complex relationships Recommendations are given in real-time Recommendations utilize multiple levels of relationships For example, recommending purchases might involve looking at purchase event information and the many types of relationships between purchases, including customer preferences, website, store or brand loyalty, and general popularity. It also may be beneficial to look at relationships between customers, including trends within communities, socio-economic groups, etc. This type of relationship analytics is most successful after looking at multiple levels of depth to see how pervasive trends may be. This blog will look at complex relationships and multiple levels of relationship in graph data sets to see how they can be mined to develop an interesting and compelling recommendation algorithm. Design To create a successful recommendation service, care must be taken to determine what types of data are required to create a compelling recommendation engine. For example, if we recommend podcasts based only on popularity, then we would only be offering recommendations along one differentiating factor. All queries would return the same top set of podcast titles based on that one factor. Even two factors of differentiation is uninteresting. Consider using two factors like category...
Everybody Forgets about Path Qualification

Everybody Forgets about Path Qualification

Is a single traversal of your graph database taking an insanely long time or is it crashing your application because it is consuming all of your free memory? It is possible that you have neglected to filter the search space for your navigation using path qualification. This is a review of all of the powerful ways that InfiniteGraph gives you to filter your result set before you even execute a navigation.

How to Distribute Evenly Across Multiple Storage Locations

How to Distribute Evenly Across Multiple Storage Locations

Submitted by nquinn on December 16, 2013 - 12:24pm Introduction When using InfiniteGraph, it is simple to add storage locations using the AddStorageLocation tool which would enable the location to be used for storage when the current main storage location is unavailable (it may no longer be available via the network or the maximum storage capacity may have been reached). At the same time, it can be harder to spread data out evenly during ingest across multiple storage locations because it is a multi-step process. In this blog, the steps to evenly distribute data across storage locations on the same or different hosts are outlined. Placement Configurations In InfiniteGraph, the placement system places data according to a placement model. Without specifying an advanced placement configuration, a default placement model is used. The default placement model places most of the user graph data in one of three groups: Vertex, Edge, and Connector. If a custom placement model is used, these groups can be overridden (see footnote [1]). When setting up the storage locations (local or remote), you can use use the AddStorageLocation tool. When you want to achieve an even distribution of the data, you must also pre-create containers in each of the storage locations for each of the placement groups using the CreateContainers tool. This allows the placement system to “prime” the storage locations and allow the data to spread out according to how many containers were pre-created in each storage location. Image 1: Multiple Storage Locations with Pre-Created Containers Adding storage locations can be done at any time, but pre-creating containers for placement groups need to be done...