Twitter đại diện cho thời kỳ đầu Web3

spot_imgspot_img

Hôm 14/11, Elon Musk xin lỗi vì Twitter đã tạo hơn 1.000 RPC để hiển thị dòng thời gian trên trang chủ của người dùng. Twitter đang phục vụ hơn 260 triệu người dùng hàng tháng làm cho bài toán giải quyết về RPC vô cùng lớn. Để giải quyết việc áp dụng hàng loạt với độ trễ dưới giây, Twitter đi tiên phong trong một số giải pháp, bao gồm Apache Storm, Heron, DistributedLog và Aurora.

Câu hỏi đặt ra là tại sao một công ty sáng tạo toàn cầu như Twitter lại yêu cầu quá nhiều dữ liệu trên dòng thời gian của người dùng?

Không chỉ riêng Twitter, các nhà phát triển Web3 đang phải gọi liên tục nhiều API để lấy dữ liệu hình thành logic dựa trên thói quen người dùng. Điều này dẫn đến hiệu suất không đáng tin cậy và không thể đoán trước, ngay cả đối với các trường hợp sử dụng đơn giản nhất, chẳng hạn như tìm nạp lịch sử giao dịch của người dùng.

Đổi lại, khối lượng giao dịch của mười blockchain hàng đầu tăng mạnh trong thời gian qua, chúng được thể hiện qua hình sau đây:

So sánh các tweet và QPS của lưu lượng ghi sớm của 10 chuỗi hàng đầu trong Web3

Biểu đồ so sánh giữa số lượng tweet mỗi giây (2006-2013, màu xanh lam) và số lượng giao dịch Web3 mỗi giây (2017-2022, màu đỏ), không bao gồm các giao dịch bằng phần mềm. Nếu Web3 tiếp tục trên quỹ đạo, hầu hết các giải pháp cơ sở hạ tầng dữ liệu Web3 ngày nay sẽ không thể xử lý sự tăng trưởng.

Chúng ta hãy cùng xem Web3 có thể học được những gì từ giải pháp mở rộng quy mô của Twitter, cụ thể như sau:

  • Dựa trên hành trình cơ sở hạ tầng dòng thời gian của Twitter, kiến ​​trúc hiện tại phù hợp với các trường hợp sử dụng cụ thể và kết luận rằng một số lời chỉ trích có thể không đúng chỗ, chẳng hạn như lời xin lỗi của Musk khi “làm phiền” dòng thời gian của người dùng.
  • Một số điểm tương đồng về kỹ thuật giữa Twitter và Web3 và khám phá cách các giải pháp của trang web trước có thể mang lại lợi ích cho trang web sau.
  • Xu hướng phát triển của Web3 và việc thiếu các giải pháp cơ sở hạ tầng dữ liệu hiệu suất cao hiện có và kết luận rằng cần phải nâng cấp lớn nếu các nhà phát triển muốn hỗ trợ truy cập dữ liệu Web3 theo thời gian thực.

Hành trình cơ sở hạ tầng dữ liệu của Twitter

Trước đây, Twitter sử dụng kiến trúc vanilla MySQL, nhưng nó không còn phù hợp từ khi số lượng tweet tăng gấp 10 lần mỗi năm trong những năm đầu tiên. Từ năm 2007 đến 2012, số người dùng hoạt động hàng tháng của Twitter đã tăng từ vài nghìn người lên hơn 138 triệu. Kiến thức đã biết về các lát cắt ngang và dọc không thể xử lý hiệu suất lưu lượng truy cập cao cho Twitter, đặc biệt là khi hiển thị dòng thời gian của trang chủ.

Dòng thời gian là một trong những tính năng nền tảng chính của Twitter. Nhìn chung, dòng thời gian của Twitter có 2 thao tác chính như sau:

  1. Đường dẫn viết: Đường dẫn này được sử dụng để người dùng đăng tweet. Vào năm 2012, Twitter đã xử lý trung bình 46.000 yêu cầu viết mỗi giây và 12.000 RPS trong giờ cao điểm.
  2. Đường dẫn đọc: Đường dẫn này được sử dụng để người dùng yêu cầu dòng thời gian của họ. Vào năm 2012, Twitter đã xử lý khoảng 300.000 yêu cầu đọc mỗi giây.

Quy trình hiển thị của Twitter biểu thị trong hình dưới đây, khi một người dùng đăng một tweet thì Twitter sẽ ghi nó vào Manhattan, một cơ sở dữ liệu khóa giá trị phân tán lưu trữ các tweet của người dùng, tin nhắn trực tiếp, chi tiết tài khoản và nhiều thứ khác.

Tweet được truyền tải đến tất cả những người theo dõi của người dùng trong bộ đệm dòng thời gian. Mặc dù điều này làm tăng mức khuếch đại ghi từ 4,6 nghìn yêu cầu mỗi giây lên 345 nghìn yêu cầu mỗi giây, nhưng nó cũng giúp giảm đáng kể độ trễ. Vì vậy, thay vì thực hiện một bảng tham gia giữa những người theo dõi và các tweet, kết xuất dòng thời gian sẽ lấy các tweet từ một bảng duy nhất trong bộ đệm. Các hoạt động này thường hoàn thành trong vòng chưa đầy 5 giây. Bằng cách phân phối dữ liệu đang được ghi, hệ thống có thể tránh tăng trưởng quá mức bằng cách loại bỏ các phép nối bảng. Do đó, độ trễ đọc được cải thiện lên hàng trăm mili giây.

