Gần đây tôi phát hiện ra rằng (họ nói do thay đổi giấy phép). Điều này khiến tôi suy nghĩ vì trong vài năm qua, tôi đã thấy rất nhiều bài viết về mức độ khủng khiếp của MongoDB và việc không ai nên sử dụng nó. Nhưng trong thời gian này, MongoDB đã trở thành một sản phẩm trưởng thành hơn rất nhiều. Chuyện gì đã xảy ra thế? Có phải tất cả sự căm ghét thực sự là do những sai lầm trong quá trình tiếp thị ban đầu một DBMS mới? Hay mọi người đang sử dụng MongoDB không đúng chỗ?
Nếu bạn cảm thấy tôi đang bảo vệ MongoDB, vui lòng đọc ở cuối bài viết.
Xu hướng mới
Tôi đã làm việc trong ngành công nghiệp phần mềm nhiều năm hơn những gì tôi có thể nói, nhưng tôi vẫn chỉ tiếp xúc với một phần nhỏ các xu hướng đang ảnh hưởng đến ngành của chúng ta. Tôi đã chứng kiến sự trỗi dậy của 4GL, AOP, Agile, SOA, Web 2.0, AJAX, Blockchain... danh sách này là vô tận. Mỗi năm xu hướng mới xuất hiện. Một số nhanh chóng biến mất, trong khi một số khác thay đổi căn bản cách phát triển phần mềm.
Mọi xu hướng mới đều tạo ra sự phấn khích chung: mọi người hoặc nhảy lên tàu hoặc nhìn thấy tiếng ồn do người khác tạo ra và đi theo đám đông. Quá trình này được Gartner hệ thống hóa trong . Mặc dù còn gây tranh cãi nhưng dòng thời gian này mô tả đại khái những gì xảy ra với công nghệ trước khi chúng trở nên hữu ích.
Nhưng đôi khi một cải tiến mới xuất hiện (hoặc sắp có cải tiến thứ hai, như trong trường hợp này) chỉ được thúc đẩy bởi một cách triển khai cụ thể. Trong trường hợp của NoSQL, sự cường điệu này chủ yếu được thúc đẩy bởi sự xuất hiện và phát triển nhanh chóng của MongoDB. MongoDB đã không bắt đầu xu hướng này: trên thực tế, các công ty Internet lớn bắt đầu gặp vấn đề khi xử lý lượng lớn dữ liệu, dẫn đến sự trở lại của các cơ sở dữ liệu phi quan hệ. Phong trào tổng thể bắt đầu với các dự án như Bigtable của Google và Cassandra của Facebook, nhưng MongoDB mới trở thành triển khai cơ sở dữ liệu NoSQL nổi tiếng và dễ tiếp cận nhất mà hầu hết các nhà phát triển đều có quyền truy cập.
Lưu ý: Bạn có thể nghĩ rằng tôi đang nhầm lẫn cơ sở dữ liệu tài liệu với cơ sở dữ liệu cột, kho khóa/giá trị hoặc bất kỳ loại kho dữ liệu nào khác nằm trong định nghĩa chung của NoSQL. Và bạn đã đúng. Nhưng vào thời điểm đó sự hỗn loạn ngự trị. Mọi người đều bị ám ảnh bởi NoSQL, nó đã trở thành tất cả mọi người hoàn toàn cần thiết, mặc dù nhiều người không nhận thấy sự khác biệt trong các công nghệ khác nhau. Đối với nhiều người, MongoDB đã trở thành đồng nghĩa với Không có SQL.
Và các nhà phát triển đã chộp lấy nó. Ý tưởng về một cơ sở dữ liệu không có sơ đồ có khả năng mở rộng một cách kỳ diệu để giải quyết mọi vấn đề khá hấp dẫn. Khoảng năm 2014, dường như mọi nơi cách đây một năm sử dụng cơ sở dữ liệu quan hệ như MySQL, Postgres hay SQL Server đều bắt đầu triển khai cơ sở dữ liệu MongoDB. Khi được hỏi tại sao, bạn có thể nhận được câu trả lời từ câu hỏi tầm thường “đây là quy mô của web” đến câu trả lời sâu sắc hơn là “dữ liệu của tôi có cấu trúc rất lỏng lẻo và phù hợp với cơ sở dữ liệu không có lược đồ”.
Điều quan trọng cần nhớ là MongoDB và cơ sở dữ liệu tài liệu nói chung giải quyết một số vấn đề với cơ sở dữ liệu quan hệ truyền thống:
- Đề án nghiêm ngặt: Với cơ sở dữ liệu quan hệ, nếu bạn có dữ liệu được tạo động, bạn buộc phải tạo một loạt cột dữ liệu "linh tinh" ngẫu nhiên, chuyển các khối dữ liệu vào đó hoặc sử dụng cấu hình ...tất cả những điều này đều có những hạn chế đáng kể.
- Khó khăn trong việc mở rộng quy mô: Nếu có quá nhiều dữ liệu không vừa trên một máy chủ, MongoDB sẽ đưa ra các cơ chế để cho phép dữ liệu đó mở rộng trên nhiều máy.
- Sửa đổi mạch phức tạp: không di cư! Trong cơ sở dữ liệu quan hệ, việc thay đổi cấu trúc cơ sở dữ liệu có thể là một vấn đề lớn (đặc biệt khi có nhiều dữ liệu). MongoDB đã có thể đơn giản hóa quá trình này rất nhiều. Và nó trở nên dễ dàng đến mức bạn chỉ cần cập nhật mạch khi tiếp tục và tiếp tục rất nhanh.
- Ghi lại hiệu suất: Hiệu suất của MongoDB rất tốt, đặc biệt là khi được cấu hình đúng cách. Ngay cả cấu hình sẵn có của MongoDB, vốn thường bị chỉ trích, cũng cho thấy một số con số hiệu suất ấn tượng.
Mọi rủi ro đều thuộc về bạn
Lợi ích tiềm tàng của MongoDB là rất lớn, đặc biệt đối với một số loại vấn đề nhất định. Nếu bạn đọc danh sách trên mà không hiểu ngữ cảnh cũng như không có kinh nghiệm, bạn có thể có ấn tượng rằng MongoDB thực sự là một DBMS mang tính cách mạng. Vấn đề duy nhất là những lợi ích được liệt kê ở trên đi kèm với một số cảnh báo, một số trong đó được liệt kê dưới đây.
Công bằng mà nói, không có ai ở 10gen/MongoDB Inc. sẽ không nói rằng những điều sau đây là không đúng sự thật, đây chỉ là những sự thỏa hiệp.
- Giao dịch bị mất: Giao dịch là tính năng cốt lõi của nhiều cơ sở dữ liệu quan hệ (không phải tất cả, nhưng hầu hết). Giao dịch có nghĩa là bạn có thể thực hiện nhiều thao tác một cách nguyên tử và có thể đảm bảo rằng dữ liệu vẫn nhất quán. Tất nhiên, với cơ sở dữ liệu NoSQL, giao dịch có thể nằm trong một tài liệu duy nhất hoặc bạn có thể sử dụng các cam kết hai giai đoạn để có được ngữ nghĩa giao dịch. Nhưng bạn sẽ phải tự mình triển khai chức năng này... đây có thể là một công việc khó khăn và tốn thời gian. Thường thì bạn không nhận ra có vấn đề cho đến khi bạn thấy dữ liệu trong cơ sở dữ liệu ở trạng thái không hợp lệ vì không thể đảm bảo tính nguyên tử của các hoạt động. Lưu ý: Nhiều người nói với tôi rằng MongoDB 4.0 đã giới thiệu các giao dịch vào năm ngoái nhưng có một số hạn chế. Nội dung rút ra từ bài viết vẫn giữ nguyên: đánh giá mức độ công nghệ đáp ứng nhu cầu của bạn.
- Mất tính toàn vẹn quan hệ (khóa ngoại): Nếu dữ liệu của bạn có mối quan hệ thì bạn sẽ phải áp dụng chúng trong ứng dụng. Việc có một cơ sở dữ liệu tôn trọng các mối quan hệ này sẽ giúp giảm bớt rất nhiều công việc cho ứng dụng và do đó là các lập trình viên của bạn.
- Thiếu khả năng áp dụng cấu trúc dữ liệu: Các lược đồ nghiêm ngặt đôi khi có thể là một vấn đề lớn, nhưng chúng cũng là một cơ chế mạnh mẽ để cấu trúc dữ liệu tốt nếu được sử dụng một cách khôn ngoan. Cơ sở dữ liệu tài liệu như MongoDB cung cấp tính linh hoạt đáng kinh ngạc của lược đồ, nhưng tính linh hoạt này loại bỏ trách nhiệm giữ cho dữ liệu sạch sẽ. Nếu không quan tâm đến chúng, bạn sẽ phải viết rất nhiều mã trong ứng dụng của mình để giải quyết những dữ liệu không được lưu trữ ở dạng bạn mong đợi. Như chúng tôi thường nói tại công ty Simple Thread... một ngày nào đó ứng dụng sẽ được viết lại, nhưng dữ liệu sẽ tồn tại mãi mãi. Lưu ý: MongoDB hỗ trợ kiểm tra lược đồ: nó hữu ích nhưng không cung cấp các đảm bảo giống như trong cơ sở dữ liệu quan hệ. Trước hết, việc thêm hoặc thay đổi kiểm tra lược đồ không ảnh hưởng đến dữ liệu hiện có trong bộ sưu tập. Việc đảm bảo rằng bạn cập nhật dữ liệu theo lược đồ mới là tùy thuộc vào bạn. Hãy tự quyết định xem điều này có đủ cho nhu cầu của bạn hay không.
- Ngôn ngữ truy vấn gốc/mất hệ sinh thái công cụ: Sự ra đời của SQL thực sự là một cuộc cách mạng và không có gì thay đổi kể từ đó. Đó là một ngôn ngữ cực kỳ mạnh mẽ nhưng cũng khá phức tạp. Nhu cầu xây dựng các truy vấn cơ sở dữ liệu bằng một ngôn ngữ mới bao gồm các đoạn JSON được những người có kinh nghiệm làm việc với SQL coi là một bước lùi lớn. Có rất nhiều công cụ tương tác với cơ sở dữ liệu SQL, từ IDE đến các công cụ báo cáo. Việc chuyển sang cơ sở dữ liệu không hỗ trợ SQL có nghĩa là bạn không thể sử dụng hầu hết các công cụ này hoặc bạn phải dịch dữ liệu sang SQL để sử dụng chúng, điều này có thể khó khăn hơn bạn nghĩ.
Nhiều nhà phát triển chuyển sang sử dụng MongoDB không thực sự hiểu được sự đánh đổi và thường lao đầu vào cài đặt nó làm kho lưu trữ dữ liệu chính của họ. Sau này thường rất khó để quay lại.
Điều gì có thể đã được thực hiện khác đi?
Không phải ai cũng nhảy đầu tiên và chạm đáy. Nhưng nhiều dự án đã cài đặt MongoDB ở những nơi mà nó đơn giản là không phù hợp - và họ sẽ phải sống chung với nó trong nhiều năm tới. Nếu các tổ chức này dành thời gian và suy nghĩ một cách có phương pháp về các lựa chọn công nghệ của mình thì nhiều tổ chức sẽ đưa ra những lựa chọn khác.
Làm thế nào để lựa chọn công nghệ phù hợp? Đã có một số nỗ lực nhằm tạo ra một khuôn khổ có hệ thống để đánh giá công nghệ, chẳng hạn như и , nhưng đối với tôi, có vẻ như đây là sự phức tạp không cần thiết.
Nhiều công nghệ có thể được đánh giá một cách thông minh chỉ bằng cách hỏi hai câu hỏi cơ bản. Vấn đề là tìm được người có thể trả lời chúng một cách có trách nhiệm, dành thời gian để tìm ra câu trả lời và không thiên vị.
Nếu bạn không gặp phải bất kỳ vấn đề nào, bạn không cần một công cụ mới. Chấm.
Câu hỏi 1: Tôi đang cố gắng giải quyết vấn đề gì?
Nếu bạn không gặp phải bất kỳ vấn đề nào, bạn không cần một công cụ mới. Chấm. Không cần thiết phải tìm giải pháp rồi mới phát minh ra vấn đề. Trừ khi bạn gặp phải một vấn đề mà công nghệ mới giải quyết tốt hơn đáng kể so với công nghệ hiện tại của bạn, thì không có gì để thảo luận ở đây. Nếu bạn đang cân nhắc sử dụng công nghệ này vì bạn đã thấy người khác sử dụng nó, hãy nghĩ xem họ gặp phải những vấn đề gì và hỏi xem bạn có gặp những vấn đề đó không. Thật dễ dàng để chấp nhận một công nghệ vì những người khác đang sử dụng nó, thách thức là hiểu xem bạn có gặp phải những vấn đề tương tự hay không.
Câu hỏi 2: Tôi đang thiếu gì?
Đây chắc chắn là một câu hỏi khó hơn vì bạn sẽ phải tìm hiểu sâu và hiểu rõ về cả công nghệ cũ và mới. Đôi khi bạn không thể thực sự hiểu được một cái mới cho đến khi bạn xây dựng được thứ gì đó với nó hoặc nhờ ai đó có kinh nghiệm về nó.
Nếu bạn không có thì bạn nên nghĩ đến khoản đầu tư tối thiểu có thể có để xác định giá trị của công cụ này. Và một khi bạn đã đầu tư thì việc đảo ngược quyết định đó sẽ khó đến mức nào?
Con người luôn phá hỏng mọi thứ
Khi bạn cố gắng trả lời những câu hỏi này một cách khách quan nhất có thể, hãy nhớ một điều: bạn sẽ phải đấu tranh với bản chất con người. Có một số thành kiến về nhận thức cần phải được khắc phục để đánh giá công nghệ một cách hiệu quả. Đây chỉ là một vài:
- - mọi người đều biết về anh ta, nhưng vẫn khó để chống lại anh ta. Chỉ cần đảm bảo rằng công nghệ thực sự phù hợp với nhu cầu thực tế của bạn.
- — Nhiều nhà phát triển có xu hướng đánh giá thấp những công nghệ mà họ đã làm việc trong một thời gian dài và đánh giá quá cao lợi ích của công nghệ mới. Không chỉ các lập trình viên, mọi người đều dễ mắc phải khuynh hướng nhận thức này.
- -Chúng ta có xu hướng nhìn thấy những gì ở đó và quên đi những gì còn thiếu. Điều này có thể dẫn đến sự hỗn loạn khi kết hợp với hiệu ứng mới lạ, vì bạn không chỉ đánh giá quá cao công nghệ mới mà còn bỏ qua những thiếu sót của nó..
Đánh giá khách quan không hề dễ dàng, nhưng hiểu được những thành kiến nhận thức cơ bản sẽ giúp bạn đưa ra những quyết định hợp lý hơn.
Tóm tắt thông tin
Bất cứ khi nào một sự đổi mới xuất hiện, hai câu hỏi phải được trả lời hết sức cẩn thận:
- Công cụ này có giải quyết được vấn đề thực sự không?
- Chúng ta có hiểu rõ về sự đánh đổi không?
Nếu bạn không thể tự tin trả lời hai câu hỏi này, hãy lùi lại vài bước và suy nghĩ.
Vậy MongoDB có phải là lựa chọn đúng đắn không? Tất nhiên là có; Giống như hầu hết các công nghệ kỹ thuật, điều này phụ thuộc vào nhiều yếu tố. Trong số những người trả lời hai câu hỏi này, nhiều người đã được hưởng lợi từ MongoDB và tiếp tục làm như vậy. Đối với những người chưa làm như vậy, tôi hy vọng bạn đã học được một bài học quý giá và không quá đau đớn về việc vượt qua chu kỳ cường điệu hóa.
Tuyên bố từ chối trách nhiệm
Tôi muốn làm rõ rằng tôi không có mối quan hệ yêu cũng như ghét với MongoDB. Chúng tôi chưa gặp phải loại vấn đề mà MongoDB phù hợp nhất để giải quyết. Tôi biết rằng 10gen/MongoDB Inc. ban đầu rất táo bạo, đặt các giá trị mặc định không an toàn và quảng bá MongoDB ở khắp mọi nơi (đặc biệt là tại các cuộc thi hackathons) như một giải pháp phổ biến để làm việc với bất kỳ dữ liệu nào. Đó có lẽ là một quyết định tồi. Nhưng nó xác nhận cách tiếp cận được mô tả ở đây: những vấn đề này có thể được phát hiện rất nhanh ngay cả khi đánh giá sơ bộ về công nghệ.
Nguồn: www.habr.com