On behalf of all contributors to the MongoDB module suite for Drupal over the years, I am pleased to announce the 8.x-2.0-alpha1 release of the MongoDB package for Drupal 8, six years after we started this project on Drupal 6.
This release is the first step to an initial stable release of the MongoDB package for Drupal 8, containing:
mongodba module exposing the new PHP library as Symfony services exposed to a Drupal 8.x instance. It is designed as a minimal and consistent connection layer on top of the PHP library for MongoDB, for all modules targeting MongoDB on Drupal 8.x, be they contributed or bespoke.mongodb_watchdoga PSR-3 logger storing event data in MongoDB. On top of the features already present in 6.x and 7.x versions, it introduces a per-request report showing all events logged during a request, in order.
Roadmap
The 8.x-2.x series is a reboot of this package: initial work on the Drupal 8 version of the package, in branch 8.x-1.x, is a moonshot project aiming at providing a fully No SQL version of Drupal. Although it made good progress for the first years of Drupal core 8.x development, thanks especially to MongoDB Inc. sponsorship, it has shown little progress since 2015, and is not compatible with any stable version of Drupal 8 core.
To leave a chance for that ambitious branch to resume development, 8.x-2.x has been started as a lower-risk version focused on:
- Not only SQL: supporting MongoDB on top of a standard Drupal distribution, rather than providing a full SQL-less CMS
- Use of newer code like MongoDB 3.x series, the new
mongodbPHP extension, and PHP 7.x, rather than continued support for older MongoDB versions, the legacymongoextension, and PHP 5.5/5.6 - Providing an actual usable release in the wake of Drupal Dev Days Milan 2016, rather than an ongoing dev branch with little visibility
- Providing new services as ongoing incremental releases rather than wait for the whole set to be available
Contributors
The MongoDB package for Drupal 8 is the work of multiple contributors: Karoly Negyesi (chx), Frédéric G. MARAND (fgm), Janez Urevc (slashrsm), Zsolt Tasnádi (skipyT), Marc Ingram (marcingy), Rok Žlender (Rok Žlender), Jakob Perry (japerry), Philippe Guillard (pguillard), ...and the many contributors to earlier versions, without whom this would not exist today.
Are you still believing that
Are you still believing that NoSQL is better than SQL where PostgreSQL achieve better performance and scalability than MongoDB (and where MongoDB suicide itself once a month)?
Not Only SQL ?
Well, I have yet to see a Drupal site based on PGSQL achieve reasonable performance without some PGSQL specialist DBA working on it, while neither MySQL nor MongoDB require much to give better result than raw, untuned PGSQL. Note I'm not claiming it can't be done, but for some reason I never saw a client willing to spend resources on DB tuning for Drupal sites, although they had no big trouble requiring bigger machines, more custom development, adding a NoSQL solution (be it MongoDB, Redis, Memcached, RethinkDB...).
Maybe you could publish a set of articles on your blog, or even on d.o. doc pages to detail how to tune PGSQL to beat more pervasive technologies like MariaDB / Percona / MySQL : it might trigger a general change of mind about our default DB. Actually seeing the work you and Berdir did on Redis, it looks like - PGSQL or not - you still think a NoSQL store is still required for Drupal sites, don't you ?
Also, in case you didn't notice, RoySegall has been doing very interesting work recently on https://drupal.org/project/rethinkdb : it might well go further than anything we've had until now on any NoSQL solution.
Yes, I guess that PostgreSQL's not easy to tune
Yes, I guess that PostgreSQL's not easy to tune. A while back I did see a few benchmarks on the JSON and JSONB types of PostgreSQL, I should try to find back again. But once again, I never got the chance to see MongoDB scale since it was consistently breaking data, in most of our usage we ended up removing it and doing good'old SQL instead, it never failed us. But my experience is limited, and I never tried latest versions, since they changed their backend.
You know me quite well, I like to flame, especially when it comes to fun stuff such as NoSQL :)
All jokes aside, in my whole experience, I never got any use case where the database broke due to excessive loads, at the exception, of course, of Drupal that doesn't use it the right way.