Introduction

Follow

Countly and MongoDB

Countly uses MongoDB engine to persistently store and retrieve analytics data. MongoDB is a leading NoSQL with JSON style documents, which fits great with both the capabilities of Countly and serverside environment NodeJS.

You can read more about MongoDB on their official website: http://www.mongodb.org/

For SQL database users, there are some changes in terminology that you should become familiar with.

SQL term MongoDB term
Database Database
Table Collection
Row Document

Additionally you should know that documents may have properties many levels deep, unlike SQL rows. So for some of you Countly database scheme may seem like a nightmare, but it was designed with performance in mind, for both storing and retrieving data, thus sometimes it can be far from easily understandable.

For Countly Enterprise, countly divides data in 2 databases:

  • countly - common statistics for users and metrics
  • countly_drill - deeper insight on data relations

To view contents of your Countly databases, you can use DBViewer Plugin, which provides both browsing through Web UI and REST API for data extraction.

There are also other third party libraries available, as Mongo-Express: https://www.npmjs.org/package/mongo-express

There are also other solutions, that will help you to easily set up REST API to query Mongo databases. You may find solution suitable for your needs and environment here: http://docs.mongodb.org/ecosystem/tools/http-interfaces/

New Data Model

With the release of Countly 24.10, a new data model has been introduced to simplify data management. This model introduces two key collections:

  • countly.events_data - All aggregated events from various apps are now stored in this single collection, replacing the previous multiple countly.events_data+HASH collections.
  • countly_drill.drill_events - Granular data is now consolidated into a single collection, eliminating the need for multiple drill_events+HASH collections.

Note: If you start a new server, only the countly_drill.drill_events collection will be present. However, if the server is upgraded, it will retain all previous countly_drill.drill_events{ID} collections along with the data gathered before the upgrade.

Additionally, two new fields have been added to support this transition:

  • a - This field identifies the app from which the event originates, making it easier to trace the source.
  • e - This field represents the event key, categorizing and defining the specific type of event.

For more details on the migration process and changes, refer to the migration guide here.

Looking for help?