Nhanh chóng mở rộng lưu trữ trực tuyến để phục vụ hơn 1 tỷ người dùng ChatGPT

Mọi sản phẩm OpenAI đều phụ thuộc vào khả năng truy cập dữ liệu nhanh chóng và đáng tin cậy, dù người dùng đang đăng nhập, kiểm tra cài đặt Codex hay bắt đầu cuộc trò chuyện mới trong ChatGPT. Mỗi hành động đó có thể cần nhiều lượt tra cứu dữ liệu riêng biệt trước khi sản phẩm có thể phản hồi. Nếu các yêu cầu đó chậm, người dùng sẽ thấy sản phẩm chậm. Nếu các yêu cầu đó thất bại, sản phẩm sẽ ngừng hoạt động hoàn toàn.

Habitat là nền tảng lưu trữ trực tuyến do chúng tôi xây dựng để các sản phẩm OpenAI truy cập thông tin cần thiết một cách nhanh chóng và đáng tin cậy. Habitat hiện xử lý hơn 70 triệu yêu cầu mỗi giây, hỗ trợ các sản phẩm được hơn 1 tỷ người sử dụng hằng tuần tại gần 40 khu vực địa lý. Habitat ban đầu ra mắt để hỗ trợ GPT tại DevDay 2023, khởi đầu là một thư viện Python đơn giản phía máy khách, kết nối với một cơ sở dữ liệu duy nhất. Ngày nay, đây là một hệ thống phân tán phức tạp phục vụ hơn 500 petabyte dữ liệu.

Xây dựng và vận hành hạ tầng ở quy mô này không hề dễ, nhưng bản thân việc đó cũng không phải thách thức gì ghê gớm. Điểm khiến hoàn cảnh của chúng tôi trở nên khác biệt là tốc độ mở rộng chưa từng có để đáp ứng mức tăng trưởng người dùng và nhu cầu sản phẩm khổng lồ, trong khi vẫn đồng thời xây dựng một nền tảng trưởng thành. Các kỹ sư hệ thống thường xây dựng cho quy mô gấp 10 lần, hy vọng hệ thống trụ được vài năm trong lúc chuẩn bị cho mức tăng gấp 10 lần tiếp theo. Trong trường hợp của chúng tôi, quy mô đã tăng hơn 10 lần mỗi năm trong ba năm qua. Vì vậy, quá trình xây dựng và vận hành Habitat là một chuỗi quyết định chiến thuật cùng việc sắp xếp trình tự: hiểu từng thành phần ở tầng thấp nhất để khai thác tối đa ngăn xếp hiện có, đồng thời ứng phó tình trạng thiếu năng lực lưu trữ và điện toán nhằm có thêm thời gian đầu tư vào nền tảng cốt lõi.

Khi OpenAI phát triển, Habitat cũng phải phát triển theo: trước tiên đủ tin cậy cho lưu lượng sản phẩm trọng yếu, sau đó đủ nhanh cho người dùng toàn cầu, và cuối cùng đủ linh hoạt để vận hành ở quy mô khổng lồ. Đây là bài đầu tiên trong loạt hai phần về cách chúng tôi mở rộng hệ thống lưu trữ trực tuyến. Trong bài này, chúng tôi sẽ chia sẻ quá trình phát triển của Habitat, lý do chuyển nó từ thư viện thành dịch vụ và cách đưa một dịch vụ viết bằng Python, một ngôn ngữ hiếm dùng trong ngăn xếp phục vụ, trở thành một tầng nền tảng lưu trữ đáng tin cậy.

Trong bài tiếp theo, chúng tôi sẽ trình bày chi tiết cách bảo đảm độ tin cậy của kiến trúc đa đối tượng thuê ở quy mô lớn, chiến lược nhiều tầng để tối ưu hiệu năng đọc và cách mở rộng quan hệ hợp tác với Azure Cosmos DB nhằm xử lý đáng tin cậy nhu cầu chưa từng có.

Habitat bắt nguồn từ một ý tưởng đơn giản: kỹ sư sản phẩm không cần phải bận tâm đến việc quản lý cơ sở dữ liệu. Habitat ra mắt lần đầu để hỗ trợ GPT tại DevDay 2023 dưới dạng một thư viện Python nhỏ tương tác với máy chủ chính của ChatGPT. Thư viện này hỗ trợ một tập hợp nhỏ các thao tác được ánh xạ ngầm tới ứng dụng cơ sở dữ liệu Azure Cosmos DB.

