How strategic database migration + data (re)modeling improved latencies and cut database costs 5X ZEE là doanh nghiệp truyền thông và giải trí lớn nhất Ấn Độ, bao gồm truyền hình phát sóng, phim ảnh, phương tiện truyền thông trực tuyến và âm nhạc. ZEE5 là dịch vụ phát trực tuyến OTT hàng đầu của họ, có sẵn ở hơn 190 quốc gia với ~150 triệu người dùng hoạt động hàng tháng. Các kỹ sư đằng sau hệ thống biết rằng sự phát triển kinh doanh tiếp tục sẽ nhấn mạnh cơ sở hạ tầng của họ (cũng như những người xem xét hóa đơn cơ sở dữ liệu). Vì vậy, nhóm đã quyết định suy nghĩ lại hệ thống trước khi nó gây ra bất kỳ cơn đau tim nào. TL;DR, họ đã thiết kế một hệ thống được yêu thích nội bộ và bởi người dùng. Và Jivesh Threja (Trưởng công nghệ) và Srinivas Shanmugam (Kiến trúc sư chính) đã tham gia cùng chúng tôi vào Ngày Valentine năm ngoái để chia sẻ kinh nghiệm của họ. Họ đã phác thảo các yêu cầu kỹ thuật cho việc thay thế (tính trung lập đám mây, khả năng sẵn sàng của nhiều người thuê, sự đơn giản của việc đưa các trường hợp sử dụng mới vào sử dụng, và công suất cao và độ trễ thấp với chi phí tối ưu) và làm thế nào điều đó dẫn đến ScyllaDB. Kết hợp lại, họ chia sẻ những bài học đã học được có thể mang lại lợi ích cho bất cứ ai xem xét hoặc sử dụng ScyllaDB. 5X cost savings (from $744K to $144K annually) and single-digit millisecond P99 read latency https://youtu.be/nArmqus9fbo?embedable=true Dưới đây là một số điểm nổi bật từ cuộc nói chuyện đó... Heartbeat là gì? "Heartbeat" đề cập đến một yêu cầu được phát vào khoảng thời gian thường xuyên trong quá trình phát lại video trên nền tảng ZEE5 OTT. Những yêu cầu đơn giản này theo dõi những gì người dùng đang xem và họ đã tiến bộ đến đâu trong mỗi video. Chúng rất cần thiết cho chức năng "tiếp tục xem" của ZEE5, cho phép người dùng tạm dừng nội dung trên một thiết bị sau đó tiếp tục nó trên bất kỳ thiết bị nào. Tại sao thay đổi? Hệ thống nhịp tim ban đầu của ZEE5 là một mạng lưới các cơ sở dữ liệu khác nhau, mỗi cơ sở xử lý một phần cụ thể của trải nghiệm phát trực tuyến.Mặc dù nó có chức năng về mặt kỹ thuật, phương pháp này tốn kém và khóa chúng vào một hệ sinh thái nhà cung cấp cụ thể. Họ muốn một hệ thống không bị khóa trong bất kỳ nhà cung cấp dịch vụ đám mây cụ thể nào, sẽ tốn kém hơn để vận hành và có thể xử lý quy mô khổng lồ của họ với hiệu suất nhanh nhất quán - cụ thể là phản ứng millisecond một chữ số.Thêm vào đó, họ muốn sự linh hoạt để thêm các tính năng mới một cách dễ dàng và khả năng cung cấp hệ thống của họ cho các nền tảng phát trực tuyến khác. Kiến trúc hệ thống, trước và sau Dưới đây là một cái nhìn về kiến trúc hệ thống ban đầu của họ với nhiều cơ sở dữ liệu: DynamoDB lưu trữ dữ liệu nhịp tim cơ bản Amazon RDS để lưu trữ thông tin tập tiếp theo và trước Apache Solr để lưu trữ dữ liệu siêu dữ liệu One Redis instance để cache metadata Một phiên bản Redis khác để lưu trữ chi tiết người xem Nhóm ZEE5 đã xem xét bốn lựa chọn cơ sở dữ liệu chính cho dự án này: Redis, Cassandra, Apache Ignite và ScyllaDB. Sau khi đánh giá và đánh giá so sánh, họ đã chọn ScyllaDB. Chúng tôi không cần thêm một lớp bộ nhớ cache trên cơ sở dữ liệu vĩnh viễn. ScyllaDB quản lý cả lớp bộ nhớ cache và cơ sở dữ liệu vĩnh viễn trong cùng một cơ sở hạ tầng, đảm bảo độ trễ thấp giữa các khu vực, sao chép và khả năng sẵn sàng đa đám mây. nó hoạt động với bất kỳ nhà cung cấp đám mây nào, bao gồm Azure, AWS và GCP, và bây giờ cung cấp hỗ trợ được quản lý với thời gian quay vòng ít hơn một giờ. Chúng tôi không cần thêm một lớp bộ nhớ cache trên cơ sở dữ liệu vĩnh viễn. ScyllaDB quản lý cả lớp bộ nhớ cache và cơ sở dữ liệu vĩnh viễn trong cùng một cơ sở hạ tầng, đảm bảo độ trễ thấp giữa các khu vực, sao chép và khả năng sẵn sàng đa đám mây. nó hoạt động với bất kỳ nhà cung cấp đám mây nào, bao gồm Azure, AWS và GCP, và bây giờ cung cấp hỗ trợ được quản lý với thời gian quay vòng ít hơn một giờ. Kiến trúc mới đơn giản hóa và làm phẳng cấu trúc kiến trúc hệ thống trước đó. Bây giờ, tất cả các sự kiện nhịp tim được đẩy vào chủ đề nhịp tim của họ, được xử lý thông qua xử lý luồng, và được hấp thụ vào ScyllaDB Cloud bằng cách sử dụng kết nối ScyllaDB. Bất cứ khi nào nội dung được xuất bản, nó được hấp thụ vào chủ đề siêu dữ liệu của họ và sau đó được chèn vào ScyllaDB Cloud thông qua kết nối siêu dữ liệu. Srinivas kết luận: “Với kiến trúc mới này, chúng tôi đã di chuyển thành công khối lượng công việc từ DynamoDB, RDS, Redis và Solr sang ScyllaDB. ” 5x cost reduction, bringing our monthly expenses down from $62,000 to around $12,000. Đi sâu vào thiết kế Next Jivesh chia sẻ thêm về thiết kế cấp thấp của họ... Real-Time Stream Processing Pipeline - Đường ống xử lý thời gian thực Trong đường ống xử lý dòng thời gian thực, nhịp tim được gửi đến ScyllaDB với khoảng thời gian thường xuyên. Tần số nhịp tim được đặt ở mức 60 giây, có nghĩa là mỗi client frontend gửi một nhịp tim mỗi 60 giây trong khi người dùng đang xem video. Những nhịp tim này đi qua hệ thống xử lý luồng phát lại, khách hàng logic kinh doanh chuyển đổi dữ liệu đó thành định dạng cần thiết – sau đó dữ liệu được xử lý được lưu trữ trong ScyllaDB. Lớp API Scalable Thành phần đầu tiên trong lớp API có thể mở rộng là dịch vụ Heartbeat, chịu trách nhiệm xử lý khối lượng dữ liệu lớn. Topics xử lý dữ liệu, sau đó nó đi qua một dịch vụ kết nối và được lưu trữ trong ScyllaDB. Một dịch vụ API nổi bật khác là dịch vụ Concurrent Viewership Count. dịch vụ này sử dụng ScyllaDB để lấy dữ liệu xem đồng thời – cho mỗi người dùng hoặc cho mỗi tài sản (ví dụ, cho mỗi ID). ví dụ, nếu một bộ phim được phát hành, dịch vụ này có thể cho biết có bao nhiêu người dùng đang xem bộ phim tại bất kỳ thời điểm nào. Quản lý Metadata Case Một trong những thách thức lớn đầu tiên mà ZEE5 phải đối mặt là quản lý siêu dữ liệu cho nền tảng OTT khổng lồ của họ. Ban đầu, họ dựa vào sự kết hợp của ba cơ sở dữ liệu khác nhau - Solr, Redis và Postgres - để xử lý nhu cầu siêu dữ liệu rộng lớn của họ. Dưới đây là một cái nhìn vào mô hình siêu dữ liệu của họ: create keyspace.meta_data ( id text, title text, show_id text, …, …, PRIMARY KEY((id),show_id) ) with compaction = {‘class’: ‘LeveledCompactionStrategy’ }; Trong mô hình này, ID phục vụ như là phím phân vùng. vì bảng này trải nghiệm tương đối ít chữ viết (một chữ viết chỉ xảy ra khi một tài sản mới được phát hành) nhưng đọc nhiều hơn đáng kể, họ đã sử dụng Chiến lược nén bằng cấp để tối ưu hóa hiệu suất. và, theo Jivesh, “Chọn phân vùng đúng và các phím nhóm đã giúp chúng tôi có được độ trễ millisecond một chữ số.” Viewership Count Sử dụng Case Viewership Count là một trường hợp sử dụng khác mà họ đã chuyển sang ScyllaDB. Viewership count có thể được theo dõi cho mỗi người dùng hoặc cho mỗi ID tài sản. ZEE5 quyết định thiết kế một bảng nơi ID người dùng phục vụ như phím phân vùng và ID tài sản như phím sắp xếp - cho phép dữ liệu viewership được truy vấn hiệu quả. Họ đặt TTL của ScyllaDB để khớp với khoảng nhịp tim 60 giây, đảm bảo rằng dữ liệu tự động hết hạn sau thời gian được chỉ định. Jivesh giải thích, “Bảng này được cập nhật liên tục với nhịp tim từ mỗi đầu và mỗi người dùng. Khi nhịp tim đến, số lượng người xem được theo dõi trong thời gian thực và tự động xóa khi TTL hết hạn. Dưới đây là mô hình số lượng người xem dữ liệu của họ: CREATE TABLE keyspace.USER_SESSION_STREAM ( USER_ID text, DEVICE_ID text, ASSET_ID text, TITLE text, …, PRIMARY KEY((USER_ID), ASSET_ID) ) WITH default_time_to_live = 60 and compaction = { 'class' : 'TimeWindowCompactionStrategy' }; ScyllaDB Kết quả và bài học học Báo cáo kiểm tra tải sau đây cho thấy lượng truy cập là 41.7K yêu cầu mỗi giây. tiêu chuẩn này được thực hiện trong quá trình lựa chọn cơ sở dữ liệu để đánh giá hiệu suất dưới tải cao. Jivesh nhận xét, “Ngay cả với công suất cao như vậy, chúng tôi có thể đạt được độ trễ viết microsecond và độ trễ đọc trung bình microsecond. Sau đó, ông tiếp tục chia sẻ một số sự kiện làm sáng tỏ quy mô triển khai ScyllaDB của ZEE5: “Chúng tôi có khoảng 9TB trên ScyllaDB. Ngay cả với khối lượng dữ liệu lớn như vậy, nó có thể xử lý độ trễ trong microseconds và một milisecond chữ số duy nhất, đó là khá lớn. Mỗi giây, chúng ta đang viết rất nhiều dữ liệu vào ScyllaDB và lấy rất nhiều dữ liệu ra khỏi nó Chúng ta xử lý hơn 100 tỷ nhịp tim trong một ngày. đó là khá lớn.” Cuộc nói chuyện kết thúc với những bài học sau: Mô hình dữ liệu là yếu tố quan trọng nhất trong việc đạt được độ trễ millisecond đơn số. Chọn đúng cài đặt quorum và chiến lược nén. Ví dụ, một nhịp tim cần phải được viết cho mỗi nút trước khi nó có thể được đọc, hoặc là một quorum địa phương là đủ? Chọn đúng quorum đảm bảo sự cân bằng tốt nhất giữa độ trễ và yêu cầu SLA. Chọn Partition và Clustering Keys một cách khôn ngoan – không dễ dàng để sửa đổi chúng sau này. Sử dụng View Materialized để tìm kiếm nhanh hơn và tránh các truy vấn lọc. Sử dụng các tuyên bố đã chuẩn bị để cải thiện hiệu quả. Ví dụ, trong mô hình siêu dữ liệu, 20 truy vấn đồng bộ được thực hiện song song, và ScyllaDB xử lý chúng trong milliseconds. Khách hàng ScyllaDB nhận thức vùng giúp giảm chi phí mạng cross-AZ (Availability Zone). thu thập dữ liệu trong cùng một AZ giảm thiểu độ trễ và giảm đáng kể chi phí mạng.
