thảo luận API lấy dữ liệu giao dịch lớn (hàng triệu row) liệu có đảm bảo không?

Chào các bác, như tiêu đề em có một thắc mắc là liệu việc cung cấp API cho đối tác query vào lấy lịch sử GD (số lượng lớn) thì có vấn đề gì không?
API bọn em đang sử dụng đồng thời cả Rest và Soap, câu lệnh query đảm bảo nhanh. Em chỉ băn khoăn về mặt hiệu năng, số lượng bản ghi GD lớn thì có ảnh hường gì không ạ. Nhờ mọi người cho em xin lời khuyên với.
Hiện tại bọn em đang cung cấp cho đối tác rồi, lấy GD trong vòng 1 tháng, dữ liệu vài triệu rows và vẫn đang hoạt động ổn ạ.

Cái này tuỳ vào nhiều yếu tố, tốt nhất hỏi cái đứa nào chịu trách nhiệm về hệ thống ấy. Hỏi vOz thì

Vipluckystar said:

Cái này tuỳ vào nhiều yếu tố, tốt nhất hỏi cái đứa nào chịu trách nhiệm về hệ thống ấy. Hỏi vOz thì

Click to expand...

thực ra trên đây nhiều bác level chuyên gia và có nhiều kinh nghiệm thực chiến mà
Nên em vẫn hi vọng được mọi người cho ý kiến thì yên tâm sử dụng hơn ạ.

nguyenmanhdcn said:

thực ra trên đây nhiều bác level chuyên gia và có nhiều kinh nghiệm thực chiến mà
Nên em vẫn hi vọng được mọi người cho ý kiến thì yên tâm sử dụng hơn ạ.

Click to expand...

Thím đưa thông tin chung chung vậy thì bó tay
Ví dụ cái server 1GB RAM với cái 2GB RAM nó đã khác nhau rồi.
Rồi client request 1 tiếng 1 triệu lần hay 1 phút 1 triệu lần nó cũng khác nhau.
Hay đơn giản là cấu hình của server thím cho query không giới hạn hay cần authenticate, giới hạn thời gian giữa mỗi query.
Trả về 1 kq hay 1 triệu kq, pagination...

Em thì thích chạy batch job, 1 ngày export ra 1 cái db cho ông khách 1 lần

Love U So Much said:

Em thì thích chạy batch job, 1 ngày export ra 1 cái db cho ông khách 1 lần

Click to expand...

em cũng thích xài cách này. Theo em thấy các đối tác em từng làm thì thường chốt giải pháp đối soát như này. 2 bên đều export ra file định dạng text đẩy lên FTP, các bên vào lấy r tự import vào DB r xử lý. Nhưng cách kia em thấy cũng được nên hỏi xem có ổn không ấy.

Cái này bên bạn phải bench rồi tự định nghĩa các tiêu chí "đảm bảo" trước rồi mới phân tích tiếp được.

Ví dụ bên bạn cấp cho đối tác 3 API: A, B, C.
Bạn đo được như sau:
A, query hết 1s, tốn 5% CPU, tốn 50MB RAM
B, query hết 1.5s, tốn 8% CPU, tốn 70MB RAM
C, query hết 1.8s, tốn 10% CPU, tốn 90MB RAM

Từ đó bạn ước lượng được tài nguyên tối đa có thể đáp ứng. Giả thiết là bên đối tác query quá nhiều và liên tục (nguyên nhân do họ cố ý, có lỗi lập trình...) thì khi đó mới tính đến các phương án xử lý như:
1. Đặt rate limiting theo giây, phút, giờ...
2. Cho query kiểu async, gửi request trước, nhận kết quả qua webhook sau
3. Đối tác request manually, mình gửi report sau
...

Nếu mà thấy chả tốn kém tài nguyên bao nhiêu thì kệ cho tẹt ga đi. Mà thực tế thì ít nhất nên đặt thêm cái rate limiting để tránh trường hợp bên kia nó lỗi gì đó nó vô tình DoS mình

nguyenmanhdcn said:

em cũng thích xài cách này. Theo em thấy các đối tác em từng làm thì thường chốt giải pháp đối soát như này. 2 bên đều export ra file định dạng text đẩy lên FTP, các bên vào lấy r tự import vào DB r xử lý. Nhưng cách kia em thấy cũng được nên hỏi xem có ổn không ấy.

Click to expand...

Làm thế là để tránh sync call, nó gọi nhiều lần trong ngày hoặc nhiều khách gọi cùng lúc. Hoặc nó gọi lúc lỗi mạng thì mất công support

Vipluckystar said:

Thím đưa thông tin chung chung vậy thì bó tay