Nhiệm vụ của thư viện là giúp các đội ngũ sản phẩm lưu trữ và truy xuất dữ liệu theo cách đơn giản mà không cần nắm vững các chi tiết bên dưới. Habitat đảm nhiệm những việc cần thiết: xác định loại dữ liệu liên quan, dữ liệu phải đến từ đâu hoặc đi đâu, yêu cầu có được phép hay không, v.v.

Kỹ sư sản phẩm không cần bận tâm đến việc tra cứu lược đồ, định tuyến, cấp quyền, mã hóa, tuần tự hóa, định hình yêu cầu và gộp kết nối. Họ thậm chí không cần cân nhắc dữ liệu đến từ đâu: Azure Cosmos DB, bộ nhớ đệm hay loại hình lưu trữ khác.

Thư viện Python này hoạt động tốt và Habitat nhanh chóng được các kỹ sư sản phẩm tại OpenAI áp dụng, dù không có một nỗ lực tập trung nhằm thúc đẩy họ rời khỏi Postgres tự phục vụ và Azure Cosmos DB.

Khi nhu cầu sản phẩm thay đổi, nhà phát triển sản phẩm cũng dễ dàng bổ sung vào thư viện dùng chung khả năng hỗ trợ các tính năng như lưu vào bộ nhớ đệm phía máy khách, nén hoặc mã hóa.

Đến giữa năm 2025, Habitat đã chạm giới hạn của một giải pháp triển khai phía máy khách. Khi tầng Habitat ngày càng phức tạp và số lượng dịch vụ của OpenAI gia tăng, việc thay đổi giao thức mà vẫn tương thích ngược đã trở nên bất khả thi.

Có lần, chúng tôi muốn giảm phạm vi ảnh hưởng nếu một khu vực gặp sự cố đối với các tập dữ liệu trọng yếu nhất bằng cách di chuyển các tập dữ liệu đó sang một nhóm tài khoản Azure Cosmos DB phân tán theo khu vực. Thay đổi này đòi hỏi phải bổ sung logic định tuyến vào máy khách, tạm tắt logic đó sau một cờ tính năng, bảo đảm triển khai đến mọi máy khách rồi mới bật cờ.

Việc điều phối triển khai trên hàng chục dịch vụ và phối hợp với từng đội ngũ để phát hành mất nhiều ngày. Trước khi bật tính năng, chúng tôi nhận ra cần thêm lưu lượng bóng để bảo đảm logic phân mảnh hoạt động chính xác. Việc triển khai đó lại mất thêm vài ngày. Còn sửa một lỗi mà chúng tôi vừa nhận ra? Lại thêm vài ngày nữa. Cuối cùng, khi đã sẵn sàng bật cờ, một đội ngũ lại quay lui dịch vụ của họ về phiên bản máy khách cũ còn lỗi vì những lý do không liên quan, gây ra chính sự cố mà chúng tôi đã rất nỗ lực để tránh.

Các thay đổi đối với thư viện máy khách đòi hỏi sự điều phối phức tạp giữa hàng chục dịch vụ; quy trình này ngày càng mong manh, kém hiệu quả và dễ gặp sự cố vận hành. Để giảm mức phân tỏa vận hành cho những lần triển khai sau, chúng tôi quyết định tách Habitat thành một dịch vụ riêng.

Bằng cách tách logic lưu trữ thành một dịch vụ độc lập, chúng tôi thiết lập một điểm kiểm soát duy nhất cho hoạt động triển khai, khả năng quan sát và cải tiến nền tảng. Thay vì quản lý các bản cập nhật rời rạc, chúng tôi có thể triển khai cải tiến tập trung, mang lại lợi ích tức thì cho mọi sản phẩm OpenAI.

Dịch vụ tập trung cũng tạo ra một điểm kiểm soát duy nhất để cung cấp các cơ chế bảo mật và quyền riêng tư dữ liệu mạnh nhất. Dịch vụ Habitat là nơi chúng tôi có thể thực thi tập trung các chính sách kiểm soát truy cập, ghi nhật ký kiểm toán và hạn chế quyền truy cập vào tài nguyên lưu trữ bên dưới như Azure Cosmos DB. Habitat đóng vai trò then chốt trong việc bảo vệ dữ liệu người dùng và ngăn chặn truy cập trái phép từ các đối tượng bên ngoài, nội bộ và tác nhân.

