Sernior hỏi Intern: Theo bạn cách nào tốt nhất check user có tồn tại trong 100 triệu user như github

  Рет қаралды 51,571

Tips Javascript

Tips Javascript

Күн бұрын

Пікірлер: 95
@tnanhpt
@tnanhpt Ай бұрын
trong ngày vừa thắc mắc vụ này trong facebok tự nhiên thấy video, cảm ơn bác nhiều ạ
@anonystick
@anonystick Ай бұрын
Duyên đó em kakka
@duc.nguyen67
@duc.nguyen67 Ай бұрын
video anh làm hay quá, em thành fan của anh, mong anh ra nhiều nội dung như vậy nữa🙏
@longshin4299
@longshin4299 Ай бұрын
Ví dụ ở video này áp dụng chưa thực tế lắm. Nó phải là #1 bitmap dùng khi số lượng trùng lặp cao #2 bloom filter hiệu quả với các dataset lớn như văn bản dài #3 Việc check user có tồn tại hay không thì dùng redis sẽ thêm phức tạp và tốn kém trong khi việc này database handle được. Mặc dù có 100tr người dùng nhưng mà số lượng người truy cập đồng thời là bao nhiêu, số lượng người dùng đăng ký mới là bao nhiêu v.v. Nếu dùng query vào database để kiểm tra user tồn tại hay không thì nó database vẫn handle được. Database của các doanh nghiệp lớn chịu tải và tốc độ cũng rất cao. Câu truy vấn check exists chỉ tốn vài mili giây. Trong khi đó dùng redis cũng tốn 1 mils. Nói chung dùng redis để giải quyết vấn đề chịu tải và tốc độ cho vd trong video thì chưa hợp lý
@VuaTommy
@VuaTommy Ай бұрын
Theo em hiểu là đang chỉ xoáy vào bộ nhớ sử dụng + tốc độ. Nếu nói về đơn giản thì cứ xếp vào database rồi query bắt user đợi 1s cũng được rồi, máy khủng quá mà
@longshin4299
@longshin4299 Ай бұрын
@VuaTommy Sao lại 1s nhỉ. Câu select check user tồn tại hay không ở database chỉ mất 1 mili giây thôi
Ай бұрын
Redis vẫn tối ưu hơn, hệ thống lớn business logic lớn k thể cứ user vào query data từ db truyền thống đc đâu kk.
@longshin4299
@longshin4299 Ай бұрын
Ngoài performance ra thì yếu tố về bảo toàn dữ liệu và giá. Redis trong trường hợp này ko giúp tăng hiệu suất giá thì đắt độ phức tạp thì thêm. Database của các hệ thống lớn dưới dạng distributed database, chưa kể nó có nhiều loại khác nhau. Vd như key-value dynamoDB có thể chịu tải cực cao. Vì vậy dùng redis chỉ tăng chi phí và độ phức tạp, không giải quyết được gì
@nabi188
@nabi188 Ай бұрын
@@longshin4299đồng ý với quan điểm của bro
@kduy10b8
@kduy10b8 Ай бұрын
+1 kiến thức bổ ích, cám ơn bác nhé
@ueihgnurt
@ueihgnurt 26 күн бұрын
Cách này thật sự thì cũng bắt đầu outdate rồi. Nên mới thành bài cho intern. hiện giờ cả tỷ param rồi còn dùng cách này thì query tốn cũng tận 0.5-1s lận. chưa kể Big Data như LLM bh chắc cả chục tỷ param thì cách này bh ko ăn thua. Bây giờ chúng nó chia bảng bằng kNN cả. MongoDB có Compass, RedisAI Chromadb etc. Chúng nó chỉ đơn giản là tìm độ tương đồng dữ liệu hoặc chữ thôi. Nếu bạn hash nó ra thành số nguyên bạn sẽ chỉ tra cứu trên một trục. Ox rãi từ 0 tới 1 tỷ tra cứu sẽ lâu. Vậy nên hiện tại bên Big Data họ sẽ hash thành ma trận. Thay vì phân loại 10000 params thì họ chỉ cần tính góc Oxy của 100 params x và 100 params y rồi tra trên đường thẳng đó thôi. tương tự với 10^8 thid cũng chỉ cần chia thành ma trận 1,8 rồi tìm độ tương đồng query gần nhất là được.
@wanghien
@wanghien 24 күн бұрын
hay quá a ơi
@alexnguyen385
@alexnguyen385 18 күн бұрын
Hình như bạn k hiểu bitmap alg và bloom filter alg thì phải. Bitmap + bloom filter đâu phải linear search đâu mà từ 0 tới 1 tỷ ? Bitmap lookup O(1) còn bloom filter lookup O(k) where k is number of hash functions. Căn bản cả 2 đều là constant time.
@ueihgnurt
@ueihgnurt 18 күн бұрын
@@alexnguyen385 hình như bạn không hiểu cách máy tính hoạt động thì phải? dù bạn có kiếm bao nhiêu thuật toán nó vẫn chỉ là cộng trừ nhân chia lớn bé.toán tử cơ bản được tạo ra trong nhân CPU. Dù nó có là nhị phân hay thập phân hay cả hash256. Tất cả các hàm bạn dùng ở ngôn ngữ bậc cao đều được tạo ra từ tổ hợp đó. B-Tree đơn giản là chia để trị theo khoảng lớn. Mỗi khoảng nó sẽ cắt đôi miếng bánh rồi xem bên nào đúng hơn. rồi lại cắt. Còn Cosine Similarity nó không chia đôi. Bạn vừa vào là đã loại 99% trường hợp sai rồi. bạn thử chia đôi 1 tỷ liên tục tiến tới 1 so với chia 100 liên tục tiến tới 1 xem cái nào nó nhanh hơn. Nên nhớ với B-tree chuỗi bitmap càng dài query càng lâu. Không phải tự dưng người ta tạo ra LLM với LCM đâu bạn. Dữ liệu như documents bạn cũng có thể Query đấy. mà Query bằng filter của bạn Query tới tết congo nó cũng chịu chết.
@ueihgnurt
@ueihgnurt 18 күн бұрын
@@alexnguyen385 I understand your concern. Với độ lớn dữ liệu hiện tại thì sử dụng cosine similarity nó sẽ chậm và không cần thiết so với B-tree. Nhưng bạn đang ở thời đại 4.0 lên 5.0. Nơi mà kể cả website cũng đang chạy ngầm task A.I. bằng web assembly. Nếu bạn cứ cổ hủ và đinh ninh vài trăm bảng dữ liệu là peak thì cứ việc. LLM nó không hề khó. Nhưng nếu bạn không phá vỡ cái định kiến cũ thì mãi thiết kế mấy cái web app 3.0 mà không lên nổi đâu.
@tranluan9391
@tranluan9391 16 күн бұрын
@@ueihgnurt Cosine similarity sao nghe cứ như trong search engine vậy ta? bạn có bị nhầm lẫn không?
@quoczuong7777
@quoczuong7777 Ай бұрын
Khoá NodeJS backend của anh rất hay, em đang học em thấy anh nên làm một video đầu khoá giới thiệu chi tiết về các công nghệ của dự án sẽ thu hút thêm nhiều bạn đăng ký học ấy anh.
@baoreview7478
@baoreview7478 28 күн бұрын
Làm sao để học. Dc khoá đấy v bạn
@quoczuong7777
@quoczuong7777 28 күн бұрын
@ bạn vào danh sách phát tìm, những video đó chỉ dành cho hội viên nên bạn đăng ký hội viên kênh để xem
@tranluan9391
@tranluan9391 Ай бұрын
Cái này DB vẫn handle dc. Kỹ thuật này là over-engineering. Dùng BTREE index thì 1 tỉ rows chỉ có depth = log100(10^9) bằng 5 thôi(Một block 100 node). Check 5 block là tìm được user rồi. Đó là trường hợp xui nhất.5 block với một block size cho thả ga là 1mb thì tốn 5mb RAM. cần chi tới 15GB ram cho redis với 1 triệu rows trong khi một tỉ rows tốn có 5mb?
@abcxyz-tu1sn
@abcxyz-tu1sn Ай бұрын
Mình có db lưu log, mỗi ngày 1-2 tỉ row. GIờ cần làm báo cáo (trước tiên báo cáo đơn giản thì task đang là select count where type = ...). Case này của mình còn cứu được không bác
@tranluan9391
@tranluan9391 Ай бұрын
@@abcxyz-tu1sn bạn làm ứng dụng gì mà ghê vậy? nếu nói rõ hơn thì mới confirm dc yes hay no. Theo mình cái này vẫn được thôi. dùng cơ chế partitioning của engine để weekly/monthly partitions. Chuyện đâu lại vào đó.
@alexnguyen385
@alexnguyen385 17 күн бұрын
Có tradeoff nhưng k đến nổi như bạn nói trong khi bitmap hoặc bloom filter lookup là O(1) hoặc O(k) thì query với BTREE index lookup là O(NlogN) chưa tính memory usage thì cả bitmap + bloom avg memory cho 1 tỉ record khoảng ~100mb còn db bạn vừa store data vừa store cả index. Nếu query trực tiếp db để check thì trừ khi db cluster như master slave thì ok còn k cứ bitmap + bloom mà vả LOL
@tranluan9391
@tranluan9391 17 күн бұрын
@alexnguyen385 nghe kỹ video đi bạn. Nghe xong sẽ biết 15GB ở đâu ra. Còn db cần thì ko cần cluster vẫn handle dc. Cluster để blance loading thôi
@alexnguyen385
@alexnguyen385 17 күн бұрын
@ rồi b k tính là btree index của email column k tốn disk storage ha? K những tốn disk storage cho 10^9 indexes mà khi execute query nó dùng buffer pool hoặc cache để load vào memory nữa. Eg root hoặc internal level thì memory ít chứ vô 10% leaves thì lên 2-3Gb là chuyện bth.
@lâmtrịnh-r4m
@lâmtrịnh-r4m Ай бұрын
Cho các bạn nào chưa biết thì cái bloom filter kia có trả về trường hợp dương tính giả ( kiểu mk nhập tài khoản trong database không hề có nhưng nó vẫn báo trong data base đã tồn tại )
@VuaTommy
@VuaTommy Ай бұрын
Em thắc mắc cái hash map nó cũng bị vậy thì xử ký sao anh, đa phần sử dụng hàm băm là đều có khả năng bị trùng hash dù rất thấp
@ucaoxuan9256
@ucaoxuan9256 Ай бұрын
mình nghĩ nếu chỉ dùng cho việc đăng ký người dùng thì vẫn chấp nhận được, mình check AI thì nó bảo tỉ lệ false positive trong prj thực tế là 0.1% - 1%, user nhập tên khác là xong
@lâmtrịnh-r4m
@lâmtrịnh-r4m Ай бұрын
@@ucaoxuan9256 yes , cái đó trong thực tế chấp nhận đc vì chả ảnh hưởng gì cả
@lâmtrịnh-r4m
@lâmtrịnh-r4m Ай бұрын
@@VuaTommy mk nghĩ là xử lí = cách giảm xác suất thôi, mỗi hàm băm đều có hàm đánh giá mà. Như hàm tính p(bloom) kia thì tăng size và K hàm hash lên là nó tiệm cận 0 r
@truongnhompro
@truongnhompro 19 күн бұрын
DB engine nào check index 100M record tốn 2-3 giây vậy? Dùng hash thì xử lí hash collision như thế nào, dùng redis thì sync redis với db như thế nào trong trường hợp redis restart. Bài toán đơn giản mà solution phức tạp quá
@phatminh2003
@phatminh2003 Ай бұрын
Cảm ơn ạ
@ucnguyenminh977
@ucnguyenminh977 Ай бұрын
thấy tiêu đề là đã uy tín, like và comment cái
@PhanNguyenAnh-p8c
@PhanNguyenAnh-p8c Ай бұрын
Thường là làm gì cũng có tradeoff mà, cái chính là mọi người nắm hiểu được tính chất các thành phần để phân tích có nên làm hay không. Chứ vấn đề không tự dưng mất đi được, khó phần này sẽ chuyển sang vấn đề phần khác.
@dev_kui
@dev_kui 24 күн бұрын
hay anh ơi
@sangnguyendev
@sangnguyendev Ай бұрын
Tuyệt vời
@duskblade184
@duskblade184 Ай бұрын
Anh có thể làm 1 video giải thích về proxy server, forward proxy hay reverse proxy (như Nginx) đc kh ạ
@huynguyenvvnhanoi9963
@huynguyenvvnhanoi9963 Ай бұрын
bác nói chưa đúng lắm email mà đánh index thì số luơng bản ghi ko qua ảnh hưởng đến tốc độ cùng lắm nó mất vài ms chứ không có chuyện vài s đc. trong 1 lập trình cần cân bằng độ phức tạp thuật toán và độ phức tạp của code
@duyhoangha500
@duyhoangha500 17 күн бұрын
e cũng đang nghĩ thế, DB đã cung cấp index, kết hợp với lệnh Exist thay vì count nữa.
@duyhoangha500
@duyhoangha500 17 күн бұрын
khác biệt có thể là việc dùng bitmaps thì sử dụng bộ nhớ sẽ hiệu quả hơn
@huynguyenvvnhanoi9963
@huynguyenvvnhanoi9963 17 күн бұрын
@@duyhoangha500 chưa chắc nhá bạn vẫn phải lưu mail thôi đây là muốn đẩy service check này ra ngoài hệ thống chính thôi chứ sao trong db chính không lưu mail đc disk là 1 tài nguyên rẻ 1 hệ thống cả trăm triệu người chả ai tiếc 1,2 gb ổ cứng
@huynguyenvvnhanoi9963
@huynguyenvvnhanoi9963 17 күн бұрын
nhưng mình không phủ nhận độ hiệu quả của bitmap hay bloom filter tóm lại nó cần áp dụng đúng bối cảnh thì mới thật sự hiệu quả đc
@timango1399
@timango1399 Ай бұрын
Anh ơi, cho em tham khảo ý kiến với ạ. Hiện tại em đang làm Java dev backend thì ngoài Java spring,.. thì em có nên học thêm Go để tăng thêm cơ hội việc làm sau này không ạ. Em thấy Go cũng tương đối mạnh và được sử dụng dần trong hệ thống Backend.
@anonystick
@anonystick Ай бұрын
Có em. Rất nên. Hãy trang bị cho mình nhiều vũ khí để có thể săn bắt nhiều môi trường khác nhau..
@timango1399
@timango1399 Ай бұрын
@ vâng ạ. Anh ơi, em muốn tham gia hội viên của anh thì cần làm gì vậy ạ.
@lost.in.maze.official
@lost.in.maze.official Ай бұрын
Xem video thì thấy bloom filter, tìm hiểu thì cũng khá hay, nhưng 100million user. Sau khi index rồi thì find chỉ chất 1-4ms /req nên k đáng lắm.
@anonystick
@anonystick Ай бұрын
Tuyệt vời
@lamhoang8768
@lamhoang8768 Ай бұрын
cho e hỏi chẳng may con redis bị chết hoặc bị restart, thì cái data ở bitmap sẽ bị mất đi, mình cần khắc phục như nào ạ ? Em mới fresher chưa có kinh nghiệm lắm.
@lowtechdev
@lowtechdev Ай бұрын
cái này ai làm Devops cũng biết là luôn có 1 tiến trình để khởi tạo lại toàn bộ bitmap mỗi lần khởi động lại server. Đôi khi Facebook cũng bị ngỏm vài năm một lần mỗi lần khoảng gần tiếng thì bạn tự hiểu 1 tiếng đấy làm những gì
@SaMi-kv6yi
@SaMi-kv6yi Ай бұрын
Redis lưu xuống đĩa cứng rồi phục hồi lại
@quangtruong4593
@quangtruong4593 Ай бұрын
@@SaMi-kv6yi rất chậm, không dùng cách lưu xuống ổ cứng rồi đọc lại dc
@tungvu3054
@tungvu3054 Ай бұрын
​@@quangtruong4593 nó dùng cách nào vậy bạn nhỉ?
@truongbuipv
@truongbuipv Ай бұрын
Có bị mất đâu mà khắc phục?
@dientri2090
@dientri2090 Ай бұрын
Nếu redis chết thì đồng bộ dữ liêu như nào ạ
@creativevn2924
@creativevn2924 Ай бұрын
nếu redis chết thì bật lại vẫn còn dữ liệu nha , dùng redis AOF nha
@truongbuipv
@truongbuipv Ай бұрын
Chết thì bật lại có mất đâu?
@egozMaster
@egozMaster Ай бұрын
@@truongbuipvlưu đâu mà k mất???
@phamtrung5745
@phamtrung5745 25 күн бұрын
senior not sernior
@QuyNguyen-cd1pe
@QuyNguyen-cd1pe 9 күн бұрын
em thì dùng Ctrl + F nha
@bachnguyen4741
@bachnguyen4741 Ай бұрын
Cách này rất tuyệt nhưng có một vấn đề lớn là đồng bộ dữ liệu giữa redis và database. Anh có thể ra thêm video xử lý vấn đề này không ạ?
@otis4ex
@otis4ex Ай бұрын
có video r mà
@nvtmjfan
@nvtmjfan Ай бұрын
xem 3 lần vẫn ko hiểu vụ bitmap
@harris269
@harris269 Ай бұрын
ở đây bạn có thể hiểu nôm na là bạn khởi tạo 1 vector existed[userid], với các giá trị ban đầu là 0, rồi cập nhật thành 1 sau khi người dùng tạo tài khoản, khi cần kiểm tra 1 email có tồn tại trong hệ thống hay không thì vào mảng này kiểm tra, với userid = hash(email), ý tương sơ bộ là vậy, chỉ khác nhau về công cụ thì video sử dụng bitmap được implement sẵn trong redis (được tối ưu hơn thay vì người lập trình phải tự implement những chi tiết kĩ thuật này từ đầu)
@khoinguyen-lg4cy
@khoinguyen-lg4cy 28 күн бұрын
các a chị quên đi nguyên lý của lập trình rồi, mọi thứ đều là trade-off nguyên lý này nói chung về các hệ thống cntt bao gồm luôn lĩnh vực AI, ko có khái niệm đúng tuyệt đối hay sai tuyệt đối, nó chỉ mang tính tương đối, ko có hệ thống hoàn hảo vì nó sẽ luôn đánh đổi 1 thứ gì đó, tôi đánh giá cao video này vì cho tôi thấy 1 cách tiếp cận và nó có thể giải quyết vấn đề nào đó, còn bạn nào lên đây nói cách này sai, cách kia dở hay cách của các bạn là đúng thì tôi nói thẳng các bạn chả biết gì về lập trình . thân ái và quyết thắng
@tranluan9391
@tranluan9391 17 күн бұрын
🙃 cũng vậy, nếu nói "các bạn chả biết gì về lập trình" thì nó cũng tương đối không đúng ko sai, không hoàn hảo, không đầy đủ. biết lập trình là gì? ai là người biết lập trình? lập trình là gì? liệu lập trình chỉ là viết code theo requirements hay còn là gì khác? Ở đây không bàn đến đúng sai mà bàn tới good design and bad design. VD như cái điện thoại của bạn, để kéo dài thời gian sử dụng thì designer đầu tiên lắp cho nó một cục pin như pin máy khoan, còn người thứ hai thì giữ nguyên cục pin mini, tối ưu các thứ còn lại để tiết kiệm pin. tất cả đều là trade-off nhưng không phải trade-off nào cũng giống trade-off nào, mặc dù mục tiêu đã đạt được đều như nhau. Hoặc như cách tính số PI, trước khi Newton đưa ra công thức tính số PI thì trước đó người ta tính theo cách xấp xỉ đa giác. cũng ra được số Pi thôi, nhưng giờ có ai rãnh mà đi tính theo cách xấp xỉ đa giác đâu vì cách của Newton tối ưu hơn. Không lẽ giờ nhận xét cách tính bằng xấp xỉ đa giác không hay là "không biết gì về toán học"?
@futhedude4848
@futhedude4848 25 күн бұрын
22:14 đoạn này check hơi ảo nhỉ. step 1: setbit uu:bit 999999 1 xong kiểm tra dung lượng uu:bit, kq: 262192 step 2: set 999996 -> 999999 1 xong kiểm tra dung lượng, kq: 258 step 3: setbit uu:00 1 -> 5 1 xong kiểm tra dung lượng, kq: 56 các bước này nhằm giải thích tại sao setbit tiết kiệm hơn set thông thường, cơ mà 2 step đầu đều sử dụng 6 số từ 999996 -> 999999, step 3 lại sử dụng có 1 từ 1 -> 5, thì cũng đâu có giải thích được là tại sao setbit lại tiếp kiệm hơn set thường được, bởi vì giá trị chênh lệch quá mà.
@ntq023
@ntq023 Ай бұрын
sernior sernior sernior
Что-что Мурсдей говорит? 💭 #симбочка #симба #мурсдей
00:19
Don’t Choose The Wrong Box 😱
00:41
Topper Guild
Рет қаралды 62 МЛН
She made herself an ear of corn from his marmalade candies🌽🌽🌽
00:38
Valja & Maxim Family
Рет қаралды 18 МЛН
Tất cả các thuật toán Machine Learning trong 23 phút
25:59
Việt Nguyễn AI
Рет қаралды 75 М.
Github Actions - CI/CD chưa bao giờ dễ hơn thế
32:12
How To Handle Permissions Like A Senior Dev
36:39
Web Dev Simplified
Рет қаралды 339 М.
Что-что Мурсдей говорит? 💭 #симбочка #симба #мурсдей
00:19