Ví dụ cái server 1GB RAM với cái 2GB RAM nó đã khác nhau rồi.
Rồi client request 1 tiếng 1 triệu lần hay 1 phút 1 triệu lần nó cũng khác nhau.
Hay đơn giản là cấu hình của server thím cho query không giới hạn hay cần authenticate, giới hạn thời gian giữa mỗi query.
Trả về 1 kq hay 1 triệu kq, pagination...

Click to expand...

À server bọn em thì đang là 8GB với triển khai LB với 2 server farm, mỗi bên 2 nodes.
Query thường 1 ngày/1-2 lần /1 đối tác. Giả sử cao nhất 50 đối tác thì cũng k nhiều. 50 request 1 ngày vào thời điểm đầu ngày. Trả về GD trong 1 ngày có thể lên tới 1 triệu GD.
Có thể có đối tác query 1 lần lấy ra GD trong 1 tháng thì lên tới vài triệu chẳng hạn.Đây là lấy đối soát nên k phân trang bác nhé.

RPG29 said:

Cái này bên bạn phải bench rồi tự định nghĩa các tiêu chí "đảm bảo" trước rồi mới phân tích tiếp được.

Ví dụ bên bạn cấp cho đối tác 3 API: A, B, C.
Bạn đo được như sau:
A, query hết 1s, tốn 5% CPU, tốn 50MB RAM
B, query hết 1.5s, tốn 8% CPU, tốn 70MB RAM
C, query hết 1.8s, tốn 10% CPU, tốn 90MB RAM

Từ đó bạn ước lượng được tài nguyên tối đa có thể đáp ứng. Giả thiết là bên đối tác query quá nhiều và liên tục (nguyên nhân do họ cố ý, có lỗi lập trình...) thì khi đó mới tính đến các phương án xử lý như:
1. Đặt rate limiting theo giây, phút, giờ...
2. Cho query kiểu async, gửi request trước, nhận kết quả qua webhook sau
3. Đối tác request manually, mình gửi report sau
...

Nếu mà thấy chả tốn kém tài nguyên bao nhiêu thì kệ cho tẹt ga đi. Mà thực tế thì ít nhất nên đặt thêm cái rate limiting để tránh trường hợp bên kia nó lỗi gì đó nó vô tình DoS mình

Click to expand...

cảm ơn bác, hay quá ạ. Đúng là bọn em yếu về quy trình và kinh nghiệm. Việc đánh giá API qua các bài test performance hay stress test là cần thiết để đảm bảo được các kịch bản có thể sảy ra.
Mấy phương án bác đưa ra cũng hay ạ. Em đang nghiên cứu vụ rate limiting, triển khai cho mấy con SOAP vs REST trên linux ạ.
Đợt vừa r k có rate limiting bọn em cũng bị spam nhiều quá. Bác có kinh nghiệm chia sẻ em chút về Rate limiting dc k?

nguyenmanhdcn said:

cảm ơn bác, hay quá ạ. Đúng là bọn em yếu về quy trình và kinh nghiệm. Việc đánh giá API qua các bài test performance hay stress test là cần thiết để đảm bảo được các kịch bản có thể sảy ra.
Mấy phương án bác đưa ra cũng hay ạ. Em đang nghiên cứu vụ rate limiting, triển khai cho mấy con SOAP vs REST trên linux ạ.
Đợt vừa r k có rate limiting bọn em cũng bị spam nhiều quá. Bác có kinh nghiệm chia sẻ em chút về Rate limiting dc k?

Click to expand...

Rate limiting thoạt nhìn thì cũng đơn giản nhưng mà đi sâu vào cũng phức tạp vì còn phụ thuộc vào đặc thù của business và cách mà bên trong đang xử lý ntn.

Thông thường thì các proxy như Nginx nó đã có sẵn rate limiting ở mức cơ bản. Có thể limit request theo thời gian (giây, phút, giờ...); limit request theo IP, User-Agent... nhưng mà nó cơ bản lắm, xử lý phức tạp hơn nó ko làm được phải dùng kèm thêm giải pháp khác.

Hồi xưa mình có làm một project dùng Spring Cloud Zuul/Spring Cloud Gateway để code lại phần rate limit theo nhu cầu của business. Vd như rate limit theo "weight" của API, API nào xử lý lâu tốn tài nguyên thì cho ít lại, thằng nào nhẹ nhàng thì cho nhiều hơn.

Hiện tại mình thấy một số open source API Gateway mới mới sau này cũng có, chỉ là không biết có match nhu cầu hay ko, nếu ko dc thì phải tự code thôi. Vd như hồi xưa mình có làm việc với một bên họ limit theo "job", vì mỗi "job" xử lý khá tốn tài nguyên và thời gian nên 1h họ chỉ cho gửi 5 job, các job được queue bên server của họ, khi nào job done thì họ sẽ trigger webhook cho mình biết mà xử lý.

