Hekaton: Good or bad form?
July is coming to an end, and at the “Habré” still no one remembered the CTP release of MSSQL Server 2014.
Next year's release is assigned the call “Hekaton”. Its appearance was announced at the PASS 2012 conference, and then it was just the name of the in-memory OLTP engine. Now this is the name of the whole release with built-in support and optimization of transaction processing directly in RAM.
Turn to the story.
If in times of old (already in the severe 70s when the saints Date and Codd worked at IBM, and the 300 MB hard disk weighed like an adult sow), the data was optimized initially for storage at ... yes on anything: the files consisting of the header, the body and the end-of-file icon on the disks of file systems in a modern form did not exist - the data from the database was flopped onto disks already marked for storing data of a given table, that is, the formatting was done by the database itself and for storing its own data. And there were still memory cells (data cells). They were a dream for allowing random access to reading and writing at any time, but as it should have been expensive and really huge (640 KB in the memory cells for the 70th year would be enough for the Olympic record in the stand-off test). The years went by: hefty reels of tapes turned into neat LTO cartridges, hard drives got file systems and also dropped heavily in weight, and memory cells turned into well-known RAM and partly into SSD. Technically, it seems to be a bright future, but no. The intrigues of enemies to efficiently calculate and process data came on all fronts. OOP appeared which, instead of economical byte-by-byte requests, started to pick right in RAM first megabyte and then gigabyte arrays and fill it with corpses of underdeveloped objects right in RAM.
At this time, the databases in the old-fashioned way honestly believed that they were working with a hard disk, although they tried to drag more into RAM, but they did it without much arrogance and bashfully called the word cache (English) - cash . That is, they could not say: “This table (base) will be in RAM and full stop! ". And bashfully they took out the hit cache statistics, then delighting us with numbers like 99.8, then distressing and disheartening, showing 25.2.
Embedding the Hekaton engine into the core of MSSQL Server 2014 slightly expands the functionality
It would seem, how can this help simple DBA in business?
I am attaching a few photos from that scandalous conference of 2012. (piquant places are highlighted):
')
That is, we have the following. Not only can the table (base) be completely pulled into RAM (goodbye RAM-drive for temp_db, although not - goodbye), so also the recompilation of the procedures for these bases will occur at the Native level, which for one part DBA will significantly increase the speed , and for others, it will allow writing more curved code without loss of performance.
I will not say that I am shocked by this “revolutionary” “innovation”, but this is just a monumental change in comparison, for example, with the AlwaysOn extension of a group of up to 8 secondary servers (Has anyone seen read-intent support in 1C: Enterprise or Navision? I'm not.) , or with the introduction of new whistles, fakes integrated with the whistles, fakes, Office and Sharepoint, for drawing comics on "How we spent a quarter."
It is clear that a similar mechanism on different types of crutches already exists in many other DBMSs, but the main trick is that at the DBMS core level, to put it mildly, not everyone has it.
Summary: In general, as usual. A new release is coming out, and new items from the category of those that were needed yesterday (now the high-speed databases are actively crawling on the SSD and this memory trick is not really needed anymore), or simple decorators for thejunior middle management team. Breakthrough, like the implementation of SQL 3.0, or at least PL / SQL - once again did not happen. Again, they did not wait.
UPD: For those interested, click on the whitlist and other documentation. And I'll go get a drink for the futility of the release. All with a holiday.
Note: English cache, from fr. cacher - “hide”; pronounced [k ] - "cash" is often confused with cash - actually cash. Considering the prices for quick access devices - the second option is more vital. :)
Next year's release is assigned the call “Hekaton”. Its appearance was announced at the PASS 2012 conference, and then it was just the name of the in-memory OLTP engine. Now this is the name of the whole release with built-in support and optimization of transaction processing directly in RAM.
Turn to the story.
If in times of old (already in the severe 70s when the saints Date and Codd worked at IBM, and the 300 MB hard disk weighed like an adult sow), the data was optimized initially for storage at ... yes on anything: the files consisting of the header, the body and the end-of-file icon on the disks of file systems in a modern form did not exist - the data from the database was flopped onto disks already marked for storing data of a given table, that is, the formatting was done by the database itself and for storing its own data. And there were still memory cells (data cells). They were a dream for allowing random access to reading and writing at any time, but as it should have been expensive and really huge (640 KB in the memory cells for the 70th year would be enough for the Olympic record in the stand-off test). The years went by: hefty reels of tapes turned into neat LTO cartridges, hard drives got file systems and also dropped heavily in weight, and memory cells turned into well-known RAM and partly into SSD. Technically, it seems to be a bright future, but no. The intrigues of enemies to efficiently calculate and process data came on all fronts. OOP appeared which, instead of economical byte-by-byte requests, started to pick right in RAM first megabyte and then gigabyte arrays and fill it with corpses of underdeveloped objects right in RAM.
At this time, the databases in the old-fashioned way honestly believed that they were working with a hard disk, although they tried to drag more into RAM, but they did it without much arrogance and bashfully called the word cache (English) - cash . That is, they could not say: “This table (base) will be in RAM and full stop! ". And bashfully they took out the hit cache statistics, then delighting us with numbers like 99.8, then distressing and disheartening, showing 25.2.
Embedding the Hekaton engine into the core of MSSQL Server 2014 slightly expands the functionality
It would seem, how can this help simple DBA in business?
I am attaching a few photos from that scandalous conference of 2012. (piquant places are highlighted):
')
That is, we have the following. Not only can the table (base) be completely pulled into RAM (goodbye RAM-drive for temp_db, although not - goodbye), so also the recompilation of the procedures for these bases will occur at the Native level, which for one part DBA will significantly increase the speed , and for others, it will allow writing more curved code without loss of performance.
I will not say that I am shocked by this “revolutionary” “innovation”, but this is just a monumental change in comparison, for example, with the AlwaysOn extension of a group of up to 8 secondary servers (Has anyone seen read-intent support in 1C: Enterprise or Navision? I'm not.) , or with the introduction of new whistles, fakes integrated with the whistles, fakes, Office and Sharepoint, for drawing comics on "How we spent a quarter."
It is clear that a similar mechanism on different types of crutches already exists in many other DBMSs, but the main trick is that at the DBMS core level, to put it mildly, not everyone has it.
Summary: In general, as usual. A new release is coming out, and new items from the category of those that were needed yesterday (now the high-speed databases are actively crawling on the SSD and this memory trick is not really needed anymore), or simple decorators for the
UPD: For those interested, click on the whitlist and other documentation. And I'll go get a drink for the futility of the release. All with a holiday.
Note: English cache, from fr. cacher - “hide”; pronounced [k ] - "cash" is often confused with cash - actually cash. Considering the prices for quick access devices - the second option is more vital. :)
Source: https://habr.com/ru/post/187938/
All Articles