Dữ liệu này nằm ở đâu?
Cũng có bằng 28 ngôn ngữ khác
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Mô-đun 4 trong 10 của chương Kiến trúc dữ liệu Salesforce, chương 3 của khóa học Data Architect. Mỗi mô-đun có thể đọc độc lập. Trước: Tự xây dựng: các đối tượng tùy chỉnh · Tiếp theo: Chọn đúng đối tượng
Câu hỏi mô-đun này trả lời: trước khi tạo một đối tượng, dữ liệu này thực sự nên nằm ở đâu: trên lõi trong Salesforce, được tham chiếu ở nơi nó đang nằm, hay được lưu trữ?
Cho tôi hỏi bạn một câu. Một yêu cầu mới đến bàn bạn. Việc đầu tiên bạn làm là gì?
Nếu bạn giống phần lớn chúng ta, bạn mở Thiết lập và tạo một đối tượng tùy chỉnh. Tôi hiểu. Trong mười phút bạn có một tab, một bố cục trang và một chế độ xem danh sách. Và đây là điều tôi nói với mọi lớp học: ngay khoảnh khắc bạn tạo đối tượng mới đó, bạn đã đang tư duy như một kiến trúc sư, dù bạn có chủ ý hay không. Bởi vì mỗi đối tượng bạn tạo là một cam kết. Nó chiếm dung lượng lưu trữ. Nó dính vào các giới hạn. Nó có một mô hình chia sẻ, dù bạn có thiết kế hay không. Nó cần giấy phép cho bất kỳ ai chạm vào nó. Và một khi con người và các tích hợp đã phụ thuộc vào nó, chúc bạn may mắn khi muốn gỡ nó đi.
Vậy quyết định kiến trúc đầu tiên không phải là đối tượng nào. Mà là dữ liệu này nên nằm ở đâu? Làm đúng điều đó, và loại đối tượng gần như tự chọn ra.
Trên lõi và ngoài lõi
Phần tiêu đề “Trên lõi và ngoài lõi ”Trước hết, một từ tôi sẽ dùng rất nhiều: lõi (core). Lõi là nền tảng Salesforce mà org của bạn chạy trên đó: nền tảng đa người thuê, vận hành bằng siêu dữ liệu từ mô-đun 1, nơi các đối tượng Sales và Service từ mô-đun 2 sinh sống, cùng mọi đối tượng tùy chỉnh bạn xây trong mô-đun 3. Khi tôi nói dữ liệu nằm trên lõi (on core), ý tôi là nó được lưu trong org của bạn, trong các đối tượng của org.
Không phải mọi dữ liệu đều nằm ở đó. Data 360 giữ dữ liệu trong kho riêng của nó, bên ngoài các đối tượng của org bạn (nó là gần lõi (near-core): quản lý trên lõi, dữ liệu lưu trữ ngoài lõi; xem thêm ở chương 4). Và rồi còn mọi thứ công ty bạn vận hành mà hoàn toàn không phải Salesforce: ERP, kho hàng, hệ thống đơn hàng, nền tảng của đối tác. Tất cả những thứ đó nằm ngoài lõi (off core). Salesforce có thể với tới, hiển thị và sử dụng chúng, nhưng org của bạn không lưu trữ chúng.
Trên lõi, có hai loại đối tượng thực sự chứa bản ghi của bạn: sObject, chuẩn và tùy chỉnh (__c), và đối tượng lớn (__b). Ngoài lõi, bạn với tới dữ liệu qua đối tượng bên ngoài (__x) và các công cụ tích hợp khác. Hãy nhớ những hậu tố đó từ mô-đun 3; chỉ nhìn tên là chúng cho bạn biết một mẩu dữ liệu nằm ở đâu.
Tôi nghĩ về chuyện này như một văn phòng. Có những thứ thuộc về bàn làm việc của bạn, nơi bạn dùng chúng hằng ngày. Có những thứ bạn chỉ cần tra trong tủ hồ sơ của người khác. Và có những thứ được đóng thùng cất vào nhà kho phía sau. Điều đó cho tôi ba câu trả lời.
1. Trên lõi: nó nằm trên bàn làm việc của bạn
Phần tiêu đề “1. Trên lõi: nó nằm trên bàn làm việc của bạn ”Dữ liệu được tạo, thay đổi và sử dụng trong Salesforce hằng ngày: tài khoản, trường hợp, cơ hội, lệnh công việc. Giữ nó trong sObject giống như giữ nó ở phía trước văn phòng. Đó chính là mục đích của đối tượng chuẩn và tùy chỉnh, và bạn có mọi thứ: bố cục trang, chia sẻ, tự động hóa, báo cáo, tìm kiếm, và giờ đây cả các tính năng AI được xây trên mô hình dữ liệu.
Tuy vậy, bàn làm việc của bạn không miễn phí. Dữ liệu trên lõi tốn dung lượng lưu trữ, được tính theo cách Salesforce tính, theo từng bản ghi chứ không theo từng cột, và tài liệu được tính riêng vào dung lượng lưu trữ tệp. Chúng ta đã nói về cả hai trong mô-đun 2. Khối lượng lớn ảnh và bản quét thường nên nằm ngoài lõi, với Salesforce chỉ giữ một liên kết.
2. Tham chiếu: nó nằm trong tủ hồ sơ của người khác
Phần tiêu đề “2. Tham chiếu: nó nằm trong tủ hồ sơ của người khác ”Dữ liệu thuộc về một hệ thống khác (ERP, một kho dữ liệu, một nền tảng đơn hàng), và hệ thống đó vẫn là nguồn sự thật. Người dùng cần nhìn thấy nó trong Salesforce, có thể liên kết nó với một bản ghi, nhưng Salesforce không cần bản sao riêng. Bạn cũng sẽ nghe gọi đây là dữ liệu ảo (virtual): nó xuất hiện trong Salesforce một cách ảo, mà không bao giờ được lưu ở đó.
Đó là đối tượng bên ngoài, thông qua Salesforce Connect. Tôi hay nói nó trông như con vịt và đi như con vịt, nhưng nó không phải con vịt. Nó xuất hiện như một sObject: bạn có thể đặt nó lên bố cục trang và danh sách liên quan, và liên kết nó với bản ghi của bạn bằng quan hệ tra cứu bên ngoài và gián tiếp. Nhưng dữ liệu không được lưu trên lõi. Mỗi lần bạn chạm vào nó, nó thực hiện một lời gọi ra ngoài (callout). Mở một bản ghi, tải một danh sách liên quan, chạy một báo cáo, và Salesforce đi hỏi hệ thống kia. Điều đó có nghĩa là độ trễ, và trang của bạn chỉ sẵn sàng bằng hệ thống đứng sau nó.
Người ta hay phản đối chi phí giấy phép, nên hãy tính toán theo cách tôi làm trong lớp. Connect được cấp phép theo điểm cuối, và một điểm cuối có thể mang vào nhiều đối tượng. Giờ hãy hỏi xem xây và bảo trì phương án thay thế tốn bao nhiêu: một thành phần tùy chỉnh, mã callout đằng sau nó, và một lập trình viên trực khi nó hỏng. Thường thì giấy phép rẻ hơn, và quản trị viên của bạn có thể cấu hình nó mà không viết một dòng mã nào. Chỗ nó yếu: dữ liệu mà người dùng sửa cả ngày, hoặc báo cáo dày đặc.
Tài liệu cũng có thể được tham chiếu. Nếu một hợp đồng đã nằm trong SharePoint Online, OneDrive, Google Drive hoặc Box, Files Connect cho phép người dùng truy cập nó từ Salesforce mà không cần sao chép vào.
Salesforce Connect không phải là cách duy nhất để tham chiếu dữ liệu. Đôi khi đó là logic tùy chỉnh: mã gọi hệ thống kia theo thời gian thực và hiển thị dữ liệu của nó lên trang, không giữ bản sao nào. Cách đó cho bạn toàn quyền kiểm soát, và toàn bộ trách nhiệm về callout, lỗi và việc bảo trì. Và Data 360 cũng có thể liên kết (federate) mà không sao chép. Lựa chọn đó có chương riêng (Ảo hóa, liên kết dữ liệu và Zero-Copy). Ở đây, điều cốt lõi là chính quyết định: tham chiếu, đừng sao chép.
3. Lưu trữ: nó vào nhà kho phía sau
Phần tiêu đề “3. Lưu trữ: nó vào nhà kho phía sau ”Lịch sử, dấu vết kiểm toán, giao dịch cũ. Bạn phải giữ nó, đôi khi nhiều năm, nhưng gần như không ai mở ra. Và đây là thứ các nhóm hay trì hoãn. Khi một lớp học kể với tôi họ có một đối tượng 50 triệu bản ghi và hỏi vì sao nên lưu trữ, tôi hỏi lại: nếu hôm nay bạn không lưu trữ, liệu bạn có bao giờ lưu trữ không? Hôm nay ở mức 50 triệu, bạn đang tiến tới 100, 150, 200 triệu.
Có hai nhà kho. Một cái nằm trên lõi: đối tượng lớn (big objects). Hãy nghĩ về chúng như cất dữ liệu trong gara. Bạn có thể lưu một số lượng bản ghi khổng lồ, nhưng không thể đặt chúng lên bố cục trang, không có giao diện hay báo cáo chuẩn, và bạn truy vấn qua chỉ mục của đối tượng lớn, bằng khớp chính xác hoặc theo khoảng (Big Objects Best Practices (opens in a new tab), tiếng Anh). Bảo mật chỉ có quyền đối tượng và quyền trường, không có chia sẻ bản ghi, và tự động hóa không chạy trên chúng. Tôi đã dùng Salesforce Connect hàng chục lần nhưng đối tượng lớn chỉ một hai lần. Chúng hoạt động, nhưng vụng về, và tôi đã viết không ít cách lách để lấy được dữ liệu ra. Vì vậy lời khuyên của tôi: hãy làm nguyên mẫu trước khi đề xuất nó, và lên kế hoạch cách người ta sẽ tìm dữ liệu trước khi chọn nó.
Nhà kho còn lại nằm ngoài lõi: một kho dữ liệu hay một cơ sở dữ liệu ở nơi khác (Thiết kế cho quy mô). Thường đó là nhà kho tốt hơn, và nó không nhất thiết phải khuất mắt. Dữ liệu lưu trữ ngoài lõi vẫn có thể xuất hiện trong báo cáo qua các công cụ như Tableau, và vẫn có thể truy cập từ Salesforce, qua Salesforce Connect hoặc một cách ảo hóa khác, khi ai đó cần nhìn lại.
Để tôi kể về một dự án chúng tôi làm đúng ngay từ đầu. Một khách hàng bán lẻ có hơn 1.200 địa điểm. Họ nói với tôi: “Mỗi cửa hàng chúng tôi chỉ có một trăm lịch hẹn mỗi ngày. Không có gì to tát.” Rồi tôi tính: một trăm mỗi ngày, sáu ngày một tuần (khoảng 305 ngày mỗi năm), trên 1.200 địa điểm, là hơn 36 triệu lịch hẹn mỗi năm. Rồi họ nhắc rằng mỗi lượt ghé tạo hai lịch hẹn, một ở quầy trước và một cho khu phía sau cửa hàng: hơn 73 triệu bản ghi mỗi năm. Rồi họ muốn năm năm lịch sử: hơn 360 triệu bản ghi, chưa tính bất kỳ mức tăng trưởng nào. Chúng tôi còn chưa go-live, và tôi đã thấy con tàu đang lao thẳng về ga khối lượng dữ liệu lớn. Vì vậy phần lưu trữ được xây trước khi chúng tôi thu thập lịch hẹn đầu tiên: lịch hẹn cũ được chuyển sang đối tượng lớn, và màn hình tìm kiếm hiển thị lịch hẹn hiện tại cùng các lịch hẹn đã lưu trữ ngay bên dưới. Nhiều năm sau, nó vẫn chạy tốt.
Đưa vào thực tế: Steve Trucking
Phần tiêu đề “Đưa vào thực tế: Steve Trucking ”Steve Trucking là tình huống xuyên suốt của chúng ta: một công ty gia đình giao hàng chặng cuối, nhận đồ gia dụng và điện tử tại các trung tâm phân phối của những nhà bán lẻ lớn, rồi giao và lắp đặt tại nhà khách hàng. Bốn loại dữ liệu của công ty, ba câu trả lời:
| Dữ liệu | Nằm ở đâu | Tại sao |
|---|---|---|
| Các lần giao, tổ giao hàng và lịch hẹn hôm nay | Trên lõi | Điều phối viên và các tổ làm việc trên nó cả ngày |
| Chi tiết đơn hàng của nhà bán lẻ | Tham chiếu (hoặc một bản sao mỏng trên lõi) | Hệ thống của nhà bán lẻ là nguồn sự thật |
| Lịch sử giao hàng từ ba năm trước | Lưu trữ | Được giữ cho khiếu nại và xu hướng; gần như không ai mở |
| Ảnh giao hàng | Ngoài lõi, có liên kết | Hàng nghìn ảnh mỗi ngày; lưu bên ngoài Salesforce với một liên kết trên lần giao |
Đây là cùng điều đó dưới dạng một mô hình dữ liệu. Giao hàng (Delivery) nằm trên lõi, nơi mọi người làm việc với nó cả ngày. Ba năm sau, nó chuyển vào Lịch sử giao hàng (Delivery History), một đối tượng lớn: vẫn trên lõi, nhưng đã ra nhà kho phía sau. Đơn hàng của đối tác xuất hiện dưới dạng một đối tượng bên ngoài, __x: Salesforce liên kết lần giao với nó, nhưng dữ liệu vẫn ở trong hệ thống của nhà bán lẻ. Còn ảnh thì nằm hoàn toàn ngoài lõi, với một liên kết từ lần giao. Một mô hình, ba ngôi nhà.
Mỗi org thực tế đều có cả ba. Những org gặp rắc rối là những org đặt mọi thứ lên lõi, vì tạo một đối tượng là nút mặc định.
Kiến trúc sư quyết định gì ở đây
Phần tiêu đề “Kiến trúc sư quyết định gì ở đây ”- Ngôi nhà cho mỗi loại dữ liệu, trước khi thiết kế bất kỳ đối tượng nào: trên lõi, tham chiếu hay lưu trữ.
- Nguồn sự thật. Nếu một hệ thống khác sở hữu dữ liệu, Salesforce không nên lặng lẽ trở thành bản gốc thứ hai.
- Đường truy cập cho bất cứ thứ gì nằm ngoài lõi. Dữ liệu tham chiếu cần một nguồn sẵn sàng và độ trễ chấp nhận được; dữ liệu lưu trữ cần một cách để người ta tìm thấy nó.
- Tăng trưởng lưu trữ. Hãy tính ngay bây giờ (số bản ghi mỗi ngày, nhân với mức tăng trưởng, nhân với thời gian lưu giữ), đừng đợi đến khi có cảnh báo dung lượng.
Ngoài kỳ thi: AI nâng cao mức độ rủi ro của “trên lõi”. Các tính năng AI và tác tử hoạt động tốt nhất trên dữ liệu mà nền tảng hiểu: dữ liệu trong đối tượng chuẩn và tùy chỉnh, được đặt tên và mô tả tốt. Điều đó tạo ra một lực kéo hướng về việc đặt nhiều hơn lên lõi. Hãy cưỡng lại nó với dữ liệu sai. Một tác tử được neo trên một bản sao cũ của dữ liệu ERP sẽ đưa ra những câu trả lời tự tin nhưng sai. Thường thì bước đi tốt hơn là tham chiếu nguồn trực tiếp, hoặc giữ một lát cắt nhỏ, được mô tả rõ trên lõi. Nơi AI đọc dữ liệu giờ là một phần của việc quyết định dữ liệu nằm ở đâu.
Tìm hiểu thêm
Phần tiêu đề “Tìm hiểu thêm ”- Big Objects Best Practices (opens in a new tab), Salesforce Developers (tiếng Anh, kiểm tra ngày 2026-09-25)
- Files Connect FAQ (opens in a new tab), Salesforce Help (tiếng Anh, kiểm tra ngày 2026-09-25)
- Trong khóa học này: Ảo hóa, liên kết dữ liệu và Zero-Copy và Thiết kế cho quy mô