Ngoài ra cải thiện tốc độ của MySQL thì cũng chỉ có thể có một vài cách là tối ưu lại các câu SQL, thực hiện caching cho các query được gọi đi gọi lại nhiều lần thôi Hi vọng giúp ích được cho bạn.

giờ nó được thay bằng BM25, hẳn là hàng còn tốt hơn, thử tiếp đi anh =)))

Nice post! Trước em cũng dùng TF-IDF để đánh giá độ quan trọng 1 một từ trong văn bản ngôn ngữ tự nhiên. Hiệu quả không ngờ

cho mình hỏi thứ tự assign middleware có ảnh hưởng đến thứ tự thực hiện không? Mình muốn middleware A thực hiện trước middleware B thì có được không?

Cấu trúc dữ liệu thế nào, theo mình chuyến sang nosql để tăng tốc độ là ngon nhất

khó quá. Thực sự không có kinh nghiệm thì chắc không thể mò được ra

Sao lại 4.000.000 * 500.000 nhể. Sao k tân dụng sức mạnh của data base server B1: Lưu xừ cái 500.000 kia vào bảng A (khoá là domain nếu k trùng nhau) B2: Bulk insert tiếp 20 file kia vào bảng B (khoá cũng là domain nếu k trùng nhau) B3: Cần 1 câu query join A và B lại với nhau trên key. Chắc sẽ nhanh hơn nhiều đấy

Mông lung như 1 trò đùa chị à !

bạn Đạt có phải là lập trình viên full stack ko ? mình đang muốn tìm 1 free lancer full stack để làm dự án ở hà nội, bạn có gợi ý nào ko ?

(Dull)

Rất hay, cảm ơn chị thớt, mặc dù không hiểu gì(wara).

Cảm ơn bạn đã quan tâm đến nội dung của Seminar này. Thông thường trong Deep learning không có một quy tắc riêng nào để chọn số lượng Hidden layer. Và mỗi một kiến trúc mạng nơ ron sẽ phù hợp với một bài toán nhất định mà thôi. Việc lựa chọn số hidden layer sao cho phù hợp với từng bài toán là tùy thuộc vào cá nhân người xây dựng mô hình sao cho đảm bảo nguyên tắc của học máy đó là không để mô hình bị overfitting, không để mô hình bị underfitting thế nên cách mà mình thường hay sử dụng đó là thêm các hidden layer cho đến khi lỗi trên tập dữ liệu kiểm tra không cải thiện được nữa. Cảm ơn bạn

Rất chi tiết, cảm ơn bạn để mình nghiền ngẫm

Mình mới học lập trình, bài viết rất bổ ích, mong bạn sớm ra bài tiếp theo

Có bạn nhé. Snapkit là thư viện nó viết lại cho các thuộc tính NSconstraints của Apple.

bài viết rất hay ạ..em có làm nhưng mà vẫn chưa hiểu rõ lắm, nhờ bài này mà em hiểu hơn..thanks chị ạ

@bs90, @manhtqb Cảm ơn các bạn 😉

Trường hợp bị rebase 40 lần là do branch của bạn có 40 commit khác tính từ điểm 2 branch có commit chung. Hoặc là commit giống nhau nhưng lịch sử bị thay đổi khác nhau.

Giả sử branch của mình có lich sử commit là: A->B->C1->D1 (branch1) Mình sẽ rebase branch có lịch sử là: A->B->C2 (branch2)

git checkout branch1 git rebase branch2

Như vậy sẽ bị rebase 2 lần.

Để rebase 1 lần thì ta chỉ cần gộp 2 commit trên branch của mình lại thành 1 thôi

git rebase -i HEAD~2

để "p" ở dòng đầu, các dòng khác để "s" xong lưu lại.

Hoặc cách 2 dễ hơn: git reset --soft HEAD~2 Xong tạo commit mới git commit -m "commit moi"

Mình chắc chắn rằng trong 40 commit kia sẽ có các commit có thay đổi giống nhau giữa 2 branch nhưng do lịch sử bị thay đổi nên git sẽ vẫn cho là commit khác nhau. Bạn sẽ băn khoăn là nếu mình "reset soft" 40 commit thì thay đổi của nó có được áp dụng ko. Chắc chắn là có nhé bạn. Tuy nhiên lịch sử commit sẽ theo cái branch mà mình rebase. (tức là ở ví dụ trên sẽ là branch 2) Tuy nhiên việc rebase như vậy sẽ có khá nhiều conflic đó. Trong khi làm project chung bạn nên tạo 1 branch riêng dùng để merge các commit và mình chỉ rebase branch đó thôi. Và mỗi lần rebase phải chắc chắn là mình chỉ commit 1 lần tính từ lúc mình rebase lần cuối cùng. Trường hợp rebase code mà mất code thì đó là do trong code của bạn có những đoạn giống nhau hãy để ý và fix conflic thật kĩ trước khi "git add -A" => "git rebase --continue"

Có một cái hay ho nữa là; Giả sử ta có 2 branch master: A=>B branch1: A=>B=>C

checkout branch 2 từ branch1 git checkout branch1 git checkout -b branch2

++> branch2: A=>B=>C commit 1 phát: A=>B=>C=>D

master merge branch1: git checkout master git merge branch1

Lúc này master: A=>B=>C git checkout branch2 git rebase master ==> không phải rebase. Và lịch sử commit vẫn giữ nguyên.

Mình nghĩ cái khung đó bạn ấy đang dev dở :v

cảm ơn tác giả!