Les om våre oppdateringsplaner heri.

Pålitelige løsninger fungerer effektivt og pålitelig. De er tilgjengelige, fungerer konsistent og skaleres for å støtte voksende virksomheter.

Et pålitelig system er ikke feilsøkt, fungerer som forventet og gir resultater i rett tid. Omvendt er et upålitelig system tregt, oppfører seg ikke som forventet eller mislykkes på kritiske tidspunkter. Upålitelige systemer gir unøyaktig informasjon, slik at interessenter ikke kan Trust dem for forretningsbeslutninger.

Systempåliteligheten er ikke konstant. Et system som er pålitelig i dag, kan bli upålitelig hvis det ikke er utformet for vekst. Et upålitelig system kan kreve kostbart vedlikehold, ombygging eller gjenimplementering, som avleder midler fra strategiske prosjekter.

Forbedre påliteligheten i Salesforce-løsningene ved å fokusere på tre prinsipper: tilgjengelighet, ytelse og skalering. Salesforces skalerbarhetsproduktsett gir innebygde funksjoner som hjelper arkitekter med å operere pålitelige implementeringer.

Tilgjengelighet er en måling av hvor lang tid systemet har vært i drift. Salesforce Platform håndterer de fleste problemer med tilgjengelighet på infrastrukturnivå. Tilgjengeligheten av løsningene som du bygger på plattformen, og som oppleves av kundene, er imidlertid et delt ansvar. Det er viktig å forstå at selv med Salesforces høy tilgjengelighet er risikoen for tjenesteavbrudd aldri null.

Arkitekter må forberede seg på Salesforce-tjenesteavbrudd som planlagt vedlikehold eller uforutsette omstendigheter. I tillegg til tjenesteavbrudd bør du vurdere hvordan du kan opprettholde høy ytelse og vokse med virksomheten. Begrensede arkitektoniske valg kan føre til problemer med langsiktig tilgjengelighet.

Tenk på tilgjengelighet i utformingsfasen, før løsningen bygges. Jo lenger du utsetter arkitekturen for tilgjengelighet, desto høyere blir den faktiske kostnaden for tilgjengelighetsproblemer på lang sikt. Bruk Salesforce Skaleringstest i testmiljøet for å redusere potensielle risikoer. I dette miljøet kan du teste på produksjonsskalaen før du distribuerer kode i produksjonsorganisasjonen.

Arkitekter bruker forretningsspråket til å ramme inn tekniske bekymringer for at forretningsinteressenter skal få innkjøp og prioritere tilgjengelighetsarbeid.For å redusere potensielle risikoer kan du bruke Salesforce Skaleringstest i testmiljøet. I dette miljøet kan du teste på produksjonsskalaen før du distribuerer kode i produksjonsorganisasjonen.

Du kan arkitektere for høyere tilgjengelighet av Salesforce-løsninger gjennom risikobehandling og feilreduksjon.

Behandling av risikoer i Salesforce-arkitekturen innebærer å identifisere potensielle farer for systemets drift, dets brukere, inkludert ansatte, partnere og kunder, og forretningsprosessene. Ofte faller den formelle prosessen med å utføre riskanalyse under ansvaret til prosjektledere. Som arkitekt må du forsikre deg om at risikanalyse tilstrekkelig representerer de tekniske og forretningsinteressenters bekymringer. Det er også ditt ansvar å identifisere de forretningskritiske brukstilfellene som du må skalere test for, basert på produktionstopppunktene.

Noen av de største fellen i risikobehandling kommer fra å ikke bruke nok tid og tanke på det. Teamet hopper ofte over risikovurdering, eller de kombinerer løsning for sikkerhetskopiering og gjenoppretting, en viktig del av å redusere risiko for dataintegritet, med omfattende risikovurdering og -reduksjon.

Bruk disse metodene til å vurdere risiko for Salesforce-løsningene:

