Прочитайте о расписаниях обновления здесь.

Надежные решения работают эффективно и надежно. Они доступны, работают стабильно и масштабируются для поддержки растущего бизнеса.

Надежная система не подвержена ошибкам, действует корректно и своевременно предоставляет результаты. И наоборот, ненадежная система работает медленно, ведет себя некорректно или дает сбой в критические моменты. Ненадежные системы предоставляют недостоверную информацию, поэтому заинтересованные лица не могут Trust им бизнес-решения.

Надежность системы непостоянна. Система, надежная сегодня, может стать ненадежной, если не рассчитана на рост. Ненадежная система может требовать дорогостоящего обслуживания, реорганизации или повторного внедрения, отвлекая средства от стратегических проектов.

Повысьте надежность решений Salesforce, ориентируясь на три принципа: доступность, производительность и масштабируемость. Набор продуктов масштабируемости Salesforce предоставляет собственные возможности, помогающие архитекторам внедрять надежные внедрения.

Доступность — это мера процента времени работы системы. Salesforce Platform обрабатывает большинство проблем доступности на уровне инфраструктуры. Однако, доступность решений, созданных на платформе, с которой сталкиваются клиенты, является общей ответственностью. Важно понимать, что даже при высокой доступности Salesforce риск прерывания обслуживания никогда не будет нулевым.

Архитекторы должны подготовиться к сбоям обслуживания Salesforce, например, плановому обслуживанию или непредвиденным обстоятельствам. В дополнение к сбоям обслуживания, подумайте, как поддерживать высокую производительность и развиваться вместе с бизнесом. Узкий архитектурный выбор может привести к долгосрочным проблемам доступности.

Подумайте о доступности на этапе проектирования, прежде чем создавать решение. Чем дольше вы откладываете создание архитектуры для доступности, тем выше будет фактическая стоимость проблем доступности в долгосрочной перспективе. Чтобы уменьшить потенциальные риски, используйте Масштабное тестирование Salesforce в тестовой среде. В этой среде можно протестировать в масштабах производства, прежде чем развертывать код в производстве.

Архитекторы используют язык предприятия, формулируя технические проблемы для бизнес-заинтересованных лиц, чтобы получить бай-ин и расставить приоритеты в работе над доступностью.Чтобы уменьшить потенциальные риски, используйте Масштабное тестирование Salesforce в тестовой среде. В этой среде можно протестировать в масштабах производства, прежде чем развертывать код в производстве.

Вы можете создать архитектуру для повышения доступности решений Salesforce посредством управления рисками и уменьшения сбоев.

Управление рисками в контексте архитектуры Salesforce предполагает определение потенциальных опасностей для работы системы, ее пользователей, включая сотрудников, партнеров и клиентов), а также бизнес-процессов. Зачастую официальный процесс проведения анализа рисков входит в обязанности руководителей проектов. Архитектор должен обеспечить, чтобы анализ рисков надлежащим образом отражал интересы технических и бизнес-заинтересованных лиц. Вы также обязаны определить важные для бизнеса сценарии использования, которые нужно масштабировать на основе точек пика производства.

Одни из самых больших ловушек в управлении рисками связаны с недостаточностью времени и размышлений. Группы часто пропускают оценку рисков. Или они смешивают решение для резервного копирования и восстановления, что является важной частью уменьшения рисков целостности данных, с комплексной оценкой рисков и их уменьшением.

Чтобы оценить риск для решений Salesforce, используйте следующие методы:

• Использовать инфраструктуру оценки рисков. Некоторые крупные предприятия уже могут иметь соответствующие матрицы рисков. Если да, используйте их, чтобы определить, как классифицировать опасности, какие сведения собирать, что нужно создать для исправления и прочее. Если у вас еще нет инфраструктуры оценки рисков, найдите ее из надежного источника и используйте ее.
• Оцените серьезность влияния и категории риска с точки зрения клиентов. Proactive Monitoring и Scale Center предоставляют настраиваемые предупреждения и панели мониторинга. Они постоянно оценивают риски производительности и масштабируемости и уменьшают зависимость от контрольных списков вручную. Trust и восприятие клиентов являются ключом к каждому предприятию. С точки зрения влияния на бизнес, риски проблем, которые достигают клиентов, обычно перевешивают риски проблем, которые не достигают их. Клиенты могут думать или воспринимать риски не так, как внутренние рабочие группы. Если клиент не может войти в свою учетную запись, его, вероятно, не волнует корневая причина проблемы. Они больше всего заботятся о своем сиюминутном опыте.
• Определите приоритеты рисков. В идеале каждый риск связан с надежным планом смягчения последствий и реагирования. В действительности, у вас будут пробелы, которые нужно устранить в динамике. Важно применять подход «раньше и повторно обеспечивать ценность». Вы и ваши группы доставки и обслуживания можете взять на себя только столько работы в данный момент времени. В Salesforce распространено выражение: «Если все важно, ничего важного нет». Мы используем V2MOM для приоритизации и согласования работы во всей компании, в разных рабочих группах и вплоть до каждого отдельного лица. ( Дополнительные сведения о V2MOM можно узнать в Trailhead.) Используйте оценки рисков, которые дают вам возможность работать с заинтересованными лицами над определением приоритетов и обязательств по наиболее важной работе по управлению рисками. Используйте Масштабное тестирование - Создание плана тестирования для определения рисков для приоритизации и уменьшения этих рисков посредством масштабного тестирования.

Используйте Proactive Monitoring для обнаружения рисков ранней доступности. Он отображает аномалии, например, скачки ограничения запросов API, ошибки блокировки строк или параллельные ошибки Apex, предоставляя действенные важные данные до того, как проблемы перерастут в сбои обслуживания.

Схемы и антисхемы доступности отображают корректное и плохое управление рисками в решении Salesforce. Используйте схемы для проверки дизайна перед созданием или для определения областей рефакторинга в системе.

Дополнительные сведения об инструментах Salesforce, связанных с управлением рисками, см. в разделе «Инструменты Salesforce для надежности».

Точка сбоя - это уязвимость, которая делает систему ненадежной. Хорошее предотвращение сбоев не означает определение каждой потенциальной точки сбоя. Вместо этого необходимо быстро классифицировать и расставить приоритеты точек сбоя, чтобы рабочие группы по обслуживанию и поддержке могли эффективно реагировать. См. ответ на инцидент.

Для разработки лучших стратегий смягчения последствий сбоев:

• Классифицировать триггеры для точек сбоя по людям, процессу и технологии. Подобно классификации рисков с точки зрения людей, процессов и технологий, примените одинаковое мышление к способу запуска точек сбоя с высоким приоритетом. Этот метод помогает определить потенциальные триггеры сбоев и разработать и систематизировать ответы на них. Иногда можно смягчить кажущиеся разнонаправленными триггеры сбоев посредством похожих подходов к смягчению, в зависимости от классификации триггеров.

• Определите, как выглядит базовое, промежуточное и зрелое смягчение. Для разработки стратегий смягчения последствий потребуется время. Определите уровни смягчения, чтобы помочь вам и вашей рабочей группе увидеть, где можно немедленно создать элементы управления и как сосредоточить усилия в динамике. Всегда ищите возможности для использования автоматизации в подходах к смягчению последствий, как только это будет возможно. Чтобы проиллюстрировать, как этот подход выглядит на практике, этот пример отображает триггер, ориентированный на человека, и как смягчение на основе политики выглядит на базовом, среднем и зрелом уровнях.

В дополнение к использованию архитектурных сценариев и планированию преемственности используйте Proactive Monitoring. С помощью Proactive Monitoring можно настроить оповещение в реальном времени о триггерах сбоев, например, сбои входа, исключения времени ожидания процессора или параллельные ошибки запроса API. Этот подход к оповещению дополняет меры по смягчению последствий сбоев, обеспечивая своевременное информирование как технических, так и бизнес-заинтересованных лиц для уменьшения последствий сбоев.

Шаблоны и антишаблоны доступности отображают, как правильно и плохо выглядит предотвращение сбоев в решении Salesforce. Используйте их для проверки дизайна перед созданием или для определения мест в системе для реорганизации.