Chúng tôi biết mình cần một dịch vụ, nhưng chưa muốn rời Python ngay, dù việc dùng Python cho dịch vụ phát sinh thêm chi phí. So với chạy thư viện cục bộ, việc dùng Python cho dịch vụ có thông lượng cao làm tăng độ trễ mạng và đáng kể chi phí mở rộng CPU lẫn bộ nhớ. Hơn nữa, chúng tôi hiểu rằng sự kém hiệu quả của Python sẽ không thể chấp nhận được ở quy mô gấp 100 lần, nên gần như chắc chắn sau này sẽ phải viết lại.

Tuy nhiên, chúng tôi xem đây là quyết định chủ động chấp nhận nợ kỹ thuật vì mục tiêu chiến lược. Mục tiêu chính lúc đó không phải tối ưu chi phí hay tài nguyên, mà là tháo gỡ trở ngại cho các nhà phát triển sản phẩm và ổn định nền tảng. Bằng cách tạm thời chấp nhận đánh đổi hiệu năng của dịch vụ Python, chúng tôi có thể ưu tiên các thách thức cấp bách hơn, thiết lập những API cốt lõi và xây dựng hạ tầng vững chắc.

Chúng tôi cũng có tính toán khi đặt cược rằng tốc độ tiến bộ nhanh chóng của các mô hình lập trình do mình phát triển sẽ đơn giản hóa lộ trình kỹ thuật trong tương lai. Chúng tôi tin rằng khi cần di chuyển hoàn toàn khỏi Python, Codex và GPT sẽ giúp việc đó trở nên khả thi. Cuối cùng, tính toán đó đã đúng.

Xét về hiệu năng, chạy Habitat dưới dạng dịch vụ Python không phải lựa chọn tối ưu, nhưng là lựa chọn cần thiết. Python giúp chúng tôi tiến nhanh, nhưng không có nghĩa là có thể bất chấp rủi ro và chấp nhận độ trễ tệ hơn đáng kể. Khi một yêu cầu trung bình của người dùng kéo theo hàng trăm lệnh gọi cơ sở dữ liệu, người dùng sẽ cảm nhận độ trễ của lệnh gọi chậm nhất. Chúng tôi nhận thấy thách thức chính khi vận hành dịch vụ Python ở quy mô này là kiểm soát độ trễ đuôi.

Asyncio giúp Python thực thi đồng thời các khối lượng công việc phụ thuộc I/O, nhưng không thể khắc phục GIL của Python để cung cấp khả năng xử lý CPU song song. Ngoài việc chuyển tiếp yêu cầu nặng về I/O, Habitat còn đảm nhiệm nhiều tác vụ nền và trách nhiệm nặng về CPU: định tuyến, nén, mã hóa, tính tổng kiểm, kiểm tra tình trạng hệ thống hạ nguồn, tạo lưu lượng bóng và gửi yêu cầu dự phòng.

Với rất nhiều khối lượng công việc nặng về CPU và tác vụ nền trong dịch vụ, độ trễ lập lịch asyncio rất dễ trở thành yếu tố chi phối độ trễ đuôi của yêu cầu. Trước khi tinh chỉnh để ra mắt dịch vụ ban đầu, bản ghi trace của các yêu cầu có độ trễ p99 trở lên cho thấy dù hệ thống lưu trữ hạ nguồn phản hồi nhanh, yêu cầu vẫn thường xuyên bị đình trệ trong lúc chờ coroutine phụ trách được lập lịch lại để phân tích cú pháp phản hồi.

Với các dịch vụ Python tại OpenAI, ngoài những chỉ số sử dụng và bão hòa tiêu chuẩn cho bộ nhớ, CPU, mạng và ổ đĩa, chúng tôi nhận thấy việc theo dõi vòng lặp asyncio cùng mức độ bận của vòng lặp rồi tinh chỉnh tương ứng cũng vô cùng quan trọng.

Bằng cách định kỳ lập lịch các tác vụ nền và ghi lại chênh lệch giữa thời điểm thực thi dự kiến với thực tế, chúng tôi có thể đo độ trễ lập lịch của vòng lặp sự kiện theo thời gian thực bằng dữ liệu thực nghiệm. Khi mức sử dụng cao và có nhiều tác vụ tốn kém, chỉ một lượng yêu cầu đồng thời vừa phải trên mỗi tiến trình cũng đủ gây dao động lập lịch đáng kể, lên tới hàng trăm mili giây và trong một số trường hợp biên là vài giây.