• Bruk et rammeverk for risikovurdering. Enkelte store virksomheter kan allerede ha relevante risikomatriser på plass. Hvis du gjør det, bruker du dem til å bestemme hvordan farer skal klassifiseres, hva slags informasjon som skal samles inn, hva du trenger å sette på plass for utbedring og mer. Hvis du ikke allerede har et risikovurderingsrammeverk, finner du et fra en anerkjent kilde og bruker det.
• Vurder virkningsgrad og risikokategorier fra kundenes perspektiv. Proactive Monitoring og Scale Center tilbyr konfigurerbare varsler og kontrollpaneler. De evaluerer kontinuerlig ytelses- og skaleringsrisikoer og reduserer avhengigheten av manuelle sjekklister. Kunde Trust og oppfatning er nøkkelen til enhver virksomhet. Når det gjelder forretningsinnvirkning, er risikoen for problemer som når kunder, vanligvis større enn risikoen for problemer som ikke gjør det. Det er ikke sikkert at kunder tenker på eller oppfatter risiko på samme måte som interne team. Hvis en kunde ikke kan logge seg på kontoen sin, bryr de seg sannsynligvis ikke om rotårsaken til problemet. De bryr seg mest om sin egen umiddelbare opplevelse.
• Prioriter risikoen. Ideelt sett er alle risikoer knyttet til en solid avbøying og responsplan. I virkeligheten vil du ha hull som du må løse over tid. Det er viktig å ta en "lever verdi tidlig og gjenta"-tilnærming. Du og leverings- og vedlikeholdsteamene kan bare ta på deg så mye arbeid på et gitt tidspunkt. I Salesforce er et vanlig uttrykk: "Hvis alt er viktig, er ingenting viktig." Vi bruker V2MOM-er til å prioritere og justere arbeid i hele firmaet, på tvers av team og ned til hver enkelt person. (Du kan lære mer om V2MOMs på Trailhead.) Bruk risikovurderingene dine, som gir deg mulighet til å samarbeide med interessentene om å prioritere og engasjere seg i det viktigste risikobehandlingsarbeidet. Bruk Skaleringstest - Oppretting av testplaner til å identifisere risikoene for å prioritere og redusere disse risikoene ved bruk av skaleringstester.

Bruk Proactive Monitoring til å oppdage risikoer for tidlig tilgjengelighet. Den viser avvik som API-forespørselsgrense, radlåsefeil eller samtidige Apex, og gir handlingsorienterte innsikter før problemer eskaleres til tjenesteavbrudd.

Tilgjengelighetsmønstrene og motmønstrene viser riktig og dårlig risikostyring i en Salesforce-løsning. Bruk mønstrene til å validere utformingene før du bygger, eller til å identifisere refaktoreringsområder i systemet.

Hvis du vil vite mer om Salesforce-verktøy relatert til risikostyring, kan du se Salesforce-verktøy for pålitelighet.

Et feilpunkt er en sårbarhet som gjør et system upålitelig. God feilsøking handler ikke om å finne alle potensielle feilpunkter. I stedet handler det om å raskt klassifisere og prioritere feilpunkter slik at vedlikeholds- og kundestøtteteam kan svare effektivt. Se hendelsessvar.

For å utvikle bedre strategier for feilsøking:

• Klassifisere utløsere for feilpunkter når det gjelder personer, prosesser og teknologi. På samme måte som du kategoriserer risikoer med hensyn til personer, prosesser og teknologi, bruker du samme tenkning på hvordan feilpunkter med høy prioritet utløses. Denne tilnærmingen hjelper deg både å identifisere potensielle feilutløsere og utvikle og organisere svar på dem. Noen ganger kan du avhjelpe tilsynelatende forskjellige feilutløsere med lignende avhjelpende tilnærminger, basert på hvordan utløserne er klassifisert.

