Læs om vores opdateringsplaner heri.

Pålidelige løsninger fungerer effektivt og pålideligt. De er tilgængelige, klarer sig ensartet og skaleres til at understøtte voksende forretninger.

Et pålideligt system er ikke fejlvenligt, fungerer som forventet og giver rettidige resultater. Omvendt er et upålideligt system langsomt, fungerer ikke som forventet eller mislykkes på kritiske tidspunkter. Pålidelige systemer giver unøjagtige oplysninger, så interessenterne ikke kan Trust dem til forretningsbeslutninger.

Systemets pålidelighed er ikke konstant. Et system, der er pålideligt i dag, kan blive upålideligt, hvis det ikke er designet til vækst. Et upålideligt system kan kræve dyr vedligeholdelse, omstrukturering eller genimplementering, hvilket omdirigerer midler fra strategiske projekter.

Forøg pålideligheden i dine Salesforce-løsninger ved at fokusere på tre principper: tilgængelighed, ydeevne og skalerbarhed. Salesforces skalerbare produktserie leverer indbyggede funktioner til at hjælpe arkitekter med at implementere pålidelige implementeringer.

Tilgængelighed er et mål for den procentdel af tid, som dit system er operativt. Salesforce Platform håndterer de fleste tilgængelighedsproblemer på infrastrukturniveau. Men tilgængeligheden af de løsninger, som du opbygger på platformen, og som dine kunder oplever, er et fælles ansvar. Det er vigtigt at forstå, at selv med Salesforces høj tilgængelighed er risikoen for serviceafbrydelse aldrig nul.

Architekter skal forberede sig på Salesforce-serviceafbrydelser som planlagt vedligeholdelse eller uventede omstændigheder. Udover serviceafbrydelser kan du overveje, hvordan du vedligeholder høj ydeevne og vokser med forretningen. Smalle arkitektoniske valg kan føre til problemer med langsigtet tilgængelighed.

Tænk over tilgængelighed under designfasen, før din løsning er bygget. Jo længere du udsætter arkitektur for tilgængelighed, jo højere vil de faktiske omkostninger ved tilgængelighedsproblemer være på lang sigt. Brug Salesforce Skaleringstest i dit testmiljø for at reducere potentielle risici. I dette miljø kan du teste på produktionsskalaen, før du implementerer kode i produktion.

Arkitekter bruger forretningens sprog til at skitsere tekniske bekymringer for forretningsinteresserede for at få buy-in og prioritere tilgængelighedsarbejde. Hvis du vil reducere potentielle risici, skal du bruge Salesforce Skaleringstest i dit testmiljø. I dette miljø kan du teste på produktionsskalaen, før du implementerer kode i produktion.

Du kan opbygge tilgængelighed af dine Salesforce-løsninger gennem risikostyring og fejlreduktion.

Administration af risici i konteksten af Salesforce-arkitekturen involverer identificering af potentielle farer for dit systems drift, dets brugere, herunder medarbejdere, partnere og kunder) og dine forretningsprocesser. Ofte falder den formelle proces med at udføre risikanalyser under ansvaret for projektledere. Som arkitekt skal du sørge for, at risikanalyser tilstrækkeligt repræsenterer de tekniske og forretningsinteressenters bekymringer. Det er også dit ansvar at identificere de forretningskritiske anvendelsessituationer, som du skal skalere-test for baseret på dine produktionshøjdepunkter.

Nogle af de største fejl i risikostyring kommer fra ikke at bruge nok tid og tænke over det. Teams springer ofte over risikovurderingen, eller de kombinerer løsninger til sikkerhedskopiering og gendannelse, som er en vigtig del af at reducere risici for dataintegriteten, med omfattende risikovurdering og -reduktion.

Hvis du vil vurdere risiko for dine Salesforce-løsninger, skal du bruge disse metoder:

• Brug en risikovurderingsramme. Nogle store virksomheder kan allerede have relevante risikomatrikser på plads. Hvis din gør, kan du bruge dem til at bestemme, hvordan du klassificerer farer, hvilke typer oplysninger der skal indsamles, hvad du skal implementere til afhjælpning mm. Hvis du ikke allerede har en risikovurderingsstruktur, skal du finde en fra en pålidelig kilde og bruge den.
• Vurder påvirkningens alvorsgrad og risikokategorier fra dine kunders perspektiv. Proactive Monitoring og skaleringscenter giver konfigurerbare advarsler og dashboards. De evaluerer løbende risici for ydeevne og skalerbarhed og reducerer din afhængighed af manuelle tjeklister. Kunde Trust og opfattelse er nøglen til enhver virksomhed. Risici for problemer, der når kunderne, opvejer normalt risici for problemer, der ikke gør. Kunder tænker muligvis ikke over eller opfatter risici på samme måde som interne teams. Hvis en kunde ikke kan logge ind på sin konto, er de sandsynligvis ligeglade med årsagen til problemet. De bekymrer sig mest om deres egen øjeblikkelige oplevelse.
• Prioriter dine risici. Ideelt er hver risiko linket til en solid reduktions- og responsplan. I virkeligheden vil du have mangler, som du skal håndtere over tid. Indføring af en "lever værdi tidligt og gentag"-tilgang er vigtig. Du og dine leverings- og vedligeholdelsesteams kan kun udføre så meget arbejde på et givet tidspunkt. I Salesforce er et almindeligt udtryk "Hvis alt er vigtigt, er intet vigtigt". Vi bruger V2MOM'er til at prioritere og justere arbejde i hele firmaet, på tværs af teams og ned til hver enkelt person. (Du kan lære mere om V2MOMs på Trailhead.) Brug dine risikovurderinger, som giver dig mulighed for at samarbejde med dine interessenter om prioritering og forpligtelse til det vigtigste risikostyringsarbejde. Brug Skaleringstest - Oprettelse af testplan til at identificere risici for at prioritere og reducere disse risici ved hjælp af skaleringstest.

Brug Proactive Monitoring til at registrere risici for tidlig tilgængelighed. Den viser afvigelser som API-anmodningsbegrænsningspik, rækkespærrefejl eller samtidige Apex, hvilket giver indsigter, der kan handles på, før problemer eskaleres til serviceafbrydelser.

Tilgængelighedens mønstre og anti-mønstre viser korrekt og dårlig risikostyring i en Salesforce-løsning. Brug mønstrene til at validere dine designs, før du opbygger, eller til at identificere omstruktureringsområder i dit system.

Hvis du vil vide mere om Salesforce-værktøjer, der er relateret til risikostyring, kan du se Salesforce-værktøjer til pålidelighed.

Et fejlpunkt er en sårbarhed, der gør et system upålideligt. En god fejlbegrænsning handler ikke om at finde hvert potentielt fejlpunkt. I stedet handler det om hurtigt at klassificere og prioritere fejlopunkter, så vedligeholdelses- og supportteams kan reagere effektivt. Se Hændelsessvar.

Hvis du vil udvikle bedre fejlbegrænsningsstrategier:

• Klassificer udløsere for fejlpunkter i forhold til personer, proces og teknologi. Ligesom du kategoriserer risici i forhold til personer, proces og teknologi, skal du anvende den samme tankegang på, hvordan fejlpunkter med høj prioritet udløses. Denne tilgang hjælper dig med at identificere potentielle fejludløsere og udvikle og organisere reaktioner på dem. Nogle gange kan du reducere tilsyneladende forskellige fejludløsere med lignende reduktionstilgange, baseret på hvordan udløserne er klassificeret.

• Identificer, hvordan basis, mellemliggende og moden reduktion ser ud. Det vil tage tid at udvikle reduktionsstrategier. Definer niveauerne af reduktion for at hjælpe dig og dit team med at se, hvor du kan implementere kontroller med det samme, og hvordan du fokuserer dine bestræbelser over tid. Se altid efter muligheder for at bruge automatisering i dine reduktionstilgange – så tidligt som muligt. For at illustrere, hvordan denne tilgang ser ud i praksis, viser dette eksempel en personorienteret udløser, og hvordan politikbaseret reducering ser ud på basisniveau, mellemniveau og moden niveau.

