thảo luận Cần được giúp để trang dashboard chạy nhanh hơn

[H15082000]

Em mới được cấp trên giao cho tạo 1 trang dashboard như hình

nhưng mỗi lần chạy thì phải mất tầm 6p đến 7p mới xong.
- Trong project này em tạo 1 package và trong package thì tạo các procedure cho mỗi phần như biểu đồ 1 procedure và table 1 procedure và 4 con số lớn trên cùng là riêng 1 procedure

- Với 4 con số lớn này em có mã lệnh như sau

- Và table thì em có câu lệnh như sau

- Có cách nào tối ưu truy vấn cho nhanh hơn không mấy anh chứ chạy lâu quá trên FE em phải dùng web worker cho nó chạy ở luồng riêng để không ảnh hưởng tới luồng chính

 

[Be_tap_code]

1. Các dữ liệu này bạn dùng job tính toán trước, lúc show lên chỉ gọi từ dữ liệu đã tính toán, đặt job sao cho hợp lý
2. Phải có cache
3. Tối ưu lại các câu lệnh

via theNEXTvoz for iPhone

 

[H15082000]

1. Các dữ liệu này bạn dùng job tính toán trước, lúc show lên chỉ gọi từ dữ liệu đã tính toán, đặt job sao cho hợp lý
2. Phải có cache
3. Tối ưu lại các câu lệnh

via theNEXTvoz for iPhone

Cảm ơn bác nhiều

 

[H15082000]

1. Các dữ liệu này bạn dùng job tính toán trước, lúc show lên chỉ gọi từ dữ liệu đã tính toán, đặt job sao cho hợp lý
2. Phải có cache
3. Tối ưu lại các câu lệnh

via theNEXTvoz for iPhone

Mà bác cho em hỏi dữ liệu biểu đồ này nó biến động theo thời gian bác ơi qua vài phút số liệu nó đã khác đi rất nhiều rồi ko có cố định nếu dùng job tính toán trước em lại sợ không được rồi ạ

 

[CzeK]

Mà bác cho em hỏi dữ liệu biểu đồ này nó biến động theo thời gian bác ơi qua vài phút số liệu nó đã khác đi rất nhiều rồi ko có cố định nếu dùng job tính toán trước em lại sợ không được rồi ạ

Mỗi lần chạy là nó compute lại tất cả từ đầu à thím. Nếu vậy thì không tối ưu lắm. Thím thử vd compute tới thời gian hiện tại rồi lưu vào db, sau tầm 5p có bn giá trị mới thì lấy giá trị compute ở mốc thời gian 5p trước mang ra compute với giá trị mới xong lại lưu vào db.

 

[H15082000]

Mỗi lần chạy là nó compute lại tất cả từ đầu à thím. Nếu vậy thì không tối ưu lắm. Thím thử vd compute tới thời gian hiện tại rồi lưu vào db, sau tầm 5p có bn giá trị mới thì lấy giá trị compute ở mốc thời gian 5p trước mang ra compute với giá trị mới xong lại lưu vào db.

Vậy để em thử ạ

 

[beatvn.truongton]

Mà bác cho em hỏi dữ liệu biểu đồ này nó biến động theo thời gian bác ơi qua vài phút số liệu nó đã khác đi rất nhiều rồi ko có cố định nếu dùng job tính toán trước em lại sợ không được rồi ạ

Dữ liệu gì mà lại cần report gần như realtime vậy bạn

 

[H15082000]

Dữ liệu gì mà lại cần report gần như realtime vậy bạn

Dữ liệu đánh giá kỹ năng công nhân bác công ty em công nhân đông rồi họ chuyển job liên tục nên nhiều khi mấy phút trước đang job này vài phút sau cái họ sang job khác

 

[LangTangPhang]

1. Các dữ liệu này bạn dùng job tính toán trước, lúc show lên chỉ gọi từ dữ liệu đã tính toán, đặt job sao cho hợp lý
2. Phải có cache
3. Tối ưu lại các câu lệnh

via theNEXTvoz for iPhone

cơ bản thì đúng rồi.
Chi tiết thì phải xây dựng thành tree các level data tính toán phụ thuộc lẫn nhau.
giả sử giờ bác call 1 lần thì nó thực hiện 1000 phép tính toán với 1000 data trên 1 cpu process thì tốn nhiều thời gian/resource tại 1 thời điểm.
xây dựng thành tree, tao thanh các compute node thì nó sẽ tăng khả năng tính toán song song + tối ưu resource. tạo schedule cho các node tính toán, node dưới tính toán xong thì trigger node trên tính và cập nhật lên dashboard.
btw, bác xem lại khái niệm realtime nhé. realtime nó có delay và quan trọng là delay chấp nhận được.

 

[Be_tap_code]

Mà bác cho em hỏi dữ liệu biểu đồ này nó biến động theo thời gian bác ơi qua vài phút số liệu nó đã khác đi rất nhiều rồi ko có cố định nếu dùng job tính toán trước em lại sợ không được rồi ạ

