DEVELOPER USER GROUP

Bilbao, 7 de Febrero, 2014

BIENVENIDOS!!!

¿Qué es DUG?

Es nuestra segunda reunión

¿Qué fue lo que más nos gustó?

¿Qué cambiaríamos?

PRESENTACIONES

@agarciaodeian

SOQL PARA GRANDES VOLÚMENES DE DATOS

Jesús González

@bit0211

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

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

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’

¿CÓMO OPTIMIZAMOS NUESTRAS SOQL’S?

Utilizando campos que estén indizadosSELECT 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’

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

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

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.

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

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

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

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

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

SALESFORCE1

Carolina Ruiz

@CarolEnLaNube

GRACIAS!!

NOS VEMOS EN EL PRÓXIMO DUG