Udover at bruge arkitektoniske pluklister og kontinuitetsplanlægning, skal du bruge Proactive Monitoring. Med Proactive Monitoring kan du opsætte advarsler i realtid om fejludløsere, f.eks. loginfejl, CPU-timeouts eller samtidige API-anmodningsfejl. Denne tilgang til advarsel øger fejlreduktion ved at sikre, at både tekniske og forretningsinteressenter informeres rettidigt for at reducere påvirkningen af fejl.

Mønstrene og anti-mønstrene for tilgængelighed viser, hvordan korrekt og dårlig fejlreduktion ser ud i en Salesforce-løsning. Brug dem til at validere dine designs, før du opbygger, eller til at identificere steder i dit system til refactor.

Hvis du vil vide mere om Salesforce-værktøjer til fejlreduktion, kan du se Værktøjer, der er relevante for pålidelighed.

Denne tabel viser et udvalg af mønstre, der skal søges efter eller opbygges i din organisation, og anti-mønstre, der skal undgås eller målrettes for rettelse.

✨ Oplev flere mønstre for tilgængelighed i Pattern & Anti-Pattern Explorer.

Systemarkitektydeevne er et mål for, hvor meget et system behandler (gennemstrømning), og hvor hurtigt det svarer (forsinkelse). Du forstår typisk dit systems ydeevne gennem produktionstest og overvågning.

Et effektivt system fuldfører processer rettidigt på hvert forventet efterspørgselsniveau.

Dårlig ydeevne går hånd i hånd med højere forsinkelse og lavere gennemsnit, hvilket fører til lavere produktivitet og øget brugerfrustration. Løsning af ydeevneproblemer er presserende, da de kan føre til tab af kundernes Trust og økonomiske tab.

Du kan forbedre ydeevnen af dine løsninger ved at optimere gennemsnit og forsinkelse.

Bemærk: Optimering af gennemsnit og forsinkelse er vigtige aspekter af forbedring af systembehandling og responsivitet. Det er dog vigtigt at huske på, at den samlede ydeevne af systemet også afhænger af, hvor godt du er arkitekt for skalaen. Du skal overveje begge dimensioner i dine designs.

I konteksten af Salesforce-arkitekturen er gennemsnit det antal samtidige anmodninger, som et system kan fuldføre inden for et givent tidsinterval. Kundernes Salesforce-løsninger, der er designet og optimeret til gennemsnit, fungerer bedre inden for de indbyggede styringsbegrænsninger i Salesforce Platform.

Optimering af gennemsnit i Salesforce begynder med nøjagtigt at beregne arbejdsbelastninger i dit system og planlægge deres vækst. Uden nøjagtige projiceringer for de krav, der vil blive stillet på systemet, kan du ikke finde potentielle problemer med dit systems kapaciteter.

Når du tænker på arbejdsbelastninger, skal du overveje disse tre dimensioner.

• Antallet af transaktioner, som dit system skal behandle i et givet tidsrum
• Antallet af brugere, der skal have adgang til dit system samtidigt
• Den overordnede kompleksitet af transaktionslogik i systemet

Når du tænker på ydeevne, fokuserer teams nogle gange for meget på beregning og begrænsningerne på maksimal CPU-tid, som er blandt platformens styringsbegrænsninger. Team med et begrænset fokus på CPU-tid overser andre metoder til optimering af gennemsnit. Udvidelse af dit fokus og anvendelse af disse metoder forbedrer den generelle gennemsnit og effektivitet af din Salesforce-arkitektur. Disse forbedringer vil igen hjælpe med at reducere forsinkelse og øge den generelle systemydeevne. ApexGuru registrerer proaktivt gennemsnitsbegrænsende anti-mønstre, f.eks. SOQL i løkker, DML i løkker, ineffektive GGD-kald og dyre metoder. Disse indsigter hjælper teams med at eliminere styringsbegrænsningsrisici, der dækker gennemsnit.

