5. SOQL PARA GRANDES VOLÚMENES DE DATOS
Introducción
Conceptos base.
¿Cómo optimizamos nuestras SOQL’s?
Campos indizados
Umbral selectivo
Conclusiones
Query Optimization – Recursos
Recursos Adicionales * Query Resource Feedback
Parameter – Pilot
6. INTRODUCCIÓN
Construimos un proceso que tratará cualquier
número de registros (más de 50 millones)
Heap Size
Disminuir scope (inviable)
Refactorización
Code statements / Time limit
Refactorización (proceso perfect!)
A pesar de que la cláusula SOQL tenía un ORDER
BY comportamiento extraño en el encadenamiento
entre de batchs.
Quitamos el order by
Refactorización
ORA 1013 – La pesadilla. Ya en Blueray y DVD
Query >2 minutos de procesamiento
7. CONCEPTOS BASE.
Multitenant architecture. Una única solución de software
para todos los “tenants”.
Se mantienen estructuras de BD virtuales y pivot tables
Técnicas de rendimiento tradicionales no hacen efecto.
La tabla subyacente no es apropiada para ser indizada.
Salesforce Query Optimizer (SQO).
Ayudan a determinar el mejor plan de ejecución basado en
los índices de la condición de la query, estadísticas de
ejecución, generan tablas de índices, …
Las dynamic pre-queries determinarán si se utiliza el valor en
“caché” o se consultará a la base de datos directamente.
Ejemplo (*Account_Type custom index):
SELECT * from Account WHERE Account_Type=‘Large’
8. ¿CÓMO OPTIMIZAMOS NUESTRAS SOQL’S?
Utilizando campos que estén indizados
SELECT Id from Account WHERE CreatedDate > 2013-01-01T00:00:00Z
Reduciendo el número de registros que recuperamos
(30% para 1mill + 10% para el resto)
Evitando procesamiento de la BD:
No usando fórmulas
SELECT id, Date1__c FROM Account WHERE IsValidDate__c = true
No consultando valores nulos
SELECT id FROM Account WHERE ShippingAddress__c = null
No usando comodines en los textos %
SELECT id FROM Account WHERE Name LIKE ‘%Acme%’
Solicitando custom indexes (Customer support)
SELECT id FROM Account WHERE Type__c = ‘Vendor’
9. CAMPOS INDIZADOS
Standard Fields indizados en todos los objetos
Id
Name
OwnerId
CreatedDate
SystemModstamp
RecordType
Siempre indizado para los objetos que usen esta propiedad
Master-detail fields
Lookup fields
Otros campos indizados
Unique fields
External ID fields
**Custom indexes
10. UMBRAL SELECTIVO
Condición unaria:
Standard index
<30% sobre el primer millón de registros
<15% del total después del 1er millón
<1millón de registros
Custom index
<10% sobre el primer millón
<5% del total después del 1er millón
<333,333 en total
Compuestas
AND:
<2 veces el umbral de cada filtro
< umbral por intersección de campos
11. UMBRAL SELECTIVO (2)
Compuestas (continuación)
OR:
< El umbral de cada uno de los filtros
< El umbral de la suma de los campos
LIKE:
Para las condiciones que no comiencen con un comodín (%)
Force.com comprueba los primeros 100,000 registros.
12. EJEMPLO DE UMBRAL
Si tenemos 1 millón de casos (con un custom index
en el campo Status) repartidos así:
[SELECT id FROM Case WHERE Status != ‘Closed’] No usa
índice y además está por encima del umbral.
[SELECT id FROM Case WHERE Status IN (‘New’, ‘On Hold’,
‘Pending’, ‘ReOpened’)] Está dentro del umbral
Estado de los casos Número de registros en
BD
New 50,000
Closed 880,000
On Hold 20,000
Pending 30,000
ReOpened 20,000
13. EXCEPCIONES SELECTIVAS
Excepciones en los que las queries son no
selectivas y por lo tanto no usan índices
Condiciones con:
Filtros negativos: !=, NOT LIKE, EXCLUDES
Comparación de textos: text_field [< | > | <= | >=]
Comodines: LIKE ‘%string%’
Referencias a fórmulas no deterministas: Cross-object formula
fields, dependientes del tiempo,…
Campos con valores nulos
14. CONCLUSIONES
No hacer consultas dentro de bucles para reducir el
tiempo y evitar errores de governador
Si podemos, no almacenar los datos en variables,
usar for loops.
Si nuestra query no hace uso de índices o no
cumple el umbral de selectividad, pensar en qué es
más costoso en nuestra query:
ORDER BY
Queries sobre null realizan un “full table scan”.
Filtrar sobre fórmulas (se calculan en tiempo de ejecución) vs
descomponer en un conjunto de filtros
Recuperar la mínima información posible
Limitar una query casi no reduce el coste de ejecutar la query
El uso de IN es tratado como un conjunto de igualdades
15. QUERY OPTIMIZATION – RECURSOS
Query search optimization cheat sheet.
http://s3.amazonaws.com/dfc-wiki/en/images/0/0e/Db-query-search-
optimization-cheat-sheet.pdf
Large data volumes best practices (Winter’12). Muy
interesante: underlaying concepts.
http://www.salesforce.com/us/developer/docs/ldv/salesforce_large_data_
volumes_bp.pdf
Consideraciones sobre los campos nulos y las fórmulas en
las queries.
http://blogs.developerforce.com/engineering/2013/02/force-com-soql-
best-practices-nulls-and-formula-fields.html
Publicaciones de MVP’s (recomiendo el primero)
http://blogs.developerforce.com/engineering/2013/07/maximizing-the-
performance-of-force-com-soql-reports-and-list-views.html
http://blogs.developerforce.com/engineering/2013/09/collecting-
selectivity-statistics-for-force-com-queries.html
http://blogs.developerforce.com/engineering/2013/03/force-com-formula-
fields-indexes-and-performance-gotchas.html
16. RECURSOS ADICIONALES
Herramientas
http://wiki.developerforce.com/page/A_Guide_to_Applic
ation_Performance_Profiling_in_Force.com
“White paper” Guía oficial para los “arquitectos” de
las aplicaciones escrita por Salesforce.
http://wiki.developerforce.com/page/Best_Practices_for
_Deployments_with_Large_Data_Volumes
Query Resource Feedback Parameter – Pilot
https://eu2.salesforce.com/help/pdfs/en/salesforce_spri
ng14_release_notes.pdf - página 284
