Setting Up Storages

Configure Storages

Out of the box, Lightna supports the following storage options: opcache, redis, and database. By default, on a fresh setup, Opcache storage is preconfigured. You can change it by overriding default.storage in your YAML configuration.

Available storages are defined in the storage configuration section, where you can register custom storage implementations.

Storage can be configured at the entity level. To assign a different storage to a specific entity, override: entity.[entity_name].storage.

Opcache

Opcache storage is easy to use when the index size is small and does not risk exhausting memory. However, if you plan to store a large index in Opcache, it will require more fine-tuning and a deeper understanding compared to other storage options.

Key Aspects:

• Best suited for large arrays of rarely changing data, such as global configurations, translations, and category trees.
• It's recommended to monitor memory usage to ensure sufficient allocation across all nodes
  • Keep at least 20% of memory free
  • If using Opcache for dynamic entities (frequently created/removed), keep 50%+ free
• Opcache must be reset after every deployment or index version change. See Setting Up Deployment.
• If deployments are infrequent and the index is dynamic, you may need to reset Opcache periodically, as it won't store new entities once it's full.
• The Opcache storage folder must be shared across all nodes to ensure indexer changes are globally visible.
• Relatively slow loading after invalidation but fastest on subsequent loads, making it less suitable for low-hit-rate data.
• In high-traffic scenarios with a low hit rate, it may cause bottlenecks due to frequent disk reads

Read-only mode

Opcache storage can be used in read-only mode. The use case is to deliver Opcache indices in the same way as a compilation result, which can only be changed during the next deployment.

Configuration:

Lightna uses separate Opcache storage settings instead of the global configuration.

By default:

• validate_timestamps = 1
• revalidate_freq = 15

For all other cases, except Lightna's Opcache storage, the global settings are used.

Both can be adjusted in YAML: storage.opcache.options.ini.

Increasing revalidate_freq does not force Opcache to recompile files every 15 seconds. It only determines how often a check is performed to detect file changes.

When changing the storage configuration, reset Opcache, as it caches the configuration per file along with the opcode.

Redis

Like any key-value storage, Redis is fast and reliable, making it a strong choice for storing the index. Available serializers out of the box: igbinary (default), php, json, none.

Key Aspects:

• Performance does not depend on hit rate but introduces connection overhead.
• Requires the lightna/redis package and the Redis PHP extension.
• Sufficient memory should be allocated with extra capacity to store the index.
• The Redis storage must be shared across all nodes to ensure indexer changes are globally visible.
• The index should not be affected by Redis eviction policies. If you use Redis for caching, you need either:
  • A separate instance for the Lightna index (recommended).
  • To ensure Redis never reaches its memory limit.
  • Custom eviction policy settings.

Database

While not the fastest option, database storage offers a simple and quick setup for index storage without concerns about index size or tuning. It is a good choice for large indexes when Redis or Opcache cannot allocate enough memory. Available serializers out of the box: igbinary (default), json.

However, it is not recommended to use database storage for all indices. Stick to Opcache for globally required data such as configurations, translations, and category trees.

Planned Support:

• MySQL JSON
• MongoDB