== MongoDB Currently CDRTool uses OpenSIPS radius client/ FreeRadius server/ MySQL database chain. This chain has weaknesses and scalability drawbacks, too many to mention. Based on this analysis, MongoDB is a good candidate to replace the whole chain with a more scalable and elegant solution. * Scales horizontally with the amount of hardware * Almost zero configuration to install and run on Debbian, a few binaries only * All works as one would expect a database, well documented by the makers * Easy to learn and use (about two days) * Multiple collections per database, equivalent to table in SQL * Document oriented, a document is equivalent to a row in SQL schema * Documents can have a different structure, unlike SQL schemas that have fixed columns * Documents are JSONs. Can be imported and exported as such using cli tools. Backup/restore is dead easy * Query language is dead simple using array/dictionaries * Clever pipelines of processing on database server similar to UNIX pipes (version > 2.2) * All CDRTool SQL queries equivalent were possible (with latest 2.2 server version and 1.3 client version) * Multiple nodes with automatic replication, nothing to repair, does not conflict * New nodes can be added or removed with a simple command, data replicated on the fly without locking

== MongoDB Currently CDRTool uses OpenSIPS radius client/ FreeRadius server/ MySQL database chain. This chain has weaknesses and scalability drawbacks, too many to mention. Based on this analysis, MongoDB is a good candidate to replace the whole chain with a more scalable and elegant solution. * Scales horizontally with the amount of hardware * Almost zero configuration to install and run on Debbian, a few binaries only * All works as one would expect a database, well documented by the makers * Easy to learn and use (about two days) * Multiple collections per database, equivalent to table in SQL * Document oriented, a document is equivalent to a row in SQL schema * Documents can have a different structure, unlike SQL schemas that have fixed columns * Documents are JSONs. Can be imported and exported as such using cli tools. Backup/restore is dead easy * Query language is dead simple using array/dictionaries * Clever pipelines of processing on database server similar to UNIX pipes (version > 2.2) * All CDRTool SQL queries equivalent were possible (with latest 2.2 server version and 1.3 client version) * Multiple nodes with automatic replication, nothing to repair, does not conflict * New nodes can be added or removed with a simple command, data replicated on the fly without locking * One primary node elected by nodes, is the entity responsable for writing data * Connected clients are aware of the primary selection and always write to elected primary * Writes can be done with or without confirmation of committing to disc * Clients can connect automatically to closest server RTT-wise * Read queries can be targeted to slaves located in tagged data centers * No need to create tables in advance, all is created on the fly (e.g. radacct tables) * Data can expire automatically, no need to manually purge old logs (e.g. siptrace table) * Clients available for every programming language * Clients automatically failover * Client can discover the whole cluster set by connecting to any available node * Supports TLS transport for encrypted client to server connections * Supports authentication * Self-learning DNS can be used to discover nodes === Minuses * Does not support the equivalent of SQL JOIN between tables. The need for joins can be eliminated by chosen data model

== MongoDB Currently CDRTool uses OpenSIPS radius client/ FreeRadius server/ MySQL database chain. This chain has weaknesses and scalability drawbacks, too many to mention. Based on this analysis, MongoDB is a good candidate to replace the whole chain with a more scalable and elegant solution. * Scales horizontally with the amount of hardware * Almost zero configuration to install and run on Debbian, a few binaries only * All works as one would expect a database, well documented by the makers * Easy to learn and use (about two days) * Multiple collections per database, equivalent to table in SQL * Document oriented, a document is equivalent to a row in SQL schema * Documents can have a different structure, unlike SQL schemas that have fixed columns * Documents are JSONs. Can be imported and exported as such using cli tools. Backup/restore is dead easy * Query language is dead simple using array/dictionaries * Clever pipelines of processing on database server similar to UNIX pipes (version > 2.2) * All CDRTool SQL queries equivalent were possible (with latest 2.2 server version and 1.3 client version) * Multiple nodes with automatic replication, nothing to repair, does not conflict * New nodes can be added or removed with a simple command, data replicated on the fly without locking * One primary node elected by nodes, is the entity responsable for writing data * Connected clients are aware of the primary selection and always write to elected primary * Writes can be done with or without confirmation of committing to disc * Clients can connect automatically to closest server RTT-wise * Read queries can be targeted to slaves located in tagged data centers * No need to create tables in advance, all is created on the fly (e.g. radacct tables) * Data can expire automatically, no need to manually purge old logs (e.g. siptrace table) * Clients available for every programming language * Clients automatically failover * Client can discover the whole cluster set by connecting to any available node * Supports TLS transport for encrypted client to server connections * Supports authentication * Self-learning DNS can be used to discover nodes === Minuses * Does not support the equivalent of SQL JOIN between tables. The need for joins can be eliminated by chosen data model