Why the Livecache has been developed ?

􀂄 For the development of the Advanced Planning and Optimization (APO) component a database system was needed which allows fast access to data organized in a complex network.

􀂄 Applying conventional relational database management systems as data sources for the APO showed a poor performance since disk I/O and the non-appropriate data description in the relational schema limited the performance.

􀂄 To read data from an application buffer which is in the same address space as the application
takes about 0.1ms. Reading data from a database takes about 1ms if the corresponding record
is already in the database buffer and even 10 ms if the record must be read from a hard disk
before.

􀂄 Working with an application having a too small buffer to accommodate all required data causes a huge data traffic between application and database server.

􀂄 An additional problem of the traditional buffering is that after reading data into the application buffer they are still organized in a relational schema which is not appropriate to describe complex networks.

􀂄 To achieve a good performance for applications which require access to a large amount of data (i.e. APO) it is necessary to bring the application logic and the application data together in one address space. One possible solution could be to shift the application logic from the application server to the database server via stored procedures. However, this impairs the scalability of R/3. On the other hand one could shift all required data to the application server.
But this requires that each server is equipped with very large main memory. Furthermore, the
synchronization of the data changed on each server with the data stored in the database server is rather complicated.

􀂄 To overcome performance problems the liveCache was introduced which is a dedicated server tier for the main memory-based temporary storage of volatile shared data.