Hvis du vil optimere gennemsnit i dit system:

• Favorere asynkron behandling. Salesforce Platform bruger transaktionskontekster til at kontrollere dataintegritet og begrænse kørsel af kode. Se transaktioner i Grundlæggende om arkitektur i Grundlæggende om arkitektur. Af denne årsag kan brug af asynkron (asynkron) behandling, hvor det er muligt, hjælpe med at minimere potentielle flaskehalse i synkrone kørselskontekster. Se datahåndtering. Brug af asynkron beregning er ikke en løsning på alle typer af ydeevneproblemer, og du skal tage forsinkelse med i betragtning, når du integrerer asynkrone processer. Visse platformsfunktioner, f.eks. Apex, der kan sættes i kø, kan øge forsinkelsen under spidsbelastning, fordi de får meddelelser til at vente længere i en kø. Afhængig af din anvendelsessituation kan du beslutte at tolerere en potentiel reduktion i responsivitet for at vedligeholde eller forbedre gennemsnit. I andre situationer kan du beslutte, at øget forsinkelse ikke er acceptabel. Med Skaleringstest kan du validere disse afvejninger ved at simulere trafikspikes i en Fuld sandbox. Der kan du måle, hvordan job påvirker gennemsnit og forsinkelse.
• Brug altid massebehandling. På et højt niveau betyder massebehandling udførelse af handlinger mod samlinger. Ofte fokuserer teams, der diskuterer masseinddeling for deres Salesforce-løsninger, på at strømline datahandlinger op mod samlinger. Se Operational Logic. Men massebehandling på systemniveau involverer mere end blot datahandlinger. Overvej også visse opgaver, f.eks. udkald eller komplekse beregninger, som kandidater til massebehandling. Korrekt massebehandling reducerer overhead. Den udfører flere handlinger med en anmodning i stedet for en anmodning pr. handling. ApexGuru viser anti-bulkification mønstre som DML eller SOQL i løkker, som du kan rette, før du skalerer til produktion. Se Bulk Operations.
• Brug SOSL til søgninger og behandl SOQL som en datahandling. Det kan synes indlysende, at brug af overdrevent komplekse SOQL-erklæringer vil øge mængden af tid, det tager systemet at hente registreringer. SOQL tilføjer overhead til den underliggende relationsdatabase, hvilket nedsætter hastigheden af behandlingen. Når der bruges tekst- eller jokertegnskriterier, klarer SOSL sig bedre. SOSL bruger platformens søgemaskine, som er optimeret til fuldtekstindeksering og universelle søgninger. Hvis du vil optimere registrerings hentningsmønstre, skal du sørge for, at dine designstandarder angiver, hvornår du skal bruge SOSL til at finde data i dit system. Sørg også for, at de angiver, hvordan du bruger SOQL til effektive datahandlinger. Se Operational Logic).
• Brug platformscache og ApexGuru. Laget Lightning Platform Cache giver hurtigere ydeevne og bedre pålidelighed ved cachelagring af Salesforce-sessioner og organisationsdata. Platformscache forbedrer ydeevnen ved at distribuere cacheplads, så nogle applikationer eller handlinger ikke stjæler kapacitet fra andre. ApexGuru registrerer manglende salgsmuligheder til cachelagring af gentagne forespørgsler (f.eks. platformscache for SOQL-resultater), hvilket forbedrer gennemsnittet i miljøer i høj skala.

Mønstrene og anti-mønstrene for ydeevne viser, hvordan korrekt og dårlig gennemsnit ser ud i en Salesforce-organisation. Brug dem til at validere dine designs, før du opbygger, eller til at identificere muligheder for yderligere optimering.

Hvis du vil vide mere om Salesforce-værktøjer til optimering af gennemsnit, kan du se Salesforce-værktøjer til pålidelighed.

Forsinkelse er et mål for, hvor hurtigt et system fuldfører en kørselssti. Optimering af systemets gennemsnit vil bidrage til at forbedre forsinkelsen. En anden dimension af forsinkelse er den opfattede ydeevne, eller hvor responsiv systemet virker for brugere.

