In 2012, Krescendo introduced NoSQL technologies to its infrastructure. MongoDB was the chosen distribution as it provided answers to the key requirements of scalability, resiliency, performance, and flexibility. During the early stages all implementations used the MongoDB Java driver directly, with hand build data access layers. Implementations were then refactored to use Spring Data abstractions and MongoDB Templates, this made for simpler configuration and integration.
Why did Krescendo consider NoSQL?
– For non-relational data the overhead of running a heavy relational database management system (RDBMS) is unnecessary
– Specific requirements introduced the need to store less structured data (prior to embracing NoSQL technologies Krescendo’s systems stored unstructured data in MySQL database fields using coded text, XML, or raw JSON)
– MySQL databases containing tables with large Blob fields for unstructured data were not scalable, difficult to administer, and difficult to query
– Better resiliency due to the fact that MongoDB was designed with secure clustering in mind
The largest MongoDB databases within the Krescendo infrastructure are for:
– Auditing
– File Management
Krescendo is also migrating its Messaging solutions to this architecture.
Auditing
What is it?
Krescendo have developed an Auditing service to track changes to data items. The Auditing service is also being used to log particular events.
Why was it implemented?
Krescendo develop and support systems for a number of clients which are mainly CRUD based web applications.
Before the auditing service was deployed it was normal practice to store the last update date/time and the last update user ID against each MySQL database record. For client specific requirements ad-hoc services were developed to build a history of changes. These ad-hoc services used varying data structures with the common storage mechanism of a MySQL database table field and a Blob of text. Data items that were updated frequently introduced capacity issues on MySQL table fields, and memory capacity issues when loading objects from the database. Specific views on audit data introduced performance issues, querying the MySQL data involved intensive processing, prolonged table locks, and due to the size of the Blobs disk swapping became common.
Behold the Auditing service. The Auditing service is completely standalone, multiple instances can be deployed as and when necessary. The Audit data is stored across 4 servers, within a MongoDB cluster, spanning across 2 data centres, using SSL to transmit data securely between the 2 sites. In each data centre there is a “triad” consisting of 2 data nodes and an arbiter node. Access to the data is strictly through REST, however, for guaranteed delivery of data RabbitMQ is used to send the audit information to the service.
File Management
What is it?
Krescendo have developed a clustered File Management repository service (for compliance reasons external cloud solutions, such as Amazon S3, were not an option).
Why was it implemented?
Many of the Krescendo services/applications support file uploads and file attachments. One of the biggest applications that Krescendo develop and support is a Call Tracking system for a global financial institution. This call tracking system supports the raising of tickets via email, where each email generates at least 3 files. This system is fairly high volume, 4000 call tickets per day. For each call ticket there is on average 4 files, so that’s 16000 files per day, ~5.8 million files per year. This volume introduced 3 big challenges, general system capacity limitations, replication to the secondary data centre for disaster recovery purposes, and archiving.
Behold the File Manager service. Like the auditing service the File Manager is standalone such that multiple instances can be deployed. All data transfer is over HTTPS via REST APIs. For a production system, there are at least 3 deployments of the File Manager acting as nodes. The first deployment normally runs on the same hardware as the integrating application, used purely as a queue/gateway to the live nodes. The local instance is configured to replicate to at least 2 live nodes, 1 at the primary data centre, the other at the secondary data centre. The data storage metaphor adopted is the “Bucket”, a “Bucket” can be a database table/collection or a directory on a file system. A “Bucket” has meta data associated with it, mainly the storage engine. Each file has meta data including size, type, and more importantly the bucket that it’s stored in.
The fact that the File Manager is clustered by design, and utilises simple storage strategies, means that it scales well, has very good performance, and is resilient. Moving the mass storage onto dedicated hardware has also freed up resources on the servers where the main applications are hosted.
If you are interested in finding out more, contact us!