Big segments
Read time: 9 minutes
Last edited: Dec 14, 2024
Segments synced from external tools and larger list-based segments are the two kinds of big segment. Big segments are available to customers on only select plans. To learn more, read about our pricing. To upgrade your plan, contact Sales.
Overview
This topic explains how the big segments feature works in the LaunchDarkly SDKs that support it.
Big segments are segments that are either synced from external tools or list-based segments that can contain an arbitrarily large number of contexts of any one context kind.
You can use big segments with client-side or server-side SDKs.
Client-side SDKs
If you are using client-side SDKs, no additional SDK configuration is required.
However, if you use the Relay Proxy with client-side SDKs, then the Relay Proxy must be configured to use persistent storage. To learn more, read Configuring the Relay Proxy for segments.
Server-side SDKs
If you are using server-side SDKs, big segments require a persistent store within your infrastructure. LaunchDarkly keeps the persistent store up to date and consults it during flag evaluation.
You can use either Redis or DynamoDB as your persistent store when you work with segments. LaunchDarkly keeps the persistent store up to date using either a persistent store integration or the Relay Proxy. You must decide which you want to use. Then you must either configure a persistent store integration, or configure the Relay Proxy. To learn how, read SDK and integration configuration for segments.
Whether you use a persistent store integration or the Relay Proxy, you must also configure your server-side SDK. Server-side SDK configuration for big segments is comprised of two parts:
- The specific database options to get the segment data: These options include which database to use, and any other parameters supported by the SDK to configure that database. These are the same database options you specify when configuring server-side SDKs to use external databases as persistent feature stores, for example, key prefix or DynamoDB table name. However, note that if you are using a feature store for your SDK, you can use either the same or a different persistent store for your segments. To learn more about these database options, read Storing data.
Only the Redis and DynamoDB integrations support big segments. If you use Redis, each Redis host needs enough RAM to load the full set of segments and flag configurations.
- The general options for the SDK's big segments behavior: The table below lists all the general options available. They are all optional and valid for all server-side SDKs and can be used for any supported database integration.
| Config option | Description |
|---|---|
user or context cache size | The maximum number of contexts whose segment status the SDK can cache. The segment status includes all of the segments the context is a part of. A higher value means that the SDK queries the database for recently-referenced contexts' segments statuses less often. If not specified, the default value is 1000. |
user or context cache time | The maximum length of time that the SDK caches the segments status. If you do not specify a value, the default is five seconds. |
status poll interval | The interval at which the SDK polls the persistent store to make sure it is available and to determine how long ago it was updated. If not specified, the default value is five seconds. |
stale after | The maximum length of time between updates of persistent store data before the SDK considers the data out of date. If you do not specify a value, the default is two minutes. |
In all the server-side SDK code examples below, the configuration is set as follows:
- using a Redis server at
your-redis:6379 - with a key prefix of
client-side-id-123abc - cache size: 2000
- cache time: 30 seconds
If you are using a persistent store integration, the value of the key prefix for the persistent store must be the client-side ID of your environment.
Your environment's client-side ID is available in the Environments list for your project. To learn more about key types, read Keys.
This feature is available in the listed versions and later of the following server-side SDKs:
- .NET (server-side): 6.2.0
- Go: 5.5.0
- Java: 5.7.0
- Node.js (server-side): 6.2.0
- Python: 7.3.0
- Ruby: 6.3.0
A context is a generalized way of referring to the people, services, machines, or other resources that encounter feature flags in your product. Contexts replace another data object in LaunchDarkly: "users."
Creating contexts and evaluating flags based on them is supported in the latest major versions of most of our SDKs. For these SDKs, the code samples on this page include the two most recent versions.
.NET (server-side)
Expand .NET (server-side) code sample
Persistent store support for big segments is available in version 6.2.0 and later:
Big segment stores are required if you want to use big segments with a server-side SDK. In the .NET (server-side) SDK, big segment stores are defined with a *BigSegmentStore function, for example Redis.BigSegmentStore(), and with the BigSegments options.
Feature stores are used if you want to cache flag data in an external database, rather than in local memory. In the .NET (server-side) SDK, feature stores are defined with a *DataStore function, and with the DataStore options. To learn more, read Storing data.
To learn more about the available configuration options, read BigSegmentsConfigurationBuilder.
Go
Expand Go code sample
Persistent store support for big segments is available in version 5.5.0 and later:
Big segment stores are required if you want to use big segments with a server-side SDK. In the Go SDK, big segment stores are defined with a *BigSegmentStore function, for example ldredis.BigSegmentStore(), and with the BigSegments options.
Feature stores are used if you want to cache flag data in an external database, rather than in local memory. In the Go SDK, feature stores are defined with a *DataStore function, and with the DataStore options. To learn more, read Storing data.
To learn more about the available configuration options, read BigSegmentsConfigurationBuilder.
Java
Expand Java code sample
Persistent store support for big segments is available in version 5.7.0 and later:
To use either the Redis integration, as shown above, or the DynamoDB integration in the Java SDK, you must also install additional packages. To learn more, read Redis and DynamoDB.
Big segment stores are required if you want to use big segments with a server-side SDK. In the Java SDK, big segment stores are defined with a *bigSegmentStore function, for example Redis.bigSegmentStore(), and with the bigSegments options.
Feature stores are used if you want to cache flag data in an external database, rather than in local memory. In the Java SDK, feature stores are defined with a *dataStore function, and with the dataStore options. To learn more, read Storing data.
To learn more about the available configuration options, read BigSegmentsConfigurationBuilder.
Node.js (server-side)
Expand Node.js (server-side) code sample
Persistent store support for big segments is available in version 6.2.0 and later:
Big segment stores are required if you want to use big segments with a server-side SDK. In the Node.js (server-side) SDK, big segment stores are defined with a *BigSegmentStore function, for example RedisBigSegmentStore, and with the bigSegments options.
Feature stores are used if you want to cache flag data in an external database, rather than in local memory. In the Node.js (server-side) SDK, feature stores are defined with a *FeatureStore function, and with the featureStore options. To learn more, read Storing data.
To learn more about the available configuration options, read LDBigSegmentsOptions.
Python
Expand Python code sample
Persistent store support for big segments is available in version 7.3.0 and later:
To use either the Redis integration, as shown above, or the DynamoDB integration in the Python SDK, you must also install additional packages. To learn more, read Redis and DynamoDB.
Big segment stores are required if you want to use big segments with a server-side SDK. In the Python SDK, big segment stores are defined with a *BigSegmentStore function, for example RedisBigSegmentStore(), and with the bigSegments options.
Feature stores are used if you want to cache flag data in an external database, rather than in local memory. In the Python SDK, feature stores are defined with a feature_store option. To learn more, read Storing data.
To learn more about the available configuration options, read BigSegmentsConfig.
Ruby
Expand Ruby code sample
Persistent store support for big segments is available in version 6.3.0 and later:
To use either the Redis integration, as shown above, or the DynamoDB integration in the Ruby SDK, you must also install additional gems. To learn more, read Redis and DynamoDB.
Big segment stores are required if you want to use big segments with a server-side SDK. In the Ruby SDK, big segment stores are defined with a *new_big_segment_store function, for example Redis.new_big_segment_store(), and with the big_segments options.
Feature stores are used if you want to cache flag data in an external database, rather than in local memory. In the Ruby SDK, feature stores are defined with a *new_feature_store function, and with the feature_store options. To learn more, read Storing data.
To learn more about the available configuration options, read BigSegmentsConfig.