Vì vậy, chúng tôi chỉ để mỗi tiến trình phục vụ một lượng nhỏ yêu cầu đồng thời và thay vào đó mở rộng mạnh số lượng tiến trình worker Python.

Trong lần ra mắt dịch vụ ban đầu, nhờ phân tích hiệu năng CPU trên dịch vụ đang chạy, chúng tôi đã tìm ra một nguyên nhân gốc rễ khiến độ trễ asyncio cao và kéo theo độ trễ đuôi cao: Statsig định kỳ phân tích cú pháp JSON trong cấu hình cờ tính năng của chúng tôi (đây là công cụ quản lý cờ tính năng, có thể dùng để chạy thử nghiệm A/B và nhiều việc khác).

Theo mặc định, Statsig được cấu hình thăm dò cấu hình mới mỗi phút mà không có độ lệch ngẫu nhiên; cấu hình này còn chứa mọi quy tắc trên môi trường production của tất cả dịch vụ. Ở một phần khác của hệ thống, chúng tôi đã quyết định về mặt kiến trúc rằng mỗi pod sẽ chạy tối đa 8 tiến trình Python để tăng mức sử dụng CPU và giảm độ trễ. Kết hợp lại, điều này có nghĩa là mỗi phút, mọi pod đều có lúc tất cả worker ngừng xử lý yêu cầu đang diễn ra và dành chu kỳ CPU để phân tích cú pháp một tệp cấu hình khổng lồ.

Sau khi lập hồ sơ CPU giúp tìm ra nguyên nhân gốc rễ, cách khắc phục khá đơn giản: triển khai cấu hình nhỏ hơn, đúng trọng tâm; kéo dài khoảng thời gian làm mới; và thêm độ lệch ngẫu nhiên cho các tác vụ nền kiểu này.

Để duy trì độ trễ asyncio thấp, việc cân bằng tốt tải yêu cầu giữa các tiến trình máy chủ cũng rất quan trọng; nếu không được tinh chỉnh, cơ chế gộp kết nối có thể đi ngược mục tiêu này.

Với cơ chế gộp kết nối phía máy khách, một tiến trình máy khách gửi nhiều yêu cầu đồng thời có thể chỉ thiết lập vài kết nối máy chủ và vì thế dồn toàn bộ tải vào một vài tiến trình. Trước khi điều chỉnh cách cân bằng tải, mức sử dụng của dịch vụ chênh lệch rất lớn: một số tiến trình ở phần đuôi phục vụ lượng yêu cầu đồng thời gấp 5–10 lần mức trung bình.

Chúng tôi tình cờ phát hiện điều này trong một sự cố: dù đã dừng máy khách gây quá tải một phần dịch vụ, một nhóm tiến trình vẫn suy giảm hiệu năng rất lâu sau khi đợt lưu lượng tăng vọt kết thúc. Trên thực tế, chúng tôi nhận thấy các tiến trình đó suy giảm mất kiểm soát, nhận ngày càng nhiều yêu cầu cho đến khi được khởi động lại. Khi một pod bị quá tải, một cơ chế nào đó lại ghim thêm lưu lượng vào chính pod đó. Đây là một dạng lỗi mà một số đồng nghiệp của chúng tôi đã rất quen thuộc từ công việc trước đây: lỗi siêu ổn định⁠(mở trong cửa sổ mới).

Chúng tôi nghi ngờ nhóm kết nối là nguyên nhân và kiểm tra bằng cách giới hạn thời gian tái sử dụng kết nối tối đa. Cách này quả thực đã hạn chế tình trạng suy giảm và xác nhận hướng điều tra. Điều tra sâu hơn cho thấy TCPConnector của aiohttp trong Python mặc định tái sử dụng kết nối theo LIFO: kết nối vừa được trả về gần nhất sẽ được chọn cho yêu cầu tiếp theo. Thông thường, đây là lựa chọn mặc định hợp lý: tái sử dụng các kết nối gần đây cho phép những kết nối bổ sung được tạo để xử lý lưu lượng tăng vọt tự hết thời gian chờ khi rảnh, qua đó giảm chi phí duy trì chúng. Nhưng trong trường hợp này, nó tạo ra lỗi siêu ổn định. Trong một đợt yêu cầu tăng vọt, các yêu cầu gửi đến máy chủ chậm và quá tải trả kết nối về nhóm muộn hơn, nên được yêu cầu tiếp theo chọn thường xuyên hơn, dần dồn thêm lưu lượng vào những pod vốn đã chật vật. Việc vá nhóm kết nối để tái sử dụng theo FIFO đã phá vỡ vòng phản hồi này và còn giảm mức chênh lệch yêu cầu ở trạng thái ổn định.

