ProcessOne SiteCustomer Helpdesk and FeedbackFollow us on Twitter
 
   
 
MongoDB on ejabberd
Posted: 16 February 2012 07:50 AM   [ Ignore ]
Newbie
Rank
Total Posts:  1
Joined  2012-02-16

Hi all,

We have a project where we’d like to integrate ejabberd with an existing
system based on MongoDB.

I’ve seen approaches to running ejabberd over Mongo which involve an
ODBC wrapper, but I’d like to avoid that—it strikes me as inefficient
(and complicated!), and involves using a highly relational schema in
Mongo, which it isn’t well-suited for.

Instead, we’d like to write a new gen_storage backend, implementing the
same API as gen_storage_odbc and translating queries to native Mongo
calls.


That part seems fairly easy, but there are places in the ejabberd code
that explicitly check backend names (e.g. gen_storage:create_table, and
one place in gen_storage:table_info which looks like a bug).

I also notice that mod_pubsub seems to have two completely parallel
implementations, one for mnesia and one for odbc, which duplicate code
rather than abstracting backend calls out via gen_storage. I can’t
immediately see a reason for this.


So, we’d like to write a patch for ejabberd which does the following:

- Minor tweaks to gen_storage to allow custom backends in places like
create_table

- Minor tweaks to other hardcoded backend references (e.g.
mod_roster:update_table) to allow the same.

- Major refactoring of mod_pubsub to abstract out storage calls, either
via gen_storage or by splitting it into e.g. mod_pubsub,
mod_pubsub_storage_mnesia, and mod_pubsub_storage_odbc, and then
allowing alternate backends to be injected.


If we do this, what are our chances of getting it merged into trunk? Are
there major problems that I haven’t anticipated, or existing work in the
same direction?

Profile
 
 
Posted: 20 February 2012 11:24 AM   [ Ignore ]   [ # 1 ]
Senior Member
Avatar
RankRankRankRank
Total Posts:  134
Joined  2006-11-13

Hello

pubsub have two implementations (mod_pubsub_odbc being generated from mod_pubsub with pubsub_odbc.patch) for performances reasons.
indeed,  if we want to take minimal advantage of SQL, we can not exactly map calls to database the same way with odbc and mnesia.

We already have worked on a complete rewrite of a pubsub server to abstract storage, and it’s online for P1PP service:
http://www.process-one.net/en/blogs/article/p1pp_goes_live_with_tools/
This is a kind of rewrite you are talking about, except we do not use MongoDB.
But this code is not going to be part of ejabberd, and is a lot of work.

Profile