Khác thì vẫn phải tổng hợp trước thôi, xem thời gian delay chấp nhận là bao nhiêu? Còn tính toán như nào cho hợp lý thì như mấy bác bên trên cmt rồi đó
Còn về chỗ tối ưu câu lệnh thì mình nhìn cái kia hơi ngán. Bạn viết thành các func rồi join qua nghe có vẻ code sạch đẹp nhưng cost nó sẽ nặng. Nói chung tối ưu sql thì xem index, paảtiton xem ok chưa; explain câu lệnh lên mà xem thôi, xem nó nặng ở đâu,…

via theNEXTvoz for iPhone

 

[H15082000]

Khác thì vẫn phải tổng hợp trước thôi, xem thời gian delay chấp nhận là bao nhiêu? Còn tính toán như nào cho hợp lý thì như mấy bác bên trên cmt rồi đó
Còn về chỗ tối ưu câu lệnh thì mình nhìn cái kia hơi ngán. Bạn viết thành các func rồi join qua nghe có vẻ code sạch đẹp nhưng cost nó sẽ nặng. Nói chung tối ưu sql thì xem index, paảtiton xem ok chưa; explain câu lệnh lên mà xem thôi, xem nó nặng ở đâu,…

via theNEXTvoz for iPhone

Cảm ơn bác nhiều em sẽ xem lại code rồi bàn với user xem họ chấp nhận delay không

 

[banbegiupdo007]

H15082000. Bác cho em thắc mắc tí, là bác viết SQL xong rồi sao bỏ qua excel để vẽ report như hình bác up lên vậy?

 

[H15082000]

H15082000. Bác cho em thắc mắc tí, là bác viết SQL xong rồi sao bỏ qua excel để vẽ report như hình bác up lên vậy?

Cái excel là cái giao diện user làm gửi cho em thiết kế theo á bác ơi tại giao diện em mà chạy dữ liệu nó lâu lắm nên dùng tạm ảnh đó hỏi cho nhanh

 

[H15082000]

Công ty em dùng table để show dữ liệu nên có nhiều view search dữ liệu ngày công của công nhân từ ngày này đến ngày này nó ra tới mấy trăm nghìn dòng lag mẹ luôn cái web scroll cái table còn cà giật cà giật không hiểu nên tối ưu kiểu gì cho nó mượt mà mà nhanh nữa

 

[Illuminati97]

Công ty em dùng table để show dữ liệu nên có nhiều view search dữ liệu ngày công của công nhân từ ngày này đến ngày này nó ra tới mấy trăm nghìn dòng lag mẹ luôn cái web scroll cái table còn cà giật cà giật không hiểu nên tối ưu kiểu gì cho nó mượt mà mà nhanh nữa

bác chỉ hiện 20 - 50 dòng khi scroll thôi, những dòng ngoài màn hình thì xoá đi.

 

[banbegiupdo007]

Bác thử chia partition ra theo thời gian và lưu trữ xem, rồi khi mình viết font-end thì mình xử lý câu query cho partition nào cho hợp lý.

 

[H15082000]

bác chỉ hiện 20 - 50 dòng khi scroll thôi, những dòng ngoài màn hình thì xoá đi.

Em sợ user la um sùm chỗ này

kiểu nhiều khi họ chỉ nhìn số này rồi so với báo cáo tay xem tạm thời đủ số lượng chưa, haizzz đau đầu mấy vụ này quá

 

[Illuminati97]

Em sợ user la um sùm chỗ này View attachment 2444438
kiểu nhiều khi họ chỉ nhìn số này rồi so với báo cáo tay xem tạm thời đủ số lượng chưa, haizzz đau đầu mấy vụ này quá

bác đã load được data rồi thì bác đã biết được có bn dòng rồi mà nhỉ.
Ý e là ntn:
ví dụ data trả về 1000 dòng, thì bác chỉ cho hiện 50 dòng ban đầu thôi, khi scroll xuống dưới thì bác mới render thêm các dòng tiếp theo.

 

[H15082000]

bác đã load được data rồi thì bác đã biết được có bn dòng rồi mà nhỉ.
Ý e là ntn:
ví dụ data trả về 1000 dòng, thì bác chỉ cho hiện 50 dòng ban đầu thôi, khi scroll xuống dưới thì bác mới render thêm các dòng tiếp theo.

Để em tìm hiểu thêm cái table này xem do table này tạo bằng library của mấy anh hàn toàn doc tiếng hàn đọc ko hiểu gì hết

 

[zzchaolegionzz]

Không liên quan nhưng mà dữ liệu công ty lại đem up lên mạng tơ hơ thế này ah thím?

Em sợ user la um sùm chỗ này View attachment 2444438
kiểu nhiều khi họ chỉ nhìn số này rồi so với báo cáo tay xem tạm thời đủ số lượng chưa, haizzz đau đầu mấy vụ này quá

Chỗ đếm số row loaded thì thím count 1 phát rồi trả về.

Công ty em dùng table để show dữ liệu nên có nhiều view search dữ liệu ngày công của công nhân từ ngày này đến ngày này nó ra tới mấy trăm nghìn dòng lag mẹ luôn cái web scroll cái table còn cà giật cà giật không hiểu nên tối ưu kiểu gì cho nó mượt mà mà nhanh nữa

Dùng paging để load data, mỗi page có skip, limit truyền vào, còn frontend thì dùng mấy cái unlimited scroll nó tái sử dụng lại element nên không tốn thêm memory.