콘텐츠로 이동
SteveTechArcSteveTechArc Courses

Salesforce가 정말 인덱스를 쓸까요?

19개 언어로도 제공

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)

Data Architect 과정 8장, 파트 2: 규모를 위한 아키텍처. 이전: 규모를 위한 설계.

I send you into a library with 10 million books and ask for every book by A. Ortiz. No catalog. You start at one end and open every book. That’s a table scan. Now give you a card catalog with a drawer by author: that’s an index. And add a librarian who decides, for every question, whether the drawers or the shelves are faster: that’s the query optimizer. ⟲

Here’s the catch, and the hardest idea on the exam: an index that exists isn’t an index Salesforce will use. Think of it as the nitro in a race car. It only fires when three things are true at once: there’s an index on the field, you ask in a selective way, and few enough records match. Ask the catalog for every book in English when 95% of the library is in English, and it hasn’t narrowed anything. Everybody lives in Arizona. That’s why “don’t worry, that field is indexed” is never the end of the conversation. ⟲

On a race car's dashboard, a switch with its red guard lifted waits under three lights: two green, the third still dark.

Image generated with AI. ⟲

Before the library, we open the hood. Salesforce isn’t a database you install for one company. It’s one building with many tenants, a few shared tables that hold every org’s records, and metadata that describes your objects and fields. That design explains why Salesforce indexes the way it does, and why a query can do work you never asked for. ⟲

The last chapter counted the zeros. This one finds things inside them: first with queries, then with search, which finds by words. ⟲

이 장의 생각들

섹션 제목: “이 장의 생각들 ”
  • Salesforce is multitenant and metadata-driven. Adding a field adds a row of metadata, not a column. Standard and custom fields are stored apart, so a query that uses both does a join you never wrote. ⟲
  • An index is a copy: one fact and the record’s location. Every index makes finding faster and every save slower. ⟲
  • Three checks for every filter: is there an index; do you ask in a selective way (equals and starts with, not contains, not equal or empty); and are you under the threshold? ⟲
  • 외워 둘 임계값: 표준 인덱스는 처음 100만 레코드의 30%에 그 이상의 15%를 더하고 상한 100만, 사용자 정의 인덱스는 10%에 5%를 더하고 상한 333,333.
  • A query can go bad without changing. Cases close, history piles up, the object grows 30% a year, and the filter stops narrowing. ⟲
  • The librarian decides, every time. Measure the distribution, then read the Query Plan; the optimizer chooses the path, not you. ⟲
  • When it’s slow: index, rewrite, redesign or archive, chosen deliberately. Skinny tables are for the pattern you “know in your heart”: the same few fields, again and again, on a giant object. ⟲
  • Search is not query. Search finds tokens first, then fetches the records; its index is asynchronous; and it cuts the list at 2,000 before it checks what the user can see. That’s search crowding. ⟲
  • Data can deserve to exist without deserving to appear in search. Decide what’s searchable, by object, profile and field. ⟲
  • Search to discover; query to operate. ⟲

Five questions, five modules

섹션 제목: “Five questions, five modules”
The questionWhere it’s answered
Why doesn’t Salesforce work like a traditional database?Module 1, the engine
What is an index, and which ones does Salesforce give you?Module 2, the library
When can Salesforce use an index?Module 3, the nitro
Who decides how the query runs, and what if it’s slow?Module 4, the librarian
When should you search instead of query?Module 5, search

이 장의 길

섹션 제목: “이 장의 길 ”

다섯 개 모듈, 각각 독립적으로 읽을 수 있습니다.

  1. Inside the Salesforce Engine. One building, many tenants, kept apart by the org ID; no new tables, just metadata; the few shared tables; the join you never wrote; why a normal index doesn’t fit; and how Salesforce rebuilt the engine underneath without anyone noticing. ⟲
  2. How Salesforce Finds Your Data. The library and its card catalog: a table scan, an index as a copy, every copy kept up to date, two ways to ask (SOQL and SOSL), the standard indexes, custom indexes, which fields can be indexed, and index tables. ⟲
  3. When Salesforce Uses an Index. The nitro’s three checks: is there an index, are you asking it the right way, and are you under the threshold. Everybody lives in Arizona, the thresholds and their caps, the closed-cases trap, and 30% growth. ⟲
  4. How Salesforce Executes a Query. Four words (query, fetch, table scan, join), the librarian, reports at volume, the Query Plan, more than one index, two-column indexes, skinny tables, divisions, database statistics, and index, rewrite, redesign or archive. ⟲
  5. Search Is Not Query. Tokens first, then the fetch; freshness; search crowding step by step, and a seven-step playbook to reduce it; search runs as someone; search to discover, query to operate. ⟲

Finding by meaning (semantic and hybrid retrieval), and agents that retrieve far more often than any person, are in chapter 16, Choosing How the Agent Gets the Data. ⟲

아키텍트가 여기서 결정하는 것

섹션 제목: “아키텍트가 여기서 결정하는 것 ”
  • 어떤 조회 패턴이 중요한지, 그리고 모델이 그 패턴에 어떤 경로를 주는지.
  • Whether each important filter stays selective at year three and year five, at real volume and real distribution. ⟲
  • Which indexes are worth their cost, standard, custom or two-column, and when a skinny table is the answer. ⟲
  • 조회가 확장되지 않을 때 인덱싱할지, 재작성할지, 재설계할지, 아카이브할지.
  • When to search and when to query, and what deserves to be searchable at all. ⟲

Beyond the exam: AI doesn’t repeal database physics. An assistant writes plausible SOQL that dies at 50 million rows, and an agent runs the same inefficient retrieval a thousand times a day. The librarian still decides, the thresholds still apply, and search still cuts at 2,000. Each module ends with what AI changes for its part of retrieval. ⟲

더 알아보기

섹션 제목: “더 알아보기 ”

다음: 통합과 데이터 이동