Чтобы узнать больше об инструментах Salesforce для уменьшения сбоев, см. Инструменты, связанные с надежными.

Данная таблица отображает набор схем для поиска или создания в организации, а также антисхемы, которые нужно избежать или нацелить на исправление.

✨ Узнайте больше о доступных схемах в Проводнике по шаблонам и антипаттернам.

Производительность архитектуры системы — это мера, определяющая объем обработки (производительность) и скорость реагирования (задержка). Производительность системы обычно понимается посредством тестирования и мониторинга производственной среды.

Производительная система своевременно завершает процессы на каждом ожидаемом уровне спроса.

Низкая производительность сопровождается более высокой задержкой и низкой производительностью, что приводит к снижению производительности и усилению недовольства пользователей. Устранение проблем с производительностью крайне необходимо, поскольку они могут привести к потере Customer Trust и финансовым потерям.

Производительность решений можно повысить, оптимизировав производительность и задержку.

Примечание: Пропускная способность и оптимизация задержек являются важными аспектами улучшения обработки системы и ее реагирования. Важно помнить, что общая производительность системы также зависит от того, насколько хорошо вы создаете масштаб. При создании необходимо учитывать оба измерения.

В контексте архитектуры Salesforce пропускная способность - это количество параллельных запросов, которые система может выполнить в заданный интервал времени. Решения Salesforce, разработанные и оптимизированные для повышения производительности клиентов, лучше функционируют в пределах управления Salesforce Platform.

Оптимизация производительности в Salesforce начинается с точного расчета загруженности системы и планирования ее роста. Без точных прогнозов требований, которые будут предъявляться к системе, невозможно определить потенциальные проблемы с возможностями производительности вашей системы.

Обдумывая загруженность, учитывайте следующие три измерения.

• Количество транзакций, которые должны быть обработаны системой за указанное время
• Количество пользователей, имеющих доступ к системе одновременно
• Общая сложность логики транзакций в системе

При рассмотрении производительности рабочие группы иногда слишком узко фокусируются на вычислениях и ограничениях максимального времени процессора, которые входят в контролирующие ограничения платформы. Группы с узким фокусом на процессорном времени упускают из виду другие методы оптимизации производительности. Расширение фокуса и применение этих методов повышает общую производительность и эффективность архитектуры Salesforce. Эти усовершенствования, в свою очередь, помогут сократить задержки и повысить общую производительность системы. ApexGuru активно обнаруживает антипаттерны, ограничивающие пропускную способность, например, SOQL в циклах, DML в циклах, неэффективные вызовы GGD и дорогостоящие методы. Эти важные данные помогают рабочим группам устранить риски, ограничивающие производительность.

Для оптимизации производительности в системе:

• Предпочтение асинхронной обработке. Salesforce Platform использует контексты транзакций для управления целостностью данных и ограничения кода поиска. См. транзакции в разделе Основы архитектуры в разделе Основы архитектуры. По этой причине использование асинхронной (асинхронной) обработки при возможности может помочь минимизировать потенциальные преграды в контекстах синхронного выполнения. См. обработка данных. Использование асинхронных вычислений не является лекарством от всех типов проблем производительности, и вам нужно учитывать задержку при внедрении асинхронных процессов. Определенные возможности платформы, например, стоящий в очереди Apex, могут увеличить задержку во время скачков трафика, поскольку они приводят к тому, что сообщения дольше ожидаются в очереди. В зависимости от сценария использования, вы можете принять решение о допустимом снижении оперативности для поддержания или улучшения производительности. В других случаях вы можете решить, что увеличение задержки недопустимо. С помощью Масштабного тестирования можно проверить эти преимущества, смоделировав скачки трафика в Full Sandbox. Здесь можно определить, как задания влияют на производительность и задержку.
• Всегда используйте пакетирование. На высоком уровне пакетирование означает выполнение операций против коллекций. Часто рабочие группы, обсуждающие пакетирование для своих решений Salesforce, фокусируются на оптимизации операций над данными относительно коллекций. См. Оперативная логика. Однако пакетирование на системном уровне включает не только операции над данными. Также учитывайте определенные задачи, например, выноски или сложные вычисления, в качестве кандидатов на пакетирование. Правильный пакет уменьшает накладные расходы. Он выполняет несколько операций с одним запросом вместо одного запроса на операцию. ApexGuru отображает схемы защиты от пакетирования (например, DML или SOQL) внутри циклов, которые можно исправить перед началом масштабирования в производственную среду. См. Пакетные операции.
• Используйте SOSL для поиска и обрабатывайте SOQL как операцию над данными. Может показаться очевидным, что использование слишком сложных операторов SOQL увеличит время, необходимое системе для извлечения записей. SOQL добавляет накладные расходы в базу данных, замедляя обработку. При использовании критериев текста или специальных символов SOSL работает более эффективно. SOSL использует поисковую систему платформы, которая оптимизирована для полнотекстовой индексации и универсального поиска. Чтобы оптимизировать схемы извлечения записей, убедитесь, что стандарты проектирования определяют время использования SOSL для поиска данных в системе. Также убедитесь, что они определяют способ использования SOQL для эффективных операций с данными. См. Operational Logic).
• Используйте кэш платформы и ApexGuru. Уровень кэширования платформы Lightning обеспечивает более высокую производительность и надежность кэширования данных сеанса Salesforce и организации. Кэш платформы повышает производительность, распределяя пространство кэша, чтобы одни приложения или операции не украли нагрузку у других. ApexGuru обнаруживает упущенные возможности для кэширования повторяющихся запросов (например, Кэш платформы для результатов SOQL), что улучшает производительность в широкомасштабных средах.

Шаблоны и антишаблоны производительности отображают правильную и плохую производительность в организации Salesforce. Используйте их для проверки дизайна перед созданием или для определения возможностей дальнейшей оптимизации.

Чтобы узнать больше об инструментах Salesforce для оптимизации производительности, см. «Инструменты Salesforce для надежности».

Задержка - это мера скорости выполнения системой пути выполнения. Оптимизация производительности системы будет способствовать улучшению задержки. Еще одним аспектом задержки является предполагаемая производительность, или насколько адаптивной система кажется пользователям.

Люди не хотят ждать загрузки страниц или завершения процессов. Пользователи вашей системы будут расстроены, если часто будут сталкиваться с длительным временем загрузки при попытке перехода к списковым представлениям, страницам записей, отчетам и т. д. Когда это происходит, клиенты или партнеры могут принять решение перенести свое предприятие в другое место, а не работать с плохо работающими системами. Внутренне сотрудники могут создавать обходные пути, чтобы избежать использования системы должным образом, что может привести к проблемам в дальнейшем для безопасности и целостности данных.

Предполагаемая производительность может быть трудно диагностировать. Когда пользователь сообщает о низкой производительности, группы поддержки могут не воспроизвести проблему. Увеличение задержек часто является результатом сочетания более мелких проблем, которые взаимодополняют друг друга, что может затруднить диагностику точной причины предполагаемых проблем с производительностью.

Чтобы уменьшить задержку и повысить оперативность в системе Salesforce:

• Оптимизация отчетов. Убедитесь, что каждый отчет служит одной конкретной цели. Четко определите аудиторию и цель каждого отчета в системе. Добавьте в отчеты только минимальный объем данных, необходимый участникам аудитории для принятия решений. Удаление столбцов, которые не соответствуют цели отчета, повысит производительность отчета, уменьшив объем данных, которые нужно извлечь и отобразить.
• Оптимизировать фильтры. Эффективные фильтры ускоряют производительность отчетов и списковых представлений, точно определяя количество строк, извлеченных из базы данных. Как правило, чем конкретнее будет логика фильтра, тем более эффективным будет основной запрос данных. Способы оптимизации фильтров включают:
  • Использование слов «равно» и «не равно» вместо слов «содержит» и «не содержит»
  • Избежание фильтрации по полям формул
