Từ 1 tới 5 trên tổng số 5 kết quả

Đề tài: Có phải MongoDB luôn chạy nhanh hơn MySQL?

  1. #1
    Ngày gia nhập
    07 2006
    Nơi ở
    Hanoi, Vietnam
    Bài viết
    2,750

    Mặc định Có phải MongoDB luôn chạy nhanh hơn MySQL?

    'Có phải MongoDB luôn chạy nhanh hơn MySQL?' là một câu hỏi cổ điển có lẽ bạn cũng đã trải qua, nhưng có thể với câu hỏi này bạn chỉ nhận được câu trả lời đơn giản là YES hoặc NO. Vâng, tôi sẽ không viết nếu câu trả lời là dễ dàng!

    Bài viết gốc của tác giả Gerhard (PHP Developer và Linux Sysadmin) viết vào tháng 3/2013, được Kevin dịch, bổ sung thêm, lược bớt theo cách hiểu của Kevin chia sẻ cho thành viên cộng đồng C Việt.

    MongoDB là một NoSQL database, MongoDB dẫn đầu bảng xếp hạng trong thời gian dài (là NoSQL database tốt nhất). MongoDB có rất nhiều người hâm mộ, rất nhiều trong số họ đã kinh ngạc với các tính năng ưa thích và tốc độ của nó. Và, câu hỏi ở đây được đặt ra không phải là quá stupid ở tất cả trường hợp, giống MongoDB đã promoted với tốc độ kinh ngạc và nêu ra cách MangoDB chạy nhanh và tốt hơn MySQL. Nhưng vẫn còn một điều, cuộc sống không hề đơn giản. ;D Hãy nhìn nhanh vào trong hoạt động nội bộ của các database engines này và trả lời câu hỏi.

    MySQL xử lý các query như thế nào?
    MySQL dựa trên khái niệm của một database khá cũ. Đó là lý do tại sao nó có một số vấn đề để nói. Khi bạn nghĩ về lịch sử của MySQL, nó có thể giải thích chi tiết lý do cách xây dựng như những gì bạn đã thấy. Qua đó có thể thấy rằng, MySQL cũng sử dụng các kỹ thuật hiện đại như sử dụng multiple threads để tăng hiệu suất, khi nhiều query cần được xử lý cùng một thời điểm, một số threads làm việc để xử lý các query song song với nhau. Nếu có một trường hợp high load (tải ở mức cao) với một lượng lớn query, MySQL xử lý cùng lúc một số query trong số chúng. Để tránh va chạm đối với các write query khác MySQL sử dụng một kỹ thuật gọi là locks để block các write query khác và bảo vệ các write query trên cùng một bản ghi(entry). Phụ thuộc vào storage engine bạn sử dụng, một cơ chế được gọi là row-locking có thể được sử dụng. Với row-locking, nếu một write query ở một row, cơ chế này sẽ block các query khác ghi dữ liệu vào cùng row đó cho đến khi quá trình ghi dữ liệu của query trước kết thúc. Cùng một thời điểm, các query khác vẫn có thể thay đổi, ghi dữ liệu ở các row khác trên cùng một table bằng một thread khác.

    MongoDB xử lý các query như thế nào?
    Khái niệm nội bộ của MongoDB hoàn toàn khác với MySQL. Để so sánh giữa chúng ở đây, tôi sẽ tập trung vào một điểm quan trọng, bỏ qua các điểm khác. Các query MongoDB không được xử lý song song cùng lúc. Tất cả các query tới MongoDB Server được đưa vào một hàng đợi, và server xử lý từng query một(tại thời điểm này, không có sự khác nhau nếu query được gửi tới cùng một collection [trong SQL là table], database hoặc không). MongoDB sử dụng một kỹ thuật gọi là instance-wide-locking. Điều này có nghĩa là, toàn bộ quá trình xử lý chỉ có thể chạy một query tại một thời điểm. Để loại bỏ một ít 'nút cổ chai', MongoDB đang chuyển sang database-wide-locks như đã đề cập trong release notes mới nhất nhưng hiện tại vẫn chỉ có instance-wide-locking.

    Vậy điều này hàm ý gì? instance-wide-lock cho phép toàn bộ MongoDB Server để xử lý chỉ một write query ở cùng một thời điểm. database-wide-lock cho phép MongoDB Server xử lý chỉ một write query đối với mỗi database, nhưng có thể xử lý nhiều database cùng lúc. Điều này có thể khiến bạn cảm thấy thật khủng khiếp, nhưng có một điều bạn cần nhớ là các query trong MongoDB được xử lý nhanh hơn rất nhiều trong MySQL, và bạn sẽ thấy rằng nó không còn là vấn đề lớn. Tất nhiên, tất cả những điều nói ra ở đây chỉ có tác dụng nếu bạn thiết lập database một cách chính xác, nếu không, vấn đề sẽ không được như đã nêu ra ở đây.

    Làm thế nào so sánh MongoDB với MySQL?
    Xét về hiệu xuất của một query đơn giản và duy nhất, MongoDB sẽ nhanh hơn rất nhiều MySQL. Trong kinh nghiệm của tôi, bạn có thể sẽ thấy được sự khác biệt trong các tình huống high load (tải ở mức cao) và một số trường hợp truy vấn phức tạp, hoặc đặc biệt. Trong MySQL, tất cả các quản trị dữ liệu đều hiểu tầm quan trọng của database indexes. So sánh với MangoDB có vẻ như hầu hết các quản trị viên không biết một cái gì tồn tại như indexes! Điều này bắt nguồn từ một thực tế, MongoDB là structureless database, tại sao tôi phải quan tâm indexes? Nhưng ở đây tôi muốn chỉ ra đây rằng việc sử dụng indexes thích hợp ít nhất cũng quan trọng như với các database engines khác.

    Indexes trong MongoDB quan trọng như thế nào?
    MongoDB sử dụng instance-wide-lock hoặc database-wide-lock đối với các write query. Nó có thể quan trọng hơn đối với việc thiết lập đúng đắn indexes trong MySQL. Để tôi cho bạn một ví dụ trong kinh nghiệm của tôi, và giả sử dụng chúng ta sử dụng instance-wide-locking.

    Hình dung rằng bạn có một table với vài triệu bản ghi, mỗi bản ghi có một vài trường có dữ liệu dài và lớn trong cả MangoDB lẫn MySQL và không có định nghĩa indexes, nếu một truy vấn được thực hiện để update 100 bản ghi với điều kiện theo giá trị của một trường chỉ định. Điều gì sẽ xảy ra lúc này?

    MySQL bắt đầu xử lý truy vấn trong một thread, và một tất nhiên là MySQL sẽ thực hiện 'full table scan' để tìm kiếm các bản ghi phù hợp với điều kiện trong vài triệu bản ghi. Và có thể truy vấn này sẽ mất chừng 20 phút để hoàn thành.

    MangoDB sẽ xử lý cùng một truy vấn và chỉ mất chừng 5 phút. Nghe có vẻ rất tuyệt vời phải không? Trong thực tế, MongoDB Server đã scan toàn bộ collection (trong SQL là table) để tìm ra các bản ghi có liên quan. Như đã thảo luận lúc trước, trong 5 phút đó MangoDB sẽ block toàn bộ việc xử lý write query của cả server. Lúc này bạn còn thấy là 5 phút có phải là nhanh? Và MongoDB tốt hơn bởi vì nó nhanh hơn?

    Thời gian thực thi một truy vấn đơn lẻ so với tác động tổng thể trên hệ thống là 2 việc khác nhau hoàn toàn. MySQL vẫn xử lý các write query khác gửi đến server, thậm chí trên cùng một database hoặc cùng một table. Trong khi Server đang bận rộn với 'quey tốn thời gian', tài nguyên được chiếm sử dụng và không được giải phóng cho các truy vấn khác, nhưng các truy vấn khác có thể chạy chậm hơn nhưng chúng vẫn được xử lý đối với hệ quản trị MYSQL.

    Trong 5 phút xử lý query trong MongoDB, instance-wide-lock được active sẽ dẫn đến tất cả các truy vấn khác phải xếp hàng đợi, không có ngoại lệ nào ở đây. Tất cả các truy vấn phải chờ cho việc xử lý xong, và các query trong hàng đợi được xử lý từng cái một. Điều này vẫn còn đúng khi kết nối cơ bản đã bị ngắt do timeout hoặc một vài lý do khác. Với thời gian thực hiện truy vấn dài, như ví dụ trên đối với một truy vấn, một đoạn mã PHP hay Python đã timeout và kết thúc. Đối với các ứng dụng web, trình duyệt có timeout ngắn và sẽ ngắt kết nối đến server. Như đã đề cập, truy vấn được xếp hàng đợi ngay cả khi kết nối đã closed, và các truy vấn vẫn tiếp tục được xử lý theo thứ tự.

    Trên cả 2 hệ thống MongoDB và MySQL, nếu định nghĩa đúng indexes sẽ làm giảm thời gian truy vấn rất nhiều và có thể giải quyết nhiều vấn đề liên quan đến việc tắc nghẽn hệ thống.

    Kết luận
    Ngay cả khi MongoDB thực hiện các truy vấn đơn giản và duy nhất nhanh hơn rất nhiều MySQL, nhưng không có nghĩa là nó sẽ nhanh ở mọi trường hợp, ngay cả một structure-less databases như thế này cũng cần có một vài cách tổ chức, định nghĩa các indexes là nhiệm vụ quan trọng, thiếu indexes có thể gây ra các tác động lớn ngay cả khi thời gian thực hiện truy vấn nhanh hơn nhiều MySQL.

    MongoDB development road map cho thấy, vấn đề được mô tả là một vài thứ mà các nhà phát triển nhận thức được, chuyển từ instance-wide-locking sang database-wide-locking là một bước tiến lớn và đúng đắn. Hi vọng rằng các tính năng hữu ích sẽ sớm được ra mắt.

    Hi vọng bài viết này giúp mọi người có thêm nhìn nhận và lựa chọn phù hợp!
    Email: admin[@]congdongcviet.com | CC to: info[@]congdongcviet.com
    Phone: 0972 89 7667 (Office: 04 6329 2380)
    Yahoo & Skype: dreaminess_world (Vui lòng chỉ rõ mục đích ngay khi liên hệ, cảm ơn!)

    Một người nào đó coi thường ý thức kỷ luật cũng có nghĩa là người đó đã coi thường tương lai số phận của chính bản thân người đó. Những người coi thường ý thức kỷ luật sẽ không bao giờ có được sự thành công trong sự nghiệp!

  2. #2
    Ngày gia nhập
    03 2009
    Nơi ở
    %appdata%\Temp
    Bài viết
    819

    Em có một số ý kiến nhỏ thông qua quá trình dùng cả 2 tên (MongoDB và MySQL) là như thế này:
    - Với MongoDB, việc tổ chức dữ liệu, mô hình hóa bài toán là phải "làm bằng tay" hết thẩy. Có nghĩa là ko có khái niệm khóa hay tham chiếu... Thêm nữa MongoDB cũng không đảm bảo đầy đủ các tính của hệ quản trị CSDL quan hệ (ACID). Đối tượng cơ bản của MongoDB là các bản ghi (gọi là Document) giống như 1 Javascript Object với các cặp key-value. Trong 1 schema (gọi là collection) các document này có thể có cấu trúc rất khác nhau. Nói túm lại là nó cho bạn thoải mái đến mức cái gì cũng phải tự làm để mô hình hóa cái bài toán của bạn, không có bất kì ràng buộc nào như khóa ngoài, khóa chính...
    - Nếu bạn cần 1 không gian chỉ để ghi 1 đống (dạng danh sách, số lượng rất nhiều) các thông tin kiểu như 1 danh sách các key, mỗi key ứng với 1 số seri nào đó của sản phẩm... và khi hiệu năng là 1 yêu cầu bài toán => chọn MongoDB
    - Nếu bạn cần mô hình hóa một vài toán với nhiều thực thể, qua hệ loằng ngoằng thì MySQL (hay RDBMS nói chung) sẽ làm đỡ cho bạn khá nhiều như CASCADE DELETE hay UPDATE mà không phải lo lắng về sự toàn vẹn dữ liệu (không thỏa mãn các contraint của bài toán ban đầu).
    PS: Đi họp đã, viết vậy thôi.
    .::[The best way to predict the future is to invent it]::.
    __________________________________________________ _ - Alan Kay -

  3. #3
    Ngày gia nhập
    06 2007
    Nơi ở
    HCM
    Bài viết
    365

    Không nên so sánh hai loại cơ sở dữ liệu RDBMS & NoSQL , vì bản chất của chúng khác nhau , dùng cho các đối tượng và bài toán khác nhau ! Ví dụ để đảm bảo toàn vẹn dữ liệu như các ngân hàng thì đâu có thể dùng NoSQL !, cũng như dùng dữ liệu cho các mạng xã hội thì chẳng ai dại dùng RDBMS! Nếu có so sánh thì so sánh các công nghệ cùng 1 loại : ví dụ : MySQL vs SQL Server!

  4. #4
    Ngày gia nhập
    07 2006
    Nơi ở
    Hanoi, Vietnam
    Bài viết
    2,750

    Kevin thì nghĩ rằng việc hiểu một cách rõ ràng những vấn đề lợi và hại của một hệ quản trị Database như MongoDB hay MySQL sẽ giúp cho việc thiết kế hệ thống, giải pháp phù hợp hơn, tiết kiệm chi phí và ổn định. Trong giới hạn bài viết này, việc so sánh về perfomance không có gì mang tính riêng rẽ hay đặc thù. Ngay cả MongoDB khi giới thiệu họ cũng đem so sánh perfomance với các hệ quản trị cơ sở dữ liệu khác, đó chính là lý do xuất hiện bài viết này từ góc độ một người bên ngoài nhìn vào.

    Tất nhiên, bài viết chỉ là đưa ra một luận điểm chứng minh rằng MongoDB không phải lúc nào cũng nhanh hơn MySQL nếu xét ở mức độ toàn hệ thống.
    Email: admin[@]congdongcviet.com | CC to: info[@]congdongcviet.com
    Phone: 0972 89 7667 (Office: 04 6329 2380)
    Yahoo & Skype: dreaminess_world (Vui lòng chỉ rõ mục đích ngay khi liên hệ, cảm ơn!)

    Một người nào đó coi thường ý thức kỷ luật cũng có nghĩa là người đó đã coi thường tương lai số phận của chính bản thân người đó. Những người coi thường ý thức kỷ luật sẽ không bao giờ có được sự thành công trong sự nghiệp!

  5. #5
    Ngày gia nhập
    07 2006
    Nơi ở
    Hanoi, Vietnam
    Bài viết
    2,750

    Hôm trước quên mất, hôm nay đọc lại mới thấy thiếu vấn đề: Google, Facebook đều sử dụng MySQL cho phần main của hệ thống. Facebook còn tạo ra một trang riêng để sự đồn đoán không chính xác về việc Facebook sử dụng NoSQL.

    Mới đây Kevin đi phỏng vấn, một người quản lý IT ở một công ty mới nổi (không tiện tiết lộ thông tin) có chia sẻ về vấn đề anh ấy đã quyết định cho chuyển toàn bộ hệ thống xử lý dữ liệu cho ứng dụng mobile từ MySQL sang NoSQL là một sai lầm to lớn. Kevin càng nhận thấy việc một cách tổng quan về hệ thống dữ liệu là một điều rất quan trọng, bởi vì vấn đề không ở thời điểm hiện tại và vấn đề nó xảy ra trong tương lai.

    PS: Bên cạnh đó Kevin cũng cập nhật lại nội dung bài viết để người đọc dễ hiểu hơn vấn đề muốn nói ở đây.
    Email: admin[@]congdongcviet.com | CC to: info[@]congdongcviet.com
    Phone: 0972 89 7667 (Office: 04 6329 2380)
    Yahoo & Skype: dreaminess_world (Vui lòng chỉ rõ mục đích ngay khi liên hệ, cảm ơn!)

    Một người nào đó coi thường ý thức kỷ luật cũng có nghĩa là người đó đã coi thường tương lai số phận của chính bản thân người đó. Những người coi thường ý thức kỷ luật sẽ không bao giờ có được sự thành công trong sự nghiệp!

Tags của đề tài này

Quyền hạn của bạn

  • Bạn không thể gửi đề tài mới
  • Bạn không thể gửi bài trả lời
  • Bạn không thể gửi các đính kèm
  • Bạn không thể chỉnh sửa bài viết của bạn