{'fraction_non_alphanumeric': 0.024539877300613498, 'fraction_numerical': 0.002788622420524261, 'mean_word_length': 5.229166666666667, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Fast In-Memory SQL Analytics on Graphs

We study a class of graph analytics SQL queries, which we call relationship queries. Relationship queries are a wide superset of fixed-length graph reachability queries and of tree pattern queries. Intuitively, it discovers target entities that are reachable from source entities specified by the query. It usually also finds aggregated scores, which correspond to the target entities and are calculated by applying aggregation functions on measure attributes, which are found on the target entities, the source entities and the paths from the sources to the targets. We present real-world OLAP scenarios, where efficient relationship queries are needed. However, row stores, column stores and graph databases are unacceptably slow in such OLAP scenarios. We briefly comment on the straightforward extension of relationship queries that allows accessing arbitrary schemas. 
The GQ-Fast in-memory analytics engine utilizes a bottom-up fully pipelined query execution model running on a novel data organization that combines salient features of column-based organization, indexing and compression. Furthermore, GQ-Fast compiles its query plans into executable C++ source codes. Besides achieving runtime efficiency, GQ-Fast also reduces main memory requirements because, unlike column databases, GQ-Fast selectively allows more dense forms of compression including heavy-weighted compressions, which do not support random access. 
We used GQ-Fast to accelerate queries for two OLAP dashboards in the biomedical field. It outperforms Postgres by 2-4 orders of magnitude and outperforms MonetDB and Neo4j by 1-3 orders of magnitude when all of them are running on RAM. In addition, it generally saves space due to the appropriate use of compression methods.