Bài viết của tác giả John De Goes là CTO của SlamData Inc.
Cuối cùng khi tôi tập hợp tất cả các manh mối lại với nhau, tôi đã bị sốc. Nếu tôi đúng, thì MongoDB có thể đã làm những việc mà tôi cho là sai lầm lớn nhất từng được thực hiện trong lịch sử của các công ty cơ sở dữ liệu.
Tôi làm việc trên một công cụ phân tích mã nguồn mở để kết nối tới các cơ sở dữ liệu NoSQL như MongoDB, nên tôi đã dành toàn bộ thời gian của mình cho các nhà cung cấp cơ sở dữ liệu thế hệ kế tiếp trở nên thành công.
Thực ra, tôi vừa mới có một bài trình bày tại một phiên thảo luận nằm trong chuỗi sự kiện MongoDB Days ở Thung lũng Silicon, đưa ra những lợi điểm để thuyết phục các công ty sử dụng cơ sở dữ liệu mới này.
Vì vậy, khi tôi phát hiện ra bí mật tồi tệ này, tôi cảm thấy khá hoảng loạn: vào ngày 12/11/2015, tôi đã gửi một bức email đến Asya Kamsky, là Giám đốc sản phẩm (Lead Product Manager) tại MongoDB.
Với một thái độ lịch sự, tôi đã trình bày ý kiến của mình một cách rõ ràng rằng: MongoDB đang thực hiện một sai lầm to lớn, và nên xem xét lại thì may ra còn kịp.
Tôi sẽ chẳng bao giờ nhận được email trả lời từ Asya - hoặc bất cứ ai khác từ công ty MongoDB về vấn đề này. Thành công trước đây của tôi trong việc giúp đỡ thuyết phục MongoDB đảo ngược tiến trình khi họ cố gắng kiếm tiền từ các tính năng sai lầm sẽ không được lặp lại.
Đây là câu chuyện về những gì tôi đã phát hiện ra, nó là tổng hợp của những thông tin mà tôi chắp ghép qua các manh mối từ các thông cáo báo chí, video YouTube, mã nguồn nằm rải rác trên Github, và cuối cùng tôi đã thất bại ra sao khi không thuyết phục được MongoDB thay đổi tiến trình sai lầm đó.
Câu chuyện bắt đầu vào 1 tháng 6 năm 2015, tại hội nghị hàng năm MongoWorld diễn ra tại thành phố New York.
MongoWorld 2015
SlamData, công ty startup của tôi, là nhà tài trợ cho sự kiện MongoWorld 2015, vì vậy tôi có một tấm vé hiếm hoi để tham gia một buổi tiệc gồm các quan khách VIP vào đêm trước khi diễn ra hội nghị.
Buổi tiệc được tổ chức tại NASDAQ MarketWatch, trong một không gian đẹp nhìn ra Quảng trường Thời đại, so với các quan khách thì tôi cảm thấy mình ăn mặc khá xuề xòa trong chiếc quần jean và chiếc áo t-shirt in hình logo startup của mình. Trong điệu nhạc du dương và rượu chảy tràn ly, đội ngũ quản lý của MongoDB đều có mặt đông đủ.
Tôi bắt tay với Giám đốc điều hành mới của MongoDB, là Dev ("Dave") Ittycheria, và nói với ông ta một vài lời động viên cho con đường phía trước.
Chỉ trong năm nay, quỹ đầu tư mạo hiểm Fidelity Investments đã giảm lượng vốn của họ trong MongoDB đến 50% so với thời điểm năm 2013 ($1.6 tỷ đô-la), và đã hạ mức tín nhiệm startup này từ "con kỳ lân (unicorn)" xuống thành "con lừa (donkey)".
Công việc của Dev là chứng minh cho quỹ đầu tư Fidelity và phần còn lại thấy rằng họ đã quyết định thoái vốn một cách sai lầm.
Dev tiếp quản công ty từ Max Schireson (người nổi tiếng đã từ chức vào năm 2014), và trong nhiệm kỳ của ông, Dev đã xây dựng nên một đội ngũ quản lý mới tại MongoDB, với nhiều bất cập tồn tại trong công ty này.
Mặc dù tôi chỉ nói chuyện với Dev trong vài phút, nhưng ông ta có vẻ rất thông minh, thân thiện, và muốn tìm hiểu về những gì công ty của tôi đã làm. Ông ta đưa cho tôi tấm danh thiếp của mình và nói tôi cứ gọi cho ông nếu tôi cần bất cứ điều gì.
Kế tiếp là Eliot Horowitz, CTO và đồng sáng lập của MongoDB. Tôi bắt tay anh ta, và giới thiệu về bản thân mình, và dành ra khoảng 30 giây để giới thiệu về startup của tôi.
Vào thời điểm đó, tôi nghĩ rằng tôi đã quảng cáo cho startup của mình quá tồi, vì Eliot có vẻ dường như chẳng quan tâm đến mọi thứ mà tôi nó. Hóa ra Eliot ghét SQL và xem các công cụ phân tích như là một mối phiền toái, vì vậy cũng không có gì đáng ngạc nhiên khi tôi không ưa anh ta!
Tuy nhiên, Eliot đã tiết lộ rằng vào ngày mai tại hội nghị, MongoDB sẽ có một số tin tức về việc phát hành phiên bản 3.2 sắp tới, và rằng tôi sẽ cảm thấy thấy rất thú vị.
Tôi năn nỉ anh ta cho biết thêm chi tiết, nhưng không được, vì đó là bí mật. Tôi đã biết đó là điều gì vào ngày hôm sau, cũng như phần còn lại của thế giới.
Tôi có chia sẻ thông tin với đồng sáng lập startup của mình là Jeff Carr, và chúng tôi đều có một khoảnh khắc ngắn ngủi trong sự lo lắng. Nỗi sợ hãi lớn nhất đối với 4 người chúng tôi, những người tự góp vốn xây dựng startup của mình đó là MongoDB sẽ công bố công cụ phân tích của riêng họ, nếu điều đó xảy ra có thể sẽ làm chúng tôi mất cơ hội kêu gọi vốn cho startup của mình.
Chúng tôi đã cảm thấy nhẹ nhõm, vì những ngày sau đó thông báo lớn của MongoDB không phải là về một công cụ phân tích. Thay vào đó, nó là một giải pháp được gọi là MongoDB BI Connector, một tính năng chính của phiên bản 3.2 phát hành sắp tới.
MongoDB 3.2 BI Connector
Eliot đã có vinh dự công bố về BI connector đó. Trong số tất cả những thứ anh ta công bố, Eliot dường như ít quan tâm nhất đến công cụ connector này, vì vậy nó hầu như chỉ là một đề cập sơ qua.
Nhưng các chi tiết nhanh chóng lan rộng như đám cháy rừng nhờ một thông cáo báo chí chính thức của công ty, trong đó nó được tóm tắt ngắn gọn như thế này:
MongoDB hôm nay công bố một connector mới cho BI và visualization, nó kết nối MongoDB tới các chuẩn business intelligence (BI) và các công cụ trực quan dữ liệu (data visualization). Được thiết kế để làm việc với tất cả các công cụ phân tích dữ liệu SQL-compliant trên thị trường, bao gồm cả Tableau, SAP Business Objects, Qlik và IBM Cognos Business Intelligence, connector này hiện đang ở phiên bản preview và dự kiến sẽ trở thành phiên bản chính thức trong quý IV năm 2015.
Theo như thông cáo báo chí, BI connector sẽ cho phép bất kỳ phần mềm BI nào trên thế giới đều có thể giao tiếp với cơ sở dữ liệu MongoDB.
Tin tức về bộ connector đó xuất hiện trên Twitter, và giới truyền thông nhảy vào một cách điên cuồng. Câu chuyện này đã được đăng tải bởi TechCrunch và nhiều trang báo khác. Mỗi trang báo lại thêm mắm thêm muối để tăng thêm phần kịch tính, trang Fortune thậm chí tuyên bố rằng BI connector thực sự đã được phát hành tại sự kiện MongoWorld!
Do tính chất mập mờ của thông báo, dẫn đến hệ quả các phương tiện truyền thông tô vẽ thêm có lẽ là hợp lý.
Khi các thế giới đụng nhau
MongoDB, giống như nhiều cơ sở dữ liệu NoSQL khác, không lưu trữ dữ liệu quan hệ. Nó lưu trữ các cấu trúc dữ liệu phong phú mà phần mềm BI dạng quan hệ không thể hiểu được.
Kelly Stirman, Phó chủ tịch chiến lược tại MongoDB, đã giải thích vấn đề này rất rõ ràng:
"Thứ định nghĩa các ứng dụng hiện đại đó là các cấu trúc dữ liệu phong phú (rich data structures) không khít một cách gọn gàng vào các hàng và cột của cơ sở dữ liệu truyền thống."
Một connector cho phép bất kỳ phần mềm BI nào trên thế giới thực hiện những phân tích mạnh mẽ trên các cấu trúc dữ liệu phong phú (rich data structures), mà không làm mất đi tính chính xác trong phân tích, sẽ là một tin tức gây chấn động.
MongoDB đã thực sự làm được điều không thể đó ư? Nếu họ phát triển một connector đáp ứng tất cả các yêu cầu phân tích của NoSQL, nhưng đưa ra các ngữ nghĩa quan hệ dạng phẳng (flat), dữ liệu thống nhất, nên phần mềm BI có thể xử lý được nó?
Một vài tháng trước đó, tôi đã nói chuyện với Ron Avnur, Phó chủ tịch phụ trách sản phẩm của MongoDB. Ron chỉ ra rằng tất cả các khách hàng của MongoDB đều rất muốn một công cụ phân tích, nhưng họ vẫn chưa quyết định liệu nên tự xây dựng một công cụ như vậy hay là hợp tác với một đối tác nào đó.
Điều này có nghĩa là MongoDB đã đi từ không có gì đến điều kỳ diệu chỉ trong một vài tháng.
Vén bức màn bí ẩn
Sau thông báo đó, Jeff và tôi quay trở lại gian hàng dành cho nhà tài trợ của mình, và Jeff đã hỏi tôi câu hỏi rõ ràng nhất: "Làm thế quái nào mà họ đi từ không có gì đến một BI connector có thể làm việc được với tất cả các công cụ BI chỉ trong vòng một vài tháng vậy?!?"
Tôi đã suy nghĩ cẩn thận về câu hỏi này.
Trong số các vấn đề khác mà một BI connector sẽ cần phải giải quyết, nó sẽ phải có khả năng thực hiện các phân tích SQL-like một cách hiệu quả trên MongoDB. Từ nền tảng kiến thức sâu sắc của mình trong phân tích, tôi biết rằng việc thực hiện các phân tích đa mục đích trên các cơ sở dữ liệu hiện đại như MongoDB là điều rất khó khăn.
Những cơ sở dữ liệu hỗ trợ các cấu trúc dữ liệu rất phong phú (very rich data structures) và các interface của chúng được thiết kế cho cái gọi là operational use cases (chứ không phải là analytical use cases). Loại công nghệ có thể tận dụng các operational interface để chạy các phân tích tùy ý trên các cấu trúc dữ liệu phong phú (rich data structures) thường phải mất nhiều năm để phát triển. Nó không phải một cái gì đó bạn có thể hoàn thành trong vòng 2 tháng.
Vì vậy, tôi đã trả lời Jeff bằng suy nghĩ từ đáy lòng mình: "Họ đã không tạo ra một BI connector mới. Đó là điều không thể. Có cái gì đó khác đang xảy ra ở đây!"
Tôi không biết chính xác đó là cái gì. Nhưng ở giữa những cái bắt tay và trao danh thiếp, thì tôi đã làm một số việc để điều tra về nó.
Hãng Tableau trình bày một bản demo về phần mềm của họ làm việc với MongoDB BI Connector, điều này khơi gợi sự tò mò của tôi. Tableau đã thiết lập một tiêu chuẩn cho các phân tích trực quan (visual analytics) trên cơ sở dữ liệu quan hệ, và team làm việc với dữ liệu lớn của họ đã chuyển suy nghĩ đó sang NoSQL một cách nghiêm túc.
Nhờ mối quan hệ của họ với MongoDB, Tableau phát hành một thông cáo báo chí để ủng hộ thông báo của MongoWorld, cái mà tôi đã tìm thấy trên trang web của họ.
Tôi mải mê nghiên cứu thông cáo báo chí này và hy vọng sẽ tìm thấy một số chi tiết mới. Những bí mật được chôn sâu bên trong, và tôi đã phát hiện ra một gợi ý thoáng qua về những gì đã xảy ra:
MongoDB sẽ sớm công bố bản beta của connector, cùng với kế hoạch xung quanh việc phát hành phiên bản MongoDB 3.2 vào cuối năm nay. 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.
Đây là những từ đã cung cấp manh mối đầu tiên cho tôi: thông qua PostgreSQL driver của chúng tôi. Điều này ngụ ý, ở mức tối thiểu, rằng BI Connector của MongoDB của sẽ nói chuyện cùng một "ngôn ngữ" (wire protocol) với cơ sở dữ liệu PostgreSQL.
Điều đó làm cho tôi cảm thấy một chút nghi ngờ: liệu MongoDB có thực sự sử dụng toàn bộ giao thức (wire protocol) của PostgreSQL, bao gồm hỗ trợ cho hàng trăm chức năng của PostgreSQL?
Trong khi điều này là có thể, nhưng nó có vẻ rất khó xảy ra.
Tôi chuyển sang quan sát trên Github, để tìm kiếm các dự án mã nguồn mở nào mà MongoDB có thể đã sử dụng làm đòn bẩy. Sóng wifi tại hội nghị rất chập chờn, vì vậy tôi đã phải gắn chặt với điện thoại của mình trong khi quan sát hàng tá repositories có đề cập đến cả PostgreSQL và MongoDB.
Cuối cùng, tôi đã tìm thấy cái mà tôi cần tìm: mongoose_fdw, một repository mã nguồn mở forked bởi Asya Kamsky (người mà tôi không biết vào thời điểm đó, nhưng profile cho thấy cô ta làm việc tại MongoDB).
Repository đó chứa một cái được gọi là Foreign Data Wrapper (FDW) cho cơ sở dữ liệu PostgreSQL. FDW interface đó cho phép các nhà phát triển cắm vào những nguồn dữ liệu khác, để PostgreSQL có thể lấy dữ liệu ra và thực thi SQL trên dữ liệu đó (dữ liệu NoSQL phải được làm phẳng (flattened), bổ sung thêm dữ liệu null (null-padded), và thậm chí phải lọc bỏ bớt để nó có thể làm việc được với các công cụ BI).
"Tôi nghĩ là tôi biết điều gì đang xảy ra", tôi nói với Jeff như vậy. "Đối với nguyên mẫu (prototype) đó, có vẻ như họ đã làm phẳng (flattening ) dữ liệu và sử dụng một cơ sở dữ liệu khác để thực thi SQL được tạo ra bởi phần mềm BI."
"Cơ sở dữ liệu nào?" anh hỏi ngược trở lại.
"PostgreSQL."
Jeff đứng như trời trồng. Anh đã không nói thêm một lời nào nữa. Nhưng tôi có thể nói chính xác những gì anh đang suy nghĩ, bởi vì tôi cũng đang suy nghĩ về nó.
Đúng là c*'t thật. Đây là tin xấu đối với MongoDB. Điều này thực sự tồi tệ.
Bạn đọc tiếp phần 2 bài viết tại link này: https://techmaster.vn/posts/33694/mongodb-dua-vao-suc-manh-cua-postgresql-2
* 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