• Finn ut hvordan grunnleggende, middels og moden avbøying ser ut. Det tar tid å bygge opp avbøyningsstrategier. Definer nivåene for avverging for å hjelpe deg og teamet med å se hvor du kan sette inn kontroller umiddelbart og hvordan du fokuserer innsatsen over tid. Se alltid etter salgsmuligheter for å bruke automatisering i avbøtende tilnærminger – så tidlig som mulig. For å illustrere hvordan denne tilnærmingen ser ut i praksis viser dette eksemplet en personorientert utløser og hvordan policybasert avbøying ser ut på grunnleggende, middels og modne nivåer.

I tillegg til å bruke arkitektoniske spillboker og kontinuitetsplanlegging, bruker du Proactive Monitoring. Med Proactive Monitoring kan du konfigurere sanntidsvarsler om feilutløsere, som påloggingsfeil, unntak fra CPU-tidsavbrudd eller samtidige API-forespørselsfeil. Denne tilnærmingen til varsling øker feilreduksjonen ved å sikre at både tekniske interessenter og forretningsinteressenter informeres i tide for å redusere virkningen av feil.

Mønstrene og anti-mønstrene for tilgjengelighet viser hvordan riktig og dårlig feilmelding ser ut i en Salesforce-løsning. Bruk dem til å validere utformingene før du bygger, eller til å identifisere steder i systemet som skal gjengis.

Hvis du vil vite mer om Salesforce-verktøy for feilsøking, kan du se Verktøy som er relevante for pålitelighet.

Denne tabellen viser et utvalg av mønstre som du kan se etter eller bygge i organisasjonen, og motmønstre som du kan unngå eller målrette etter rettelse.

✨ Oppdag flere mønstre for tilgjengelighet i Pattern & Anti-Pattern Explorer.

Systemarkitekturs ytelse er en måling av hvor mye et system behandler (gjennomløp) og hvor raskt det svarer (latens). Du forstår vanligvis systemets ytelse gjennom produksjonstesting og -overvåking.

Et system med gode resultater fullfører prosesser i rett tid på alle forventede etterspørselsnivåer.

Dårlig ytelse går hånd i hånd med høyere latens og lavere gjennomstrømning, noe som fører til lavere produktivitet og økt brukerfrustrasjon. Det er viktig å løse ytelsesproblemer fordi de kan føre til tap av kundet Trust og økonomiske tap.

Du kan forbedre ytelsen til løsningene ved å optimalisere gjennomløp og latens.

Notat: Gjennomløps- og latensoptimalisering er viktige aspekter ved forbedring av systembehandling og responsivitet. Det er imidlertid viktig å huske at den generelle systemytelsen også avhenger av hvor godt du arkitekterer for skala. Du må vurdere begge dimensjonene i utformingene.

I Salesforce-arkitekturen er gjennomløp antall samtidige forespørsler som et system kan utføre innenfor et gitt tidsintervall. Kunders Salesforce-løsninger som er utformet og optimalisert for gjennomstrømning, fungerer bedre innenfor de innebygde styringsgrensene for Salesforce Platform.

Optimalisering av gjennomløp i Salesforce starter med nøyaktig beregning av arbeidsbelastninger i systemet og planlegging av vekst. Uten nøyaktige projeksjoner for kravene som vil bli stilt til systemet, kan du ikke finne potensielle problemer med systemets gjennomløpsfunksjoner.

Ta hensyn til disse tre dimensjonene når du tenker på arbeidsbelastninger.

• Antall transaksjoner systemet må behandle i en gitt tidsperiode
• Antall brukere som må få tilgang til systemet samtidig
• Den generelle kompleksiteten av transaksjonslogikk i systemet

Når du tenker på ytelse, fokuserer team noen ganger for lite på beregning og begrensningene for maksimal CPU-tid, som er blant plattformens styringsgrenser. Team med et smalt fokus på CPU-tid overser andre metoder for optimalisering av gjennomløp. Utvidelse av fokuset og bruk av disse metodene forbedrer det generelle gjennomløpet og effektiviteten til Salesforce-arkitekturen. Disse forbedringene vil i sin tur bidra til å redusere latens og øke den generelle systemytelsen. ApexGuru oppdager proaktivt gjennomløpsbegrensende motmønstre som SOQL i sløyfer, DML i sløyfer, ineffektive GGD-kall og dyre metoder. Disse innsiktene hjelper team med å eliminere styringsrisici som begrenser gjennomløp.

