Version 3 vs 4
Version 3 vs 4
Content Changes
Content Changes
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
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