Getting Started with Open Learning Analytics - Storage

Published on: August 27, 2015
Gary Gilbert, Software Architect

In this article we continue our discussion of how to get started with Open Learning Analytics. Here we discuss the storage of learning events within the context of the Learning Analytics Diamond (see figure 1 – Learning Record Storage).

This is the second in a series of articles on Open Learning Analytics. You can catch up on the Learning Analytics Diamond if you missed the first article. In the first article we reviewed the components of an open analytics environment as represented in the Learning Analytics Diamond diagram and discussed strategies for capturing learning events within your application. In this article we focus on options for storing those learning events.


Now that you are capturing learning events within your application, you need a place to store them. Traditional storage solutions such as relational or NoSQL databases are an option, but typically learning events are captured by a learning record store (LRS). Think of an LRS as an application that handles receipt, processing, and persistence of learning events. Most learning record stores expose web services to handle the receipt of learning events and often these web services conform to a particular learning event standard such as xAPI. Processing and persistence generally involves a series of operations including data validation, transactional persistence (tier 1), data normalization (perhaps as part of an ETL workflow), long(er) term persistence (tier 2), and possibly some analytics-related processing. Of course the LRS also provides services (web or otherwise) to query and retrieve persisted learning events. Long story short, the LRS has a lot going on and it is central to your Open Learning Analytics strategy, so it is important to consider all the angles when selecting one.

Buy or build? Use a hosted (SaaS) LRS or deploy it on-premise? These are questions that you probably consider with any software project, so it is no surprise that they are applicable to an LRS too. The good news is that unlike your other projects (I'm looking at you, LMS) there are only a handful of LRS solutions on the market, so it won't take you long to research. The bad news is that there are only a handful of LRS solutions on the market, so if you are in the buy/SaaS camp your options are very limited. No matter where you fall on the buy/SaaS versus build/deploy on-premise spectrum there are some unique aspects of an LRS project worth considering. The first and probably most important consideration is scalability. If the LRS can't scale to handle high transaction volumes, or the LRS provider caps the number of events you can send in a given period, you are going to be limited on where and when you capture learning events. Similarly, storage (e.g. disk space) is a major consideration. Capturing large numbers of learning events means you probably need to procure or pay for lots of storage. It also means you need to have plans for long term (read: cheaper) storage or data clean up and purging. Also, consider message format. Is the LRS closely associated to a particular message standard (e.g. xAPI)?  If so, how will that impact your ability to support emerging standards such as IMS Caliper or track learning events across multiple systems? Finally, consider data security. Are learning events secured properly in-flight and at rest in the LRS? Do the learning events contain any personally identifiable information, and if so, how does that impact long term storage?

As mentioned above there are not many learning record stores available on the market today. Some of the leading players include Wax LRS from Saltbox, Learning Locker, and Watershed LRS. Each of these learning record stores support xAPI and are offered in the SaaS model. Learning Locker is an open source project so it is available for download and local deployment as well. Other open source options include ADL LRS and OpenLRS. Both of these open source offerings support xAPI. OpenLRS, which is being developed as part of the Apereo Learning Analytics Initiative, also plans to be an early adopter of the IMS Caliper specification.

If you are getting ready to execute a learning record store project and would like some guidance, Unicon can help. Unicon has experience planning and implementing LRS projects that help clients achieve short and long term organizational goals. Unicon technologists are, to date, the primary developers of OpenLRS.

Stay tuned for the next article in the Getting Started with Open Learning Analytics series, which will cover the analysis component of the Learning Analytics Diamond.

Useful Reading:

Gary Gilbert photo

Gary Gilbert

Software Architect

Gary Gilbert is a Software Architect at Unicon where he provides technical leadership to the integrations and learning analytics practice. He has 10+ years experience designing and developing learning systems for clients ranging from small community colleges to global publishers. Gary has been involved in numerous open source software projects including Sakai, uPortal and Moodle as well as open standards efforts such as IMS Learning Tool Interoperability.  Gary is an active member of the Apereo Learning Analytics Initiative (LAI). He is particularly interested in the intersection of open learning technology standards and open educational resources.  Gary specializes in Java, PHP, and Javascript. He is experienced with most mainstream application frameworks with a focus on the Play Framework.