java - son - programacion android pdf 2018

¿Validación de la fila en el lado del cliente mejor que el índice secundario con la clave primaria completa? (2)

La buena opción aquí sería crear una clave primaria compuesta que consta de nombre de usuario y tipo de usuario con el nombre de usuario como clave de partición y utilizar una clave de clúster. Ni siquiera necesitará un índice y la consulta funcionará.

CREATE TABLE users ( username text, usertype text, .... PRIMARY KEY ((username), usertype) )

En Casandra, es bien sabido que los índices secundarios deben usarse con moderación.

Si tengo una tabla por ejemplo:

User(username, usertype, email, etc..)

Aquí el nombre de usuario es la clave de partición. Ahora quiero apoyar la operación que devuelve un usuario específico (se dará nombre de usuario) si y solo si usertype es un valor específico X.

Hay dos formas en que puedo hacerlo:

Uno: crea un índice secundario en usertype, posibles valores (''A'', ''B'', ''C'') y el nombre de usuario es la clave de partición.

SELECT * FROM user WHERE username=''something'' AND usertype=''A'';

Dos:

Puedo buscar la fila con el nombre de usuario en el cliente y luego verificar si usertype es A.

¿Qué enfoque es mejor? Considere también un escenario de filas anchas (no tan grandes, 10s) donde no todas las filas de una partición pueden tener el valor dado (lo que requiere algún tipo de filtrado del lado del cliente).

Lo que no tengo claro sobre los índices secundarios es cómo se buscan los datos en un nodo particular.

Ej: SELECT * FROM user WHERE username=''something'' AND usertype=''A''

Por ejemplo, usertype hidden CF tiene los datos ''A'' -> ''jhon'', ''miller'', ''chris'', ... etc, 100 nombres de usuario

Y la consulta con la clave de partición se da junto con usertype ¿escanea a través de estos 100 nombres de usuario para que coincida con el nombre de usuario ''algo'' o simplemente recupera por nombre de usuario y ve la columna usertype si coincide con ''A''? ¿Cómo funciona exactamente esa búsqueda? ¿Cómo funciona la consulta dado que el índice está en datos de cardinalidad baja y cada uno está mapeado en muchas filas?

Estoy usando Java como cliente si eso importa.

Actualización: entiendo que puedo usar la clave de clustering (usertype) para este ejemplo en particular, pero quería saber cuál fue el intercambio que pedí. Mis tablas originales son mucho más complejas.

Para este ejemplo, digamos que creo una tabla para hacer un seguimiento de los miembros de la tripulación por barco y por id:

CREATE TABLE crewByShip ( ship text, id int, firstname text, lastname text, gender text, PRIMARY KEY(ship,id));

Y crearé un índice de gender :

CREATE INDEX crewByShipG_idx ON crewByShip(gender);

Después de insertar algunos datos, mi tabla se ve así:

ship | id | firstname | gender | lastname ----------+----+-----------+--------+----------- Serenity | 1 | Hoban | M | Washburne Serenity | 2 | Zoey | F | Washburne Serenity | 3 | Malcolm | M | Reynolds Serenity | 4 | Kaylee | F | Frye Serenity | 5 | Sheppard | M | Book Serenity | 6 | Jayne | M | Cobb Serenity | 7 | Simon | M | Tam Serenity | 8 | River | F | Tam Serenity | 9 | Inara | F | Serra

Ahora voy a activar el seguimiento y consultar una fila distinta con PRIMARY KEY, pero también restringir por nuestro índice de gender .

