The xGT server, written in C++ for scalability and performance, is typically run on a large-memory platform. It is a schema-first property graph application that does graph pattern search. Given a small pattern, described in TQL as a collection of vertices and edges along with filtering constraints on property values, the server searches through a large data graph for every matching instance of that small pattern.
xGT can be run in a variety of deployment strategies:
It can run as a standalone graph analytics application for a single user. For a desktop application that is “owned” by one person, it is common to bypass user authentication, and avoid using any of the access control capabilities.
It can run as a multi-user graph analytics tool, where each user brings their own data to be analyzed. Authentication occurs using a common authentication mechanism used throughout the enterprise. This is similar to a Linux server platform that is shared by many users. Security granularity can be on graph element collections or on individual graph elements.
It can run as a multi-user property graph resource where there are one or more data sources that are curated by a site administrator and brought into the xGT server. Data is periodically updated as new data becomes available. Old data may be removed to make room for the new data. This process can be automated by the site administrator. Users (data scientists) would be granted read-access to these curated graphs.
It is possible to run multiple copies of the same graph data as described in the previous bullet. With multiple instances of xGT, each with the same data graph, it is possible to spread out the query work across the instances. One advantage of this elaborate setup is high availability.
This flexibility is made possible by allowing Python scripts on clients to control all activity in the xGT server.