Sơ đồ dòng thời gian của Twitter

Đây là áp dụng cho người dùng thông thường, vậy đối với những người nổi tiếng thì sao? Họ có hàng triệu đến hàng chục triệu người theo dõi, thì Twitter cần phóng đại hệ số hơn nữa. Twitter từng phải thiết kế phần máy chủ riêng cho Justin Bieber bởi độ phổ biến của nam ca sĩ, Twitter buộc phải áp dụng dịch vụ đặc biệt có tên Earlybird. Trong Earlybird, người dùng siêu trung tâm và người dùng bình thường nhận được các tweet khác nhau tương ứng. Quá trình này được minh họa như sau:

Dòng thời gian hỗn hợp người dùng Twitter được mô tả ở bên trái và SQL đã đọc tương ứng được mô tả ở bên phải

Điều này hoàn toàn phù hợp với số lượng RPC cho một lần hiển thị dòng thời gian. Khi có hơn 100 tweet khi người dùng lướt, cần hơn 1.000 lệnh gọi RPC, bởi vì việc tìm nạp tweet yêu cầu rất nhiều lệnh gọi RPC. Do đó, Twitter phải đánh đổi có chủ đích để cung cấp cho người dùng hiệu suất đọc thông tin tối ưu.

Twitter đã đạt được đến độ 99% độ trễ chỉ trong khoảng vài mili giây. Mạng xã hội này liên tục phát triển trong 10 năm qua, cơ sở hạ tầng đáng tin cậy và có thể xử lý tốc độ tăng trưởng cao của lưu lượng truy cập Twitter.

>> Đọc thêm: Liệu Twitter do Elon Musk lãnh đạo có trở thành một nền tảng Web3?

Web3 và Twitter có điểm tương đồng nào?

Điểm tương đồng giữa dữ liệu Twitter và Web3

Những điểm tương đồng giữa hệ sinh thái Web3 và Twitter dễ nhận thấy như:

  1. Web3 là một biểu đồ xã hội, các tweet tương tự như giao dịch và phản hồi tương tự như nhật ký. Hình bên trênmô tả điều này, kết xuất dòng thời gian tuần tự và các khối chuỗi khối tuần tự được so sánh.
  2. Các giao thức Web3 và Twitter có hiệu ứng siêu trung tâm. Khối lượng giao dịch của nền tảng NFT phổ biến nhất gấp 1000 lần so với nền tảng thứ 10.
  3. Cả Web3 và Twitter đều là nền tảng mở, hiển thị cho tất cả người dùng và cho phép truy cập API nhất định.

Nếu chúng ta phân tích kỹ hơn, những điểm tương đồng trong các kiểu truy cập dữ liệu giữa Twitter và Web3:

  1. Lượng đọc nhiều nhưng mỗi bản ghi lại ít. Trên chuỗi EVM, kích thước trung bình của nhật ký và giao dịch chỉ là vài KB.
  2. Dữ liệu mới nhất sẽ được xem thường xuyên hơn, hầu hết là từ vài giờ đầu tiên sau khi xuất bản.
  3. Dữ liệu là bất biến trong một thời gian ngắn. Dữ liệu trên chuỗi có thể được khôi phục 000org. Tương tự như vậy, giờ đây người dùng có thể chỉnh sửa các tweet trong một khoảng thời gian sau khi đăng chúng.

Web3 có thể tận dụng kiến trúc của Twitter không?

Hiện tại, cơ sở hạ tầng dữ liệu Web3 tương tự những ngày đầu của Twitter vào khoảng năm 2008, khi hầu hết lưu lượng truy cập dựa vào cơ sở dữ liệu được phân chia theo chiều ngang từ các nhà cung cấp khác nhau. Do đó, khi Web3 tiếp tục phát triển, cơ sở hạ tầng dữ liệu Web3 hiện tại sẽ khó cung cấp khả năng truy cập dữ liệu hiệu suất cao.

Các ứng dụng Web3 chạy theo hiện trạng đang thiếu một thành phần quan trọng để tổng hợp dữ liệu liên quan một cách hiệu quả. Cụ thể, các nhà phát triển phải gọi từng API để lấy dữ liệu. Ngay cả đối với các trường hợp sử dụng đơn giản nhất, chẳng hạn như tìm nạp lịch sử giao dịch của người dùng (hình dưới), điều này dẫn đến hiệu suất không đáng tin cậy và không thể đoán trước.

Các ứng dụng Web3 cần liên tục gọi nhiều API khác nhau

>> Đọc thêm: Tại sao Web3 cần một layer dữ liệu riêng biệt

Bài viết liên quan

GỬI PHẢN HỒI

Vui lòng để lại bình luận!
Vui lòng nhập tên của bạn ở đây

Đọc nhiều nhất

spot_img

Subscribe

- Never miss a story with notifications

- Gain full access to our premium content

- Browse free from up to 5 devices at once