Ngày nay, chúng tôi chủ yếu dựa vào Istio và Envoy để cung cấp cơ chế gộp kết nối cùng các chiến lược cân bằng tốt hơn dựa trên tải máy chủ trong toàn bộ hạ tầng OpenAI, qua đó tránh hẳn vấn đề này.

Một tác dụng phụ của việc tinh chỉnh để giảm độ trễ asyncio và chạy quá nhiều tiến trình Python là số lượng kết nối khổng lồ có thể dễ dàng áp đảo các thành phần phụ thuộc hạ nguồn—hiện tượng gọi là “đàn sấm”.

Một đợt triển khai thường lệ hằng ngày—nếu không được tinh chỉnh để diễn ra chậm—có thể khiến CPU biến động mạnh do các kết nối liên tục được thay mới. Hoặc rò rỉ kết nối có thể đánh sập mạng do làm bão hòa cổng NAT. Đây cũng là những vấn đề không hiếm gặp ở các dịch vụ khác, nhưng số lượng tiến trình lớn hơn cả một bậc độ lớn làm giảm đáng kể ngưỡng kích hoạt, thường khiến các tài nguyên liên quan đến mạng bị bão hòa—điều mà máy khách không dự tính phải xử lý ở trạng thái ổn định nếu chỉ xét riêng thông lượng.

Chúng tôi cũng dựa vào Envoy để tối đa hóa khả năng hội tụ kết nối. Chúng tôi dùng Envoy để nâng cấp kết nối HTTP/1 của Python lên HTTP/2 nhằm tận dụng khả năng ghép kênh, sau đó gộp các kết nối này và kéo dài thời gian tồn tại của chúng. Envoy cũng cung cấp một nơi tập trung để triển khai giới hạn tốc độ và bộ ngắt mạch—những cơ chế sẽ kém hiệu quả hơn nếu đặt trong từng tiến trình Python độc lập.

Một lý do giúp chúng tôi mở rộng Python đến mức này là API có giới hạn của Habitat, nhờ đó chi phí xử lý yêu cầu luôn dự đoán được. Thay vì cho phép máy khách tạo các truy vấn SQL tùy ý có thể quét bảng lớn hoặc nối nhiều bảng, Habitat cung cấp một API NoSQL đơn giản. Việc không có một API mạnh là sự đánh đổi có chủ đích trong thiết kế Habitat.

Chúng tôi hướng đến tối ưu cho các yêu cầu đơn giản, dễ dự đoán và có lượng công việc cố định. Theo kinh nghiệm của chúng tôi, những hệ thống này dễ mở rộng hơn đáng kể và khó bị triển khai sai hoặc sử dụng sai. Các yêu cầu có mức phân tỏa khó dự đoán rất nguy hiểm cho vận hành: loại yêu cầu này làm phức tạp việc cô lập và cân bằng tải, đồng thời tạo ra những ngưỡng khiến độ trễ tăng vọt mà cả dịch vụ lẫn máy khách đều khó mở rộng để ứng phó.

Trước khi chuyển sang Habitat và Azure Cosmos DB, phần lớn dữ liệu trực tuyến của OpenAI được lưu trên Postgres. Khi đó, chúng tôi có thể dễ dàng xem xét mọi thay đổi về truy vấn và lược đồ để bảo đảm chúng hoạt động đúng mực trên dữ liệu đã lập chỉ mục trước khi đưa vào môi trường sản xuất. Khi đội ngũ và sản phẩm phát triển, việc này nhanh chóng trở nên không thể kiểm soát và thường xuyên gây sự cố: chỉ một truy vấn mới tốn kém trên đường xử lý trọng yếu cũng có thể đánh sập cơ sở dữ liệu.

Vấn đề nằm ở sự mất cân đối chi phí: viết các truy vấn SQL tốn kém và khó thực thi lại rất dễ dàng và ít tốn công. Trong Habitat, chúng tôi tránh điều này và giúp máy khách nhận biết ngay các truy vấn tốn kém. Không có truy vấn không giới hạn nào có thể làm Habitat quá tải; còn với phép nối phức tạp và duyệt đồ thị, đội ngũ sản phẩm phải tự đảm nhận một phần công việc nặng, qua đó thúc đẩy các thiết kế hiệu quả hơn về tổng thể.

