Database

DB2

Q: When running G2 supplied utilities against DB2 why am I getting segmentation faults?

A: It's likely because you have the wrong library set in the odbcinst.ini file. For example, you might be referencing libdb2o.so when it should be libdb2.so. See Setting up the ODBC environment (Linux and UNIX) in the DB2 Knowledge Center for details.

MemSQL

Q: Does G2 support MemSQL?

A: Currently no it isn't 100% compatible with the G2 requirements. We have tried it but had some issues with prepared statements. We will re-evaluate in the future.  

NoSQL Data Stores

Q: Our standard platform is a NoSQL data store - such as Cassandra. Does G2 support NoSQL stores? 

A: G2 was designed ground-up and optimized for NoSQL row stores. G2 was also architected to make it rather easy to port to new backend datastores. Over the years we explored Redis, HBASE, Cassandra and other exotic backends. REDIS had memory bloating issues. HBASE is designed for heavy write, some read (opposite of G2’s IO activity) – leading to horrible performance.

The problem with Cassandra was eventual consistency. If eventual consistency OFF, everything is OK for G2 functionality, but then Cassandra does not scale/perform. Turn eventual consistency on and suddenly unacceptable errors pile up (data drift some would say). Transactional Entity Resolution, a property of G2, requires the datastore produce trusted answers in T=0. There are all kinds of reasons the future of Entity Resolution will be transactional including no need for periodic re-loading to account for data drift. Another reason is Active Maintenance: Incrementally add, change, delete records while the system is operational.

G2 has no issue being fed from, or posting results to NoSQL datastores (e.g., HDFS, HBASE, Cassandra, MongoDB, Elasticsearch, NEO4j).

The G2 datastore is expected to deliver trusted, real-time, Entity Resolution, supporting heavy OLTP workloads. As such, the datastores currently supported can be found in the System Requirements. More coming …