Everyone always talks about how important data modeling is for Cassandra, and rightfully so. However, do any data modeling principles change when we have DSE search integrated, due to the Solr indices and so on?
PLANNED MAINTENANCE
Hello, DataStax Community!
We want to make you aware of a few operational updates which will be carried out on the site. We are working hard to streamline the login process to integrate with other DataStax resources. As such, you will soon be prompted to update your password. Please note that your username will remain the same.
As we work to improve your user experience, please be aware that login to the DataStax Community will be unavailable for a few hours on:
- Wednesday, July 15 16:00 PDT | 19:00 EDT | 20:00 BRT
- Thursday, July 16 00:00 BST | 01:00 CEST | 04:30 IST | 07:00 CST | 09:00 AEST
For more info, check out the FAQ page. Thank you for being a valued member of our community.
This question was
closed
by
Erick Ramirez for the following reason: The question is answered, right answer was accepted
How is data modeling affected when Cassandra is integrated with Datastax Search?
@Ryan Quey, in short, data modeling becomes flexible with DSE Search indices in the equation/mix. For instance, take a look at this example: Without the search indices, one might have to design a table-per-query approach to satisfy their access patterns and that becomes easier with DSE Search indices in the mix which provides the needed flexibility by having the base table and leveraging the Search index for easily querying the table with non-primary key columns. Further resources for reading are provided below for your reference,
Hope that helps to begin exploring with DSE Search and data modeling!
So would you say we can totally forget about trying to limit our searches to only hit one partition, or is that still a valid rule?
Also, does it mean we don't have to be as careful in picking our primary key?
When doing a read in DSE Search, it happens in a two-pass operation — in the first pass, the shard router determines the minimum number of nodes it can query while still being able to cover the entire token range with at least one node; when it figures out which nodes to query, it then runs queries against the search indexes (not the C* tables) on those nodes and gets back a result set (from each) with ID values and the rank (relevancy score) of each record — in the second pass, it determines which of the records it wants to return as actual results to the client; it then makes CQL queries by ID values for the appropriate records, get these results, and packages them up for the client. We want the shard router to have to talk to as few nodes as possible.
Having partition key part of the query will significantly improve performance and primary key should uniquely identify a row in the table and that doesn't change here with DSE Search index in the mix.
6 People are following this question.