Folk ønsker ikke at vente på, at sider indlæses, eller at processer afsluttes. Brugere af dit system bliver frustrerede, hvis de ofte oplever lange indlæsningstider, når de forsøger at navigere i listevisninger, registreringssider, rapporter osv. Når dette sker, kan kunder eller partnere beslutte at tage deres forretning andre steder i stedet for at håndtere dårligt fungerende systemer. Intern kan medarbejdere oprette løsninger for at undgå at bruge systemet, som det er designet, hvilket kan forårsage downstream-problemer for sikkerhed og dataintegritet.

Fornemmelse af ydeevne kan være vanskelig at diagnosticere. Når en bruger rapporterer en langsom ydeevne, vil supportteams muligvis ikke kunne gengive problemet. Øget forsinkelse er ofte resultatet af en kombination af mindre problemer, der bygger på hinanden, hvilket kan gøre det vanskeligt at diagnosticere den nøjagtige årsag til opfattede ydeevneproblemer.

Hvis du vil reducere forsinkelse og forbedre responsivitet i dit Salesforce-system:

• Optimer rapporter. Sørg for, at hver rapport tjener et enkelt specifikt formål. Identificer tydeligt målgruppen og formålet for hver rapport i dit system. I rapporter skal du kun inkludere den mindste mængde data, som målgruppemedlemmer har brug for for at træffe beslutninger. Fjernelse af kolonner, der ikke stemmer overens med en rapports formål, vil forbedre rapportydeevnen ved at reducere mængden af data, der skal hentes og vises.
• Optimer filtre. Effektive filtre sætter fart på rapport- og listevisningsydeevnen ved nøjagtigt at omfatte antallet af rækker, der hentes fra databasen. Jo mere specifik du gør din filterlogik, jo mere effektiv vil den underliggende forespørgsel for data være. Måder at optimere filtre på omfatter:
  • Brug af "lig med" og "ikke lig med" i stedet for "indeholder" og "indeholder ikke"
  • Undgå filtrering efter formelfelter
• Forenkle din delingsmodel. En overdrevent kompleks delingsmodel kan nedsætte hastigheden af en række processer, fordi systemet skal kontrollere delings- og synlighedsmodellen for at bestemme, om en bruger har adgang til de data, der skal vises eller behandles. Komplekse delingsberegninger kan øge forsinkelsen i rapportering, listevisninger og automatisering, der kører i brugerens kontekst. Se Deling og synlighed.
• Optimer tilpassede brugergrænsefladekomponenter. Tilpassede brugergrænsefladekomponenter (UI) kan øge forsinkelsen. Hvis du vil optimere ydeevnen i tilpassede brugergrænsefladekomponenter, kan du overveje at gøre disse ting.
  • Brug Lightning Web-komponenter (LWC). LWC-strukturen er tæt tilpasset til moderne webstandarder. Tilpassede komponenter, der er skrevet i LWC, gengives mere effektivt i webbrowsere og gør det muligt for udviklere at bruge mere effektive JavaScript-metoder. Brug altid LWC i stedet for ældre brugergrænsefladeteknologier som Aura eller Visualforce.
  • Brug Lightning Data Service. Lightning Data Service håndterer oprettelse og vedligeholdelse af sikker, effektiv og delt cachelagring på tværs af komponenter. Brug den til at undgå unødvendige rundrejser til serveren for data – og til at øge den generelle applikationssvarbarhed.
  • Brug sortering og filtrering fra klientsiden til listedata. For både LWC-komponenter (foretrukne) og Aura-komponenter (andre) kan udviklere bruge JavaScript-standardmatrixfunktionalitet til at sortere, filtrere og vælge værdier på klientsiden, hvilket reducerer antallet af krævede besøg til serveren.

Mønstrene og anti-mønstrene viser, hvordan korrekt og dårlig forsinkelse ser ud i en Salesforce-organisation. Brug dem til at validere dine designs, før du opbygger, eller til at identificere muligheder for yderligere optimering.

