Database Reference
In-Depth Information
ALLOW FILTERING
The ALLOW FILTERING option ( Listing 4.19 ) enables the server to actively fil-
ter the results server-side. The default behavior of the WHERE clause is to only be
able to reduce fields based on the PRIMARY KEY parts or items specified by the
secondary indexes. With ALLOW FILTERING you can tell the server that it can
manually reduce the results by the WHERE clause as long as at least one component
of the WHERE clause is specified in a secondary index. If ALLOW FILTERING
is used, it can have severe performance implications in situations where a lot of
rows are returned. Due to these performance implications, this option should be
used with extreme caution.
Listing 4.19 Example Usage of SELECT with ALLOW FILTERING
Click here to view code image
SELECT *
FROM events
WHERE url='http://www.google.com'
AND network_location='10.10.10.10'
ALLOW FILTERING;
Example Schemas
To better understand how Cassandra physically stores data, we will provide a few
example schemas. In these examples, we will show sample output, as CQL will
give you. The alternating shaded and nonshaded rows will show you the physical
rows as stored in the Cassandra subsystem. The different styles of text will show
the possible node distribution in a three-node cluster using a partitioner that will
evenly distribute the data.
Static Tables
Static tables in Cassandra are tables whose storage schema closely represents what
is returned to the user when querying the data. These have a limited number of
physical columns and are created by not specifying a compound PRIMARY KEY .
In the basic users table in Listing 4.20 , you can see that each physical row is re-
turned as a logical row in CQL. In addition to that, each row resides on a different
node.
 
Search WWH ::




Custom Search