thảo luận Hội Dev 35 đi phỏng vấn tìm việc.

thisismyfirstclone · 28/11/25

small-lambda đã nói:
giờ chẳng hạn cái drive có nhiều page trống không nằm liền kề nhau và không có khoảng trống nào đủ chứa một file cần viết, khi cho một lệnh write để viết cái file đó xuống disk thì chuyện có buffer có đảm bảo là cái file đó được viết hoàn toàn trong các page liền kề nhau không, hay sẽ sinh ra phân mảnh?

File system kiểu cũ sẽ bị phân mảnh, nó làm y như cách m vừa mô tả ấy, cứ điền vào chỗ trống. Nên ngày xưa mới có mấy cái tool để degragmentation (có cả 1 cái tool như vậy tích hợp trong windows ngày xưa).
Nhưng các file system sau này nó sử dụng cách khác, là chia thành các block groups. Còn tại sao chia thành block groups lại fix được các vấn đề trên thì m đọc trong cuốn operating system three easy pieces. Viết ra đây khác đ' gì ngồi dịch nguyên cả chương.
Còn có một dạng file system khác là Log-Structred File System, cách này thì đơn giản, cứ có ghi mới hoặc chỉnh sửa, là ghi ra block mới, block cũ sẽ bị garbage collectioni clear đi sau. Như vậy giảm số writes cho small writes mỗi khi update. Nhưng nó lại nảy sinh bài toán là tồn tại các dữ liệu "rác". Một số người khá khôn ngoan, là biến yếu điểm này thành đặc điểm của Log-Structred File System, tức là expose cả cái phần "rác" ấy ra cho user, gọi là versions của file. Thậm chí còn thu tiền cho phần "rác" ấy (ví dụ c-l-o-u-d).

small-lambda · 28/11/25

thisismyfirstclone đã nói:
File system kiểu cũ sẽ bị phân mảnh, nó làm y như cách m vừa mô tả ấy, cứ điền vào chỗ trống. Nên ngày xưa mới có mấy cái tool để degragmentation (có cả 1 cái tool như vậy tích hợp trong windows ngày xưa).
Nhưng các file system sau này nó sử dụng cách khác, là chia thành các block groups. Còn tại sao chia thành block groups lại fix được các vấn đề trên thì m đọc trong cuốn operating system three easy pieces. Viết ra đây khác đ' gì ngồi dịch nguyên cả chương.
Còn có một dạng file system khác là Log-Structred File System, cách này thì đơn giản, cứ có ghi mới hoặc chỉnh sửa, là ghi ra block mới, block cũ sẽ bị garbage collectioni clear đi sau. Như vậy giảm số writes cho small writes mỗi khi update. Nhưng nó lại nảy sinh bài toán là tồn tại các dữ liệu "rác". Một số người khá khôn ngoan, là biến yếu điểm này thành đặc điểm của Log-Structred File System, tức là expose cả cái phần "rác" ấy ra cho user, gọi là versions của file. Thậm chí còn thu tiền cho phần "rác" ấy (ví dụ c-l-o-u-d).

lol, lmao

thisismyfirstclone · 28/11/25

small-lambda đã nói:
lol, lmao

lmao cc, để giải thích đoạn mày nói, phải giải thích cả cách file nó được lưu trên đĩa ntn.
Còn đoạn m hỏi thì nó là đoạn này

small-lambda · 28/11/25

thisismyfirstclone đã nói:
lmao cc, để giải thích đoạn mày nói, phải giải thích cả cách file nó được lưu trên đĩa ntn.
Còn đoạn m hỏi thì nó là đoạn này
Xem tệp đính kèm 3359590

lol, lmao even

small-lambda · 28/11/25

