tks

ý chủ thớt ở đây là nếu ko có set key thì mặc định ưu tiên là primary key > unique key còn nếu có set nhưng dòng trên thì lấy những field đó làm key

🥰

@thevan96 thank bác đã chia sẻ

tks

@hanli Đúng rồi bạn, để tránh trường hợp 2 first và second trùng nhau.

hình như cái điều kiện T2 nó không vào được ấy bạn, có phải ý bạn là element > second && element ! first không?

🤙😃 2 1 1

Anh có thể ví dụ trường hợp nào thì dùng ReclaimPolicy là Retain trường hợp nào dùng Delete không ạ?

Cách trên lằng nhằng, tốn mất O(nlogn) thời gian xử lý, nếu có set thì tốn thêm O(n) nữa, n = len(string)

Mình có cách khác tối ưu hơn, mã Pseudocode

first, second = INT_MIN
if len(arr) < 2
  print "Not found max two"

for element in arr
  if element > first
    second = first
    first = element
  elseif element > second && element != first
    second = element

if second = INT_MIN
  print "There's no second largest element"
else
  print "The second largest element is", second

Hi ad, e đang sử dụng bulljs nên lưu các job trong redis và e có set ttl cho job là 7 ngày (lưu để monitor và debug). Mỗi ngày có 100k job chạy thì sau 7 ngày redis phải xoá gần 100k key hết hạn và ngày chồng ngày thì lượng key hết hạn càng tăng vậy có cách nào giúp redis xoá key hết hạn tốt k a.

Đúng rồi bạn, thứ nhất là họ không có release reward model, cái này tạo ra rất tốn kém và có ý nghĩa với họ. Thứ hai là bản thân RLHF cũng là một kĩ thuật mới và rất khó training, đòi hỏi nhiều chuyên gia của họ nên với người thường như chúng ta chỉ nên tiếp cận theo SFT hoặc Prompting thôi.

@Honganh https://colab.research.google.com/drive/1AAvSdaQax8fxNEQsiUn_zFV_1RpmwOB4?usp=sharing hay là bạn xem thử code giúp mình vs

SASS là thư viện CSS nó đâu liên quan gì tới Cloud và BigData đâu nhỉ

@monmen Dạ để em thử, em cám ơn bác nhé!

@AnhTuan92NA tách mỗi lần gọi api chỉ gọi 500 đến 1000 user thôi, xong query token ra call firebase lại tách batch 500 tiếp.

@monmen Dạ, nếu vậy thì " Còn bắn noti chủ động cho 1 tập hợp user thì làm cái api truyền list uid + noti để thằng noti tạo xong query token gửi thông báo thôi" nếu hệ thống sau có nhiều user và có query ra 1000 (uid) thì qua bên notification service phải query in 1000 uid này để lấy ra token thì có bất hợp lý không ạ. Hiện tại hệ thống của bên em đang làm chính là bằng django + postgres mà em đang tách notification service ra 1 con mới làm bằng django + mongo và trong con mongo này em có lưu bảng token store gồm: uid, token, os, os_name... và bảng notification gồm: key, type subjects, subject_count, di_object, in_object, pr_object theo bài hướng dẫn của bác (https://viblo.asia/p/bi-thuat-xu-ly-ngu-phap-notification-nhu-facebook-m2vJPwxo4eK) ạ. Mong bác hướng dẫn em thêm flow phần này ạ. Em cám ơn!

cách trên đúng nhưng không dùng được cho string nhe 😁

@tuelam0810 Mình sẽ hiểu vấn đề của b là setup phần ingress cho k8s, cái này sẽ tùy thuộc vào mô hình cluster của b, nếu nằm trên cloud như AWS thì sẽ setup ingress vs ALB or NLB. Còn ở on-premise, cluster nằm ở local đi network qua 2 gateway thì mình sẽ dùng mấy service proxy như HAproxy. Public argocd khá đơn giản, trong file helm của argocd b enable phần ingress đặt tên host với secretname là ssl domain của b là xog

đây bạn