aploetz@cqlsh:2> tracing on; aploetz@cqlsh:2> SELECT * FROM crewByShip WHERE ship=''Serenity'' AND id=3 AND gender=''M''; ship | id | firstname | gender | lastname ----------+----+-----------+--------+---------- Serenity | 3 | Malcolm | M | Reynolds (1 rows) Tracing session: 34ea1840-e8e1-11e4-9cb7-21b264d4c94d activity | timestamp | source ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------+----------------+ Execute CQL3 query | 2015-04-22 06:17:48.102000 | 192.168.23.129 | Parsing SELECT * FROM crewByShip WHERE ship=''Serenity'' AND id=3 AND gender=''M''; [SharedPool-Worker-1] | 2015-04-22 06:17:48.114000 | 192.168.23.129 | Preparing statement [SharedPool-Worker-1] | 2015-04-22 06:17:48.116000 | 192.168.23.129 | Executing single-partition query on users [SharedPool-Worker-2] | 2015-04-22 06:17:48.118000 | 192.168.23.129 | Acquiring sstable references [SharedPool-Worker-2] | 2015-04-22 06:17:48.118000 | 192.168.23.129 | Merging memtable tombstones [SharedPool-Worker-2] | 2015-04-22 06:17:48.119000 | 192.168.23.129 | Key cache hit for sstable 1 [SharedPool-Worker-2] | 2015-04-22 06:17:48.119000 | 192.168.23.129 | Seeking to partition beginning in data file [SharedPool-Worker-2] | 2015-04-22 06:17:48.120000 | 192.168.23.129 | Skipped 0/1 non-slice-intersecting sstables, included 0 due to tombstones [SharedPool-Worker-2] | 2015-04-22 06:17:48.120000 | 192.168.23.129 | Merging data from memtables and 1 sstables [SharedPool-Worker-2] | 2015-04-22 06:17:48.121000 | 192.168.23.129 | Read 1 live and 0 tombstoned cells [SharedPool-Worker-2] | 2015-04-22 06:17:48.122000 | 192.168.23.129 | Computing ranges to query [SharedPool-Worker-1] | 2015-04-22 06:17:48.122000 | 192.168.23.129 | Candidate index mean cardinalities are CompositesIndexOnRegular{columnDefs=[ColumnDefinition{name=gender, type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR, componentIndex=1, indexName=crewbyshipg_idx, indexType=COMPOSITES}]}:0. Scanning with crewbyship.crewbyshipg_idx. [SharedPool-Worker-1] | 2015-04-22 06:17:48.122000 | 192.168.23.129 | Submitting range requests on 1 ranges with a concurrency of 1 (0.0 rows per range expected) [SharedPool-Worker-1] | 2015-04-22 06:17:48.122000 | 192.168.23.129 | Submitted 1 concurrent range requests covering 1 ranges [SharedPool-Worker-1] | 2015-04-22 06:17:48.122000 | 192.168.23.129 | Executing indexed scan for [Serenity, Serenity] [SharedPool-Worker-2] | 2015-04-22 06:17:48.123000 | 192.168.23.129 | Candidate index mean cardinalities are CompositesIndexOnRegular{columnDefs=[ColumnDefinition{name=gender, type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR, componentIndex=1, indexName=crewbyshipg_idx, indexType=COMPOSITES}]}:0. Scanning with crewbyship.crewbyshipg_idx. [SharedPool-Worker-2] | 2015-04-22 06:17:48.123000 | 192.168.23.129 | Candidate index mean cardinalities are CompositesIndexOnRegular{columnDefs=[ColumnDefinition{name=gender, type=org.apache.cassandra.db.marshal.UTF8Type, kind=REGULAR, componentIndex=1, indexName=crewbyshipg_idx, indexType=COMPOSITES}]}:0. Scanning with crewbyship.crewbyshipg_idx. [SharedPool-Worker-2] | 2015-04-22 06:17:48.123000 | 192.168.23.129 | Executing single-partition query on crewbyship.crewbyshipg_idx [SharedPool-Worker-2] | 2015-04-22 06:17:48.123000 | 192.168.23.129 | Acquiring sstable references [SharedPool-Worker-2] | 2015-04-22 06:17:48.123000 | 192.168.23.129 | Merging memtable tombstones [SharedPool-Worker-2] | 2015-04-22 06:17:48.124000 | 192.168.23.129 | Skipped 0/0 non-slice-intersecting sstables, included 0 due to tombstones [SharedPool-Worker-2] | 2015-04-22 06:17:48.124000 | 192.168.23.129 | Merging data from memtables and 0 sstables [SharedPool-Worker-2] | 2015-04-22 06:17:48.124000 | 192.168.23.129 | Read 1 live and 0 tombstoned cells [SharedPool-Worker-2] | 2015-04-22 06:17:48.127000 | 192.168.23.129 | Executing single-partition query on crewbyship [SharedPool-Worker-2] | 2015-04-22 06:17:48.130000 | 192.168.23.129 | Acquiring sstable references [SharedPool-Worker-2] | 2015-04-22 06:17:48.131000 | 192.168.23.129 | Merging memtable tombstones [SharedPool-Worker-2] | 2015-04-22 06:17:48.131000 | 192.168.23.129 | Skipped 0/0 non-slice-intersecting sstables, included 0 due to tombstones [SharedPool-Worker-2] | 2015-04-22 06:17:48.133000 | 192.168.23.129 | Merging data from memtables and 0 sstables [SharedPool-Worker-2] | 2015-04-22 06:17:48.134000 | 192.168.23.129 | Read 1 live and 0 tombstoned cells [SharedPool-Worker-2] | 2015-04-22 06:17:48.138000 | 192.168.23.129 | Scanned 1 rows and matched 1 [SharedPool-Worker-2] | 2015-04-22 06:17:48.138000 | 192.168.23.129 | Request complete | 2015-04-22 06:17:48.115679 | 192.168.23.129 | | source_elapsed ---------------- 0 3715 4846 5730 5757 5793 5848 5856 7056 7080 7143 7578 7742 7807 7851 10848 10936 11007 11130 11139 11155 11253 11262 11281 11369 11375 11383 11409 11415 11430 11490 13679