Hvis du vil vide mere om Salesforce-værktøjer til optimering af forsinkelser, kan du se Salesforce-værktøjer til pålidelighed.

Denne tabel viser et udvalg af mønstre, der skal søges efter eller opbygges i din organisation, og anti-mønstre, der skal undgås eller målrettes for rettelse.

✨ Oplev flere mønstre til ydeevne i Pattern & Anti-Pattern Explorer.

Skalerbarhed er et systems mulighed for at yde ensartet, mens det udvikles og vokser. Et skalerbart system håndterer store stigninger i transaktionsmængder eller samtidig adgang uden grundlæggende ændringer. Salesforces platformstjenester er designet til at understøtte applikationsskalerbarhed. Se Intern platformsbehandling. Når din organisation vokser, og efterspørgslen efter dine produkter og tjenester øges, er du ansvarlig for at oprette et system, der kan fungere effektivt og som forventet. Arkitektur for skalerbarhed fra starten resulterer i hurtigere levering af nye funktioner og færre serviceafbrydelser, efterhånden som brugertrafikken øges. Tidligt i designfasen, før du implementerer nye funktioner i produktionen, skal du bruge Skaleringstest til at simulere projekterede arbejdsbelastninger og validere, at arkitekturen kan skalere til at understøtte dem.

Systemer, der ikke er designet til skalerbarhed, kræver konstant og dyr fejlfinding, omdesign og omstrukturering. Skalerbarhedsproblemer forværres over tid og nedsætter ydeevnen i hele systemet. I nogle tilfælde bruger forretninger størstedelen af udviklings- og vedligeholdelsesressourcer på at håndtere skalerbarhedsproblemer i stedet for på nye funktioner, der skaber værdi.

Nogle gange når en forretning et kritisk udgangspunkt. Det oprindelige design af dets system kan ikke understøtte virksomhedens vækst, og uventede begivenheder gør systemet ustabilt. Brug indsigter fra Skalacenter til at identificere skalaerbarhedens spidspunkter tidligt. Skaleringscenter viser undtagelseshotspots, længe kørende transaktioner og køflaskehalse, der forværres over tid.

Du kan bedre arkitektere for skalering ved at fokusere på optimering af datamodel og datamængdeadministration.

Bemærk: Selvom det ikke er omtalt her, er test for skalerbarhed en vigtig del af validering af dine applikationsarkitekturer. Se teststrategi for vejledning.

Datamodelføring involverer strukturering af objekterne i din organisation og relatere dem til hinanden på en måde, der gør det muligt for dine brugere og automatiserede processer at hente de data, de har brug for, så hurtigt som muligt. Ved at tage skridt til at forbedre gennemsnit løses mange ydeevneproblemer, men din indsats vil ikke være så effektiv uden en optimeret datamodel.

De negative påvirkninger af en dårligt designet datamodel er ikke umiddelbart synlige. Dens svagheder vises, efterhånden som systemet vokser i form af datamængde, processer, brugere og integrationer. En veldesignet datamodel gør det nemmere at fortsætte med at omstrukturere din applikation, efterhånden som krav tilføjes og udvides. ApexGuru viser anti-adgangsmønstre som ikke-selektiv SOQL, ubrugte felter og skemaeffektiviteter, der direkte påvirker datamodellens skalerbarhed.

Hvis du vil optimere din datamodel:

