OPERATION OF EXTENSIBLE STORAGE ENGINE (ESE)

Operation of Extensible Storage Engine (ESE)

Abstract

At the core of Microsoft Exchange server and Active Directory is the Extensible Storage Engine, or ESE, is an offshoot of the Jet Blue database engine. It is an advanced indexed and sequential access method storage technology (ISAM) that is specifically modified for the storage of hierarchical data such as used for the storage of messages and attachments. Its transaction based processing capabilities allow it to withstand server crashes. ESE transactions are highly concurrent, making it ideal for server applications. The ESE database engine accomplishes a high level of reliability through the use of log files to record all transactions before the transaction is committed to the database file. The transactions must pass the ACID test (Atomicity,Consistency, Isolation, and Durability), a measure of database stability and consistency developed in the 1970s. As much as the Extensible Storage Engine may look like SQL server, it is not. In the future, however if rumors are true, Microsoft may retire ESE for a newer version of SQL.

Operation of Extensible Storage Engine (ESE)

Introduction

Many applications need to keep their state in a data warehouse when they are shut down. A developer selects a data warehouse (usually) according to the needs of an application (if there are no special marketing requirements).

For example, it might be enough for an application to keep just the user's settings. It might be necessary for a second application to keep the results of its work. For a third application, it might be important to keep some intermediate information. Depending on these, the programmer can choose different types of data warehouses - a file, the Windows registry, a Relational Database Management System (RDBMS), Active Directory, etc., and perhaps a combination of these.

Frequently, the amount of kept data is a basic criterion at the time of choosing the data warehouse. Besides that, the other important characteristics are speed of access and/or search, and the convenience of working with the chosen data warehouse.

Let us consider these criteria more in detail. Let us assume that I wish to create a new and improved Notepad. Notepad is a desktop application, and I should not have problems choosing a data warehouse - files will be kept in locations specified by the user. In addition, the user's settings will be stored in the Windows Registry.

Next, suppose I want to create a search system that will eclipse Google. Then, I need to think of where to keep the collected URLs. For their storage, as a back-end, I am sure I will choose a well proven (and it is possible, the most accessible) RDBMS. This decision can be named classical for a server application, and it will not require serious reflections on my part.

If my mail client will not carry out search, grouping, and sorting, even at the same speed as other mail clients, I will not have enough chances at making a competition. It looks like the brute-force approach (to use file(s) as warehouse) does not work in this ...