For å optimalisere gjennomløp i systemet:

• Favorere asynkron behandling. Salesforce Platform bruker transaksjonskontekster til å kontrollere dataintegritet og begrense kjørende kode. Se transaksjoner i Grunnleggende om arkitektur i Grunnleggende om arkitektur. Derfor kan bruk av asynkron (asynkron) behandling der det er mulig, bidra til å minimere potensielle flaskehalser i synkrone utførelseskontekster. Se databehandling. Bruk av asynkron databehandling er ikke en løsning på alle typer ytelsesproblemer, og du må ta hensyn til latens når du innlemmer asynkrone prosesser. Visse plattformfunksjoner, som Apex som kan legges i kø, kan øke latensen ved trafikkspiker fordi de får meldinger til å vente lenger i en kø. Avhengig av bruksområdet kan du bestemme deg for å tolerere en potensiell reduksjon i responsivitet for å opprettholde eller forbedre gjennomløpet. I andre tilfeller kan du bestemme at økt latens ikke er akseptabel. Med Skaleringstest kan du validere disse avveiningene ved å simulere trafikkspiker i en Fullstendig Sandbox. Der kan du måle hvordan jobbene påvirker gjennomløp og latens.
• Bruk alltid bulkification. På et høyt nivå betyr masseutførelse å utføre operasjoner mot samlinger. Ofte fokuserer team som diskuterer masseutførelse for Salesforce-løsningene sine, på å effektivisere dataoperasjoner mot samlinger. Se Operasjonell logikk. Masseutførelse på systemnivå involverer imidlertid mer enn bare dataoperasjoner. Vurder også bestemte oppgaver, som oppkall eller komplekse beregninger, som kandidater for masseutførelse. Riktig masseutførelse reduserer overskudd. Den utfører flere operasjoner med én forespørsel i stedet for én forespørsel per operasjon. ApexGuru viser anti-bulkification mønstre som DML eller SOQL innsiden sløyfer, som du kan fikse før skalering til produksjon. Se Bulk Operations.
• Bruk SOSL til søk og behandle SOQL som en dataoperasjon. Det kan virke åpenbart at bruk av for komplekse SOQL-setninger vil øke tiden det tar for systemet å hente poster. SOQL legger til overhead til den underliggende relasjonsdatabasen, noe som reduserer behandlingen. Når du bruker tekst- eller jokertegnkriterier, gjør SOSL det bedre. SOSL bruker plattformens søkemotor, som er optimalisert for indeksering med full tekst og universelle søk. For å optimalisere mønstre for posthenting må du forsikre deg om at utformingsstandardene angir når du skal bruke SOSL til å finne data i systemet. Forsikre deg også om at de angir hvordan SOQL skal brukes til effektive dataoperasjoner. Se Operasjonell logikk).
• Bruk Plattformbuffer og ApexGuru. Lightning Platform Cache-laget gir raskere ytelse og bedre pålitelighet ved bufring av Salesforce-økter og organisasjonsdata. Plattformbuffer forbedrer ytelsen ved å fordele bufferplass slik at enkelte programmer eller operasjoner ikke stjeler kapasitet fra andre. ApexGuru oppdager manglende salgsmuligheter for bufring av gjentatte spørringer (for eksempel plattformbuffer for SOQL-resultater), noe som forbedrer gjennomløpet i miljøer i stor skala.

Mønstrene og anti-mønstrene for ytelse viser hvordan riktig og dårlig gjennomstrømning ser ut i en Salesforce-organisasjon. Bruk dem til å validere utforminger før du bygger, eller til å identifisere muligheter for ytterligere optimalisering.

Hvis du vil vite mer om Salesforce-verktøy for gjennomløpsoptimalisering, kan du se Salesforce-verktøy for pålitelighet.

