This part of the documentation covers the data storage API that is available as TCStore API.

Caching use cases are covered by the Ehcache API. This API covers caching use cases exclusively, and has a JSR-107-compliant interface.

To understand which API matches your particular use case we recommend for you to read "Introduction to Terracotta DB > TCStore API Versus Ehcache: Why Two Different APIs?".

The Ehcache API and the TCStore API can operate on the same Terracotta Server Array instance simultaneously. However, their data sets will be segregated. I.e. you cannot "put" with the Ehcache API and expect to "get" the same entry with the TCStore API.

The base TCStore API does not handle conversion of Java objects into records with typed cells.

In order to store objects, a common practice may be to store them serialized (in a byte[] cell) and supplement that with additional cells on the same record that contain the extracted fields (or any other values) that may be of interest for search and compute.

Really! And this is a very powerful thing!

If you aren’t convinced, spend some time searching the web for articles about "schema-on-write" vs. "schema-on-read". Modern systems that have sophisticated needs and must deal with multiple and/or quickly evolving data sources highly favor schema-on-read semantics - thus most NoSQL offerings take this approach.

Use cases such as those in IoT ("Internet of Things") spaces highly favor schema-on-read (weak or no enforced schema). As an example, different brands/models of sensors may provide data for the same thing (e.g. "humidity") in various different data types and formats yet the flood of data needs to be consumed and stored quickly.

TCStore API’s "loose schema" approach - provides a powerful hybrid of schema-on-write and schema-on-read.

While core TCStore API functionality allows for completely schema-less usage, some use cases may prefer having some enforcement of some schema-like requirements. As such, some higher level constraints could be placed upon Dataset instances to enforce some loose Dataset-wide schemas, even though the underlying store would allow anything.

TCStore API does not include supplemental APIs for such functionality out of the box, however end-users could utilize patterns such as Decorators upon a Dataset to apply enforcement of schema (schema-on-write).

In deciding what functionality TCStore API may come to include with respect to enforcing loose-schemas, the Terracotta team is interested in hearing about your use cases. This is because there are many possible rule sets/semantics for loose-schema enforcement.

For example, possible meaning of a loose-schema definition could be: