MỤC LỤC:
- PostgreSQL: sát thủ giết chết MongoDB
- Từ nguyên mẫu (prototype) đến sản phẩm thực tế
- Một chuyến viếng thăm trụ sở MongoDB
- MongoDB: Những sai lầm to lớn
- Sự kiện MongoDB Days 2015 tại Thung lũng Silicon
- MongoDB: tự cô lập mình
- Bái bai, MongoDB
Bài viết của tác giả John De Goes là CTO của SlamData Inc.
Bạn đọc trước phần 1 của bài viết tại link này: https://techmaster.vn/posts/33691/mongodb-dua-vao-suc-manh-postgresql-1
PostgreSQL: sát thủ giết chết MongoDB
PostgreSQL là một cơ sở dữ liệu quan hệ mã nguồn mở phổ biến. Vì nó phổ biến như vậy nên trên thực tế nó hiện là một đối thủ cạnh tranh với MongoDB.
Cơ sở dữ liệu này cạnh tranh khốc liệt với MongoDB, chủ yếu bởi vì nó đã có được một số tính năng của MongoDB, bao gồm khả năng lưu trữ, xác nhận (validate), thao tác, và đánh index các JSON document. Phần mềm third-party thậm chí còn cung cấp cho nó khả năng mở rộng theo chiều ngang.
Cứ độ vài tháng, một người nào đó lại viết một bài khuyên mọi người nên bỏ MongoDB và chuyển sang dùng PostgreSQL. Thường thì, các bài viết này được lan truyền rất nhanh trên các trang web của cộng đồng lập trình viên. Tôi xin điểm qua một vài trong số những bài viết đó dưới đây:
- Tạm biệt MongoDB. Xin chào PostgreSQL
- Postgres nhanh hơn so với MongoDB
- MongoDB đã chết. PostgreSQL muôn năm :)
- Tại sao bạn đừng bao giờ sử dụng MongoDB
- SQL vs NoSQL KO. Postgres vs Mongo
- Tại sao tôi không dùng MongoDB nữa
- Tại sao bạn không nên và đừng bao giờ sử dụng MongoDB
- Liệu Postgres NoSQL tốt hơn so với MongoDB?
- Bái bai MongoDB. Chuyển qua PostgreSQL thôi các bạn ạ
Công ty lớn nhất thương mại hóa PostgreSQL là EnterpriseDB (mặc dù có rất nhiều công ty khác, một số lớn hơn hoặc vừa mới hoạt động), duy trì một kho lưu trữ nội dung trên trang web chính thức của họ cho rằng PostgreSQL là một cơ sở dữ liệu NoSQL tốt hơn so với MongoDB.
Dù ý kiến của bạn có thế nào đi nữa, thì có một điều rõ ràng là: MongoDB và PostgreSQL đang bị nhốt trong một trận chiến đẫm máu luẩn quẩn trong tâm trí giữa các nhà phát triển.
Từ nguyên mẫu (prototype) đến sản phẩm thực tế
Bất kỳ một kỹ sư có trình độ nào cũng sẽ cho bạn biết rằng, nguyên mẫu (prototype) không phải là sản phẩm (production).
Thậm chí nếu MongoDB đã sử dụng PostgreSQL như một prototype BI connector, có thể một số kỹ sư tài giỏi của MongoDB đã nhốt mình trong một căn phòng ở đâu đó và làm việc cật lực để cho ra một phiên bản production độc lập.
Thật vậy, cái cách mà Tableau diễn đạt trên thông cáo báo chí của họ thậm chí còn ngụ ý rằng sự phụ thuộc vào PostgreSQL driver có thể chỉ là tạm thời:
Trong phiên bản beta của MongoDB, Tableau sẽ hỗ trợ MongoDB connector trên cả Windows và Mac thông qua PostgreSQL driver của chúng tôi.
Có lẽ, tôi nghĩ rằng, việc phát hành phiên bản MongoDB 3.2 sẽ đi kèm với một chức năng thực sự ấn tượng: một BI connector đưa ra các cấu trúc dữ liệu phong phú (rich data structures) mà MongoDB hỗ trợ (thay vì làm phẳng (flattening), bổ sung thêm dữ liệu null (null-padding), và lọc mất khá nhiều dữ liệu), thực thi tất cả các truy vấn 100% trong cơ sở dữ liệu (in-database), và không phụ thuộc vào các cơ sở dữ liệu đối thủ cạnh tranh.
Trong tháng Bảy, hơn một tháng sau sự kiện MongoWorld, tôi có ghé thăm trụ sở của MongoDB ở Palo Alto trong một chuyến công tác. Và tôi đã cảm thấy rất khích lệ bởi những gì tôi học được qua chuyến đi này.
Một chuyến viếng thăm trụ sở MongoDB
Theo những tiêu chuẩn ở Palo Alto, văn phòng của MongoDB cũng khá lớn.
Tôi đã nhìn thấy biển hiệu của công ty này trong các chuyến đi trước đó đến thung lũng Silicon, nhưng đây là lần đầu tiên tôi có một cơ hội để vào bên trong.
Tuần trước đó, tôi có trò chuyện với Asya Kamsky và Ron Anvur qua email. Chúng tôi đã thảo luận về dự án mã nguồn mở của công ty tôi trong việc thực hiện các phân tích cao cấp trên các cấu trúc dữ liệu phong phú (rich data structures) trực tiếp bên trong MongoDB.
Lúc tôi vừa đến Palo Alto thì cũng tình cờ gặp Asya, cô ấy mời tôi vào công ty bàn chuyện công việc, trong lúc chờ đợi tôi được người phục vụ cho ăn bánh pizza và uống nước ngọt.
Chỉ sau vài phút tiếp xúc đầu tiên, tôi có thể nhận xét rằng Asya là người thông minh, giỏi kỹ thuật, và hướng đến từng chi tiết công việc - đây chính xác những phẩm chất đáng có của một người quản lý sản phẩm (product manager) cho một sản phẩm kỹ thuật cao như MongoDB.
Tôi đã giải thích cho Asya về những gì mà công ty của tôi đang làm, và giúp cô dựng phần mềm mã nguồn mở của chúng tôi chạy trên máy tính của mình để cô có thể vọc vậy với nó. Thỉnh thoảng, chúng tôi có trò chuyện về BI connector cho MongoDB, và một số sản phẩm có trên thị trường (Simba, DataDirect, CData, v.v...).
Cả hai chúng tôi dường như chia sẻ cùng một quan điểm: đó là phần mềm BI cần phải có được khả năng hiểu dạng dữ liệu phức tạp hơn. Việc thay thế, trong đó bao gồm lược bỏ bớt dữ liệu để phù hợp với những hạn chế của phần mềm BI thế hệ cũ, đồng nghĩa với việc đã vứt bỏ đi quá nhiều thông tin, và bạn sẽ mất khả năng giải quyết các vấn đề quan trọng trong phân tích NoSQL.
Asya nghĩ một BI connector cho MongoDB nên đưa ra các cấu trúc dữ liệu native MongoDB, chẳng hạn như mảng (array), mà không có bất kỳ quá trình làm phẳng (flattening) hoặc biến đổi nào. Đặc tính này, mà tôi đã gọi là mô hình dữ liệu đẳng cấu (isomorphic data model), là một trong những yêu cầu quan trọng cho một phân tích general-purpose NoSQL, một chủ đề mà tôi đã viết trong một bài trước đây.
Tôi đã cảm thấy rất khích lệ vì Asya đã độc lập đi đến kết luận giống mình, và cảm thấy tự tin rằng MongoDB hiểu rõ vấn đề. Lúc đó tôi nghĩ rằng tương lai của MongoDB sẽ rất tươi sáng.
Thật không may, tôi đã hoàn toàn sai lầm.
MongoDB: Những sai lầm to lớn
Vì cảm thấy vui mừng khi MongoDB đã đi đúng hướng, nên tôi ít quan tâm đến BI connector trong vài tháng sau đó, dù tôi có trao đổi qua một vài email với Asya và Ron.
Tuy nhiên, bước vào tháng Chín, tôi gặp phải sự im lặng hoàn toàn từ nhóm phát triển sản phẩm tại MongoDB. Sau một vài tuần tôi gửi email mà không được phản hồi, sự hồi hộp của tôi tăng dần, và tôi bắt đầu tìm hiểu xung quanh xem có vấn đề gì đang diễn ra.
Tôi phát hiện ra rằng Asya đã forked một dự án gọi là Multicorn, cho phép các nhà phát triển Python viết Foreign Data Wrappers cho PostgreSQL.
Trời ơi, tôi nghĩ là MongoDB đã lại ngựa quen đường cũ rồi.
Càng đào xới thêm thì điều bí mật lại càng rõ ràng: một dự án mới tên là yam_fdw (Yet Another MongoDB Foreign Data Wrapper), một FDW hoàn toàn mới được viết bằng Python sử dụng Multicorn.
Lần theo commit log (lưu vết những thay đổi trong repository đó), tôi thấy dự án này được xây dựng mới gần đây, sau cuộc gặp vào tháng Bảy giữa tôi với Asya Kamsky. Nói cách khác, đây là công việc phát triển sau nguyên mẫu (post-prototype)!
Chiếc đinh cuối cùng đóng vào cỗ quan tài, để thuyết phục tôi rằng MongoDB đã lên kế hoạch sử dụng cơ sở dữ liệu PostgreSQL như là "BI connector" của họ, đã xảy ra khi một người nào đó gửi cho tôi một đoạn video trên YouTube, trong đó Asya có demo về connector này.
Với từ ngữ được diễn đạt rất thận trọng, và bỏ qua bất kỳ thông tin buộc tội nào, video này dù sao cũng đã cung cấp một thông tin tóm tắt như sau:
BI Connector nhận các connection và có thể "nói" cùng giao thức như cơ sở dữ liệu Postgres làm, vì vậy nếu công cụ tạo báo biểu của bạn có thể kết nối thông qua ODBC, thì chúng tôi sẽ có một ODBC driver cho phép bạn có thể sử dụng công cụ đó với BI Connector.
Tại thời điểm đó, tôi đã không nghi ngờ gì nữa: phiên bản production của BI connector, được phát hành trong phiên bản MongoDB 3.2, trên thực tế chính là cơ sở dữ liệu PostgreSQL ngụy trang mà thôi!
Nhiều khả năng, logic thực sự trong việc hút dữ liệu từ MongoDB để đưa vào PostgreSQL là một phiên bản cải tiến của dự án Multicorn wrapper được viết bằng Python mà tôi đã phát hiện trước đó.
Tại thời điểm này, không có ai ở MongoDB trở lời email của tôi cả, điều này đối với bất kỳ người nào tỉnh táo sẽ là quá đủ để họ từ bỏ việc thuyết phục MongoDB.
Nhưng tôi quyết định sẽ thử thêm một lần nữa, tại hội nghị MongoDB Days vào ngày 02/12/2015, chỉ một tuần trước khi phát hành phiên bản 3.2.
Trong sự kiện đó CTO Eliot Horowitz là người phát biểu khai mạc, Asya Kamsky là diễn giả chính, và Ron Avnur có lẽ sẽ tham dự. Có thể, thậm chí cả CEO Dev cũng có thể tham gia.
Đó là khi tôi có cơ hội tốt nhất để thuyết phục MongoDB từ bỏ khỏi con đường BI connector sai lầm đó.
Sự kiện MongoDB Days 2015 tại Thung lũng Silicon
Nhờ vào đội ngũ tiếp thị tuyệt vời tại MongoDB, và dựa trên sự thành công trong bài trình bày của tôi ở Seattle tại một sự kiện khác của MongoDB, tôi đã có một bài thuyết trình 45 phút tại hội nghị MongoDB Days lần này.
Mục đích chính thức của tôi tại hội nghị này là giới thiệu về công cụ phân tích MongoDB của chúng tôi, và làm cho người dùng biết về phần mềm mã nguồn mở mà công ty tôi đang phát triển.
Nhưng chương trình cá nhân của tôi là hoàn toàn khác: đó là thuyết phục MongoDB loại bỏ BI connector trước khi phát hành phiên bản MongoDB 3.2. Trước khi mục tiêu cao cả và ảo tưởng có thể được thực hiện, tôi muốn khẳng định những nghi ngờ của mình về connector đó là chính xác.
Vào ngày diễn ra hội nghị, tôi đã chủ động tiếp cận nói lời chào với những gương mặt cũ và mới trong MongoDB. Cho dù tôi có thể không đồng tình với những quyết định về sản phẩm nào đó của họ, có rất nhiều người tuyệt vời tại công ty này chỉ đang cố gắng làm tốt nhất công việc của họ.
Tôi đã bị ốm một vài ngày trước đó, nhưng số lượng cà-phê dồi dào đã giúp cho tinh thần tôi luôn tỉnh táo. Để chuẩn bị cho bài trình bày, tôi luyện tập nói một vài lần bằng cách đi lại dọc hành lang dài của Trung tâm Hội nghị San Jose.
Đến buổi chiều hôm đó thì tôi đã sẵn sàng, và đã trình bày bài nói chuyện của mình trong một phòng riêng. Tôi vô cùng phấn khích vì có rất nhiều người quan tâm đến chủ đề về công cụ phân tích trực quan trên MongoDB.
Sau khi bắt tay và trao đổi danh thiếp với một số người tham dự, tôi đã đi săn tìm đội ngũ quản lý của MongoDB.
Đầu tiên tôi gặp Eliot Horowitz, trong khoảnh khắc trước khi anh ta trình bày phần giới thiệu của mình. Chúng tôi trò chuyện về thời tiết, và tôi chuyển sang nói với anh ta về những điều đang được làm tại công ty của tôi.
Bài phát biểu của Eliot bắt đầu vào lúc 5:10. Eliot nói về một số tính năng trong phiên bản 3.0, vì rất nhiều công ty dường như bị mắc kẹt vào các phiên bản cũ hơn. Sau đó, anh tiếp tục đưa khán giả dạo quanh một vòng các tính năng mới của phiên bản MongoDB 3.2.
Tôi tự hỏi liệu Eliot sẽ nói về BI connector. Hay anh ta sẽ chỉ đề cập đến nó?
Hóa ra, BI connector là một tính năng hàng đầu trong bài giới thiệu này, có phần trình bày riêng dành cho nó và thậm chí có cả một phần demo minh họa nữa.
BI Connector
Eliot giới thiệu về BI connector bằng cách lớn tiếng tuyên bố rằng, "MongoDB không có công cụ phân tích native nào cả."
Tôi thấy rằng điều này hơi buồn cười, vì tôi đã viết một bài dạng guest post cho MongoDB với tiêu đề là Native Analytics cho MongoDB với SlamData (Chú thích: MongoDB đã gỡ bài viết đó xuống khỏi blog, nhưng đến 15:30 MDT, nó vẫn còn được cache bởi Google Search). SlamData cũng là một đối tác của MongoDB và là công ty tài trợ cho hội nghị MongoDB Days lần này.
Eliot dường như hơi lúng túng một chút khi mô tả mục đích của BI connector. Trông anh ta cảm thấy nhẹ nhõm khi chuyển phần trình bày sang cho Asya Kamsky, cô đã chuẩn bị một bản demo khá tốt cho sự kiện này.
Trong bài trình bày đó, Asya có vẻ không đặc biệt lo lắng tới tôi. Cô đã chọn từng chữ một cách cẩn thận, và bỏ qua các chi tiết về connector đó là gì, chỉ chứa những thông tin về cách nó làm việc (như sự phụ thuộc vào DRDL để định nghĩa MongoDB schemas). Hầu hết bài trình bày đó tập trung không phải vào BI connector, mà vào Tableau (bởi vậy dĩ nhiên là phần demo rất tốt!).
Tất cả các phản hồi của tôi thậm chí còn không làm chậm lại quá trình phát triển BI connector của họ.
Kéo ra tất cả các điểm dừng
Sau bài phát biểu đó, những người tham dự hội nghị tiến hành tiệc cocktail trong phòng liền kề. Khách mời dành phần lớn thời gian của họ để nói chuyện với những khách mời khác, trong khi nhân viên của MongoDB có xu hướng tập trung thành những nhóm đứng nói chuyện với nhau.
Tôi thấy Ron Avnur đang trò chuyện với Dan Pasette, Phó giám đốc phụ trách kỹ thuật, ở một góc phòng.
Bây giờ là lúc phải hành động.
Việc phát hành phiên bản 3.2 đã sắp diễn ra trong vài ngày tới. Không ai ở MongoDB trả lời email của tôi cả. Eliot đã nói với thế giới rằng họ không có công cụ phân tích native cho MongoDB, và đã xem BI connector như là một cuộc cách mạng cho phân tích NoSQL.
Vì không có gì để mất, tôi tiến đến chỗ Ron, xen vào cuộc trò chuyện của họ, và sau đó bắt đầu lối nói cường điệu của mình để chống lại BI connector trong bất cứ điều gì có thể trong khoảng 2 phút, và chủ yếu là độc thoại.
Tôi nói với anh ta rằng tôi mong đợi nhiều từ MongoDB hơn việc họ ngụy trang cơ sở dữ liệu PostgreSQL là giải pháp huyền diệu để phân tích MongoDB. Tôi đã nói với anh ta rằng MongoDB nên chứng tỏ một sự nhất quán và đóng vai trò người dẫn đầu, và nên cung cấp một giải pháp hỗ trợ các cấu trúc dữ liệu phong phú (rich data structures) mà MongoDB hỗ trợ, đẩy tất cả tính toán vào trong cơ sở dữ liệu, và không có bất kỳ phụ thuộc nào vào một cơ sở dữ liệu cạnh tranh.
Ron khá choáng váng. Anh bắt đầu đưa ra quan điểm để bảo vệ BI connector theo một cách diễn đạt khá mơ hồ, và tôi nhận ra đây là cơ hội để xác nhận nghi ngờ của mình.
"Postgres foreign data wrappers hỗ trợ hầu như bất kỳ pushdown nào," tôi nói vấn đề sự thật hiển nhiên. "Đây là tất cả sự thật về Multicorn wrapper mà anh đang sử dụng cho BI connector, cái dựa trên một Postgres cũ và thậm chí không hỗ trợ khả năng pushdown đầy đủ của Postgres FDW."
Ron thừa nhận thất bại. "Đó là sự thật," anh nói.
Tôi đã đẩy anh đến chỗ phải bảo vệ quyết định đó. Nhưng anh không có câu trả lời. Tôi nói với anh ta hãy dừng việc đó ngay bây giờ, trước khi MongoDB phát hành "BI connector". Khi Ron nhún vai về khả năng đó, tôi nói với anh ta toàn bộ điều này sẽ là một sai lầm lớn. "Có thể là anh nói đúng," anh nói, "Nhưng tôi còn có những việc lớn hơn để lo lắng ngay bây giờ," có thể anh ta đang đề cập đến việc phát hành phiên bản 3.2 sắp tới.
Chúng tôi đã có một ly bia với nhau, cả ba chúng tôi. Tôi chỉ vào Dan, "Nhóm của anh chàng này đã xây dựng một cơ sở dữ liệu mà thực sự có thể làm phân tích. Tại sao anh không sử dụng nó trong BI connector đó?" Nhưng nó đã không được sử dụng. Ron đã không trả lời.
Chúng tôi tản ra mỗi người một nơi, mặc cho còn những vấn đề đã đồng tình cũng như không đồng tình.
Tôi phát hiện thấy Dev Ittycheria ở cuối căn phòng, và đi về phía ông. Tôi khen ngợi công việc mà bộ phận tiếp thị đã làm, trước khi chuyển sang phê bình sản phẩm. Tôi nói với Dev rằng, "Theo tôi, sản phẩm đang thực hiện một số sai lầm." Ông muốn biết nhiều hơn, vì thế tôi đã trình bày đầy đủ quan điểm của mình, điều mà tôi đã lặp đi lặp lại thường xuyên bằng cả trái tim. Ông nói với tôi hãy gửi thông tin chi tiết qua email, và tất nhiên tôi đã làm, nhưng tôi chưa bao giờ nhận được email trả lời.
Sau cuộc nói chuyện của tôi với Dev, tôi biết rằng mình sẽ không thể thay đổi tiến trình của MongoDB 3.2. Nó sẽ xuất xưởng với BI connector trong đó, và tôi không thể làm bất cứ điều gì để thay đổi điều đó cả.
Tôi đã rất thất vọng, nhưng đồng thời cũng cảm thấy một sự nhẹ nhõm trong lòng mình. Tôi đã nói chuyện với tất cả mọi người tôi có thể. Tôi đã đưa ra tất cả ý kiến ngăn cản. Tôi đã làm hết trong khả năng của mình.
Khi tôi rời tiệc cocktail, và quay trở lại khách sạn của mình, tôi không thể không suy đoán về lý do tại sao công ty MongoDB đã đưa ra quyết định bất chấp những ý kiến phản đối mạnh mẽ của tôi.
MongoDB: tự cô lập mình
Sau khi ngẫm nghĩ, bây giờ tôi nghĩ rằng các quyết định sản phẩm tồi của MongoDB là do họ không có khả năng tập trung vào phần cốt lõi của cơ sở dữ liệu. Việc họ không có khả năng tập trung này bắt nguồn từ việc họ không có khả năng nuôi dưỡng một hệ sinh thái NoSQL.
Các cơ sở dữ liệu quan hệ ngày càng tăng sự thống trị, một phần bởi vì các hệ sinh thái đáng kinh ngạc bao xung quanh các cơ sở dữ liệu này.
Hệ sinh thái này đã cho ra đời những ứng dụng như backup, replication, analytics, reporting, security, governance, và nhiều ứng dụng xác định khác. Mỗi cái đều phụ thuộc và đóng góp vào sự thành công của sản phẩm khác, tạo ra một mạng lưới lợi ích, ngược lại với những chi phí chuyển đổi cao được chứng minh là phiền hà cho các nhà cung cấp NoSQL hiện nay.
Ngược lại, hầu như không có hệ sinh thái xung quanh MongoDB, và tôi không phải là người duy nhất nhận ra sự thật này.
Tại sao lại không có một hệ sinh thái xung quanh MongoDB?
Câu trả lời quái gở của tôi là bởi vì, nếu bạn là một đối tác MongoDB cung cấp một công cụ phân tích native cho MongoDB, thì CTO của họ sẽ nhảy lên sân khấu và nói với thế giới rằng họ không cung cấp công cụ phân tích native nào cho MongoDB cả.
Tuy nhiên, khách quan hơn, tôi nghĩ rằng điều ở trên chỉ là một triệu chứng. Vấn đề thực sự đó là chương trình hợp tác của MongoDB với các partner là hoàn toàn không có ý nghĩa gì.
Nhóm partner tại MongoDB báo cáo công việc trực tiếp cho Giám đốc Doanh thu (Carlos Delatorre), ngụ ý công việc chính của nhóm partner là để trích xuất doanh thu từ các đối tác. Điều này vốn đã làm lệch lạc hoạt động hợp tác, khi mà MongoDB đáng lẽ phải tạo điều kiện cho sự thành công của hệ sinh thái NoSQL xung quanh họ.
Trái ngược với các công ty nhỏ tập trung vào NoSQL như SlamData, Datos IO, và một số khác. Những công ty này thành công chính xác trong trường hợp NoSQL thành công, và họ cung cấp chức năng đã là tiêu chuẩn trong thế giới cơ sở dữ liệu quan hệ, trong đó các cơ sở dữ liệu NoSQL cần để phát triển mạnh trong các Enterprise.
Sau khi trở thành một đối tác của MongoDB trong hơn một năm, tôi có thể cho bạn biết rằng hầu như không có một ai trong MongoDB biết về sự tồn tại của SlamData, mặc dù thực tế rằng SlamData hoạt động như là một động lực mạnh mẽ cho các công ty khác lựa chọn MongoDB hơn các cơ sở dữ liệu NoSQL khác (ví dụ như: MarkLogic), và tư vấn cho nhiều công ty khác xem xét chuyển đổi từ cơ sở dữ liệu quan hệ (ví dụ như: Oracle) sang sử dụng NoSQL.
Mặc dù trong thực tế là đối tác của nhau, nhưng MongoDB hoàn toàn không quan tâm tới doanh thu doanh và cơ hội kinh doanh của các đối tác tập trung vào NoSQL khác. Không thỏa thuận đại lý bán lẻ. Không chia sẻ doanh thu. Không tiếp thị liên kết. Không có gì ngoài một cái logo mà thôi.
Điều này có nghĩa là về mặt tổ chức, MongoDB bỏ qua các đối tác tập trung vào NoSQL, những công ty đã mang lại nhiều lợi ích nhất cho họ. Trong khi đó, khách hàng và khách hàng tiềm năng lớn nhất của họ luôn đòi hỏi cơ sở hạ tầng chung cho cả thế giới cơ sở dữ liệu quan hệ, chẳng hạn như backup, replication, monitoring, analytics, data visualization, reporting, data governance, query analysis, và nhiều hơn nữa.
Nhu cầu này xuất hiện liên tục từ các công ty lớn hơn, kết hợp với việc không có khả năng nuôi dưỡng một hệ sinh thái, nên đã tạo thành một điểm yếu của MongoDB. Điều này dẫn đến việc MongoDB cố gắng tự tạo ra hệ sinh thái của riêng mình bằng cách tự xây dựng tất cả các sản phẩm có thể!
Backup? Replication? Monitoring? BI connectivity? Data discovery? Visual analytics? Họ đều tự làm tuốt.
Nhưng một nhà cung cấp cơ sở dữ liệu NoSQL duy nhất với các nguồn tài nguyên hữu hạn không thể xây dựng một hệ sinh thái xung quanh chính nó để cạnh tranh với các hệ sinh thái khổng lồ xung quanh công nghệ cơ sở dữ liệu quan hệ (thực hiện điều này rất tốn kém!). Vì vậy, điều này dẫn đến vấn đề dở khóc dở cười, như việc MongoDB tạo ra một công nghệ "giả" như BI connector.
Giải pháp để giải quyết vấn đề này là gì? Theo thiển ý của tôi, nó khá là đơn giản.
Đầu tiên, MongoDB nên nuôi dưỡng một hệ sinh thái sôi động bằng cách đầu tư và các đối tác đang tập trung vào NoSQL. Các đối tác này cần phải có chuyên môn sâu trong một lĩnh vực ngách tương ứng của họ, và tất cả họ sẽ thành công chỉ khi trong trường hợp MongoDB thành công.
Các đại diện bán hàng và quản lý tài khoản của MongoDB cần được trao quyền với các thông tin đối tác cung cấp giúp họ vượt qua khó khăn, và MongoDB nên xây dựng điều này trở thành một nguồn thu nhập lành mạnh.
MongoDB nên phát triển các tính năng có giá trị đáng kể cho Enterprise (chẳng hạn như các giao dịch ACID, các công cụ lưu trữ NVRAM, công cụ lưu trữ dạng cột, bản sao trung tâm dữ liệu chéo, v.v...), và chu đáo vẽ ra ranh giới giữa Community và Enterprise. Tất cả trong một cách cho phép các nhà phát triển có cùng khả năng trên các phiên bản khác nhau.
Mục tiêu để cho MongoDB có thể kiếm đủ doanh thu từ cơ sở dữ liệu mà không bị cám dỗ để tự tạo ra một hệ sinh thái kém cỏi.
Chính họ là người quyết định, nhưng tôi nghĩ rằng đây là chiến lược rất rõ ràng để giành chiến thắng.
Bái bai, MongoDB
Rõ ràng, tôi không thể chấp nhận được cái quyết định đưa vào sản phẩm một cơ sở dữ liệu quan hệ cạnh tranh như là một công cụ phân tích trên cơ sở dữ liệu NoSQL (post-relational) như MongoDB.
Theo quan điểm của tôi, thì quyết định này có hại cho cộng đồng, nó không tốt cho khách hàng, và nó không tốt cho không gian mới nổi của công cụ phân tích NoSQL .
Ngoài ra, điều này không thực hiện với đầy đủ minh bạch, nó cũng tồi cho giá trị toàn vẹn, mà đó là một trụ cột mà tất cả các công ty nên dựa vào (đặc biệt là các công ty nguồn mở).
Vì vậy, với bài viết này, tôi đã chính thức từ bỏ.
Tôi sẽ không bao giờ gửi email tới MongoDB nữa. Không còn tài trợ cho các bữa tiệc cocktail của MongoDB. Không còn chia sẻ ý kiến của tôi với một công ty mà thậm chí không thèm trả lời email.
Mọi thứ đã hoàn toàn chấm dứt.
Tôi cũng đã thổi một tiếng còi rõ ràng. Bởi lúc bạn đang đọc bài viết này, cả thế giới sẽ biết rằng MongoDB 3.2 BI Connector chính là cơ sở dữ liệu PostgreSQL, cùng một chút keo để làm phẳng dữ liệu, vứt bỏ một số thông tin, và hút ra bất cứ điều gì còn lại vào PostgreSQL.
Tất cả điều này có ý nghĩa gì đối với các công ty đang định giá MongoDB?
Điều đó tự bạn đã có kết luận, nhưng cá nhân tôi muốn nói nếu bạn đang ở trong thị trường cho một cơ sở dữ liệu NoSQL, bạn cần kết nối BI, và bạn cũng đang cân nhắc PostgreSQL, thì có lẽ bạn chỉ cần chọn PostgreSQL là đủ.
Sau tất cả, câu trả lời của riêng MongoDB cho vấn đề phân tích trên MongoDB là lấy dữ liệu trong MongoDB, làm phẳng nó, và đổ nó vào PostgreSQL. Nếu dữ liệu của bạn sẽ kết thúc thành dữ liệu quan hệ phẳng như trong PostgreSQL, tại sao không bắt đầu luôn từ nó? Việc gì phải mất công làm vòng vèo như vậy!
Ít nhất bạn có thể dựa vào cộng đồng PostgreSQL để đổi mới xung quanh NoSQL, điều mà họ đã làm trong nhiều năm qua. Không có cơ hội cho cộng đồng cơ sở dữ liệu MongoDB trong một sản phẩm trò hề "PostgreSQL NoSQL", và gọi nó là một cuộc cách mạng trong công nghệ cơ sở dữ liệu NoSQL.
Thật đáng buồn, đây chính xác những gì MongoDB đã làm ngược lại.
* KHOÁ HỌC ORACLE DATABASE A-Z ENTERPRISE trực tiếp từ tôi giúp bạn bước đầu trở thành những chuyên gia DBA, đủ kinh nghiệm đi thi chứng chỉ OA/OCP, đặc biệt là rất nhiều kinh nghiệm, bí kíp thực chiến trên các hệ thống Core tại VN chỉ sau 1 khoá học.
* CÁCH ĐĂNG KÝ: Gõ (.) hoặc để lại số điện thoại hoặc inbox https://m.me/tranvanbinh.vn hoặc Hotline/Zalo 090.29.12.888
* Chi tiết tham khảo:
https://bit.ly/oaz_w
=============================
KẾT NỐI VỚI CHUYÊN GIA TRẦN VĂN BÌNH:
📧 Mail: binhoracle@gmail.com
☎️ Mobile/Zalo: 0902912888
👨 Facebook: https://www.facebook.com/BinhOracleMaster
👨 Inbox Messenger: https://m.me/101036604657441 (profile)
👨 Fanpage: https://www.facebook.com/tranvanbinh.vn
👨 Inbox Fanpage: https://m.me/tranvanbinh.vn
👨👩 Group FB: https://www.facebook.com/groups/DBAVietNam
👨 Website: https://www.tranvanbinh.vn
👨 Blogger: https://tranvanbinhmaster.blogspot.com
🎬 Youtube: https://www.youtube.com/@binhguru
👨 Tiktok: https://www.tiktok.com/@binhguru
👨 Linkin: https://www.linkedin.com/in/binhoracle
👨 Twitter: https://twitter.com/binhguru
👨 Podcast: https://www.podbean.com/pu/pbblog-eskre-5f82d6
👨 Địa chỉ: Tòa nhà Sun Square - 21 Lê Đức Thọ - Phường Mỹ Đình 1 - Quận Nam Từ Liêm - TP.Hà Nội
=============================
oracle tutorial, học oracle database, Tự học Oracle, Tài liệu Oracle 12c tiếng Việt, Hướng dẫn sử dụng Oracle Database, Oracle SQL cơ bản, Oracle SQL là gì, Khóa học Oracle Hà Nội, Học chứng chỉ Oracle ở đầu, Khóa học Oracle online,sql tutorial, khóa học pl/sql tutorial, học dba, học dba ở việt nam, khóa học dba, khóa học dba sql, tài liệu học dba oracle, Khóa học Oracle online, học oracle sql, học oracle ở đâu tphcm, học oracle bắt đầu từ đâu, học oracle ở hà nội, oracle database tutorial, oracle database 12c, oracle database là gì, oracle database 11g, oracle download, oracle database 19c, oracle dba tutorial, oracle tunning, sql tunning , oracle 12c, oracle multitenant, Container Databases (CDB), Pluggable Databases (PDB), oracle cloud, oracle security, oracle fga, audit_trail,oracle RAC, ASM, oracle dataguard, oracle goldengate, mview, oracle exadata, oracle oca, oracle ocp, oracle ocm , oracle weblogic, postgresql tutorial, mysql tutorial, mariadb tutorial, ms sql server tutorial, nosql, mongodb tutorial, oci, cloud, middleware tutorial, hoc solaris tutorial, hoc linux tutorial, hoc aix tutorial, unix tutorial, securecrt, xshell, mobaxterm, putty