Latens er en måling av hvor raskt et system fullfører en utførelsesbane. Optimalisering av systemets gjennomløp bidrar til å forbedre latensen. En annen dimensjon av latens er oppfattet ytelse, eller hvor responsivt systemet virker for brukerne.

Brukere ønsker ikke å vente på at sider skal lastes inn eller prosesser skal fullføres. Brukere av systemet vil bli frustrerte hvis de ofte opplever lange innlastingstider når de prøver å navigere i listevisninger, postsider, rapporter og så videre. Når dette skjer, kan kunder eller partnere bestemme seg for å ta virksomheten sin andre steder i stedet for å håndtere systemer som gjør det dårlig. Internt kan ansatte opprette midler for å unngå å bruke systemet slik det er utformet, noe som kan føre til nedstrøms problemer for sikkerhet og dataintegritet.

Oppfattet ytelse kan være vanskelig å diagnostisere. Når en bruker rapporterer treg ytelse, kan det hende at kundestøtteteam ikke kan reprodusere problemet. Økt latens er ofte et resultat av en kombinasjon av mindre problemer som bygger på hverandre, noe som kan gjøre det vanskelig å diagnostisere den eksakte årsaken til oppfattede ytelsesproblemer.

Slik reduserer du latens og forbedrer responsiviteten i Salesforce-systemet:

• Optimaliser rapporter. Forsikre deg om at hver rapport har ett bestemt formål. Identifiser tydelig målgruppen og formålet med hver rapport i systemet. I rapporter inkluderer du bare den minste mengden data som målgruppemedlemmer trenger for å ta beslutninger. Fjerning av kolonner som ikke er i samsvar med en rapports formål, vil forbedre rapportytelsen ved å redusere mengden data som må hentes og vises.
• Optimaliser filtre. Effektive filtre øker hastigheten på ytelsen til rapport- og listevisninger ved å nøyaktig omfatte antall rader som hentes fra databasen. Som en generell regel, jo mer spesifikk du gjør filterlogikken, desto mer effektiv blir den underliggende spørringen for data. Måter å optimalisere filtre på inkluderer følgende:
  • Bruk av "er lik" og "er ikke lik" i stedet for "inneholder" og "inneholder ikke"
  • Unngå filtrering etter formelfelt
• Forenkle delingsmodellen. En for kompleks delingsmodell kan redusere hastigheten på en rekke prosesser fordi systemet må kontrollere delings- og synlighetsmodellen for å finne ut om en bruker har tilgang til dataene som skal vises eller behandles. Komplekse beregninger av deling kan øke latensen i rapportering, listevisninger og automatisering som kjører i brukerens kontekst. Se Deling og synlighet.
• Optimaliser tilpassede brukergrensesnittkomponenter. Tilpassede brukergrensesnittkomponenter kan øke latensen. Vurder å gjøre disse tingene for å optimalisere ytelsen i tilpassede brukergrensesnittkomponenter.
  • Bruk Lightning Web Components (LWC). LWC-rammeverket er nært tilpasset moderne nettstandarder. Tilpassede komponenter som skrives i LWC, gjengis mer effektivt i nettlesere og gir utviklere mulighet til å bruke mer effektive JavaScript-metoder. Bruk alltid LWC i stedet for eldre brukergrensesnittteknologier, som Aura eller Visualforce.
  • Bruk Lightning Data Service. Lightning Data Service håndterer opprettelse og vedlikehold av sikker, effektiv og delt bufring på tvers av komponenter. Bruk den til å unngå unødvendige turer til serveren for data – og til å øke den generelle responsiviteten til programmer.
  • Bruk sortering og filtrering på klientsiden for listedata. Utviklere kan bruke standard JavaScript-matriserfunksjonalitet til å sortere, filtrere og velge verdier på klientsiden for både LWC-komponenter (foretrukket) og Aura-komponenter (fortrinnsvis).

Mønstrene og anti-mønstrene viser hvordan riktig og dårlig latens ser ut i en Salesforce-organisasjon. Bruk dem til å validere utforminger før du bygger, eller til å identifisere muligheter for ytterligere optimalisering.