• Упростите модель общего доступа. Слишком сложная модель общего доступа может замедлить разные процессы, поскольку система должна проверить модель общего доступа и доступности, чтобы определить, есть ли у пользователя доступ к данным для отображения или обработки. Сложные расчеты общего доступа могут увеличить задержку в представлении отчетов, списковых представлениях и автоматизации, выполняемой в контексте пользователя. См. Общий доступ и доступность.
• Оптимизация настраиваемых компонентов пользовательского интерфейса. Настраиваемые компоненты пользовательского интерфейса (UI) могут увеличить задержку. Чтобы оптимизировать производительность в настраиваемых компонентах пользовательского интерфейса, выполните указанные ниже действия.
  • Использовать веб-компоненты Lightning (LWC). Инфраструктура LWC тесно связана с современными веб-стандартами. Настраиваемые компоненты, написанные в LWC, более эффективно отображаются в веб-обозревателях и позволяют разработчикам использовать более эффективные методы JavaScript. Всегда стремитесь использовать LWC вместо старых технологий пользовательского интерфейса, например, Aura или Visualforce.
  • Используйте Lightning Data Service. Служба Lightning Data занимается созданием и обслуживанием безопасного, производительного и общедоступного кэширования между компонентами. Используйте его для избежания ненужных перелетов на сервер для получения данных и повышения общей оперативности приложения.
  • Использовать сортировку и фильтрацию данных списка со стороны клиента. В компонентах LWC (предпочтительно) и Aura (иначе) разработчики могут использовать стандартные функции массива JavaScript для сортировки, фильтрации и выбора значений со стороны клиента, уменьшая количество обязательных поездок на сервер.

Шаблоны и антишаблоны отображают правильный и плохой вид задержки в организации Salesforce. Используйте их для проверки дизайна перед созданием или для определения возможностей дальнейшей оптимизации.

Чтобы узнать больше об инструментах Salesforce для оптимизации задержек, см. «Инструменты Salesforce для надежности».

Данная таблица отображает набор схем для поиска или создания в организации, а также антисхемы, которые нужно избежать или нацелить на исправление.

✨ Ознакомьтесь с дополнительными схемами производительности в Проводнике по шаблонам и антипаттернам.

Масштабируемость — это способность системы работать последовательно в процессе развития и развития. Масштабируемая система обрабатывает значительное увеличение объемов транзакций или параллельный доступ без фундаментальных изменений. Службы платформы Salesforce созданы для поддержки масштабируемости приложения. См. Обработка внутренней платформы. Таким образом, по мере развития организации и увеличения спроса на продукты и услуги вы ответственны за создание системы, которая может работать эффективно и ожидаемо. Архитектура для масштабируемости с самого начала приводит к более быстрому предоставлению новых функций и меньшему количеству прерываний обслуживания по мере увеличения трафика пользователей. На раннем этапе проектирования, прежде чем развертывать новые функции в производственной среде, используйте Масштабное тестирование для имитации прогнозируемых нагрузок и проверки того, может ли архитектура масштабироваться для их поддержки.

Системы, не предназначенные для масштабируемости, требуют постоянного и дорогостоящего устранения неполадок, реорганизации и рефакторинга. Проблемы масштабируемости со временем усугубляются, ухудшая производительность во всей системе. В некоторых случаях предприятия тратят большую часть ресурсов на разработку и обслуживание на решение проблем масштабируемости, а не на новые функции, создающие ценность.

Иногда предприятие достигает критического переломного момента. Исходный дизайн системы не может поддерживать развитие бизнеса, а непредвиденные события делают систему нестабильной. Используйте важные данные из Scale Center для раннего определения переломных точек масштабируемости. Центр масштаба отображает горячие точки исключения, долгосрочные транзакции и преграды очереди, которые ухудшаются с течением времени.

Вы можете лучше создать для масштаба, сосредоточившись на оптимизации модели данных и управлении объемом данных.

Примечание: Тестирование на масштабируемость, хотя и не обсуждается здесь, является важной частью проверки архитектур приложений. Рекомендации см. в разделе Стратегия тестирования.

Моделирование данных включает структурирование объектов в вашей организации и связывание их друг с другом, что позволяет пользователям и автоматизированным процессам извлекать нужные данные как можно быстрее. Принятие мер по повышению производительности решает многие проблемы производительности, но ваши усилия не будут столь эффективны без оптимизированной модели данных.

