High Performance Computing with GPU

 

Hekaton is designed around four architectural principles

Hekaton, in contrast, is a row-based technology squarely focused on transaction processing (TP) workloads

1) Optimize for main memory data access: Storage-optimized engines (such as the current OLTP engine in SQL Server today) will retain hot data in a main memory buffer pool based upon access frequency. The data access and modification capabilities, however, are built around the viewpoint that data may be paged in or paged out to disk at any point. This perspective necessitates layers of indirection in buffer pools, extra code for sophisticated storage allocation and defragmentation, and logging of every minute operation that could affect storage. With Hekaton you place tables used in the extreme TP portion of an application in memory-optimized main memory structures. The remaining application tables, such as reference data details or historical data, are left in traditional storage optimized structures. This approach lets you memory-optimize hotspots without having to manage multiple data engines.

Hekaton’s main memory structures do away with the overhead and indirection of the storage optimized view while still providing the full ACID properties expected of a database system. For example, durability in Hekaton is achieved by streamlined logging and checkpointing that uses only efficient sequential IO.

 2) Accelerate business logic processing: Given that the free ride on CPU clock rate is over, Hekaton must be more efficient in how it utilizes each core. Today SQL Server’s query processor compiles queries and stored procedures into a set of data structures which are evaluated by an interpreter in SQL Server’s query processor. With Hekaton, queries and procedural logic in T-SQL stored procedures are compiled directly into machine code with aggressive optimizations applied at compilation time. This allows the stored procedure to be executed at the speed of native code.

3) Provide frictionless scale-up: It’s common to find 16 to 32 logical cores even on a 2-socket server nowadays. Storage-optimized engines rely on a variety of mechanisms such as locks and latches to provide concurrency control. These mechanisms often have significant contention issues when scaling up with more cores. Hekaton implements a highly scalable concurrency control mechanism and uses a series of lock-free data structures to eliminate traditional locks and latches while guaranteeing the correct transactional semantics that ensure data consistency.

4) Built-in to SQL Server: As I mentioned earlier – Hekaton is a new capability of SQL Server. This lays the foundation for a powerful customer scenario which has been proven out by our customer testing. Many existing TP systems have certain transactions or algorithms which benefit from Hekaton’s extreme TP capabilities. For example, the matching algorithm in financial trading, resource assignment or scheduling in manufacturing, or matchmaking in gaming scenarios. Hekaton enables optimizing these aspects of a TP system for in-memory processing while the cooler data and processing continue to be handled by the rest of SQL Server.

Author - Dave Campbell      Technical Fellow       Microsoft SQL Server

In-Memory Database defines itself in microseconds

http://www.bloomberg.com/article/2013-05-20/aUH1rmSgwiPw.html

Courtesy - Altibase

In-Memory Computing

I did a quick basic testing and benchmarking on Altibase Database which is Hybrid Database (Memory + Disk).

For the sake of comparison with another RDBMS which resides on DISK, I took Microsoft SQL Server 2008 Enterprise Edition.

In OLTP environment, WRITE is very important than READ to handle & manage the transactions.

Below benchmark shows that in SQL Server 2008, 1036 transactions can be (INSERT) processed in 1 second with comparing to Altibase, 40000 transactions (INSERT) can be processed in 1 second. That’s a remarkable result. To understand true power of in-memory database & table, index  were not created intentionally for in-memory table.

Altibase (HDB)	SQL Server 2008 Ent. Edt. RDBMS
MS. Windows 2008 Ent. Edt. 64 bit	MS. Windows 2008 Ent. Edt. 64 bit
Intel Xeon X5460 @3.16GHz Proc 2 socket x 4 cores	AMD Opteron 8222 SE 3.0GHz Proc 4 socket x 2 cores
Database & Table resides in Memory (RAM)	Database – Table resides in Storage (DISK)
FSB Speed	HyperTransport technology (It is same as Intel QPI)
Data is in ROW STORAGE	Data is in ROW STORAGE
Data is in uncompressed format	Data is in uncompressed format
Table Size in Memory = 15.215 GB	Table Size on DISK = 15.245 GB
Table has 2 columns of CHAR(4023) each, so to maintain Data Page size of 8060	Table has 2 columns of CHAR(4023) each, so to maintain Data Page size of 8060 minus 7bytes for header
Data INSERT in table took = 50 second and 020 mili second	Data INSERT in table took = 32 min and 18 second
Rows – close to 2 million	Rows – close to 2 million
(READ) SELECT took =  25 mins and 553 mili second, with NO INDEX	(READ) SELECT took = 11mins and 47 seconds, with NO INDEX
SELECT COUNT(*) ran in nano second, with NO INDEX	SELECT COUNT(*) took = 9mins and 30 seconds, with NO INDEX

For more information:-
http://www.microsoft.com/en-us/sqlserver/default.aspx
http://www.altibase.com/