Ahora, volveré a ejecutar la misma consulta, pero sin el índice superfluo de gender .

aploetz@cqlsh:2> SELECT * FROM crewByShip WHERE ship=''Serenity'' AND id=3; ship | id | firstname | gender | lastname ----------+----+-----------+--------+---------- Serenity | 3 | Malcolm | M | Reynolds (1 rows) Tracing session: 38d7f440-e8e1-11e4-9cb7-21b264d4c94d activity | timestamp | source | source_elapsed -------------------------------------------------------------------------------------------------+----------------------------+----------------+---------------- Execute CQL3 query | 2015-04-22 06:17:54.692000 | 192.168.23.129 | 0 Parsing SELECT * FROM crewByShip WHERE ship=''Serenity'' AND id=3; [SharedPool-Worker-1] | 2015-04-22 06:17:54.695000 | 192.168.23.129 | 87 Preparing statement [SharedPool-Worker-1] | 2015-04-22 06:17:54.696000 | 192.168.23.129 | 246 Executing single-partition query on users [SharedPool-Worker-3] | 2015-04-22 06:17:54.697000 | 192.168.23.129 | 1185 Acquiring sstable references [SharedPool-Worker-3] | 2015-04-22 06:17:54.698000 | 192.168.23.129 | 1197 Merging memtable tombstones [SharedPool-Worker-3] | 2015-04-22 06:17:54.698000 | 192.168.23.129 | 1215 Key cache hit for sstable 1 [SharedPool-Worker-3] | 2015-04-22 06:17:54.700000 | 192.168.23.129 | 1249 Seeking to partition beginning in data file [SharedPool-Worker-3] | 2015-04-22 06:17:54.700000 | 192.168.23.129 | 1278 Skipped 0/1 non-slice-intersecting sstables, included 0 due to tombstones [SharedPool-Worker-3] | 2015-04-22 06:17:54.701000 | 192.168.23.129 | 3309 Merging data from memtables and 1 sstables [SharedPool-Worker-3] | 2015-04-22 06:17:54.701000 | 192.168.23.129 | 3333 Read 1 live and 0 tombstoned cells [SharedPool-Worker-3] | 2015-04-22 06:17:54.702000 | 192.168.23.129 | 3368 Executing single-partition query on crewbyship [SharedPool-Worker-2] | 2015-04-22 06:17:54.702000 | 192.168.23.129 | 4607 Acquiring sstable references [SharedPool-Worker-2] | 2015-04-22 06:17:54.704000 | 192.168.23.129 | 4633 Merging memtable tombstones [SharedPool-Worker-2] | 2015-04-22 06:17:54.704000 | 192.168.23.129 | 4643 Skipped 0/0 non-slice-intersecting sstables, included 0 due to tombstones [SharedPool-Worker-2] | 2015-04-22 06:17:54.705000 | 192.168.23.129 | 4678 Merging data from memtables and 0 sstables [SharedPool-Worker-2] | 2015-04-22 06:17:54.705000 | 192.168.23.129 | 4683 Read 1 live and 0 tombstoned cells [SharedPool-Worker-2] | 2015-04-22 06:17:54.706000 | 192.168.23.129 | 4697 Request complete | 2015-04-22 06:17:54.697676 | 192.168.23.129 | 5676

Como puede ver, el "source_elapsed" para la consulta con el índice secundario era más del doble de lo que era para la misma consulta (que devolvió la misma fila) sin el índice.

Creo que definitivamente podemos decir que usar un índice secundario en una columna de baja cardinalidad en una tabla de filas amplias no tendrá un buen rendimiento. Ahora bien, aunque no diré que el filtrado del lado del cliente es una buena idea, en este caso , con un pequeño conjunto de resultados, probablemente sea la mejor opción.