Sigimera Architecture v2.0

mongodb-logo

It is not the first time that Sigimera had changed the underlying architecture. The first few were prototypes to exploit different technologies and find there weakness. After a extended exploitation phase the business logic was simplified and of course the REST API too. But more important is the switch to a scalable, but powerful, database. The following list summarizes why we have chosen MongoDB:

  • Horizontal scalability – Important for our crowd-sourcing approach. If more resources are needed we are able to mirror our whole platform (services + api + database) to a new host.
  • Schema-less document structure – Represents our internal structure; each crisis is a document, the same is true for multimedia meta data, user profiles, …
  • BSON format for internal storage - BSON is similar to JSON. This fact allows trivial transformation from internal to public data representation. In difference to Apache Cassandra this structure allows more complex nested structures, such as Arrays and or nested BSON objects.
  • Full index support - Allows to write complex queries.>
  • Geo-Spatial Queries - This type of queries are very important for our use-case. Each crisis has a related GPS coordinate tuple and in the most cases the users wants to see crisis near his/her location.
  • Perfect for logging messages - Collections can be limited by size (Capped Collection with  auto-FIFO age-out feature). This means that if the maximum size is reached the old message are overwritten with new one.
  • GridFS - Perfect for multimedia files uploaded by the users. Adds querying capabilities by meta data and distributes the files over more hosts (chunked) if needed.

MongoDB seams to be made specially for our use-case and it is additional really easy to use. In combination with our Web Service structure, that allows the splitting of single features to different hosts, this architecture should be future-proof.  To assure suitable performance the file storage is not handled by an underlying Web Service, but directly by REST API.

Sigimera is not quite finished and was not tested in a real-world scenario, but currently it looks promisingly that it could work out very well. Otherwise there will come another architecture changes…

About Alex Oberhauser

Alex Oberhauser’s current private and professional interests are Research and Development in the area of Semantic Web and Service Oriented Architecture with the focus on the applicability of new technologies in real world scenarios. He is founder of the meta project Networld and the Crisis Information Platform Sigimera (http://www.sigimera.org).



Fork me on GitHub
Category(s): Sigimera

4 Responses to Sigimera Architecture v2.0

  1. Useful information. Lucky me I discovered your website by chance, and I’m surprised why this twist of fate didn’t took place in advance! I bookmarked it.

  2. I am glad that you find the information useful.

  3. Great post. I was checking constantly this weblog and I am inspired! Very useful info specifically the remaining phase Smilie: :) I handle such information a lot. I used to be looking for this certain info for a very long time. Thank you and good luck.

Leave a Reply

Your email address will not be published. Required fields are marked *

*


*

 

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>