Gửi mọi người Group Telegream Wecommit Public Community : www.wecommit.com.vn/wecommitcommunity ,anh em có thể trao đổi những câu hỏi , vấn đề khi xem Video và kết nối với tôi trong Group nhé (trường hợp click trực tiếp bị lỗi thì ae copy link ra browser nhé)
Cảm ơn anh Huy giải thích rất chi tiết từ kiến trúc của 2 loại database ạ. Với hệ thống write nhiều và có nhiều index thì hiệu năng postgreSQL bị ảnh hưởng, tuy nhiên với những câu lệnh phức tạp thì để phân tích và đưa ra execution plan thì postgreSQL mạnh hơn MySQL. Do đó với hệ thống nhỏ, truy vấn đơn giản thì dùng ông nào cũng được, với hệ thống cần truy vấn những câu lệnh phức tạp thì PostgreSQL ngon hơn.
@@tranquochuywecommit "hệ thống write nhiều và có nhiều index" thì MySQL có cơ chế table riêng ngon hơn, vậy tại sao postgres ko sử dụng cơ chế tương tự? phải chăng làm thế thì nó ko phân tích và optimize đc câu query cho insert/update?
Vì trong innoDB mysql thì index và dữ liệu là 1 thể thống nhất .Còn postgres thì index và dữ liệu lưu riêng biệt (mysql các bảng nó lưu trong 1 file có tên là .ibd còn postgresql thì phân chia phức tạp hơn và qua 1 thứ gọi là OID) Khi 1 truy vấn đi vào , cơ chế index tách riêng giúp postgresq có thể kết hợp các loại chỉ mục khác nhau trong câu truy vấn tốt hơn và không bị hạn chế I/O. Còn mysql thì ngược lại do index và dữ liệu là 1 thể thống nhất -> khi bạn search thực tế là nó quét luôn dòng dữ liệu và index 1 lúc làm tăng I/O cũng như không thể kết hợp các index với nhau được ( vì muốn kết hợp thì bắt buộc phải load toàn bộ data) Do vậy khi write -> cơ chế chỉ mục và dữ liệu là 1 thể thống nhất giúp cho việc nó chỉ write 1 lần duy nhất index bị ảnh hưởng thôi . Ngược lại khi tách dữ liệu và index , thì write -> bắt buộc phải write cho toàn bộ index . Đó là lí do tại sao postgresql bạn có thể làm việc tốt với dữ liệu json , vì bản chất nó chỉ tốn I/O cho việc load các dữ liệu có index thôi . Mysql thì nó phải load luôn cả dòng dữ liệu chứa json , điều này làm tăng I/O . Tóm tắt : Mysql khi load secondery index -> đối chiếu với primary key -> ra kết quả (tốn x2 công việc) Postgresql : load 1 lần duy nhất và không có khái niệm secondery index (bản chất là không có khóa chính) -> đẩy vào heap
@@futhedude4848 Ok nha bạn . Nếu mình có phát biểu sai gì đó thì cho mình thêm thông tin nha . Cái này mình cũng chỉ nghiên cứu sơ qua có thể không chính xác ở các bản version khác nhau
nói thế này thì dìm hàng postgresql quá. với cả kiến thức cũng SAI. Khi đã nói đến MVCC thì bản chất cả 2 thằng nó đều dùng chung 1 cách cả thôi. Trừ khi mysql không sử dụng innodb ví dụ như dùng myisam thì mới có chuyện ghi đè dữ liệu. Với cả không có chuyện nó phải index lại toàn bộ các row khác =)) Học lại kiến thức cơ bản đi anh ooi.
Cảm ơn anh Huy, kiến thức rất chất lượng, ngắn gọn xúc tích, hiểu luôn được bản chất vấn đề và có tư duy đánh giá lựa chọn database phù hợp. Tiện đây em có bổ sung thêm cho postgres database có cơ chế gọi là "Heap-Only Tuples (HOT)" giúp tái sử dụng lại các vùng dữ liệu cấp cũ, giúp giảm kích thước bảng, index và giảm gánh nặng cho vacuum (vacuum giống như 1 cô dọn vệ sinh trong trường học ). Nhờ "HOT" giúp các hạn chế mvcc của postgres được cải thiện khá nhiều ạ.
Xem những video của anh Huy như nghe một câu chuyện, xem một bộ phim mà mình yêu thích. Muốn nuốt từng dòng đừng đoạn 1 😊😊😊. Kiến thức chuyên sâu và năng lượng chia sẻ tích cực làm người nghe phát sướng. Cảm ơn anh rất nhiều, cảm ơn anh đã chia sẻ.🤩🤩🤩
Thanks anh, PostgreSQL vs MySQL là những CSDL rất phổ biến và đặc biệt là miễn phí, do vậy trong các cty ae DEV thường làm từ a-z, rất cần những kiến thức hữu ích như vậy. Vote 5* cho video này.
A có thể chia sẻ nguồn bài viết được ko? Chưa từng nghe về ref column trong mvcc Khi update thì pg sẽ tạo new row version với transaction id, xmin,xmax Sở dĩ transaction khác ko đọc dc uncommited data là vì transaction khác read commited data từ snapshot trong quá khứ, ko phải snapshot mà current transaction đang dùng
Cũng từng tìm hiểu để xem thì cũng chỉ biết là postgres không nên sử dụng vào trong trường hợp ghi nhiều với các bài test chứ cũng chưa hiểu rõ vì sao. nay thấy video giải thích của anh rõ luôn
@@tranquochuywecommit có video của a là hiểu rõ vấn đề, e dùng nhiều về mysql cũng đã cài posgres bài toán to nên chưa gặp vấn đề về dữ liệu để phải suy nghĩ lựa chọn. với lại cái pgadmin quản lý đang hơi rườm rà.
Anh có cả video mysql full và postgres full trên kênh này đấy. Nếu em muốn nghiên cứu có thể xem 2 video này, nó tiết kiệm nhiều thời gian đọc tài liệu cho em.
mọi thứ bắt nguồn từ sự tò mò và mong muốn tìm hiểu sâu trong lĩnh vực này em ạ. Anh học và đọc rất nhiều. Đọc documents là điều bắt buộc rồi, ngoài ra anh học từ nhiều thứ trong quá trình làm các dự án và nghiên cứu các vấn đề gặp phải trong dự án. Anh cũng có 1 cộng đồng chia sẻ các dự án với nhau, nên nhiều cơ hội để tìm hiểu.
Việc chọn giữa MySQL và PostgreSQL phụ thuộc vào yêu cầu cụ thể của ứng dụng và môi trường sử dụng. -> Chọn MySQL trong trường hợp xây dựng một hệ thống OLTP như ứng dụng web cần hiệu suất cao và dễ quản lý, hoặc nếu ứng dụng của bạn có lượng truy vấn ghi (write) nhiều hơn đọc (read). -> Chọn PostgreSQL trong trường hợp xây dựng hệ thống OLAP như Data warehouse để xử lý các truy vấn đọc (read) phức tạp.
Đầu tiên e cảm ơn a vì những chia sẻ bổ ích của a. e có 1 câu hỏi ạ. Mysql: theo a nói thì những thằng khác (nhưng thằng không thực hiện lệnh update) thì sẽ lấy dữ liệu trong vùng undo đúng k ạ. vậy thì lúc không có thằng nào update thì vùng undo đấy nó có tồn tại không a. - nếu có thì tức là mỗi câu lệnh select nó đều phải check trước liệu data có trong undo trước đúng không ạ. - nếu không phải lúc nào cũng tồn tại thì làm sao để nó phân biệt được lúc nào cần check trong undo lúc nào query trực tiếp trong bảng thực ạ. Lần nữa cảm ơn a và nếu được a có thể đi kèm với documents về mvcc của postgres và mysql được không ạ.
Cảm ơn kiến thức rất bổ ích từ bạn, mình xin hỏi một câu: Vậy tại sao PostgreSQL lại làm điều tưởng chừng "ngu ngốc" như vậy khi UPDATE, có chăng lý do nào có lợi ở mặt khác nên PostgreSQL đã chọn thiết kế như thế?
Mình nghĩ đấy là chi phí đánh đổi thôi. UPDATE nó cồng kềnh, nhiều thông tin cần update thì đến lúc đọc, explain query thì Postgre lại có lợi thế hơn. Nên mình nghĩ => heavy update -> Mysql còn heavy READ => Postgre
Cảm ơn anh❤. Anh có thể so sánh giữa 2 loại database trả phí là MSSQL và Oracle được không ạ? Với các hệ thống quản lý dữ liệu lớn thì em thấy các công ty ở Việt Nam dùng Oracle nhiều hơn MSSQL. Có phải vì Oracle tối ưu về mặt chi phí hơn không ạ?
Em cảm ơn vì video hay của anh, rất chi tiết rõ ràng dễ hiểu ,em có câu hỏi về mysql khi không may chạy lệnh deleted all các bản ghi trong bảng cần back lại thì làm thế nào ạ
Anh Huy cho em hỏi tại sao Postgre lại dùng cơ chế tạo thêm dòng trong mvcc. Rõ ràng đây là một lỗ hổng trong hiệu năng của hệ thống. Postgre làm như đổi lại được điều gì?
Mặc dù việc tạo thêm dòng trong MVCC có thể gây ra chi phí về không gian lưu trữ và yêu cầu thực hiện VACUUM để duy trì hiệu suất, lợi ích mà MVCC mang lại trong việc quản lý đồng thời và đảm bảo tính nhất quán dữ liệu vượt trội hơn nhiều so với các hạn chế này. Đây là lý do tại sao PostgreSQL chọn cơ chế MVCC, mang lại một hệ thống quản lý cơ sở dữ liệu mạnh mẽ và hiệu quả cho các ứng dụng hiện đại. 1. Tính nhất quán mà không khóa (Lock-free Consistency) MVCC cho phép các giao dịch đọc và ghi cùng lúc mà không cần chặn nhau. Điều này đạt được bằng cách tạo ra các phiên bản khác nhau của cùng một dòng dữ liệu: Đọc không khóa: Các giao dịch đọc có thể đọc dữ liệu phiên bản cũ ngay cả khi có các giao dịch ghi đang diễn ra, miễn là dữ liệu này phù hợp với thời gian snapshot của giao dịch. Ghi không chặn: Các giao dịch ghi có thể tạo phiên bản mới của dòng dữ liệu mà không làm gián đoạn các giao dịch đọc đang tồn tại. 2. Isolation Levels và Snapshot Isolation PostgreSQL cung cấp các mức độ cô lập khác nhau để quản lý sự cô lập của giao dịch, từ Read Uncommitted đến Serializable: Snapshot Isolation: Mỗi giao dịch nhìn thấy một "snapshot" của cơ sở dữ liệu tại thời điểm nó bắt đầu. Điều này giúp giảm hiện tượng đọc bẩn (dirty reads) và đọc không lặp lại (non-repeatable reads), cải thiện tính nhất quán mà không cần khóa nhiều. 3. Giảm xung đột (Conflict Reduction) MVCC giảm xung đột giữa các giao dịch đọc và ghi. Trong cơ chế khóa truyền thống, giao dịch đọc phải chờ cho giao dịch ghi hoàn thành, dẫn đến tình trạng nghẽn cổ chai. Với MVCC, nhiều giao dịch có thể diễn ra đồng thời, cải thiện hiệu suất tổng thể. 4. Lợi ích của Vacuum PostgreSQL sử dụng cơ chế VACUUM để dọn dẹp các phiên bản cũ của dòng dữ liệu: Dọn dẹp và tái sử dụng không gian: VACUUM xóa bỏ các phiên bản không còn cần thiết, tái sử dụng không gian đã được giải phóng. Phân mảnh giảm thiểu: Mặc dù VACUUM cần tài nguyên, nó giúp duy trì hiệu suất cơ sở dữ liệu bằng cách giảm phân mảnh và giữ cho kích thước cơ sở dữ liệu không tăng quá mức. 5. Độ tin cậy và khôi phục (Reliability and Recovery) MVCC giúp PostgreSQL khôi phục cơ sở dữ liệu một cách dễ dàng hơn: Khôi phục sau sự cố: Nếu hệ thống gặp sự cố, các giao dịch chưa hoàn thành sẽ không ảnh hưởng đến các phiên bản dữ liệu đã được xác nhận (committed). Tăng khả năng phục hồi: Cơ chế này giúp bảo vệ dữ liệu khỏi các lỗi phần cứng và phần mềm bằng cách duy trì nhiều phiên bản dữ liệu. 6. Tối ưu hóa hiệu suất cho các tải công việc cụ thể MVCC có thể tối ưu hóa cho các ứng dụng cụ thể: Ứng dụng nhiều đọc: Với các ứng dụng có tỷ lệ đọc cao, MVCC cho phép các giao dịch đọc thực thi nhanh chóng mà không bị chặn bởi các giao dịch ghi. Ứng dụng nhiều ghi: MVCC có thể xử lý tốt các ứng dụng ghi nhiều mà không ảnh hưởng nhiều đến hiệu suất đọc.
Nếu cập nhật mà thêm record(đối với Posgres) thì thì sẽ lấy-gán ID như thế nào anh? Có giống như lúc insert? VÍ dụ last id = 100, sau đó 100 transaction update và không có cái nào commit thì id.nextVal() lúc này là 101 hay 201?
Cảm ơn anh về bài chia sẻ này, nó rất hay và giúp em hiểu ra một vài vấn đề của dự án em đang làm. Tuy nhiên em có 1 câu hỏi đó là khi mà postgres thêm 1 dòng mới khi chạy câu lệnh update thì đối với bảng có id là unique thì không biết là nó có vi phạm cái unique này không bởi như em thấy trong vd của anh là bản ghi thêm mới khi đó có id là y hệt bản ghi cũ. Mong sớm nhận được phản hồi từ anh ạ :D
Cái tiến trình vancum mình có thể setting thời gian nó chạy được không nhỉ ! ví dụ set vao bản đêm ko phải giờ cao điểm để bớt giành tài nguyên của table
nếu nói chi tiết hơn về vacuum trong postgresql thì nó có 2 kiểu: tự động và thủ công. Anh em có thể điều chỉnh chiến lược và thời gian để tiến trình vacuum ảnh hưởng ít nhất tới hiệu năng.
Hmm nếu thế trong MySQL, khi có 2 người cùng update mà chưa commit, vd như em update "Huy -> 1800", anh update "Huy -> 1500" thì lúc đó bảng sẽ lưu trữ cả 2 update mà chưa commit này như thế nào ạ?
2 ông cùng update 1 bản ghi đúng không em. Trường hợp đấy thì database sẽ sử dụng cơ chế LOCK. Người đầu tiên gõ lệnh UPDATE thì sẽ được thực hiện, ông thứ 2 thì bị LOCK, phải chờ ông đầu tiên update xong (commit hoặc rollback) thì mới được làm tiếp
Up@@tranquochuywecommit Với nếu thế thì rất dễ xảy ra deadlock. Vd như có 2 câu lệnh Update của 2 người khác nhau: - Transaction 1: "Update bản ghi 1 Update bản ghi 2" - Transaction 2: "Update bản ghi 2 Update bản ghi 1" Trường hợp nhiều CCU thì có khả năng ô thứ 1 get dc lock của bản ghi 1, và ô thứ 2 get dc lock của bản ghi 2. Nếu thế thì deadlock xảy ra r mà nhỉ?
Em có thắc mắc là khi câu lệnh SQL của em không thay đổi trong các lần chạy tiếp theo, nhưng mà lúc sau em đánh Index trên bảng cần truy vấn, thì việc phân tích chiến lược thực thi có được phân tích lại không ạ? Em cảm ơn!
khi em bổ sung các thông tin mới, ví dụ như Index mà em nói, chiến lược thực thi sẽ được cân nhắc, đánh giá lại. Tuy nhiên việc lựa chọn vẫn dựa trên Cost ông nào thấp nhất, không phải cứ đánh Index là ngon. Chính vì thế, anh em lập trình lúc đánh index xong phải kiểm tra chiến lược thực thi xem câu lệnh nó có dùng được không nhé.
Kết quả theo số đông người chọn anh em ah. Vote trên nhiều nhóm + TH-cam tab cộng đồng. Anh em xem trên tab cộng đồng youtube sẽ thấy đa số anh em chọn PostgreSQL vs MySQL. Video sau mình có làm về Oracle vs SQL Server đấy
mỗi loại database sẽ có các cơ chế riêng. Oracle, MySQL, PostgreSQL, SQL Server tuy là cùng RDBMS nhưng mỗi loại nó có các kiến trúc sẽ khác nhau đôi chút. NoSQL thì cũng phải xét kiến trúc riêng anh em ạ
@@Phamviet008 Chả có gì buồn cười cả bạn ạ. Chúng ta là người Việt, đều nói tiếng Việt, video cũng dành cho người Việt. Mấy cái đấy nói lái sang tiếng Việt cho dễ nghe thì không có vấn đề gì cả bạn ạ. giống như bạn nói tiếng Anh với người nước ngoài thì ví dụ tên người. bạn sẽ đọc rõ chữ "Cường", hay sẽ nói lái sang là "Cuong" ?
Gửi mọi người Group Telegream Wecommit Public Community : www.wecommit.com.vn/wecommitcommunity ,anh em có thể trao đổi những câu hỏi , vấn đề khi xem Video và kết nối với tôi trong Group nhé (trường hợp click trực tiếp bị lỗi thì ae copy link ra browser nhé)
Cảm ơn anh Huy giải thích rất chi tiết từ kiến trúc của 2 loại database ạ. Với hệ thống write nhiều và có nhiều index thì hiệu năng postgreSQL bị ảnh hưởng, tuy nhiên với những câu lệnh phức tạp thì để phân tích và đưa ra execution plan thì postgreSQL mạnh hơn MySQL. Do đó với hệ thống nhỏ, truy vấn đơn giản thì dùng ông nào cũng được, với hệ thống cần truy vấn những câu lệnh phức tạp thì PostgreSQL ngon hơn.
hiểu từ kiến trúc anh em sẽ rất tự tin và nhớ lâu.
Một ngày tuyệt vời nhé em
@@tranquochuywecommit "hệ thống write nhiều và có nhiều index" thì MySQL có cơ chế table riêng ngon hơn, vậy tại sao postgres ko sử dụng cơ chế tương tự? phải chăng làm thế thì nó ko phân tích và optimize đc câu query cho insert/update?
Vì trong innoDB mysql thì index và dữ liệu là 1 thể thống nhất .Còn postgres thì index và dữ liệu lưu riêng biệt (mysql các bảng nó lưu trong 1 file có tên là .ibd còn postgresql thì phân chia phức tạp hơn và qua 1 thứ gọi là OID)
Khi 1 truy vấn đi vào , cơ chế index tách riêng giúp postgresq có thể kết hợp các loại chỉ mục khác nhau trong câu truy vấn tốt hơn và không bị hạn chế I/O.
Còn mysql thì ngược lại do index và dữ liệu là 1 thể thống nhất -> khi bạn search thực tế là nó quét luôn dòng dữ liệu và index 1 lúc làm tăng I/O cũng như không thể kết hợp các index với nhau được ( vì muốn kết hợp thì bắt buộc phải load toàn bộ data)
Do vậy khi write -> cơ chế chỉ mục và dữ liệu là 1 thể thống nhất giúp cho việc nó chỉ write 1 lần duy nhất index bị ảnh hưởng thôi .
Ngược lại khi tách dữ liệu và index , thì write -> bắt buộc phải write cho toàn bộ index .
Đó là lí do tại sao postgresql bạn có thể làm việc tốt với dữ liệu json , vì bản chất nó chỉ tốn I/O cho việc load các dữ liệu có index thôi . Mysql thì nó phải load luôn cả dòng dữ liệu chứa json , điều này làm tăng I/O .
Tóm tắt : Mysql khi load secondery index -> đối chiếu với primary key -> ra kết quả (tốn x2 công việc)
Postgresql : load 1 lần duy nhất và không có khái niệm secondery index (bản chất là không có khóa chính) -> đẩy vào heap
@@Huynguyen-ew1ep note ở đây để t2 quay lại ngâm cứu ạ.
@@futhedude4848 Ok nha bạn . Nếu mình có phát biểu sai gì đó thì cho mình thêm thông tin nha .
Cái này mình cũng chỉ nghiên cứu sơ qua có thể không chính xác ở các bản version khác nhau
Công thức tạo dựng sự nghiệp không giới hạn của tôi - TOP 1% SECRET: www.top1percentsecret.com/
nói thế này thì dìm hàng postgresql quá. với cả kiến thức cũng SAI. Khi đã nói đến MVCC thì bản chất cả 2 thằng nó đều dùng chung 1 cách cả thôi. Trừ khi mysql không sử dụng innodb ví dụ như dùng myisam thì mới có chuyện ghi đè dữ liệu. Với cả không có chuyện nó phải index lại toàn bộ các row khác =)) Học lại kiến thức cơ bản đi anh ooi.
xem phân tích và demo đi anh em, anh em học ngọn không học gốc rồi, mình phân tích, dẫn chứng cụ thể chứ có nói vu vơ đâu
những kiến thức có lẽ chỉ có trong những khóa học phải bỏ tiền ra mua, thì lại miễn phí ở kênh của anh.
thật sự cảm ơn anh rất nhiều
Cảm ơn anh Huy, kiến thức rất chất lượng, ngắn gọn xúc tích, hiểu luôn được bản chất vấn đề và có tư duy đánh giá lựa chọn database phù hợp. Tiện đây em có bổ sung thêm cho postgres database có cơ chế gọi là "Heap-Only Tuples (HOT)" giúp tái sử dụng lại các vùng dữ liệu cấp cũ, giúp giảm kích thước bảng, index và giảm gánh nặng cho vacuum (vacuum giống như 1 cô dọn vệ sinh trong trường học ). Nhờ "HOT" giúp các hạn chế mvcc của postgres được cải thiện khá nhiều ạ.
Hay quá, làm dev lâu năm giờ mới biết được những kiến thức này
cảm ơn em nhé
Xem những video của anh Huy như nghe một câu chuyện, xem một bộ phim mà mình yêu thích. Muốn nuốt từng dòng đừng đoạn 1 😊😊😊. Kiến thức chuyên sâu và năng lượng chia sẻ tích cực làm người nghe phát sướng. Cảm ơn anh rất nhiều, cảm ơn anh đã chia sẻ.🤩🤩🤩
đọc bình luận của chú thú vị không kém.
Cảm ơn Đam nhé
@@tranquochuywecommit em luyện thành 1 chuyên gia cmt dạo được đấy a nhỉ
@@damvv.ptit12 được đấy chú, đã làm gì thỉ phải Top 1% trong việc mình làm. Hiệu quả đều đến cả
E học đc rất nhiều thứ từ trang của a, từ kiến thức chuyên môn cho tới tư duy trong công việc.
kiến thức của a rất bổ ích. em muốn hỏi thêm: microsoft SQL server thì sao a
Hay quá, cảm ơn a, e hiểu hơn vì sao Big data open source họ hay lấy Postgresql làm gốc
Thanks anh, PostgreSQL vs MySQL là những CSDL rất phổ biến và đặc biệt là miễn phí, do vậy trong các cty ae DEV thường làm từ a-z, rất cần những kiến thức hữu ích như vậy. Vote 5* cho video này.
Cảm ơn anh đã chia sẻ các kinh nghiệm phong phú, tiện đây em muốn hỏi là anh có thể thực hiện bài đánh giá cho SurrealDB, MongoDB và ScyllaDB không ạ?
A có thể chia sẻ nguồn bài viết được ko?
Chưa từng nghe về ref column trong mvcc
Khi update thì pg sẽ tạo new row version với transaction id, xmin,xmax
Sở dĩ transaction khác ko đọc dc uncommited data là vì transaction khác read commited data từ snapshot trong quá khứ, ko phải snapshot mà current transaction đang dùng
Cảm ơn a Huy về bài chia sẻ, rất hay và áp dụng được liền vào các bài toán thực tế
Em cảm ơn anh ạ. Anh giải thích rất chi tiết và giúp em rút ngắn được thời gian tìm hiểu và học tập về database rất nhiều
chào mừng em đến với kênh youtube của anh.
Quá hay nếu anh không nói ra thì có lẽ sẽ mất thêm nhiều năm nữa để hiểu cơ chế của MYSQL và POSTGRES.
Cảm ơn anh, chúc anh nhiều sức khỏe.
người anh em đăng ký kênh để nhận được thông tin sớm nhất của các video sắp tới nhé
Cũng từng tìm hiểu để xem thì cũng chỉ biết là postgres không nên sử dụng vào trong trường hợp ghi nhiều với các bài test chứ cũng chưa hiểu rõ vì sao.
nay thấy video giải thích của anh rõ luôn
đi từ kiến trúc thì anh em sẽ thấy mọi thứ rất rõ ràng, vì thế anh luôn chia sẻ mọi thứ dưới góc độ này.
Cảm ơn em đã ủng hộ video của anh nhé
@@tranquochuywecommit có video của a là hiểu rõ vấn đề, e dùng nhiều về mysql cũng đã cài posgres bài toán to nên chưa gặp vấn đề về dữ liệu để phải suy nghĩ lựa chọn. với lại cái pgadmin quản lý đang hơi rườm rà.
1 video cực kì chất lượng, cảm ơn anh đã chia sẻ
Hay quá anh ạ. Mong anh ra nhiều videos hơn nữa nhé. Cảm ơn anh rất nhiều ạ
Cám ơn anh, em đang từ mongo muốn quay lại đào sâu nghiên cứu 2 ông này thì lại gặp được video của anh đúng lúc 😂
Anh có cả video mysql full và postgres full trên kênh này đấy. Nếu em muốn nghiên cứu có thể xem 2 video này, nó tiết kiệm nhiều thời gian đọc tài liệu cho em.
Có thể cho mình hỏi dùng phần mềm gì để present bằng apple pen ko ah?
Cảm ơn anh Huy rất nhiều, kiến thức rất chất lượng ạ 😊
cảm ơn anh ạ, anh cho em hỏi làm sao để anh tìm hiểu được những thứ như này vậy ạ, danh đọc source code, đọc docs hay làm gì khác vậy ạ
mọi thứ bắt nguồn từ sự tò mò và mong muốn tìm hiểu sâu trong lĩnh vực này em ạ.
Anh học và đọc rất nhiều. Đọc documents là điều bắt buộc rồi, ngoài ra anh học từ nhiều thứ trong quá trình làm các dự án và nghiên cứu các vấn đề gặp phải trong dự án.
Anh cũng có 1 cộng đồng chia sẻ các dự án với nhau, nên nhiều cơ hội để tìm hiểu.
Cảm ơn kiến thức a chia sẽ 🙏🙏🙏
Việc chọn giữa MySQL và PostgreSQL phụ thuộc vào yêu cầu cụ thể của ứng dụng và môi trường sử dụng.
-> Chọn MySQL trong trường hợp xây dựng một hệ thống OLTP như ứng dụng web cần hiệu suất cao và dễ quản lý, hoặc nếu ứng dụng của bạn có lượng truy vấn ghi (write) nhiều hơn đọc (read).
-> Chọn PostgreSQL trong trường hợp xây dựng hệ thống OLAP như Data warehouse để xử lý các truy vấn đọc (read) phức tạp.
Postgress cũng vẫn là OTLP, OLAP em nghĩ nên chọn 1 csdl chuyên OLAP anh ạ.
note ở đây để t2 quay lại ngâm cứu ạ.
Đầu tiên e cảm ơn a vì những chia sẻ bổ ích của a. e có 1 câu hỏi ạ.
Mysql: theo a nói thì những thằng khác (nhưng thằng không thực hiện lệnh update) thì sẽ lấy dữ liệu trong vùng undo đúng k ạ. vậy thì lúc không có thằng nào update thì vùng undo đấy nó có tồn tại không a.
- nếu có thì tức là mỗi câu lệnh select nó đều phải check trước liệu data có trong undo trước đúng không ạ.
- nếu không phải lúc nào cũng tồn tại thì làm sao để nó phân biệt được lúc nào cần check trong undo lúc nào query trực tiếp trong bảng thực ạ.
Lần nữa cảm ơn a và nếu được a có thể đi kèm với documents về mvcc của postgres và mysql được không ạ.
Vậy Postgre phù hợp với các bài toán thực tế nào anh nhỉ? Với hệ thống ERP doanh nghiệp khoảng 100 user có ổn không? Cảm ơn anh
hệ thống mà nhỏ thì dùng loại nào cũng được anh em nhé
@@tranquochuywecommit Vậy Postgre sẽ không ổn nếu số lượng concurrent user từ bao nhiêu trở lên ạ. Hệ thống ERP ạ
@@bongakinhien2340 xem kỹ phần PostgreSQL và MySQL phù hợp cái nào ở trong video nhé anh em.
e có 1 thắc mắc về clip oracle a có nói mySQL có tempdb chứ không có undo anh
Video hay quá ạ
Anh làm tiếp về MongoDB và Cassandra được không ạ
tôi đăng ký ba nick cho ông rồi đấy bởi vì kênh quá hay
Kênh phát triển nhanh quá, chúc mừng anh Huy
cảm ơn chú nhé
kiến thức quá tuyệt vời. cảm ơn đã chia sẻ. so sánh giữa PostgreSQL với SQL Server đi a.
Đang có 1 loạt ý tưởng, xem so sánh cái nào anh em ah
1. PostgreSQL vs Oracle
2. PostgreSQL vs MongoDB
3. SQL Server vs Oracle
4. MySQL vs Oracle
@@tranquochuywecommit anh làm so sánh 3.mssql với oracle trước đi ạ
Kiến thức quá hay anh ơi. Cảm ơn ah đã chia sẻ ạ
Video này tiếp tục khiến em phải wow. Cảm ơn anh Huy nhiều ạ
anh có thể làm bài so sánh MVCC postgresql với MSSQL không, bỏ qua vấn đề chi phí. Xin cám ơn anh
Cảm ơn anh , Video rất hay , anh hãy so sánh PostgreSQL vs Oracle đi anh .
anh Huy ơi, anh xài phần mềm gì để vẽ trên Ipad và record trực tiếp vậy ạ? Em đang muốn làm video kiểu như vậy.
goodnotes với obs anh em nhé.
Anh em có thể kết bạn với tôi (thông tin trong phần bình luận), có gì giúp được tôi giúp cho
@@tranquochuywecommit dạ vâng, em cảm ơn anh Huy nhiều.
Những kiến thức đáng quý đến khi xem xong video này em mới biết. Trân trọng từng video anh chia sẻ ạ!
Dev hơn 10 năm giờ mới nắm được kiến thức này. Cảm ơn anh ạ
Cảm ơn kiến thức rất bổ ích từ bạn, mình xin hỏi một câu: Vậy tại sao PostgreSQL lại làm điều tưởng chừng "ngu ngốc" như vậy khi UPDATE, có chăng lý do nào có lợi ở mặt khác nên PostgreSQL đã chọn thiết kế như thế?
Mình nghĩ đấy là chi phí đánh đổi thôi. UPDATE nó cồng kềnh, nhiều thông tin cần update thì đến lúc đọc, explain query thì Postgre lại có lợi thế hơn. Nên mình nghĩ => heavy update -> Mysql còn heavy READ => Postgre
Cảm ơn anh❤. Anh có thể so sánh giữa 2 loại database trả phí là MSSQL và Oracle được không ạ? Với các hệ thống quản lý dữ liệu lớn thì em thấy các công ty ở Việt Nam dùng Oracle nhiều hơn MSSQL. Có phải vì Oracle tối ưu về mặt chi phí hơn không ạ?
Oracle đắt hơn đấy, nhưng nó có những vấn đề quan trọng hơn chi phí nhiều lần. Video tới anh sẽ so sánh 2 loại này nhé
@@tranquochuywecommit Vâng, em cảm ơn anh ạ
Thảo nào nhiều hệ thống lớn họ dùng Postgre
hay quá sếp ơi, kênh nội dung chất lượng
Kiến thức quá hay, xem anh giải thích thấy cuốn thật sự :))
Anh dùng ứng dụng nào vẽ thế anh ?
hay quá ạ làm bao lâu rồi giờ mới được khai sáng ạ. Cảm ơn a đã chia sẻ những kiến thức chất lượng ạ 😁😁
bên e dùng odoo, sao vẫn thấy tih thoảng họ lên lịch vaccum thủ công nhỉ @@, theo video trên thì e đang nghĩ vaccum là tự động :D
Video rất hay bạn cho mình hỏi, Nếu bản index cùng chỉ về 2 địa chỉ, ví dụ Hoàng -> [A, D], thì làm sao PostgreSQL biết phải sử dụng cái nào? Cảm ơn
nó theo transaction mà bạn.
Em cảm ơn vì video hay của anh, rất chi tiết rõ ràng dễ hiểu ,em có câu hỏi về mysql khi không may chạy lệnh deleted all các bản ghi trong bảng cần back lại thì làm thế nào ạ
Delete và đã commit rồi ah anh em?
Trường hợp này thì nguyên tắc đầu tiên vẫn luôn là câu hỏi "có bản backup không?"
Anh ơi, có video trình bày về database không ạ? Em chưa hiểu về Database ạ
em có thể xem 1 video full course về database bất kỳ của anh trên kênh này. Nếu mới bắt đầu em nên xem Mysql full course trên kênh nhé
@@tranquochuywecommit em cảm ơn anh nhiều ạ
Anh Huy cho em hỏi tại sao Postgre lại dùng cơ chế tạo thêm dòng trong mvcc. Rõ ràng đây là một lỗ hổng trong hiệu năng của hệ thống. Postgre làm như đổi lại được điều gì?
Mặc dù việc tạo thêm dòng trong MVCC có thể gây ra chi phí về không gian lưu trữ và yêu cầu thực hiện VACUUM để duy trì hiệu suất, lợi ích mà MVCC mang lại trong việc quản lý đồng thời và đảm bảo tính nhất quán dữ liệu vượt trội hơn nhiều so với các hạn chế này. Đây là lý do tại sao PostgreSQL chọn cơ chế MVCC, mang lại một hệ thống quản lý cơ sở dữ liệu mạnh mẽ và hiệu quả cho các ứng dụng hiện đại.
1. Tính nhất quán mà không khóa (Lock-free Consistency)
MVCC cho phép các giao dịch đọc và ghi cùng lúc mà không cần chặn nhau. Điều này đạt được bằng cách tạo ra các phiên bản khác nhau của cùng một dòng dữ liệu:
Đọc không khóa: Các giao dịch đọc có thể đọc dữ liệu phiên bản cũ ngay cả khi có các giao dịch ghi đang diễn ra, miễn là dữ liệu này phù hợp với thời gian snapshot của giao dịch.
Ghi không chặn: Các giao dịch ghi có thể tạo phiên bản mới của dòng dữ liệu mà không làm gián đoạn các giao dịch đọc đang tồn tại.
2. Isolation Levels và Snapshot Isolation
PostgreSQL cung cấp các mức độ cô lập khác nhau để quản lý sự cô lập của giao dịch, từ Read Uncommitted đến Serializable:
Snapshot Isolation: Mỗi giao dịch nhìn thấy một "snapshot" của cơ sở dữ liệu tại thời điểm nó bắt đầu. Điều này giúp giảm hiện tượng đọc bẩn (dirty reads) và đọc không lặp lại (non-repeatable reads), cải thiện tính nhất quán mà không cần khóa nhiều.
3. Giảm xung đột (Conflict Reduction)
MVCC giảm xung đột giữa các giao dịch đọc và ghi. Trong cơ chế khóa truyền thống, giao dịch đọc phải chờ cho giao dịch ghi hoàn thành, dẫn đến tình trạng nghẽn cổ chai. Với MVCC, nhiều giao dịch có thể diễn ra đồng thời, cải thiện hiệu suất tổng thể.
4. Lợi ích của Vacuum
PostgreSQL sử dụng cơ chế VACUUM để dọn dẹp các phiên bản cũ của dòng dữ liệu:
Dọn dẹp và tái sử dụng không gian: VACUUM xóa bỏ các phiên bản không còn cần thiết, tái sử dụng không gian đã được giải phóng.
Phân mảnh giảm thiểu: Mặc dù VACUUM cần tài nguyên, nó giúp duy trì hiệu suất cơ sở dữ liệu bằng cách giảm phân mảnh và giữ cho kích thước cơ sở dữ liệu không tăng quá mức.
5. Độ tin cậy và khôi phục (Reliability and Recovery)
MVCC giúp PostgreSQL khôi phục cơ sở dữ liệu một cách dễ dàng hơn:
Khôi phục sau sự cố: Nếu hệ thống gặp sự cố, các giao dịch chưa hoàn thành sẽ không ảnh hưởng đến các phiên bản dữ liệu đã được xác nhận (committed).
Tăng khả năng phục hồi: Cơ chế này giúp bảo vệ dữ liệu khỏi các lỗi phần cứng và phần mềm bằng cách duy trì nhiều phiên bản dữ liệu.
6. Tối ưu hóa hiệu suất cho các tải công việc cụ thể
MVCC có thể tối ưu hóa cho các ứng dụng cụ thể:
Ứng dụng nhiều đọc: Với các ứng dụng có tỷ lệ đọc cao, MVCC cho phép các giao dịch đọc thực thi nhanh chóng mà không bị chặn bởi các giao dịch ghi.
Ứng dụng nhiều ghi: MVCC có thể xử lý tốt các ứng dụng ghi nhiều mà không ảnh hưởng nhiều đến hiệu suất đọc.
Chào anh Huy cho em hỏi vậy nếu hệ thống vừa phải ghi liên tục và truy vấn phức tạp thì nên dùng thằng nào hay có cách xử lý khác ạ
Phải xem trong 2 cái đấy thì cái nào là chủ đạo, đâu là nghiệp vụ quan trọng nhất.
Tư duy 80-20 thôi anh em, tập trung cho 20% quan trọng nhất
sự khác biệt giữa coder giỏi và kinh nghiệm ở video này , thks a
cảm ơn người anh em
Nếu cập nhật mà thêm record(đối với Posgres) thì thì sẽ lấy-gán ID như thế nào anh? Có giống như lúc insert? VÍ dụ last id = 100, sau đó 100 transaction update và không có cái nào commit thì id.nextVal() lúc này là 101 hay 201?
Cảm ơn anh về bài chia sẻ này, nó rất hay và giúp em hiểu ra một vài vấn đề của dự án em đang làm. Tuy nhiên em có 1 câu hỏi đó là khi mà postgres thêm 1 dòng mới khi chạy câu lệnh update thì đối với bảng có id là unique thì không biết là nó có vi phạm cái unique này không bởi như em thấy trong vd của anh là bản ghi thêm mới khi đó có id là y hệt bản ghi cũ. Mong sớm nhận được phản hồi từ anh ạ :D
không hề vi phạm gì em nhé. Đây là cơ chế xử lý ngầm của Database.
Unique của em là ở phía logic thôi.
Dạ vâng ạ! Cảm ơn anh nhiều nhé 😁
cho mình xin tên cái đèn chụp cao cao với nhé. Nhìn đẹp quá.
Cái tiến trình vancum mình có thể setting thời gian nó chạy được không nhỉ ! ví dụ set vao bản đêm ko phải giờ cao điểm để bớt giành tài nguyên của table
nếu nói chi tiết hơn về vacuum trong postgresql thì nó có 2 kiểu: tự động và thủ công.
Anh em có thể điều chỉnh chiến lược và thời gian để tiến trình vacuum ảnh hưởng ít nhất tới hiệu năng.
note ở đây để t2 quay lại ngâm cứu ạ.
Anh em dev giờ chỉ có tập trung học tiếng Anh cho tốt.. rồi đọc tài liệu gốc tiếng Anh luôn.. chứ nghe kiểu này dịch ra ko bao giờ chính xác
Hmm nếu thế trong MySQL, khi có 2 người cùng update mà chưa commit, vd như em update "Huy -> 1800", anh update "Huy -> 1500" thì lúc đó bảng sẽ lưu trữ cả 2 update mà chưa commit này như thế nào ạ?
2 ông cùng update 1 bản ghi đúng không em.
Trường hợp đấy thì database sẽ sử dụng cơ chế LOCK.
Người đầu tiên gõ lệnh UPDATE thì sẽ được thực hiện, ông thứ 2 thì bị LOCK, phải chờ ông đầu tiên update xong (commit hoặc rollback) thì mới được làm tiếp
Up@@tranquochuywecommit Với nếu thế thì rất dễ xảy ra deadlock. Vd như có 2 câu lệnh Update của 2 người khác nhau:
- Transaction 1:
"Update bản ghi 1
Update bản ghi 2"
- Transaction 2:
"Update bản ghi 2
Update bản ghi 1"
Trường hợp nhiều CCU thì có khả năng ô thứ 1 get dc lock của bản ghi 1, và ô thứ 2 get dc lock của bản ghi 2. Nếu thế thì deadlock xảy ra r mà nhỉ?
Đấy cũng là yếu điểm của bọn này so với oracle phải k anh :))
Phân tích chất lượng quá anh ơi, cảm ơn anh
Hay thật, mà nhạc to quá nghe khó tập trung dc 🎉
Em có thắc mắc là khi câu lệnh SQL của em không thay đổi trong các lần chạy tiếp theo, nhưng mà lúc sau em đánh Index trên bảng cần truy vấn, thì việc phân tích chiến lược thực thi có được phân tích lại không ạ? Em cảm ơn!
khi em bổ sung các thông tin mới, ví dụ như Index mà em nói, chiến lược thực thi sẽ được cân nhắc, đánh giá lại.
Tuy nhiên việc lựa chọn vẫn dựa trên Cost ông nào thấp nhất, không phải cứ đánh Index là ngon.
Chính vì thế, anh em lập trình lúc đánh index xong phải kiểm tra chiến lược thực thi xem câu lệnh nó có dùng được không nhé.
So sánh thêm vs Oracle đi Huy
em chào anh ạ , mong anh ra thêm video về cách làm mô hình master-slave của postgres , em cảm ơn ạ
okie em, nếu nhiều người cùng cần anh sẽ làm nhé
@@tranquochuywecommit +1 ạ
Anh ơi không biết anh có thể làm về Apache Cassandra được không ạ
em mong đợi nội dung nào trong đó?
chạy 1 query là thế mạnh của thằng này thì thằng kia chẳng yếu thế hơn, dùng 1 query để chứng minh thằng kia không viết lại query thì chịu rồi =))
nghe cao thủ khác bọt thật, quá hay.
sao nhóm vote làm về SQL vs Oracle rồi sao lại làm video này trước vậy sếp?
Kết quả theo số đông người chọn anh em ah.
Vote trên nhiều nhóm + TH-cam tab cộng đồng.
Anh em xem trên tab cộng đồng youtube sẽ thấy đa số anh em chọn PostgreSQL vs MySQL.
Video sau mình có làm về Oracle vs SQL Server đấy
A dùng phần mềm gì vẽ đẹp thế ạ ?
goodnotes anh em nhé
Có db nào kết hợp xử lý index ngon của mysql với statics sql ngon của postgres không anh
xin giới thiệu anh em: Oracle database
kiến thức này là kinh nghiệm xương máu, cám ơn anh Huy sâu sắc
Dùng cho các hệ thống monitor như Zabbix thì dùng loại nào sẽ phù hợp hơn vậy ae?
Postgresql timescaleDB
@@dangkiena3 Mới đọc keyword thôi đã thấy sáng rồi, tks bạn!
hehe like + cảm ơn a Huy trước rồi xem
woa, quá nhiệt tình luôn. Cảm ơn anh em nhé
Ông qua bên thuế làm csdl giúp cái, chứ nhiều ng tồn tại 2 mst mà lâu mới phát hiện ra
tôi quen anh em quản lý cơ sở dữ liệu bên đấy đấy, anh em có cần tôi kết nối cho không :))
Cơ chế này có đại diện cho sql và nosql ko anh
mỗi loại database sẽ có các cơ chế riêng.
Oracle, MySQL, PostgreSQL, SQL Server tuy là cùng RDBMS nhưng mỗi loại nó có các kiến trúc sẽ khác nhau đôi chút.
NoSQL thì cũng phải xét kiến trúc riêng anh em ạ
Không biết a có chuyên đề về Oracle?
có đó anh em, trên kênh này luôn
Anh có thể làm thêm về Cassandra được không ạ?
để anh làm khảo sát xem nhiều anh em cộng đồng cần không, có nhiều thứ muốn làm nên anh sẽ ưu tiên các nội dung nhiều người cần em nhé
@@tranquochuywecommit dạ cảm ơn anh đã dành thời gian cân nhắc ạ.
@huythai6250 anh vẫn xem tất cả chia sẻ của anh em mà. Cảm ơn anh em vì đã ủng hộ kênh này nhé
@@tranquochuywecommit dạ, rất cần nhiều hơn những người có tầm như anh chia sẻ kinh nghiệm ạ 🥰, cảm ơn những chia sẻ của anh rất nhiều
anh Huy làm so sánh giữa sql và nosql đi ạ
nosql em thích chọn database nào? Mongodb nhé?
@@tranquochuywecommit ok ạ, à em hỏi thêm là em muốn tìm hiểu sâu hơn về index (sâu như video anh chia sẻ thì tham gia khóa 100x là có anh nhỉ)
Nói luôn cho đủ bộ a nhờ. thêm SQL Server nữa
sắp ra tiếp video oracle và sql server anh em nhé, ngay video kế tiếp
Cảm ơn bạn!
Cảm ơn anh ạ!
cảm ơn bác chia sẻ nhé ạ
😀
Hay quá thầy ơi
cảm ơn em nhé.
hay quá
rất thiết thực, cam ơn anh
So sánh Oracle luôn anh ạ
:))) phải giỏi và hiểu sâu cỡ này ms đúng là chuyên gia anh ơiii
Cảm ơn Long nhé
Giá trị, cảm ơn anh
So sánh Sql vs Oracle đi anh
Ko hiểu gì cả
nice sharing
anh làm về oracle đi anh
video ngay sau đây có nội dung oracle đó em
Các bạn tải cao cùng làm xao luong khác nhau các bạn
Video có tiếng cạch cạch khá khó chịu đó anh
cảm ơn em đã góp ý, anh sẽ để ý điều chỉnh đợt video tới nhé
Chào ♥️🌽👍
sinh viên năm 3 xem có sớm quá không ^^
anh có những anh em năm 3 đã tham gia chiến đấu rồi.
Làm công nghệ không có gì làm sớm nếu tăng công lực cả em ạ.
Càng biết sớm càng ngon thôi.
video start: 1:10
quá hay
"My SQL, SQL" tôi nghĩ nên phát âm chính xác hơn
cảm ơn người anh em đã bỏ qua phần phát âm để ủng hộ nội dung video nhé
Mình nghĩ là ko cần thiết. Mình thấy phát âm như vậy dễ nghe hơn
@@n4.nguyenmanhcuong8làm tech mà nói sai tên công nghệ thì hơi buồn cười ấy
@@Phamviet008 Chả có gì buồn cười cả bạn ạ. Chúng ta là người Việt, đều nói tiếng Việt, video cũng dành cho người Việt. Mấy cái đấy nói lái sang tiếng Việt cho dễ nghe thì không có vấn đề gì cả bạn ạ.
giống như bạn nói tiếng Anh với người nước ngoài thì ví dụ tên người. bạn sẽ đọc rõ chữ "Cường", hay sẽ nói lái sang là "Cuong" ?
chất