Q: When running Senzing 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.
Q: Does Senzing support MemSQL?
A: No, MemSQL isn't 100% compatible with the Senzing requirements. We have tried it but had issues with prepared statements. We are planning to re-evaluate in the future.
NoSQL Data Stores
Q: Our standard platform is a NoSQL data store - such as Cassandra. Does Senzing support NoSQL stores?
A: Senzing was designed ground-up and optimized for NoSQL row stores, it was also designed to make it rather easy to port to new back-end data stores. Over the years we explored Redis, HBASE, Cassandra and other exotic back-ends. REDIS had memory bloating issues. HBASE is designed for heavy write, some read (opposite of the Senzing IO activity) – leading to horrible performance.
The problem with Cassandra was eventual consistency. With eventual consistency off, everything is OK for Senzing 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 Senzing, requires the data store produce trusted answers in T=0. There are many reasons the future of entity resolution will be transactional including no need for periodic re-loading to account for data drift. Another, is active maintenance: Incrementally adding, updating and deleting records while the system is operational.
Senzing has no issue being fed from, or posting results to NoSQL datastores (e.g., HDFS, HBASE, Cassandra, MongoDB, Elasticsearch, NEO4j).
The Senzing data store is expected to deliver trusted, real-time, entity resolution, supporting heavy OLTP workloads. As such, the data stores currently supported can be found in the System Requirements.