Hvis du vil vite mer om Salesforce-verktøy for latensoptimalisering, kan du se Salesforce-verktøy for pålitelighet.

Denne tabellen viser et utvalg av mønstre som du kan se etter eller bygge i organisasjonen, og motmønstre som du kan unngå eller målrette etter rettelse.

✨ Oppdag flere mønstre for ytelse i Pattern & Anti-Pattern Explorer.

Skalerbarhet er et systems evne til å yte konsistent etter hvert som det utvikler seg og vokser. Et skalerbart system håndterer store økninger i transaksjonsvolumer eller samtidig tilgang uten grunnleggende endringer. Salesforces plattformtjenester er utformet for å støtte programskalering. Se Intern plattformbehandling. Når organisasjonen vokser og etterspørselen etter produkter og tjenester øker, er det ditt ansvar å opprette et system som kan fungere effektivt og som forventet. Arkitektur for skalerbarhet fra start av fører til raskere levering av nye funksjoner og færre tjenesteavbrudd etter hvert som brukertrafikk øker. Tidlig i utformingsfasen, før du distribuerer nye funksjoner til produksjon, bruker du Skaleringstest til å simulere projiserte arbeidsbelastninger og validere at arkitekturen kan skaleres for å støtte dem.

Systemer som ikke er utformet for skalerbarhet, krever konstant og kostbar feilsøking, ny utforming og omstrukturering. Skalerbarhetsproblemer sammensettes over tid, noe som reduserer ytelsen i hele systemet. I noen tilfeller bruker virksomheter mesteparten av utviklings- og vedlikeholdsressursene på å løse problemer med skalerbarhet i stedet for på nye funksjoner som skaper verdi.

Noen ganger når en virksomhet et kritisk punkt. Den opprinnelige utformingen av systemet kan ikke støtte virksomhetens vekst, og uventede hendelser gjør systemet ustabilt. Bruk innsikt fra Scale Center til å identifisere skiftpunkter for skalerbarhet tidlig. Skaleringssenter viser unntakstilfeller, langvarige transaksjoner og flaskehalser i køen som blir verre over tid.

Du kan forbedre arkitekturen for skalering ved å fokusere på datamodelloptimalisering og datavolumbehandling.

Note: Selv om det ikke diskuteres her, er testing av skalerbarhet en viktig del av valideringen av programarkitekturer. Se teststrategi for å få veiledning.

Datamodellering innebærer å strukturere objektene i organisasjonen og relatere dem til hverandre på en måte som gir brukere og automatiserte prosesser mulighet til å hente dataene de trenger så raskt som mulig. Å iverksette tiltak for å forbedre gjennomstrømningen løser mange ytelsesproblemer, men innsatsen din vil ikke være like effektiv uten en optimalisert datamodell.

Den negative innvirkningen av en dårlig utformet datamodell er ikke umiddelbart merkbar. Dens svakheter vises etter hvert som systemet vokser i form av datavolum, prosesser, brukere og integrasjoner. En godt utformet datamodell gjør det enklere å kontinuerlig omgjøre programmet etter hvert som krav legges til og utvides. ApexGuru viser datatilgangsmønstre som ikke-selektiv SOQL, ubrukte felt og skjemaineffektiviteter som direkte påvirker datamodellens skalerbarhet.

For å optimalisere datamodellen:

• Bruk de forhåndsbygde datamodellene fra Salesforce. Salesforce tilbyr forhåndsbygde datamodeller for salg, service og en rekke bransjer. Bruk av datamodellene som leveres av Salesforce, sikrer at funksjonaliteten i systemet bare defineres én gang, og eliminerer overflødighet og isolasjon og etablerer en enkelt sannhetskilde på tvers av hele systemet. Fordi du brukte Salesforce-forhåndsbygde datamodeller for den ene kilden, er det enklere å forstå programdata med analyser og å bruke Salesforces forhåndsbygde kunstige intelligenstjenester. Reduksjon av tilpassingene som du må støtte, reduserer også vedlikeholdskostnader og reduserer teknisk gjeld.
• Velg de riktige datatypene. Forstå de forskjellige felttypene som støttes av Salesforce, og deres begrensninger. Vurder rapporterings- og krypteringskrav slik at du kan unngå å måtte konvertere data mellom typer i fremtiden.
• Velg riktige relasjoner. Salesforce støtter to typer relasjoner mellom objekter: overordnet-detalj og oppslag. Overordnet-detalj-relasjoner har to primære fordeler. Én er innebygde oppsummeringsfunksjoner, som teller og samler detaljer fra underordnede poster. Den andre er en innebygd funksjon for gjennomgripende sletting, der sletting av en overordnet post også sletter dens underordnede poster. Pass imidlertid på at du forstår innvirkningen av deling og dataforskyvning i overordnet-detalj-relasjoner før du bestemmer deg for å bruke dem.
• Denormaliser for skala. Normalisering er prosessen med å strukturere datamodellen for redusert dataoverflødighet og forbedret dataintegritet. Normalisering fører dessverre noen ganger til skaleringsproblemer. Unormaliserte tabeller kan yte bedre i stor skala, men husk å vurdere dataintegritet og overflødighet.

Mønstrene og anti-mønstrene viser hvordan riktig og dårlig datamodelloptimalisering ser ut i en Salesforce-organisasjon. Bruk dem til å validere utforminger før du bygger, eller til å identifisere muligheter for ytterligere optimalisering.

Hvis du vil vite mer om Salesforce-verktøy for datamodelloptimalisering, kan du se Salesforce-verktøy for pålitelighet.

Datavolum er en måling av mengden data som er lagret i systemet, basert på antall og størrelser av poster. Hvis organisasjonen har titusener av brukere, titusener av millioner av poster eller hundrevis av gigabyte totalt postlagringsplass, har du et stort datavolum. Datavolumet og relasjonene mellom objekter i organisasjonen påvirker skalerbarheten og vil sannsynligvis ha større innvirkning på skalerbarheten enn antall poster alene.

For å forbedre skalerbarheten til organisasjoner med store datavolumer:

• Distribuer underordnede poster. Unngå skjev overordnet-underordnet-data ved å sikre at ingen overordnet har et stort antall underordnede poster. Den generelle anbefalingen er at ingen overordnede skal ha mer enn 10 000 underordnede poster. I en distribusjon som for eksempel har mange kontakter, men ikke bruker kontoer, kan du vurdere å konfigurere flere kontoposter og distribuere relaterte kontaktposter blant dem.
• Distribuere eierskap til poster. Unngå eierskapsskjevhet ved å sikre at ingen enkeltbruker eller kø eier, og at ikke alle medlemmene i en enkelt rolle eller felles gruppe eier, mer enn 10 000 poster fra samme objekt. "Parking" av data med en "dummy-bruker" er en fremgangsmåte som ofte fører til eierskapssvik. Hvis du støter på dette problemet, må du være oppmerksom på hvilken innvirkning det vil ha på deling av beregninger. Hvis du ikke kan omdistribuere poster for å lindre eierskapssviken, unngår du å tildele den dataeierbrukeren til en rolle. Hvis organisasjonens delingsmodell krever en rolletildeling, plasserer du den dataeiende brukeren i en distinkt rolle øverst i delingshierarkiet. Ikke tillat hyppige eller ikke-planlagte endringer i denne brukerens rolle, da eventuelle endringer vil ha betydelige innvirkninger på ytelsen på grunn av nye beregninger av deling. Hold denne brukeren unna felles grupper som det kan refereres til i eventuelle delingsregler.
• Reduser mengden postdata i Salesforce. Salesforce er utformet for å gi virksomheter en enkelt oversikt over kundene sine. Det kan virke motintuitivt at begrensning av data i Salesforce er en god fremgangsmåte. Men kraften i enkeltvisningen ligger i hvor godt den gir forretningsbrukere mulighet til å forstå og handle på kundedata. Etter hvert som datavolumet øker, fører data som ikke er oppdaterte eller relevante for daglige prosesser eller analyser, til flere problemer. Disse problemene inkluderer redusert appytelse, økt datasikkerhetsrisiko og negativ innvirkning på søk, rapportering og analyse. For å unngå slike problemer definerer du en datalivssyklus for hvert objekt i datamodellen, med tidslinjer og klassifiseringer for data etter hvert som de blir eldre og mister umiddelbar forretningsverdi. I henhold til datalivssyklusen implementerer du disse prosedyrene for å behandle data over tid.
  • Dataarkivering og sletting – Hvis du vil holde datavolumer så lave som mulig, fjerner du poster som ikke er nødvendige for virksomheten, for å bidra til å holde datavolumer så lave som mulig. Bruk Bulk API 2.0s funksjon for permanent sletting til å slette store datavolumer.
  • Dataaggregering: Opprett tilpassede aggregeringsobjekter som oppsummerer viktige historiske trender eller sammendragsdata i et format som er kompatibelt med rapportering. Fyll ut de tilpassede objektene med batch Apex. Brukere kan deretter utføre rapporter basert på de aggregerte objektpostene.
  • Datasjikting. Vedlikehold store datasett i et annet program hvis de ikke er nødvendige for Salesforce-rapporter eller daglig arbeid. Gjør dataene tilgjengelig i Salesforce etter behov via overlappinger, oppkall eller eksterne objekter.