thisismyfirstclone đã nói:
File system kiểu cũ sẽ bị phân mảnh, nó làm y như cách m vừa mô tả ấy, cứ điền vào chỗ trống. Nên ngày xưa mới có mấy cái tool để degragmentation (có cả 1 cái tool như vậy tích hợp trong windows ngày xưa).
Nhưng các file system sau này nó sử dụng cách khác, là chia thành các block groups. Còn tại sao chia thành block groups lại fix được các vấn đề trên thì m đọc trong cuốn operating system three easy pieces. Viết ra đây khác đ' gì ngồi dịch nguyên cả chương.
Còn có một dạng file system khác là Log-Structred File System, cách này thì đơn giản, cứ có ghi mới hoặc chỉnh sửa, là ghi ra block mới, block cũ sẽ bị garbage collectioni clear đi sau. Như vậy giảm số writes cho small writes mỗi khi update. Nhưng nó lại nảy sinh bài toán là tồn tại các dữ liệu "rác". Một số người khá khôn ngoan, là biến yếu điểm này thành đặc điểm của Log-Structred File System, tức là expose cả cái phần "rác" ấy ra cho user, gọi là versions của file. Thậm chí còn thu tiền cho phần "rác" ấy (ví dụ c-l-o-u-d).

ok, cho là mấy cái vớ vẩn trên giải quyết được vấn đề fragmentation đi, vầy mỗi lần viết xuống mắc gì phải xài write buffer nữa?

small-lambda · 28/11/25

small-lambda đã nói:
ok, cho là mấy cái vớ vẩn trên giải quyết được vấn đề fragmentation đi, vầy mỗi lần viết xuống mắc gì phải xài write buffer nữa?

mà chuyện đảm bảo write xuống luôn seq thì là ba cái vớ vẩn kia nó đảm bảo chứ dính líu gì tới cái write buffer?

thisismyfirstclone · 28/11/25

small-lambda đã nói:
ok, cho là mấy cái vớ vẩn trên giải quyết được vấn đề fragmentation đi, vầy mỗi lần viết xuống mắc gì phải xài write buffer nữa?

à vì m không biết một file lưu trong đĩa cấu trúc nó ntn đấy.

condao · 29/11/25

mấy ông cãi cao siêu làm gì. đôi lúc chỉ làm cái đơn giản, nhưng tốt nhất có thể cũng đủ rồi, làm mấy cái phức tạp cũng chả làm gì

))

Kaiser2013 · 29/11/25

condao đã nói:
mấy ông cãi cao siêu làm gì. đôi lúc chỉ làm cái đơn giản, nhưng tốt nhất có thể cũng đủ rồi, làm mấy cái phức tạp cũng chả làm gì ))

thread bị trôi quá bác ạ. Muốn nghe hội già nhưng trình ko cao hẳn chia sẻ mà k thấy mấy

small-lambda · 29/11/25

thisismyfirstclone đã nói:
à vì m không biết một file lưu trong đĩa cấu trúc nó ntn đấy.

enlighten us, O Wise One

canh_1412 · 29/11/25

vl chém gi mà low level vậy. có làm được không, hay chỉ sách vở đi dạy. t gặp nhiều thằng rồi chém kinh lắm. cứ tưởng chuyên gia. cuối cùng làm như mèo mửa, :ah:

hold_on_never_leave · 29/11/25

canh_1412 đã nói:
vl chém gi mà low level vậy. có làm được không, hay chỉ sách vở đi dạy. t gặp nhiều thằng rồi chém kinh lắm. cứ tưởng chuyên gia. cuối cùng làm như mèo mửa,

tích cực lên fen, ít ra họ dành thời gian để tìm hiểu là hơn nhiều người r, muốn làm được thì p học sách vở trc đã chứ

pes2020 · 29/11/25

luvziro đã nói:
Ông ấy tưởng tôi là dev nên mỉa mai con app tôi tự vibe

À, hóa ra lại là chân BA, PO chém gió

pes2020 · 29/11/25

Kaiser2013 đã nói:
thread bị trôi quá bác ạ. Muốn nghe hội già nhưng trình ko cao hẳn chia sẻ mà k thấy mấy

