Entity Flatstore

Background

This module creates flatstores for entities. Stores here refers to database tables and flat means these stores contain all of the entity's field data without any joins (see comparison to non relational dbs). Drupal stores field data in separate tables (rightfully so); loaded entities must be JOINed together in SQL; the more joins, the worse the performance and the higher the memory use (see performance section). In short: one entity type, one table. This module is aimed at developers - particularly those creating and exposing large data sets (APIs). Note views integration is provided by the Data module dependency.

Comparison to Traditional Caches

Technically, flatstores are caches. However, there are a couple of important distinctions to note. In a typical cache, records are generated / updated on cron or on first load and must be flagged for update using either time based or event based invalidation. This adds logical complexity (and configuration) and the first load will be longer since the cache needs to be built. There are mechanisms to prime caches, but again this adds logical complexity. Also, API's are usually not built from caches.

Unlike traditional caches, flatstores are synced with entity actions. When you create an instance of an entity (a node for example), a flatstore record is created; same for update and delete. When you modify an entity (a content type for example), say adding or removing a field, the flatstore is also modified with those changes. This means that the flatstore will be up to date - no validation or timing logic necessary.

Comparison to Non Relational DBs

Having a flat table (or more exactly a no join structured query) is similar to a non relational database. However, non relational databases require installation and configuration. Since flatstores live in the relational database, it does not require any special configuration - only the regular module installation process.

Limitations

This is largely a developer module; it doesn't provide a lot in terms of functionality. The biggest limitation is that no joins means that relationships (reference fields) will have be handled manually. The ID of the referenced entity is stored in the flatstore, but not the entity itself.

Performance

The larger the dataset the more performant the flatstore is compared to core or regular entity views. On small data sets or single records, performance gains will be negligible.

The below (and attached images) are simple performance metrics of JSON endpoints returning 5,002 devel generated article nodes on a local drupal instance in Acquia Dev Desktop. Response times were captured using Chrome's timeline (these can be recreated using the flat store example module that is bundled with this module). These are only times from one recorded trial, however these times seem to hold up upon multiple trials:

*Quicker times are better*

Dependencies

• Data