Frequently asked questions about Storage-Attached Indexing (SAI).

Use this FAQ to find answers to common questions and get help with Storage-Attached Indexing (SAI).

What is SAI?
SAI is a new type of secondary index for DataStax Enterprise (DSE) databases that combines:
  • the storage-attached architecture of open source SSTable Attached Secondary Indexes (SASI)
  • a number of highly optimized on-disk index structures inspired by Apache Lucene™
  • the DSE thread-per-core (TPC) infrastructure
What computing challenges does SAI solve?
Oftentimes, developers ask: “How can I query additional fields outside of the Cassandra partition key?” SAI implements efficient indexes based on a table's columns, such as parts of a composite partition key. Before SAI, you could index clustering keys, but you could not index parts of a composite partition. The development of SAI was inspired by SASI to achieve the goal of efficient and simpler filtering via the creation of secondary indexes.
SAI also makes data modeling easier because you do not need to create custom tables just to cater to particular query patterns. You can create a table that is most natural for you, write to just that table, and query it any way you want.
Does SAI replace Solr-based DSE Search?

SAI is not an enterprise search engine. While it does provide some of the same functionality, SAI is not a complete replacement for DSE Search. At its core, SAI is a filtering engine, and simplifies data modeling and client applications that would otherwise rely heavily on maintaining multiple query-specific tables.

How do I use SAI features?
With Storage-Attached Indexing, one difference compared to DSE Search is that queries are entirely CQL-based. The features, by design, are intentionally simple and easy to use.
At a high level, SAI indexes are:
  1. Created and dropped per column via CQL CREATE CUSTOM INDEX ... USING 'StorageAttachedIndex' commands and DROP INDEX commands.
  2. Rebuilt and backed up via nodetool.
  3. Monitored via a combination of nodetool, CQL virtual tables, and JMX.
Can I have a Solr-based DSE Search index and an SAI index on the same database table?
No. You cannot have a DSE Search index and an SAI index defined for the same database table.
During the beta, in your development environment, DataStax recommends that you use SAI indexes on a few tables and observe the results. For existing tables with Solr indexes, in development, consider using DROP SEARCH INDEX to first remove the DSE Search indexes. Then use CREATE CUSTOM INDEX .. USING 'StorageAttachedIndex' to observe the performance of queries, including the additional functionality of using non-partition column in the SAI indexes. See CREATE CUSTOM INDEX.
On which column(s) in a database table can I base my SAI index?
Define each SAI index on any table column other than the table's partition key. For examples, refer to Using SAI indexes.
What are the supported column data types for SAI indexing?
What configuration settings should I use with SAI?
Compared with most indexing environments, SAI configuration and related settings are much simpler. For details, refer to Configuring SAI indexes.
How do I provide feedback and get support during the beta?
Send your feedback, good or bad, through the DataStax Community, via, or both.
What options do I have to monitor the health of indexes that I create with SAI?
Monitor your SAI indexes based on data in virtual tables by enabling TRACING and examining DSE metrics. Refer to Monitoring SAI indexes.