Негативное влияние некорректно разработанной модели данных не сразу заметно; ее слабые места обнаруживаются по мере роста системы с точки зрения объема данных, процессов, пользователей и интеграций. Продуманная модель данных упрощает постоянную реорганизацию приложения по мере добавления и расширения требований. ApexGuru публикует антипаттерны доступа к данным, например, неизбирательный SOQL, неиспользуемые поля и неэффективность схемы, которые напрямую влияют на масштабируемость модели данных.

Для оптимизации модели данных:

• Используйте готовые модели данных из Salesforce. Salesforce предоставляет готовые модели данных для Sales, Service и разных отраслевых вертикалей. Использование моделей данных, предоставленных Salesforce, обеспечивает определение возможностей в системе только один раз, исключая дублирование и блокировку и устанавливая единый источник истины во всей системе. Поскольку вы использовали готовые модели данных Salesforce для этого одного источника, легче понять данные приложения с помощью аналитики и использовать готовые службы искусственного интеллекта Salesforce. Кроме того, уменьшение обязательных настроек уменьшает затраты на обслуживание и техническую задолженность.
• Выберите соответствующие типы данных. Ознакомьтесь с разными типами полей, поддерживаемых Salesforce, и их ограничениями. Рекомендуем использовать требования к отчетам и шифрованию, чтобы избежать необходимости преобразования данных между типами в будущем.
• Выберите правильные взаимосвязи. Salesforce поддерживает два типа взаимосвязей между объектами: «Основная — подробная» и «Поиск». Взаимосвязи «Основная — подробная» предоставляют два основных преимущества. Одна из них - встроенные возможности сводного резюмирования, которые учитывают и агрегируют сведения из дочерних записей. Другая — встроенная возможность каскадного удаления, посредством которой удаление родительской записи инициирует удаление ее дочерних записей. Прежде чем использовать взаимосвязи «Основная — подробная», просмотрите последствия общего доступа и искажения данных.
• Ненормализация для масштаба. Нормализация - это процесс структурирования модели данных для уменьшения избыточности данных и улучшения целостности данных. К сожалению, нормализация иногда приводит к проблемам масштабирования. Ненормализованные таблицы могут работать лучше в масштабах, но не забудьте учитывать целостность данных и избыточность.

Шаблоны и антишаблоны отображают правильную и плохую оптимизацию модели данных в организации Salesforce. Используйте их для проверки дизайна перед созданием или для определения возможностей дальнейшей оптимизации.

Чтобы узнать больше об инструментах Salesforce для оптимизации модели данных, см. «Инструменты Salesforce для надежности».

Объем данных - это мера объема данных, хранимых в системе, в зависимости от количества и размера записей. Если в вашей организации десятки тысяч пользователей, десятки миллионов записей или сотни гигабайт общего хранилища записей, у вас большой объем данных. Объем данных и взаимосвязи между объектами в вашей организации влияют на масштабируемость и, вероятно, окажут большее влияние на масштабируемость, чем количество одних только записей.

Для повышения масштабируемости организаций с большими объемами данных:

• Распространение дочерних записей. Избегайте перекосов в данных «родитель-дочерний», убедившись, что ни у одного из родителей нет большого количества дочерних записей. Общая рекомендация состоит в том, что ни один родитель не должен иметь более 10 000 дочерних записей. Например, в развертывании с большим количеством контактов, но не использующем организации, рекомендуем настроить несколько записей организаций и распространить связанные записи контактов между ними.
• Распространение ответственности за записи. Во избежание искажения ответственности, убедитесь, что ни один пользователь или очередь не владеет, а также что все участники одной роли или общедоступной группы владеют более 10 000 записей из одного объекта. «Парковка» данных с «фиктивным пользователем» — это практика, которая часто приводит к перекосу ответственности. При возникновении данной проблемы помните о ее влиянии на вычисления общего доступа. Если вы не можете перераспространить записи, чтобы устранить перекос ответственности, избегайте назначения ответственного за данные пользователя роли. Если модель общего доступа вашей организации требует назначения роли, разместите ответственного за данные пользователя в отдельной роли вверху иерархии общего доступа. Не допускайте частых или незапланированных изменений роли этого пользователя, поскольку любые изменения будут иметь значительное влияние на производительность в результате пересчетов общего доступа. Не допускайте этого пользователя к общедоступным группам, на которые могут ссылаться любые правила общего доступа.
• Уменьшить объем данных записи в Salesforce. Salesforce создан для предоставления предприятиям единого представления клиентов. Ограничение данных в Salesforce может показаться нелогичным. Однако сила единого представления заключается в том, насколько хорошо оно позволяет бизнес-пользователям понимать данные клиентов и предпринимать действия над ними. По мере увеличения объема данных, данные, не актуальные или актуальные для ежедневных процессов или аналитики, приводят к нескольким проблемам. Эти проблемы включают снижение производительности приложения, повышение риска безопасности данных и негативное влияние на поиск, отчетность и аналитику. Во избежание подобных проблем, определите жизненный цикл данных для каждого объекта в модели данных с временными шкалами и классификациями для данных по мере их старения и потери бизнес-ценности. В соответствии с жизненным циклом данных внедрите данные процедуры для управления данными в динамике.
  • Архивирование и очистка данных. Чтобы уменьшить объемы данных, удалите записи, ненужные предприятию, чтобы уменьшить объемы данных. Используйте функцию безвозвратного удаления Bulk API 2.0 для удаления больших объемов данных.
  • Агрегация данных: создание настраиваемых объектов агрегации, резюмирующих ключевые архивные тенденции или сводные данные в формате, совместимом с отчетностью. Заполнить настраиваемые объекты посредством пакета Apex. Пользователи могут потом выполнять отчеты на основе записей агрегированных объектов.
  • Уровень данных. Обслуживайте большие наборы данных в другом приложении, если они не нужны для отчетов Salesforce или повседневной работы. При необходимости предоставьте доступ к данным в Salesforce посредством сопоставлений, выносок или внешних объектов.

На практике, при возникновении проблем не всегда можно сразу устранить первопричину проблемы масштабируемости. По этой причине Salesforce предоставляет варианты, которые помогут облегчить немедленные болевые точки. Важно знать, что включение этих функций в вашей организации не является жизнеспособной долгосрочной архитектурной стратегией для обработки больших объемов данных. Эти краткосрочные временные решения могут помочь уменьшить задержку в системах, страдающих от плохой архитектуры данных, но они также могут добавить техническую задолженность вашей организации.

Краткосрочные решения проблем масштаба включают:

• Настраиваемые индексы Индексы хранятся в специальной внутренней таблице, используемой оптимизатором запросов платформы для ускорения операций доступа к данным. См. Multitenant Indexs). Платформа автоматически индексирует определенные типы полей по умолчанию. Чтобы ускорить неэффективные запросы, можно запросить дополнительные настраиваемые индексы, обратившись в службу поддержки Salesforce. Используйте инструмент «План запросов», чтобы определить, улучшат ли настраиваемые индексы производительность запросов.
• Худые столики. При необходимости дальнейшей оптимизации запросов для распространенных наборов полей в объектах с более 1 миллиона записей, могут помочь тощие таблицы. Тонкие таблицы исключают фоновое объединение, возникающее при использовании настраиваемых и стандартных полей из одного объекта в отчете или автоматизации. Чтобы использовать тощие таблицы, служба поддержки Salesforce должна включить их для вашей организации.

Шаблоны и антишаблоны масштабируемости отображают, как правильно и плохо выглядит управление объемом данных в организации Salesforce. Используйте их для проверки дизайна перед созданием или для определения возможностей дальнейшей оптимизации.

Дополнительные сведения об инструментах Salesforce для управления объемами данных см. в разделе «Инструменты Salesforce для надежности».

Это отображает выбор шаблонов для поиска или создания в вашей организации, а также антисхемы для избежания или нацеливания на исправление.

✨ Ознакомьтесь с дополнительными схемами масштабируемости в Проводнике по шаблонам и антипаттернам.

Помогите нам поддерживать актуальность Salesforce «Хорошо архитектура». Пройдите опрос, чтобы предоставить отзыв об этом содержимом и сообщить, что вы хотите видеть дальше.