Habitat cung cấp API NoSQL xoay quanh các kiểu đối tượng và cạnh do máy khách định nghĩa, lấy cảm hứng từ TAO⁠(mở trong cửa sổ mới). Máy khách định nghĩa trước các đối tượng, cạnh và mối quan hệ giữa các thành phần đó, nhưng không định nghĩa nội dung của từng kiểu. Các mối quan hệ tạo thành trông giống một đồ thị, nhưng bản thân Habitat không hỗ trợ truy vấn duyệt đồ thị thông thường, ngoại trừ truy vấn các cạnh trực tiếp của một đối tượng cụ thể.

Chúng tôi phân vùng đồ thị này để mỗi đối tượng và các cạnh tương ứng cùng nằm trong một phân vùng ở tầng lưu trữ, nhưng không chủ động bố trí ở tầng cơ sở dữ liệu để đối tượng nằm cùng các đối tượng từ xa mà cạnh của đối tượng đó trỏ đến. Nhờ đó, mô hình dễ phân vùng để mở rộng theo chiều ngang, nhưng việc duyệt đồ thị lại kém hiệu quả vì một bước bất kỳ giữa các đối tượng có thể phải truy xuất từ hai tài khoản Azure Cosmos DB hoàn toàn khác nhau, được lưu ở các khu vực khác nhau.

Với máy khách có nhu cầu truy vấn phức tạp hơn, chúng tôi cung cấp một dạng xem phụ ngoại tuyến của Habitat thông qua Rockset. Chúng tôi dùng tính năng thu thập dữ liệu thay đổi (CDC) để truyền trực tuyến các thay đổi từ hệ thống lưu trữ trực tuyến sang các phiên bản Rockset biệt lập với độ trễ gần thời gian thực. Mỗi đội ngũ máy khách chịu trách nhiệm mở rộng phiên bản Rockset của mình để đáp ứng nhu cầu truy vấn phức tạp.

Việc cấp phát Rockset tạo thêm trở ngại cho máy khách, nhưng ở thời điểm này, chúng tôi cho rằng đây là sự đánh đổi phù hợp: mặc định dùng truy vấn đơn giản, đồng thời chừa một lối thoát cho những trường hợp cần truy vấn phức tạp. Thiết kế này cô lập hệ thống lưu trữ trực tuyến khỏi các khối lượng công việc phân tích và tìm kiếm nặng về đọc.

Trì hoãn việc viết lại Python một năm giúp chúng tôi tập trung vào những thách thức cấp bách và có tác động lớn hơn trong giai đoạn tăng trưởng siêu tốc. Khi nền tảng đã trưởng thành, tốc độ tăng trưởng tiếp tục gia tăng, còn dịch vụ này đứng thứ hai tại OpenAI về số lõi và thứ tư về quy mô triển khai Envoy, cuối cùng đã đến lúc vượt ra khỏi Python. Ở thời kỳ đỉnh cao, Python giúp chúng tôi phục vụ hơn 20 triệu yêu cầu mỗi giây.

Trong quý 2 năm 2026, chỉ với 2 kỹ sư, Codex và GPT‑5.5, chúng tôi đã viết lại toàn bộ dịch vụ bằng Rust. Dịch vụ Rust mới hiện xử lý 95% yêu cầu sản xuất; chúng tôi sẽ ngừng hoàn toàn Python trong vài tuần tới. Dữ liệu cho thấy dịch vụ Rust sử dụng CPU hiệu quả gấp 6 lần và bộ nhớ hiệu quả gấp 15 lần phiên bản Python, đồng thời có độ trễ trung bình lẫn độ trễ đuôi thấp hơn đáng kể. Chúng tôi dự định chia sẻ thêm kinh nghiệm trong một bài blog sau.

Dịch vụ Python, và nay là Rust, chỉ là một khía cạnh của Habitat. Trong phần II của loạt bài giải thích cách chúng tôi nhanh chóng mở rộng hệ thống lưu trữ trực tuyến để phục vụ hơn 1 tỷ người dùng ChatGPT, chúng tôi sẽ nói về tầng lưu trữ và cách Habitat phục vụ hơn 500 petabyte dữ liệu cùng hơn 70 triệu yêu cầu mỗi giây.

Nếu muốn làm việc với các hệ thống OLTP ở quy mô tiên phong và quan tâm đến lĩnh vực kỹ thuật này, hãy xem vị trí đang tuyển trong đội ngũ của chúng tôi⁠.