Anh ráng ra trung tâm tiếng Anh học giao tiếp với giáo viên bản xứ như Anh, Úc, Mỹ để lên trình nghe nói nếu tiếng Anh hiện tại chưa tốt. Tiền học phí 1 năm dưới 20 củ thôi
Rồi học design system dùng Redis, Kafka hay RabbitMQ đi thì mới có hy vọng xin được việc khá hơn nếu có bị layoff. Thuê 1 con VPS 50$ 1 tháng mà tập tành làm pet project Rust ActixWeb luôn cho máu, có AI hỗ trợ giờ làm dễ ợt

small-lambda · 29/11/25

canh_1412 đã nói:
vl chém gi mà low level vậy. có làm được không, hay chỉ sách vở đi dạy. t gặp nhiều thằng rồi chém kinh lắm. cứ tưởng chuyên gia. cuối cùng làm như mèo mửa,

hông, chình còi nên mới hóng thread này

hmmmmmmmmmmm · 29/11/25

Ông thisismyfirstclone chém tào lao vl. Đang nói về app + db tự nhiên đánh sang low level OS write buffer. Phần write buffer thì db nó handle, có ai mà đi viết lại cái db bao giờ. Mà bọn db nó cũng phải đảm bảo durability thì write buffer cũng là trong lúc cái câu query / transaction thôi chứ khi commit phải persist xuống đĩa luôn chứ buffer gì nữa.

Fragmentation cũng không liên quan tới write buffer, nó là do implementation về block allocation của file system. SSD không cần defragmentation vì không có disk seek như HDD. Truy xuất block đầu hay block cuối của SSD đều tốn thời gian như nhau cả

Boss Lacotes · 29/11/25

mấy bác chém gió về kĩ thuật đi , cứ chém đâu đâu ko

cho em hỏi, giả sử ở tầng app , mấy bác sài load balance, rồi mấy con server viết bằng rust chịu tải khủng khiếp , thì có cần chia db per services không

vì em thấy tầm nào quả DB cũng là cái nút thắt , nếu db chứa dữ liệu nosql thì thôi không nói

chứ DB chứa dữ liệu quan hệ , mà chia DB ra trên nhiều services , tới lúc cần query dữ liệu liên quan trên nhiều services, hoặc write dữ liệu lên nhiều services là mệt

chưa kể gọi services chồng chéo nhau , ừ thì các bác sẽ dùng các message queue , với pub/sub pattern để tránh gọi chằng chịt , nhưng nó cũng có rủi ro nếu server message queue sập

nên cho em hỏi, hiện giờ có con db nào thiết kể mà đạt được
1. tự động phân tán
2. nếu db phình to về mặt cấu trúc, nó cũng tự shard

-> nói chung dev sẽ chỉ lo việc tạo cấu trúc db , ràng buộc, query các thứ, còn chuyện phân tán thế nào khi dữ liệu phình to, cấu trúc phình to, hệ quản trị sẽ có chỗ config để handle

-> mục đích là để ko phải cắt nhỏ quá từng DB cho từng services , những domain nào 100% ko có gì phục thuộc vào bọn còn lại thì mới tách DB ra cho từng services

hmmmmmmmmmmm · 29/11/25

Boss Lacotes đã nói:
mấy bác chém gió về kĩ thuật đi , cứ chém đâu đâu ko

cho em hỏi, giả sử ở tầng app , mấy bác sài load balance, rồi mấy con server viết bằng rust chịu tải khủng khiếp , thì có cần chia db per services không

vì em thấy tầm nào quả DB cũng là cái nút thắt , nếu db chứa dữ liệu nosql thì thôi không nói

chứ DB chứa dữ liệu quan hệ , mà chia DB ra trên nhiều services , tới lúc cần query dữ liệu liên quan trên nhiều services, hoặc write dữ liệu lên nhiều services là mệt

chưa kể gọi services chồng chéo nhau , ừ thì các bác sẽ dùng các message queue , với pub/sub pattern để tránh gọi chằng chịt , nhưng nó cũng có rủi ro nếu server message queue sập

nên cho em hỏi, hiện giờ có con db nào thiết kể mà đạt được
1. tự động phân tán
2. nếu db phình to về mặt cấu trúc, nó cũng tự shard

