Theo quan điểm của mình lưu ảnh sẽ có nhiều loại nhưng mình dùng 2 kiểu chính:
Hi @tieuthien.cntt
Cậu có thể giải thích thêm về cách 2 mà cậu đề cập ở dưới đây được không?
Tớ muốn nghe một chúc background và phân tích về cách này:
Hi vọng nhận được lời giải thích rõ hơn từ cậu.
Thực ra đó cách nghĩ của tuỳ người. Còn thực tế khi làm db hay dữ liệu họ đều có 1 cách đánh giá như sau:
1 dữ liệu đó có quan trọng hay ko? Nếu quan trọng ng ta ko ngần ngại lưu vào db cái đó để đảm bảo tính ok của dữ liệu. Và ảnh cmt nó ko có gì gọi lf mang sổ tay hay như nào cả.
2 là nhà mạng vietnamobile vinaphone và mobifone đều làm vậy.
Về vụ sổ tay, ý tớ là cái ảnh của cậu có kích thước tương đương với 1 cái sổ tay, cho cậu dễ hình dung Point của tớ là dữ liệu đó rất lớn, phòng TH cậu chưa hiểu.
Tớ đồng ý với cậu là tùy bài toán, cậu cần thiết kế khác nhau. Tuy nhiên, tớ sẽ diễn đạt lại ý trên của cậu (chính xác hơn là ý tớ hiểu về bài toán của Vinaphone/Mobile phone) như sau:
Vấn đề không phải dữ liệu đó có quan trọng hay không, vấn đề là yêu cầu về tính toàn vẹn dữ liệu.
Trong bài toán của Vinaphone, sự toàn vẹn dữ liệu xác thực rất quan trọng. Nếu 1 user mới được tạo ra, nó phải có ảnh CMT ngay lập tức, nhằm phục vụ xác thực.
Việc lưu trữ ảnh ở 1 external server khác có thể dẫn tới sự không toàn vẹn dữ liệu, khi ảnh đó có thể bị mất khi external server gặp vấn đề.
Tớ kỳ vọng sự giải thích cụ thể như vậy, hơn “dữ liệu đó quan trọng, nên nó được lưu vào DB” - quá abstract và khó thuyết phục. Và với vấn đề này, thiết kế đưa ảnh vào DB là hợp lý.
Cảm ơn cậu về mấy cái tên này nhé, tớ đoán chỉ trong TH CMT, sử dụng nhằm mục đích xác thực và yêu cầu cao về sự toàn vẹn dữ liệu xác thực, họ lưu ảnh như vậy. Chắc chắn in general, việc lưu ảnh trên DB ảnh hưởng rất lớn tới network consumption và performance.
Đây không phải vấn đề cách nghĩ của từng người đâu cậu.
Thiết kế là thứ được đưa ra để giải quyết vấn đề. Nếu thiết kế không có lý và giải quyết vấn đề, nó là rác rưởi.
Không có thứ gọi là “cách nghĩ từng người” để giải thích cho quyết định design.
Cậu không nên dùng cụm từ đó khi giải thích về quyết định thiết kế. Tất cả bọn tớ đều reasonable, và bọn tớ muốn nghe những thứ reasonable.
Thực ra thiết kế hay như nào cũng là cách nhìn nhận đánh giá của từng người. Còn ảnh lưu db mà suy rộng thì có nhiều giải pháp lắm. Còn đề xuất cách làm là để ng dùng lựa chọn tuỳ theo mục đích hệ thống của họ. Còn ảnh trc khi lưu vào db đều là ảnh quan trọng và tối giản đều đc resize trc khi lưu thôi. Còn nếu nói đến tốn network thì những cái upload download mới lo ngại đối với file lớn. Mình làm nhiều hệ thống r nội tại server của họ đầu tư rất mạnh nên ko có nhiều vde lắm
Tớ sẽ conclude thành 2 point dưới đây:
Hope it helps!
Nếu ảnh đó là public, ai cũng truy cập access được thì lưu path cho nhanh.
Anh làm một số hệ thống enterprise nó ko cho public list ảnh ra ngoài, lưu trên cloud hay localdisk phải có cơ chế mã hóa đàng hoàng. Muốn lấy được ảnh phải xác thực có quyền access đàng hoàng. Trong trường hợp đó lưu ảnh trong db là dễ implement nhất.
Trên kia người ta nói là làm web bán trà sữa ông ơi, chỉ là không hiểu vì sao bạn đó lạ không muốn lưu path của hình thôi.
Từ lúc comment trên topic này xong, mình không có theo dõi lại topic, nay xem lại thì không ngờ lại có người đi xa như vậy, vẫn nghĩ việc hình ảnh lưu vào db là bình thường, còn đặt ra giả thiết nếu lưu ảnh ở external server tạch con server thì sao
Comment này không nhắm đến ai, chỉ muốn có chút chia sẻ thế này
Việc làm được một tính năng gì đó chạy được, không có nghĩa là giải pháp đó chấp nhận được
Thông thường, dự liệu lưu trong database khá ít khi lên đến kB cho mỗi record
Việc lưu ảnh vào database, sẽ làm cho data đó lớn lên rất nhiều, làm cho băng thông giao tiếp giữa database và lớp code cũng tăng theo, các bạn cũng nên nhớ,
việc serve file hình 1 MB qua nginx nhẹ nhàng hơn việc đọc từ db ra cái hình 100KB rất nhiều
Việc database phải đọc lượng lớn dữ liệu, rồi nó lại chuyển cho code rồi lại chuyển cho gateway/proxy/web server cũng cần nhiều tài nguyên xử lý hơn
Với những file thường sử dụng thì cache cũng dễ giải quyết hơn nhiều với static file
Cả con server dễ chết hơn hay database service dễ chết hơn
File trên server dễ bị mất hay crassh hay không toàn vẹn hơn hay database dễ bị phát sinh hơn
Việc replicate, backup hình khi lưu file với lưu db và file, cái nào dễ hơn
Xoay quanh việc này còn cả khối vấn đề có thể phát sinh, các bạn chưa thấy không có nghĩa là không có
không ai khuyến khích làm những cái trò như vậy trong database (trừ những trường hợp đặc biệt, nhưng làm pet project thấy làm được thì không phải trường đặc biệt đâu)
Đâu phải chỉ lưu vào database mới bảo mật đâu bác. Nếu lưu cả ảnh, video vào database thì database sẽ rất nặng. Mình thấy hosting người ta cho thuê dung lượng chỉ vài chục MB, đến vài trăm MB thôi.
làm sao bác biết được ?
Thực ra các nhà mạng đó lưu và xử lý vì bên mình là đối tác đơn vị tạo và bán sản phảm cho bên nhà mạng. Mình cũng đã làm cho các đối tác đó cũng trong ngành gần 10 năm r. Quan điểm mình là show giải pháp cho mọi ng lựa chọn còn cách làm nó phù hợp phải xem tuỳ hệ thống và ng quyết định bạn ah
Đối với mình, mình vẫn ưu tiên giải pháp lưu data dạng binary (hình ảnh, document, âm thanh,…) lên storage services như S3 hay cùng lắm thì một ổ cứng có dung lượng lớn. Lý do là vì việc query data + hình dưới db sẽ kéo thời gian query lâu hơn. Việc backup, migrate, bảo trì hệ thống cũng phức tạp hơn. Đặc biệt là backup/restore. 1 db 20 tables, mỗi table khoảng 1m records dump ra cũng gần 2GB rồi, lưu cả binary data thì vài chục GB dump là thường. Tuy nhiên nếu ít lưu binary hay file binary chỉ là optional như thumbnail trong một ô sản phẩm thì lưu dưới db vẫn OK
Câu trả lời là tùy hoàn cảnh mà chọn giải pháp
Trong hoàn cảnh này mà tư vấn (nhắc tới) việc lưu ảnh vào db như là một sự lựa chọn thì các bạn nào chọn tự đánh giá lại.
Ý kiến của mình tới đây là hết
Không phải không muốn lưu path anh ạ. Ý em là có cách nào khác ngoại trừ lưu path.
Có 1 cách khác đơn giản (nhưng tiện/tốt không thì là vấn đề khác), là bạn convert hình sang text (google cụm từ convert image to base 64), sau đó lưu đoan text đó vào database.
Khi cần display ra html, thì lấy text ra show như show path của image bình thường (google cụm từ display base64 image html)
Làm cách này thì bạn không cần lưu hình trên server/hosting luôn, chỉ cần lưu phần text (hình đã mã hoá sang base64) vào database là xong.
Vậy thì dùng blob còn hơn (vì dùng Base64 sẽ bị tăng kích thước).
Đúng là cách này không hay, nhưng nó giải quyết được bài toán chủ topic đưa ra.
Chào mn cho mình hỏi: nếu không lưu ảnh ở DB thì project upload ảnh sẽ xử lý ảnh như thế nào để lưu vào một nơi khác?
Xin cảm ơn!
Mình là người ngoại đạo …
Nhưng để lưu ảnh vào đâu thì theo mình là nên lưu mỗi tên file ảnh trong DB , còn path thì sẽ lưu vào 1 biến .Khi nào cần show cái ảnh thì join 2 cái path và tên file ảnh là ra đường dẫn file ảnh, video,document… !
Nó cũng dễ dàng để tùy chỉnh khi bạn muốn thay nó bằng path của dịch vụ Cloud,SFTP… thì chỉ cần thay đổi giá trị của biến path là xong
Không nên lưu cái ảnh đó vô DB vì nó vô cùng tốn tài nguyên…Nếu k muốn ng khác truy cập vô file ảnh thì mã hóa nó và lưu nó vô 1 thư mục riêng mà chỉ những ai cấp quyền ms đc phép truy cập đc!
Bạn có thể tham khảo gợi ý của mềnh…
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?