Dược anh Thuat-Paven Do tagged trong bài viết, nên mình xin phép được trả lời theo hiểu biết và chia sẻ luôn với mọi người)
(Mọi bài viết của mình liên quan đến số liệu đều có dẫn nguồn từ tạp chí uy tín, nhưng bài viết này xin được viết nhanh dựa theo kinh nghiệm)
Đầu tiên, mình xin được nói trước mình không tìm hiểu “Sol” nhưng mình sẽ làm rõ khái niệm liên quan đến DB hay là Distributed DB theo mình nghĩ là có liên quan đến đến sự cố sập mạng.
Tiếp theo, mình xin đưa ra một vài thông tin.
a) Hiểu về transaction và TPS.
Transaction được dịch ra là giao dịch: Trong cơ sở dữ liệu, nếu ai học IT đều biết SQL server và các câu lệnh SQL query: Select, Update, Insert, Delete… và mỗi câu lệnh này được gọi là transaction.
Trong blockchain chỉ nói đến transaction trong Insert và Select.
b.Thời gian thực hiện 1 transaction phụ thuộc vào đâu
-
Phụ thuộc vào các thuật toán lập lịch trình (scheduling algorithm).
Ví dụ: Thời gian thực hiện 1 câu lệnh select/Insert (tức là 1 giao dịch trong DB) là 0.001 giây. Nghe thì đơn giản, nhưng cậu lệnh select/Insert sẽ phải làm gì?
-
với select tìm dữ liệu để select : liên quan đến thuật toán tìm kiếm.
-
với insert cũng vậy, với blockchain thì dễ hơn DB, vì blockchain thì insert sẽ luôn là insert trên đỉnh.
-
Nhưng quá trình insert sẽ phải mất thời gian cho việc tạm dừng block để insert. cơ chế làm việc trên máy tính hiện nay khi muốn thêm dữ liệu là phải khóa file để thêm. Hiểu đơn giản bạn có thể thấy là khi bạn mở file word hay text bạn không thể xóa file đó trên ổ cứng bởi đơn giản nó đang bị khóa lại cho công việc sửa hay thêm dữ liệu.
-
Vậy với quá trình insert này bạn phải có thuật toán lập lịch trình để tối ưu thời gian khóa file để cập nhật và thêm dữ liệu.
-
Với ví dụ trên, tìm 1 dữ liệu có thể hên xui lên TPS có thể lúc nhanh, lúc chậm, nhưng khi tìm 1000 dữ liệu, hay 10000 dữ liệu 1 lúc thì lúc đó mới có thể đánh giá chính xác TPS được, cũng như đánh giá được chính xác độ hiểu quả các thuật toán.
Tóm lại, để có TPS tốt thì phải có những thuật toán tối ưu truy vấn và thêm dữ liệu tốt.
2. Phụ thuộc vào độ mạnh của phần cứng.
Như vậy chúng ta đều biết là phải có thuật toán tối ưu truy vấn và thêm dữ liệu tốt thì TPS mới tốt. Nhưng bên cạnh đó thuật toán tốt phải chạy được trên thiết bị có khả năng tính toán tốt thì nó còn tốt hơn nữa. Bởi vậy độ mạnh tính toán của thiết bị rất quan trọng.
Chúng ta đều biết HDD chậm rì rì.. rồi chúng ta có SSD. Chúng ta thấy máy chạy nhanh hơn ko? có nhanh hơn. Vậy trên SSD là gì, là RAM, là CPU. Vậy sao không làm Database trên RAM hay CPU. CPU thì quá đắt và dung lượng quá nhỏ. Nhưng DB trên RAM đã được nghiên cứu từ 198x và 9x có thể sớm hơn rồi. Chỉ có điều rất ít người Việt quan tâm đến cái này. gọi là In memory Database.
(Không phải 1 dạng cache dữ liệu nhé) bây giờ cũng có rất nhiều In memory DB được phát triển bởi nhiều hãng khác nhau rồi. Hiện tại tùy vào công việc mà người ta lựa chọn các In memory DB khác nhau.
Tóm lại là có độ mạnh của phần cứng, thì phải xác định công việc cụ thể, cái muốn làm để từ đó phát triển ra In memory DB tối ưu cho công việc.
Ngoài lề: Các in memory DB đang được sử dụng như một biện pháp lưu trữ tạm thời cho các công việc đòi hỏi tính toán nhanh, bởi như chúng ta đã biết RAM sẽ mất dữ liệu sau khi khởi động. Bài này sẽ được viết chi tiết hơn nếu mọi người quan tâm.
3. Bên cạnh sức mạnh về phần cứng DB thì phải nói đến tốc độ mạng, tốc độ đường truyền. nó là phần rất quan trọng trong phần 4.
4. Các thuật toán đồng bộ (consensus) giữa các node. – cái này thì chắc nhiều người biết rồi.
Tuy nhiên, hiện tượng dead locked consensus (với khối lượng giao dịch đủ lớn) đang làm đau đầu rất nhiều hệ thống hiện tại. Chúng ta là con người đôi khi gọi điện cho nhau để truyền tải thông tin mà thông tin còn bị sai (còn tệ hơn máy móc là chỉ bị tắc thông tin). Bởi vậy, mình đã từng nghĩ đến sub consensus trong main consensus dựa vào inmemory db và scheduling cho blockchain năm 2018 – năm đó mình cũng mang ý tưởng này đi thi hackathon blockchain ở thượng hải và được giải nhì – không biết giờ có ai làm chưa. Vì mình cũng ít đẻ ý blockchain từ 2018 đến nay.
c. Vậy sập mạng là do đâu?
1. Tối ưu truy vấn, tối ưu insert đủ tốt chưa? Đã test thử trên 1 dataset chuẩn nào chưa?
2. Xác định rõ làm gì tốt đế nó tốt nhất hơn là xác định làm nhiều thứ tốt vừa vừa. Các công ty như Alibaba có hệ thống In memory DB riêng của họ, có thuật toán riêng của họ, và DB đó xác định cho công việc bán hàng. Công ty Bloomberg cũng có Inmemory DB riêng và xác định cho việc thống kê và lựa chọn tin tức tài chính…. Bởi thế có những sản phẩm blockchain mình thấy nó cái gì cũng làm, nhưng rồi đến cuối cùng lại chẳng thấy nó làm được gì “ra hồn”.
3. Có sử dụng In memory (RAM) để tối ưu hóa công việc chưa?
4. Thuật toán consensus dù tốt tới đâu chắc chắn cũng có lúc bị deadlock. con đường dù rộng đến đâu thì với số lượng xe đủ lớn thì vẫn bị tắc. Nhưng quan trọng là thuật toán “phụ” phải lập lịch thế nào để cái thuật toán chính hiểu được. Đơn giản như sẽ chia ra các node đồng bộ với nhau như thế nào. trong khi node A,B trao đổi thì các node khác làm gì…
5. DB intelligent: Nghĩa là làm sản phẩm kết nối trực tiếp với DB luôn. Mình đã từng học rằng TPS trên SQL server có thể là con số “alpha” nhưng khi dùng C# hay các ngôn ngữ khác chúng ta đều phải dùng các “giao thức có sẵn” kiểu SQLconnection, hay DBconnection hay là SQLAdapter.. thì khi đó cái TPS nó không phải là “alpha” nữa mà là “alpha”/2 hoặc alpha/3.
6. Hạ tầng network đủ tốt chưa?
Đôi khi 1 cái node “quá nghèo” trong cả khu phố “khá giả” có thể đưa cả cái khu phố đó “nghèo” đi.
Chủ đề này khá dài, và mình nghĩ bài viết này là “quá ngắn” so với kiến thức liên quan. Tuy nhiên cũng là một vài chia sẻ hi vọng có ích cho mọi người, và các bạn muốn làm “hạ tầng”.
Mình cũng đã từng có lúc “cái gì cũng muốn làm” rồi làm cái gì cũng chẳng hơn được người khác. Bởi thế vẫn “nghèo” ^^.
Author: Tô Hải Thiên (VBI)
