Hai thập kỷ vừa qua chứng kiến sự phát triển mạnh mẽ của công nghệ lưu trữ đĩa cứng, bắt đầu từ sự ra đời của SSD, thay đổi cổng kết nối từ SATA sang PCIe, và gần đây là công nghệ bộ nhớ non-volatile và các quy trình sản xuất. Với những tiến bộ trên, độ trễ trong việc truy xuất dữ liệu từ đĩa cứng đã giảm đáng kể so với trước đây.

Tuy nhiên, các hệ thống phần mềm hiện nay có vẻ vẫn chưa bắt kịp tốc độ phát triển này. Nhiều nghiên cứu cho thấy vẫn còn tồn tại nhiều điểm nghẽn khiến cho các phần mềm ở tầng ứng dụng chưa tận dụng được những tiến bộ của phần cứng. Một số điểm nghẽn thường gặp là cách tổ chức file system chưa được tối ưu hoá, và cách truy xuất dữ liệu của hệ điều hành.

Để cải thiện vấn đề này, các kỹ sư của MongoDB đã nghiên cứu giải pháp sử dụng memory-mapped files cho I/O và kỹ thuật cấp phát trước một vùng trống cho file.

Về cơ bản, memory-mapped files giúp giảm chi phí phát sinh từ system call bằng cách sử dụng Translation Lookaside Buffer (TLB là một bộ đệm dữ liệu nằm trong MMU của CPU được dùng để lưu dữ liệu ánh xạ địa chỉ vùng nhớ ảo sang địa chỉ vùng nhớ vật lý). Tuy nhiên phương án này chỉ hiệu quả khi truy cập một file có dung lượng cố định. Về sau, đội ngũ của MongoDB đã đưa ra một phương pháp giúp xử lý các thao tác liên quan đến file system theo khối, để tối ưu chi phí xử lý phát sinh.

Các thay đổi này đã giúp read throughput của storage engine tăng lên 63%, tuy nhiên trong một số trường hợp, xử lý liên quan đến việc ghi (như update và insert) tỏ ra kém hiệu quả hơn.

Mời các bạn tham khảo chi tiết giải pháp và cách thực hiện qua bài viết gốc dưới đây.

Trong những năm gần đây, các vụ rò rỉ dữ liệu trên cloud xảy ra ngày càng nhiều, với tính chất phức tạp và công phu hơn trước. Hiện tại trên thị trường có khá nhiều giải pháp giúp tìm kiếm và khắc phục các lỗ hổng an ninh, tuy nhiên các giải pháp này khó có thể đáp ứng được mọi trường hợp và nhu cầu đa dạng của nhiều hệ thống khác nhau.

Vào năm 2020, đội ngũ kỹ sư Netflix đã quyết định tự xây dựng hệ thống riêng để tìm kiếm và khắc phục các lỗ hổng an ninh, với tên gọi Snare. Snare sử dụng nhiều nguồn dữ liệu khác nhau như AWS Security Hub, AWS Config Rules, và các nguồn nội bộ để tìm kiếm lỗ hổng và lỗi. Tương tự những hệ thống an ninh khác, Snare được chia thành bốn giai đoạn: Detection, Enrichment, Reporting & Management, và Remediation. Trong bài viết sau, đội ngũ kỹ sư Netflix mô tả cách họ xây dựng và thiết kế từng giai đoạn của Snare sao cho phù hợp với mô hình hệ thống ở Netflix.

Để ra mắt tính năng quảng cáo trên UberEats, đội ngũ kỹ sư Uber phải giải quyết các bài toán liên quan đến ngành quảng cáo như hệ thống đấu giá, phân bổ hay tổng hợp báo cáo doanh thu. Để làm được điều này, đội kỹ sư Uber xác định việc đầu tiên và quan trọng nhất là xây dựng hệ thống xử lý exactly-once events với độ trễ “near real-time”.

Hiểu một cách đơn giản, mỗi quảng cáo được hiển thị sẽ có event tương ứng cho mỗi hành động của người dùng, như impression hay click. Nhiệm vụ của hệ thống là tổng hợp, phân bổ và quản lý các event do người dùng tạo ra khi tương tác với quảng cáo trên ứng dụng Uber.

Để đạt tính chính xác tuyệt đối (100%) theo quy định về xử lý dữ liệu liên quan đến hoạt động quảng cáo của Uber, đội kỹ sư tại đây đã thiết kế một mô hình kiến ​​trúc dựa trên 4 công nghệ mã nguồn mở: Stream Processing với Apache Flink, Message Queues với Apache Kafka, Real-Time Analytics với Apache Pinot và Data Warehousing với Apache Hive.

Việc xây dựng hệ thống nhằm xử lý exactly-once events được chia thành nhiều module nhỏ, tối ưu về mặt vận hành và chức năng như Data Cleansing, Aggregation, Record UUID Generation. Hiện tại, hệ thống này đang xử lý hàng trăm triệu event quảng cáo mỗi tuần, và con số này vẫn còn tiếp tục gia tăng.

Để tìm hiểu thêm về thách thức, lý do cũng như quá trình xây dựng hệ thống này, mời bạn đọc bài viết bên dưới.