A city AI platform stores bulky ordinance PDFs and high-churn embedding items in Cosmos DB. How should containers be designed?
Select an answer to reveal the explanation.
Short Explanation
Separate containers are two filing cabinets—one for the heavy ordinance binders, one for the snappy embedding cards—so each can have its own RU and index diet.
Full Explanation
City AI platforms that store bulky ordinance PDFs alongside high-churn embedding items should separate those workloads in Cosmos DB. Distinct containers for raw documents and embeddings let RU budgets, indexing policies, and partition strategies be tuned independently for large binaries versus vector-centric items. Forcing every PDF binary and every embedding into one item under a single shared RU pool couples heavy attachment I/O to embedding churn and makes indexing and throttling harder to reason about. Storing embeddings only in App Service local temp folders abandons a durable shared store and loses embeddings on recycle or scale-out. Using one container with indexing enabled on every binary attachment property regardless of query needs inflates RU and index maintenance for fields that RAG rarely filters on. Exam caveat: container separation is about operational isolation of RU and index profiles, not a mandate to never join logically related municipal content at the application layer. Operationally, place ordinance blobs and embedding documents in separate containers with indexing policies matched to actual predicates, then monitor RU per container during ordinance ingest and RAG spikes.