Relational Database Storage

Several extensions and code libraries (including Zend Framework) offer session save handlers that store session data in a relational database such as MySQL or Oracle. Session storage in a central database solves the scalability limitation imposed by local storage mechanisms, by making the session data available to all servers in the cluster, and making sure data integrity is maintained. Database session handlers work more or less the same, regardless of implementation and database used for storage; one or more tables are created using the session ID as the primary key, and with another column for serialized session data. With each new session, another row is inserted to this table. On each request with the same session ID, this row is fetched in the beginning of the request and is then updated at the end of it. This storage method is obviously more scalable than local storage, but still has several disadvantages which should be pointed out:
Session Storage is very different from regular data that is usually stored by web applications in a relational database. Sessions have an almost 1:1 read/write ratio (PHP will save the session at the end of each request that opened the session, even if the data did not change), and as such, row-level locking is required to maintain session integrity. Database-resident query caching usually does not work well with such usage patterns. To gain optimal performance, the session storage database should be isolated from the application’s database, and tuned differently. This imposes an additional maintenance overhead, at least in higher load levels. When a single database is used for an entire cluster, the single database quickly becomes both a performance bottleneck and a potential point of failure and subsequently, database clustering is required. Again, this causes a maintenance overhead whenever the application scales up.