• Brug de forudbyggede datamodeller fra Salesforce. Salesforce leverer forhåndsbyggede datamodeller for Salg, Service og en række branchevertikaler. Brug af de datamodeller, der leveres af Salesforce, sikrer, at funktioner i dit system kun defineres en gang, hvilket eliminerer overflødighed og siloer og etablerer en enkelt kilde til sandheden på tværs af hele systemet. Da du brugte Salesforce-datamodeller, der er bygget på forhånd, til denne enkelt kilde, er det nemmere at forstå applikationsdata med analyser og at bruge Salesforces tjenester med kunstig intelligens, der er bygget på forhånd. Og reduktion af de tilpasninger, som du skal understøtte, reducerer vedligeholdelsesomkostninger og reducerer teknisk gæld.
• Vælg de rigtige datatyper. Forstå de forskellige typer felter, der understøttes af Salesforce, og deres begrænsninger. Overvej rapporterings- og krypteringskrav, så du kan undgå at skulle konvertere data mellem typer i fremtiden.
• Vælg de rigtige relationer. Salesforce understøtter to typer relationer mellem objekter: overordnet-detalje og opslag. Overordnet-detalje-relationer tilbyder to primære fordele. En er indbyggede oprulningsoversigtsfunktioner, som tæller og aggregerer detaljer fra underordnede registreringer. Den anden er en indbygget overlappende sletningsfunktion, hvorigennem sletning af en overordnet registrering også sletter dens underordnede registreringer. Men sørg for, at du forstår deling og dataforskydning konsekvenser af overordnet-detalje-relationer, før du beslutter at bruge dem.
• Denormalize for skala. Normalisering er processen med at strukturere din datamodel for reduceret dataoverflødighed og forbedret dataintegritet. Desværre forårsager normalisering nogle gange skaleringsproblemer. Denormaliserede tabeller kan yde sig bedre på skala, men husk at overveje dataintegritet og redundans.

Mønstrene og anti-mønstrene viser, hvordan korrekt og dårlig datamodeloptimering ser ud i en Salesforce-organisation. Brug dem til at validere dine designs, før du opbygger, eller til at identificere muligheder for yderligere optimering.

Hvis du vil vide mere om Salesforce-værktøjer til optimering af datamodel, kan du se Salesforce-værktøjer til pålidelighed.

Datamængde er et mål for mængden af data, der er lagret i dit system, baseret på registreringsantal og størrelser. Hvis din organisation har titusinder af brugere, titusinder af millioner af registreringer eller hundredvis af gigabyte af samlet registreringslager, har du en stor datamængde. Mængden af data og relationer mellem objekter i din organisation påvirker skalerbarheden og vil sandsynligvis have en større indflydelse på skalerbarheden end antallet af registreringer alene.

Hvis du vil forbedre skalerbarheden af organisationer med store datamængder:

• Distribuer underordnede registreringer. Undgå afvigelser i overordnet-underordnet-data ved at sikre, at ingen overordnede har et stort antal underordnede registreringer. Den generelle anbefaling er, at ingen overordnede skal have mere end 10.000 underordnede registreringer. I en implementering, der f.eks. har mange kontakter, men ikke bruger konti, kan du overveje at opsætte flere kontoregistreringer og distribuere relaterede kontaktregistreringer blandt dem.
• Distribuer ejerskab til registreringer. Undgå ejerskabsforskydninger ved at sikre, at ingen enkelt bruger eller kø ejer, eller at alle medlemmer af en enkelt rolle eller en offentlig gruppe ejer mere end 10.000 registreringer fra det samme objekt. "Parkering" af data med en "dummy-bruger" er en praksis, der ofte fører til ejerskabsforskydning. Hvis du støder på dette problem, skal du være opmærksom på den indvirkning, det vil have på deling af beregninger. Hvis du ikke kan omdistribuere registreringer for at lindre ejerskabsforskydningen, skal du undgå at tildele den dataejende bruger til en rolle. Hvis din organisations delingsmodel kræver en rolletildeling, skal du placere den dataejende bruger i en særskilt rolle øverst i delingshierarkiet. Tillad ikke hyppige eller uplanlagte ændringer i den pågældende brugers rolle, da eventuelle ændringer vil have væsentlige ydeevnepåvirkninger på grund af delingsgenberegninger. Hold denne bruger ude af offentlige grupper, som der kan refereres til i delingsregler.
• Reducer mængden af registreringsdata i Salesforce. Salesforce er designet til at give forretninger en enkelt visning af deres kunder. Det kan virke kontraintuitivt, at begrænsning af data i Salesforce er en bedste fremgangsmåde. Men styrken ved den enkelte visning ligger i, hvor godt den gør det muligt for forretningsbrugere at forstå og reagere på kundedata. Efterhånden som datamængden vokser, fører data, der ikke er aktuelle eller relevante for daglige processer eller analyser, til flere problemer. Disse problemer omfatter nedsat appydeevne, øget datasikkerhedsrisiko og negative påvirkninger af søgning, rapportering og analyser. Hvis du vil undgå sådanne problemer, skal du definere en datalivscyklus for hvert objekt i din datamodel med tidslinjer og klassificeringer for data, efterhånden som de bliver ældre og mister øjeblikkelig forretningsværdi. I overensstemmelse med datalivscyklussen skal du implementere disse procedurer for at administrere data over tid.
  • Dataarkivering og rensning – Hvis du vil holde datamængder så lave som muligt, skal du fjerne registreringer, der ikke er nødvendige for virksomheden for at hjælpe med at holde datamængder så lave som muligt. Brug massens API 2.0-funktion til permanent sletning til at slette store datamængder.
  • Dataggregering – Opret tilpassede aggregeringsobjekter, der opsummerer vigtige historiske tendenser eller sammendragsdata i et format, der er kompatibelt med rapportering. Udfyld de tilpassede objekter ved brug af batch Apex. Brugere kan derefter køre rapporter baseret på de aggregerede objektregistreringer.
  • Datainddeling. Vedligehold store datasæt i en anden applikation, hvis de ikke er nødvendige til Salesforce-rapporter eller dagligt arbejde. Gør dataene tilgængelige i Salesforce efter behov via mashups, udkald eller eksterne objekter.

