Redis may be ubiquitous as a persistent caching tier, but Redis Labs, the company behind it, wants you to think about it as an operational database that is extensible. This is quite true, and it's the way fellow ZDNet contributor Tony Baer opened his deep dive on Redis a few months back.
Besides the technical aspects, which Baer analyzed in detail, Redis Labs is in the spotlight for other reasons, too. Redis Labs were among the first open-source vendors to diversify their license from the "traditional" open-source licenses that the Open Source Initiative officially recognizes as open source.
The move came as an effort to prevent cloud vendors, primarily AWS, from being able to offer managed versions of open-source software other vendors produce as a managed service in their cloud. Besides controversy and confusion, this has also caused some interesting side-effects.
In an unexpected, but reasonable move, Google announced in April 2019 a series of strategic partnerships with seven leading open source-centric vendors in the area of data management and analytics. Redis Labs was among those seven open-source vendors included in Google Cloud's partnership program, and today this becomes a reality.
The partnership offers fully managed services running on Google Cloud, a single user interface to manage apps, and unified billing -- one invoice from Google Cloud that includes the partner's service. What this means is that the services will be fully integrated in Google Cloud, users will pay one bill, and vendors will get a cut of the profits from Google.
"Offering Redis Enterprise Cloud through Google Cloud Marketplace is an exciting milestone towards our shared goal of offering a simplified and streamlined experience for building and running modern high-performance applications," said Rod Hamlin, vice president of Global Alliances and Strategic Partnerships at Redis Labs.
"The combination of Redis Enterprise Cloud and Google Cloud enables developers to do what they do best-build innovative software at scale with the tools they love," he went on to add. Manvinder Singh, director of partnerships at Google Cloud, also welcomed this:
"We're delighted to continue our close collaboration with Redis Labs on open-core, customer-centric innovation. Redis Enterprise on Google Cloud has a number of benefits for customers, including high availability, ease-of-deployment, and now simple and integrated billing via Google Cloud Marketplace."
This presented an opportunity to catch up with Redis Labs, and discuss what their future plans are. Much of the discussion with Kyle Davis, Redis Labs Head of Developer Advocacy, was deeply technical. To avoid duplication, you can read about the underpinnings of the Redis module-based architecture in Baer's piece.
We chose to focus on an up-and-coming aspect of modern data management systems that we have covered extensively: graph capabilities. As Davis explained, everything in Redis is built as a module. In Redis, entire solutions are built as data types, and graph is no exception.
When RedisGraph was announced, in November 2019, we were somewhat skeptical as to its exact nature. We have seen database vendors rushing to announce graph capabilities before, when in fact what they offer is a way to do graph analytics on data stored in their database.
While undoubtedly useful, this hardly makes said vendor offerings "graph databases." A database naturally offers both read and write capabilities, so a graph database should offer a way to do reads and writes using graph structures and a graph query language or API, in order to be considered as such.
As it turns out, although RedisGraph came about as a Redis extension, rather than a native graph database per se, it's not a case of graph-washing. As Davis explained, what Redis has done is to implement the openCypher query language over a specialized data structure. OpenCypher is the graph query language originally developed by Neo4j and subsequently open-sourced. Also worth noting, Redis Labs is participating in the effort to define a new standard for graph query languages called GQL.
Davis said although RedisGraph does not implement the entirety of openCypher, its coverage is currently about 60% and growing, with the aim of reaching 80% soon. As to what this includes? Use cases primarily targeted by Redis users, namely operational ones. Most Redis users do not show much interest for analytical queries, so those parts of openCypher will probably not be implemented in the near future.
The data type that underpins RedisGraph is sparse adjacency matrices. Using this data structure, graph nodes, and edges can be represented by 1s and 0s, and graph-traversal operations can be performed using linear algebra, which makes query processing much more efficient.
The reason why Redis Labs had not done this before is that naively implemented, this approach scales poorly for graphs that model real-world problems, which tend to be very sparse. "In Redis, we think that if something can't be done fast enough, it may be better not to do it at all," as Davis put it.
Davis' previous experience also comes into play, as he explained he used to work with another graph vendor: "Graph queries have always been useful, but a lot of the time they were frustratingly slow. I used to issue a query, then take the dog out for a walk, because I knew it would take a while," he went on to add.
What changed things was coming across GraphBLAS. GraphBLAS, started by Tim Davis in Texas A&M University, is a way of writing graph algorithms using the "language" of linear algebra. There is a GraphBLAS community, and this is also how Redis Labs came to be aware of GraphBLAS, and realized how well it could fit in Redis, as per Davis.
So, how fast is RedisGraph? Super fast, according to Redis Labs. This design allows use cases like social graph operation, fraud detection, and real-time recommendation to be executed 10x to 600x faster than any other graph database, as per the benchmarks performed by Redis Labs. Of course, the usual vendor benchmark caveat applies here too: other vendors have different opinions.
Still, if RedisGraph is as blazing fast as they say, is it being adopted like crazy? Well, not exactly. Again, as Davis put it, it's not like users came to Redis Labs asking to add graph capabilities. It was more like someone starting hacking something away in a hackathon, Redis Labs people taking note, and bringing the person and the capabilities onboard. RedisGraph is today a source-available module of Redis, not an open-source one.
Not having complete graph query language coverage, and not putting a lot of emphasis marketing wise may have something to do with subpar adoption, too. However, there are people using it to build different applications, and this highlights an interesting point in terms of the way the Redis community works.
This scenario is rather common, according to Davis: community members start a side project, someone notices, and it gets adopted and added to the product. Then others may in turn use it, often in unexpected and creative ways. The core product, and the strategic directions, however, largely remain the responsibility of Salvatore Sanfilippo, Redis' creator.
Davis described this as a benevolent dictatorship, although he added that Sanfilippo listens to the community a lot, and his thinking does evolve over time as a result. So although this may not be as much of a single-vendor open source community as others out there, it's still dominated by the vendor, in this case Redis Labs.
Now, with all this open-source community talk, the natural way to wrap up the conversation was to inquire about Redis Labs plans in terms of licensing and strategy. Although we are sympathetic to what Redis Labs said they wanted to achieve with the license they introduced, we cannot help but acknowledge the issues it seems to have caused.
Our question to Howard Ting, Redis Labs CMO, was this: didn't you see this coming? And if you did, how come you did not try to put forward an alliance with other open-source vendors, to enter a conversation with the Open Source Initiative? In our opinion, this could have helped prevent controversy and confusion in the community.
The gist of Ting's answer was that Redis Labs believe the OSI will revise their views about what constitutes an open-source license. All things new are met with some resistance, which is particularly true for long-established institutions.
Add to this the somewhat ideological approach to open source by many people involved, and the different, often conflicting, business models that underlie different licenses, and the reasons for the flat-out rejection of new licensing schemes become clearer to understand.
Ting expressed willingness to engage in conversation, and said they have listened to input and made changes to their approach. He also expressed conviction that the new licenses will eventually come to be accepted. While we have no vested interest in any vendor, we think this is a conversation that needs to be had, and hope to see the open-source community moving forward.
Note: minor edits were made to the article on 10/25/2019 to clarify points on RedisGraph heritage and openCypher implementation.