Nói chung là đa dạng lắm, bên bạn phải nghiên cứu nhu cầu thực sự là gì mới triển khai tốt dc

RPG29 said:

Hồi xưa mình có làm một project dùng Spring Cloud Zuul/Spring Cloud Gateway để code lại phần rate limit theo nhu cầu của business. Vd như rate limit theo "weight" của API, API nào xử lý lâu tốn tài nguyên thì cho ít lại, thằng nào nhẹ nhàng thì cho nhiều hơn.

Click to expand...

yêu cầu của em đúng là cần limit theo business của từng API, tùy đặc thù nghiệp vụ API sẽ setup rate limit khác nhau.
Chỗ này em sẽ nghiên cứu thêm. Cảm ơn bác đã chia sẻ nhé.

Love U So Much said:

Em thì thích chạy batch job, 1 ngày export ra 1 cái db cho ông khách 1 lần

Click to expand...

chuẩn, trước mình làm đối soát VNPay cũng xử lý thế này, chứ call API hoài sao đc, lịch sử giao dịch là data lớn rồi.

nguyenmanhdcn said:

em cũng thích xài cách này. Theo em thấy các đối tác em từng làm thì thường chốt giải pháp đối soát như này. 2 bên đều export ra file định dạng text đẩy lên FTP, các bên vào lấy r tự import vào DB r xử lý. Nhưng cách kia em thấy cũng được nên hỏi xem có ổn không ấy.

Click to expand...

về lâu dài thì k ổn, tưởng tượng cảnh cno download cả trăm MB data về đấy
tốt nhất vẫn là đẩy file text lên sftp cho đối tác tự download. Mà data cố định, biết trước cno cần cái gì rồi thì export sẵn ra text file rồi host bằng web server thông thường như nginx cho cno download, như down 1 file ảnh bt thôi, làm cái này thì bảo đảm hiệu năng tốt.

về rate limit như các bác ở trên bàn thì có thể cân nhắc triển khai hệ thống api gateway cho đỡ tốn nguồn lực code, ví dụ WSO2. Dựng lên chạy hoạt động như 1 con LB, có author, authen, rate limit, billing. Tự code thì cũng OK thôi nhưng đột nhiên dồn nguồn lực dev cho 1 phần phụ trợ k lq, để dành sức ae cho main business thôi.

Theo tôi api thím muốn trả về bao nhiêu rows cũng được, miễn là response time dưới 500ms, du di tí thì cho 1s.

Nếu response time lớn hơn thì phải nghĩ cách tách api hoặc paging gì đó cho nhanh hơn, client có thể parallel request để cải thiện. Cá nhân tôi thấy api > 1s là bad.

Sent from Samsung SM-A528B using vozFApp

Thằng em sn 96 said:

về rate limit như các bác ở trên bàn thì có thể cân nhắc triển khai hệ thống api gateway cho đỡ tốn nguồn lực code, ví dụ WSO2. Dựng lên chạy hoạt động như 1 con LB, có author, authen, rate limit, billing. Tự code thì cũng OK thôi nhưng đột nhiên dồn nguồn lực dev cho 1 phần phụ trợ k lq, để dành sức ae cho main business thôi.

Click to expand...

Bác nói đúng rồi ạ. Tuy là 1 phần phụ setup thêm cho hệ thống nhưng việc tự triển khai hoặc phát triển thì sẽ tốn nguồn lực và việc monitor maintain và xử lý sự cố phát sinh cũng là bài toán đau đầu. Em cũng chưa có kinh nghiệm trong vụ rate limit này.
Về cái WSO2 thì bên em đã từng triển khai nhưng được 1 thời gian ngắn thì đổi sang con Gateway nhà làm. Con WSO2 bên e chưa nắm vững được nên nhiều vấn đề phát sinh khó giải quyết hơn bác ạ. Em cũng mới trải nghiệm thấy vụ nó quản lý authen cho từng đối tác partner thì ok. Vụ rate limit vs billing thì em chưa được trải nghiệm. Phí quá.

Chưa hiểu vấn đề ở đây là gì?

• Performance?
• Security?
• Rate Limit

Fire Of Heart said:

Chưa hiểu vấn đề ở đây là gì?

• Performance?
• Security?
• Rate Limit

Click to expand...

em chỉ hỏi về vấn đề performance đối với server, và về nghiệp vụ thì xài giải pháp đó có ổn không thôi. Còn các nội dung khác em trao đổi để nắm được chứ không phải vấn đề chính b ạ.

1 triệu row thì database nào mà chịu nổi. Xuất ra text file rồi up lên ftp, hoặc xuất dữ liệu ra 1 db trung gian rồi charge tiền thật cao vào.