I praksis kan du måske ikke straks håndtere grundårsagen til et skalerbarhedsproblem, når der opstår problemer. Af denne årsag leverer Salesforce indstillinger til at hjælpe med at lindre øjeblikkelige smertepunkter. Det er vigtigt at vide, at aktivering af disse funktioner i din organisation ikke er en levedygtig, langsigtet arkitektonisk strategi til håndtering af store datamængder. Disse kortsigtede løsning af stopgap kan hjælpe med at reducere forsinkelsen i systemer, der lider af dårlig dataarkitektur, men de kan også føje teknisk gæld til din organisation.

Kortsigtede løsninger på skaleringsproblemer omfatter:

• Tilpassede indekser Indekser gemmes i en særlig intern tabel, som platformens forespørgselsoptimering bruger til at fremskynde dataadgangshandlinger. Se Multitenant Indexes). Platformen indekserer automatisk bestemte typer felter som standard. Hvis du vil sætte skub i forespørgsler, der ikke klarer sig godt, kan du anmode om yderligere tilpassede indekser ved at kontakte Salesforce Kundesupport. Brug forespørgselsplanværktøjet til at bestemme, om tilpassede indekser vil forbedre ydeevnen af dine forespørgsler.
• Skinny tabeller. Hvis du har brug for yderligere at optimere forespørgsler for almindelige feltsæt på objekter med mere end 1 million registreringer, kan smalle tabeller hjælpe. Smalle tabeller eliminerer den baggrundsforbindelse, der opstår, når der bruges tilpassede felter og standardfelter fra det samme objekt i en rapport eller automatisering. Hvis du vil bruge smalle tabeller, skal Salesforce Kundesupport aktivere dem for din organisation.

Mønstrene og anti-mønstrene for skalerbarhed viser, hvordan korrekt og dårlig datamængdeadministration ser ud i en Salesforce-organisation. Brug dem til at validere dine designs, før du opbygger, eller til at identificere muligheder for yderligere optimering.

Hvis du vil vide mere om Salesforce-værktøjer til administration af datamængder, kan du se Salesforce-værktøjer til pålidelighed.

Dette viser et udvalg af mønstre, der skal søges efter eller opbygges i din organisation, og anti-mønstre, der skal undgås eller målrettes for rettelse.

✨ Oplev flere mønstre til skalerbarhed i Pattern & Anti-Pattern Explorer.

Hjælp os med at holde Salesforce Well-Architected relevant for dig. Tag vores undersøgelse for at give feedback om dette indhold og fortæl os, hvad du gerne vil se som det næste.