Nhiều dự án ban đầu phản ứng không rõ ràng trong vài tháng đầu, vấn đề thực sự thường chỉ lộ diện sau 6-12 tháng.
Nguyên nhân thực ra rất đơn giản. Dữ liệu hành vi người dùng, ghi chú trạng thái, nhật ký, những thứ này mỗi ngày chỉ tăng vài chục KB, nhưng tích lũy qua một năm thì đã lên tới 10-30GB. Lưu trữ phi tập trung truyền thống bắt đầu trở nên bị động ở giai đoạn này — mỗi lần cập nhật đều phải ghi lại toàn bộ, các phiên bản lịch sử liên tục chất đống, mối quan hệ tham chiếu ngày càng rối rắm.
Thay đổi cách nghĩ thì sao? Hãy xem "cộng dồn lâu dài" như một điều kiện tiên quyết cần phải xem xét từ đầu. Danh tính và tham chiếu của đối tượng giữ cố định, nhưng trạng thái có thể liên tục tiến triển, thay vì mỗi năm tạo ra một đợt đối tượng mới. Lợi ích của thiết kế này là gì?
Theo dữ liệu công khai, các giao thức như Walrus thể hiện rõ ràng điều này: một đối tượng hỗ trợ quy mô dữ liệu ở mức MB, cùng một đối tượng có thể cập nhật trạng thái nhiều lần mà không cần thay đổi mối quan hệ tham chiếu, dữ liệu được lưu trữ dư thừa giữa nhiều nút, độ khả dụng ổn định trên 99%.
Hãy đánh giá thực tế: khi quy mô dữ liệu bước vào giai đoạn "tăng trưởng dựa trên thời gian", ý nghĩa của kiến trúc này có thể quan trọng hơn việc theo đuổi chi phí thấp. Tuy nhiên, điều kiện tiên quyết là quy mô các nút mạng có thể mở rộng phù hợp, nếu không thì lượng dữ liệu lịch sử tích tụ sẽ trở thành nguồn áp lực cho hệ thống.
Xem bản gốc
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
16 thích
Phần thưởng
16
6
Đăng lại
Retweed
Bình luận
0/400
zkNoob
· 15phút trước
Haha, đây chính là sự thật về việc kéo giá xuống, ban đầu thấy không có gì sau đó bùng nổ
Xem bản gốcTrả lời0
MEVHunterNoLoss
· 01-07 19:57
Một năm 10-30GB dữ liệu thực sự là quá lớn, hầu hết các dự án đều không nghĩ tới chuyện này
Xem bản gốcTrả lời0
NullWhisperer
· 01-07 19:53
Ừ thì, độ trễ 6-12 tháng thực sự là điểm báo... hầu hết các đội chỉ không kiểm tra thử nghiệm quy mô lớn cho đến khi quá muộn thật sự thôi.
Xem bản gốcTrả lời0
YieldWhisperer
· 01-07 19:50
Hà, lại là cái kiểu "sau nửa năm mới phát hiện lỗi" đó rồi
Xem bản gốcTrả lời0
DaoTherapy
· 01-07 19:47
Có vẻ thú vị, cuối cùng cũng có người chạm đúng điểm đau. 6 tháng không thể thấy gì, một năm sau sẽ sụp đổ ngay lập tức, kiểu này đã gặp quá nhiều rồi.
Xem bản gốcTrả lời0
ApeWithAPlan
· 01-07 19:45
Cuối cùng đã có người nói đúng trọng tâm, hầu hết các dự án đều chết ở đây
Nhiều dự án ban đầu phản ứng không rõ ràng trong vài tháng đầu, vấn đề thực sự thường chỉ lộ diện sau 6-12 tháng.
Nguyên nhân thực ra rất đơn giản. Dữ liệu hành vi người dùng, ghi chú trạng thái, nhật ký, những thứ này mỗi ngày chỉ tăng vài chục KB, nhưng tích lũy qua một năm thì đã lên tới 10-30GB. Lưu trữ phi tập trung truyền thống bắt đầu trở nên bị động ở giai đoạn này — mỗi lần cập nhật đều phải ghi lại toàn bộ, các phiên bản lịch sử liên tục chất đống, mối quan hệ tham chiếu ngày càng rối rắm.
Thay đổi cách nghĩ thì sao? Hãy xem "cộng dồn lâu dài" như một điều kiện tiên quyết cần phải xem xét từ đầu. Danh tính và tham chiếu của đối tượng giữ cố định, nhưng trạng thái có thể liên tục tiến triển, thay vì mỗi năm tạo ra một đợt đối tượng mới. Lợi ích của thiết kế này là gì?
Theo dữ liệu công khai, các giao thức như Walrus thể hiện rõ ràng điều này: một đối tượng hỗ trợ quy mô dữ liệu ở mức MB, cùng một đối tượng có thể cập nhật trạng thái nhiều lần mà không cần thay đổi mối quan hệ tham chiếu, dữ liệu được lưu trữ dư thừa giữa nhiều nút, độ khả dụng ổn định trên 99%.
Hãy đánh giá thực tế: khi quy mô dữ liệu bước vào giai đoạn "tăng trưởng dựa trên thời gian", ý nghĩa của kiến trúc này có thể quan trọng hơn việc theo đuổi chi phí thấp. Tuy nhiên, điều kiện tiên quyết là quy mô các nút mạng có thể mở rộng phù hợp, nếu không thì lượng dữ liệu lịch sử tích tụ sẽ trở thành nguồn áp lực cho hệ thống.