Description: Learn how to optimize a Spring Data MongoDB application through indexes and read preferences. This third and final part of the series covers single field, compound, unique, and TTL/partial indexes, as well as ReadPreference strategies.
Ah, I know! Just like in the second article, you're here because you enjoyed the initial topic, right? To recap: In the first article, we covered how to get started with MongoDB and Spring Data, exploring the difference between MongoTemplate and MongoRepository and when to use one or the other. In the second part, we took it a step further by exploring advanced queries and learning powerful concepts that Spring offers. Finally (but not least), we'll look at how to optimize our application through strategies like read preferences and indexes.
Pre-requisites
- Source code
-
MongoDB Atlas account
- Get started with MongoDB Atlas for free! If you don't already have an account, MongoDB offers a free-forever Atlas cluster.
- Java 21+
- Gradle 8.8+
- IDE of your choice
Why focus on MongoDB speed?
Improving performance in MongoDB is crucial for ensuring fast, efficient data access and enhancing user experience. By optimizing strategies, we can reduce latency, increase throughput, and better scale applications as they grow.
Improving performance with indexes
You've probably heard countless times that indexes are essential for achieving high performance in your queries, right? However, it's important to remember that indexes come with certain rules, and even unused indexes can negatively impact your database. In collections with a high frequency of writes compared to reads, maintaining indexes can be challenging, because each write requires updating them.
You might be wondering: "Okay, but how do I know when to create an index or not?" Well, we generally create indexes when our application frequently runs queries on the same field. In our application, let's revisit the TransactionRepository class and take a look at the findByTransactionType(String type) method:
@Repository
public interface TransactionRepository extends MongoRepository<Transaction, String> {
List<Transaction> findByTransactionType(String type);
// Other methods ..
}
This method is responsible for retrieving transactions by type. To understand the cost of this query, we can run the explain() command:
db.transactions.find({"transactionType": "Debit"}).explain()
Or, in our case, we'll run a query directly using Spring. In CustomerService, create the following method:
public String explain() {
MongoCollection<Document> collection = mongoOperations.getCollection("transactions");
Document query = new Document("transactionType", "Debit");
Document explanation = collection.find(query).explain();
logger.info(explanation.toJson());
return explanation.toJson();
}
The explain() command provides the query execution plan, detailing how MongoDB processes the query. In our case, since we don't have an index, it returns a COLLSCAN (collection scan).
Single field index
To optimize this, let's create an index for this query. Traditionally, we create the index as follows:
db.transactions.createIndex({"transactionType": 1})
However, since we are exploring Spring's options, we'll create the index in a different way. To do this, simply navigate to the Transaction class (which represents our collection) and annotate the desired field with the @Indexed annotation:
import lombok.Data;
import org.springframework.data.annotation.Id;
import org.springframework.data.mongodb.core.index.Indexed;
import org.springframework.data.mongodb.core.mapping.Document;
@Document(collection = "transactions")
@Data
public class Transaction {
@Indexed
private String transactionType;
// Other fields
}
For this to work, we need to enable auto-index creation in the application properties by adding the following configuration:
spring:
data:
mongodb:
auto-index-creation: true
Notice: While this is a convenient way to create indexes during development, it's important to exercise caution in production environments. Auto-index creation can cause the application startup to pause while the index is being created, which might lead to delays or availability issues if not handled carefully. For production scenarios, consider creating indexes explicitly during a controlled process outside the application lifecycle.
Compound index
Continuing our exploration of indexes, we now have compound indexes. As the name suggests, these indexes combine more than one field for query purposes. Let's assume we have a query that searches by both the transaction type and currency:
@Repository
public interface TransactionRepository extends MongoRepository<Transaction, String> {
List<Transaction> findByTransactionTypeAndCurrency(String type, String currency);
// Other methods
}
To optimize this query, we could create the compound index as follows:
@CompoundIndex(name = "type_currency", def = "{'transactionType': 1, 'currency': 1}")
@Data
public class Transaction {
// fields
}
Unique indexes
The @Indexed interface includes a unique() method, which is set to false by default. This means that any field annotated with @Indexed will not enforce uniqueness by default. However, we can specify that we want the field to be unique.
Imagine that in our Transaction class, we have a field called authCode, responsible for ensuring that each transaction is unique. We can annotate the class as follows:
public class Transaction {
@Indexed(unique = true)
private String authCode;
}
This annotation ensures that the transactions collection will not have any duplicate authCode values. If a duplicate code is provided, MongoDB will throw the following exception:
com.mongodb.MongoWriteException - E11000 duplicate key error collection
TTL/partial index
Let's suppose that we have a function in our application that executes a query to find all transactions older than 40 days with a status of "COMPLETED" or "SUCCESS" and runs a delete command.
In this case, we would have two steps:
- Filter all transactions in this state.
- Perform a delete operation on these items.
This can be expensive for your application. An alternative is to use the TTL index, which automatically expires documents after a certain amount of time. We can tell our application:
Hey, I want you to delete all records that were created more than 40 days ago and are in the
"SUCCESS"or"COMPLETED"state:
public class Transaction {
@Indexed(
name = "PartialIndex",
expireAfterSeconds = 3456000, // 40 days
partialFilter = "{ 'status': { $in: ['SUCCESS', 'COMPLETED'] } }"
)
private LocalDateTime createdAt;
}
In this way, the application will expire (delete) the transactions that meet this filter.
Optimizing reads with ReadPreference
Using ReadPreference can improve latency and performance by directing reads to secondary replicas that are closer, reducing the load on the primary node and optimizing data distribution in geographically distributed systems.
As shown in the image above, by default, all write operations occur on the primary node, while read operations can be directed to secondary nodes. There are several read preference modes, such as:
Let's go back to our TransactionRepository class and mark the findByTransactionType method to perform the search using the secondaryPreferred mode:
@Repository
public interface TransactionRepository extends MongoRepository<Transaction, String> {
@ReadPreference("secondaryPreferred")
List<Transaction> findByTransactionType(String type);
}
Another alternative is to apply the mode to the entire application through the connection settings. In MongoConfig, you can configure the read preference mode globally. Here's how you can do it:
@Configuration
public class MongoConfig {
@Bean
public MongoClient mongoClient() {
MongoClientSettings settings = MongoClientSettings.builder()
.applyConnectionString(new ConnectionString(connectionString))
.readPreference(ReadPreference.nearest())
.build();
return MongoClients.create(settings);
}
}
Conclusion
In this third and final part of the Spring Data Unlocked series, we learned how to create indexes directly through the application, adjust read preferences with ReadPreference, and optimize the performance of our queries. The complete code for the application is available in the mongodb-developer repository.
For more information on improving query performance with indexes, visit the indexes documentation.
If you have any questions, feel free to reach out to us through the MongoDB Community.
