-
Notifications
You must be signed in to change notification settings - Fork 0
Performance
I'm not a database expert nor do I think that mqttDB as of today is good at scaling. mqttDB handles memory quite inefficient, the whole database is kept in memory in the core and all the worker processes.
mqttDB wasn't designed for storing gigabytes of data or millions of documents, the concept was made with a couple of dozen views and a few thousand rarely changing documents of small size in mind. You should find out for yourself if it can deliver sufficient performance for your use case.
Due to the fact that mqttDB just uses retained MQTT messages to publish all documents and views, you have to be aware that this might - depending on the amount/size of documents/views and the subscription count - put significant load on your MQTT broker and raise it's memory consumption.
Furthermore you should take care that your database clients only subscribe the topics they really need, it should be well considered if it's really needed to subscribe to db/doc/#. A better approach could possibly be to create a views that contains the ids of needed documents for specific client, let the client first subscribe to that view and then subscribe only to the documents that are specified by the view.
mqttDB copyright (c) 2017 Sebastian Raff. MIT License