-> nói chung dev sẽ chỉ lo việc tạo cấu trúc db , ràng buộc, query các thứ, còn chuyện phân tán thế nào khi dữ liệu phình to, cấu trúc phình to, hệ quản trị sẽ có chỗ config để handle

-> mục đích là để ko phải cắt nhỏ quá từng DB cho từng services , những domain nào 100% ko có gì phục thuộc vào bọn còn lại thì mới tách DB ra cho từng services

Server queue có khả năng sập thì db không có hả bạn?

Có thể tự động scale read replica chứ shard theo mình thì không, phải làm manually vì application phải quyết định route đến shard nào

Chia db và service thì phụ thuộc bạn chia domain theo business ntn cho hợp lý rồi dùng queue hoặc event để đạt eventual consistency. Chứ khó có chuyện 1 service hoàn toàn độc lập với toàn bộ các service khác của công ty.

condao · 29/11/25

Boss Lacotes đã nói:
mấy bác chém gió về kĩ thuật đi , cứ chém đâu đâu ko

cho em hỏi, giả sử ở tầng app , mấy bác sài load balance, rồi mấy con server viết bằng rust chịu tải khủng khiếp , thì có cần chia db per services không

vì em thấy tầm nào quả DB cũng là cái nút thắt , nếu db chứa dữ liệu nosql thì thôi không nói

chứ DB chứa dữ liệu quan hệ , mà chia DB ra trên nhiều services , tới lúc cần query dữ liệu liên quan trên nhiều services, hoặc write dữ liệu lên nhiều services là mệt

chưa kể gọi services chồng chéo nhau , ừ thì các bác sẽ dùng các message queue , với pub/sub pattern để tránh gọi chằng chịt , nhưng nó cũng có rủi ro nếu server message queue sập

nên cho em hỏi, hiện giờ có con db nào thiết kể mà đạt được
1. tự động phân tán
2. nếu db phình to về mặt cấu trúc, nó cũng tự shard

-> nói chung dev sẽ chỉ lo việc tạo cấu trúc db , ràng buộc, query các thứ, còn chuyện phân tán thế nào khi dữ liệu phình to, cấu trúc phình to, hệ quản trị sẽ có chỗ config để handle

-> mục đích là để ko phải cắt nhỏ quá từng DB cho từng services , những domain nào 100% ko có gì phục thuộc vào bọn còn lại thì mới tách DB ra cho từng services

lại ra câu hỏi chung chung vậy làm quái gì có câu trả lời, dữ liệu to bao nhiêu, độ tin cậy cần ra sao, có cần transaction không, đọc nhiều hay ghi nhiều. số lượng keep connection có không, số connection ... nhiều lúc đíu cần db nữa

Boss Lacotes · 29/11/25

hmmmmmmmmmmm đã nói:
Server queue có khả năng sập thì db không có hả bạn?

Có thể tự động scale read replica chứ shard theo mình thì không, phải làm manually vì application phải quyết định route đến shard nào

Chia db và service thì phụ thuộc bạn chia domain theo business ntn cho hợp lý rồi dùng queue hoặc event để đạt eventual consistency. Chứ khó có chuyện 1 service hoàn toàn độc lập với toàn bộ các service khác của công ty.

db lưu trên ổ cứng bác, message queue lưu trên ram để nâng cao tốc độ , có thể nó backup vào ổ cứng nhưng để khôi phục lại nếu gặp sự cố, lúc đó lại làm 1 cụm auto scale message queue nữa khá thốn

bác có nghĩ tương lai có kiểu kiến trúc nào db phân tán phần db, app phân tán phần app , miễn sao lúc read , write nó tìm đc đúng không

em nghĩ là có nhưng sẽ là đám gg, amz nó làm và bán dịch vụ cho mình sài, thốn tiền phết

thảo luận Hội Dev 35 đi phỏng vấn tìm việc.

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Chủ đề tương tự

Thống kê chủ đề

Chia sẻ trang này