I praksis er det ikke alltid mulig å umiddelbart løse rotårsaken til et skalerbarhetsproblem når problemer oppstår. Derfor tilbyr Salesforce alternativer for å bidra til å lindre umiddelbare smertepunkter. Det er viktig å vite at aktivering av disse funksjonene i organisasjonen ikke er en levedyktig, langsiktig arkitektonisk strategi for å håndtere store datavolumer. Disse kortsiktige midlertidige løsningene kan bidra til å redusere latens i systemer som lider av dårlig dataarkitektur, men de kan også legge til teknisk gjeld i organisasjonen.

Kortsiktige løsninger på skaleringsproblemer inkluderer følgende:

• Tilpassede indekser Indekser lagres i en spesiell intern tabell som plattformens spørringsoptimalisering bruker til å øke hastigheten på datatilgang. Se Multitenant Indexes). Plattformen indekserer automatisk bestemte typer felt som standard. For å øke hastigheten på spørringer som gjør det dårlig, kan du be om flere tilpassede indekser ved å kontakte Salesforces kundestøtte. Bruk Verktøyet Spørringsplan til å finne ut om tilpassede indekser vil forbedre ytelsen til spørringene.
• Skinny tabeller. Hvis du trenger å optimalisere spørringer ytterligere for vanlige feltsett i objekter med mer enn 1 million poster, kan smale tabeller hjelpe deg. Lavtabeller eliminerer bakgrunnskoblingen som oppstår ved bruk av tilpassede og standardfelt fra samme objekt i en rapport eller automatisering. For at du skal kunne bruke nedtrekkstabeller må Salesforces kundestøtte aktivere dem for organisasjonen.

Mønstrene og anti-mønstrene for skalerbarhet viser hvordan riktig og dårlig datavolumbehandling ser ut i en Salesforce-organisasjon. Bruk dem til å validere utforminger før du bygger, eller til å identifisere muligheter for ytterligere optimalisering.

Hvis du vil vite mer om Salesforce-verktøy for behandling av datavolumer, kan du se Salesforce-verktøy for pålitelighet.

Dette viser et utvalg av mønstre som du kan se etter eller bygge i organisasjonen, og motmønstre som du kan unngå eller målrette etter rettelse.

✨ Oppdag flere mønstre for skalerbarhet i Pattern & Anti-Pattern Explorer.

Hjelp oss å holde Salesforce Well-Architected relevant for deg, ta vår undersøkelse for å gi tilbakemelding om dette innholdet og fortell oss hva du vil se videre.