Hana<\/span>-DB mit 100 Knoten mit insgesamt 100 TB aggregiertem Hauptspeicher verarbeitet.<\/p>\nTypische verteilte Hana<\/span>-Landschaften verwenden eher f\u00fcnf bis zehn Serverknoten. Es ist jedoch klar, dass in einer verteilten Serverlandschaft der Schwerpunkt eher auf einer effektiven Verteilung der Daten und Anfragen sowie einer effizienten Netzwerkkommunikation beruht als auf einem effizienten Zugriff auf den Hauptspeicher.<\/p>\nWas ist Numa?<\/h3>\n
Moderne Serversysteme haben auf ihrer Platine mehrere Prozessoren (oder CPUs) \u2013 typisch sind ein bis vier CPUs in Desktop-Systemen von Intel<\/span>, w\u00e4hrend hingegen in Intel<\/span>-Servern zwei bis acht CPUs anzutreffen sind. Prozessoren sind \u00fcber einen Socket mit der Platine verbunden.<\/p>\nIn jeder dieser CPUs stecken normalerweise mehrere Cores, in denen die Berechnungen ausgef\u00fchrt werden. Moderne Intel CPUs enthalten zwei bis zehn Cores. Insgesamt stehen damit gro\u00dfen Servern bis zu 80 Cores f\u00fcr die Datenverarbeitung zur Verf\u00fcgung.<\/p>\n
Da unter anderem aus thermischen Gr\u00fcnden die Taktfrequenz in den Cores nicht mehr weiter erh\u00f6ht werden kann, wird in den kommenden Jahren die Anzahl der Cores in Servern noch weiter zunehmen. Die CPUs und der Hauptspeicher sind \u00fcber ein Bussystem miteinander verbunden.<\/p>\n
Wenn die Berechnungen f\u00fcr eine Anfrage \u00fcber viele Cores verteilt werden kann, stellt sich die Frage, wie die Daten zu den Cores transportiert werden. Grunds\u00e4tzlich gibt es hier auf der Ebene der Prozessorarchitektur zwei Alternativen (Hennessy & Patterson, 2012):<\/p>\n
\n- Symmetric Multiprocessing (SMP<\/span>): <\/em><\/strong>
\nIn dieser Architektur ist die Zugriffszeit auf eine Speicheradresse f\u00fcr alle Adressen und f\u00fcr alle Cores gleich. Diese Architektur ist in Abbildung 2 dargestellt. Jedem Prozessor sind Caches lokal zugeordnet. Der Zugriff auf den Hauptspeicher erfolgt \u00fcber einen Bus<\/span>, den sich alle Prozessoren teilen. In dieser Architektur kann der Speicherbus<\/span> zum Flaschenhals werden, weil Leseoperationen, die nicht vom lokalen Cache bedient werden k\u00f6nnen, und alle Schreiboperationen auf den gemeinsamen Speicherbus<\/span> zugreifen m\u00fcssen.<\/li>\n- Non-Uniform Memory Access:<\/em><\/strong>
\nIn dieser Architektur (Abbildung 3) werden Prozessoren sowohl Caches als auch Speicher lokal zugewiesen. F\u00fcr einen Prozessor ist der Zugriff auf den lokalen Speicher schneller als der Zugriff auf Speicher eines anderen Prozessors, weil entfernte Zugriffe \u00fcber einen Speicherbus<\/span> verarbeitet werden m\u00fcssen. F\u00fcr Anwendungsprogramme ist die Zuordnung von physischem Speicher zu einzelnen Prozessoren nicht direkt erkennbar \u2013 sie arbeiten wie in einem SMP<\/span> mit einem homogenen Adressraum.<\/li>\n<\/ol>\nDa in modernen Intel<\/span>-Systemen in einem Prozessor mehrere Cores enthalten sind, ergibt sich eine Numa-Architektur auf der Ebene der Prozessoren, aber ein SMP<\/span>-System auf der Ebene jedes Prozessors.<\/p>\nLetzteres wird auch als Chip-Multi-Processor bezeichnet (CMP). Beispiele f\u00fcr SMP<\/span>-Systeme sind Intel Pentium D, Intel Itanium, IBM Power<\/span>, Sun UltraSparc T2 oder SGI MIPS, w\u00e4hrend Beispiele f\u00fcr Numa-Architekturen Intel Nehalem CPUs oder AMD<\/span> Opteron CPUs (und deren Nachfolger) sind.<\/p>\nIst Numa relevant f\u00fcr Hana?<\/h3>\n
Die SAP<\/span>–Hana<\/span>-DB wurde in Zusammenarbeit mit Intel<\/span> f\u00fcr die Ausf\u00fchrung auf aktuellen Intel<\/span>-Xeon-Prozessoren optimiert. Beispielsweise nutzt die Hana<\/span>-DB die SSE<\/span>-Erweiterungen von Intel<\/span>-Prozessoren, um in einer Maschineninstruktion mehrere Elemente parallel zu verarbeiten.<\/p>\nDa diese Intel<\/span>-Prozessoren auf einer Numa-Architektur basieren, muss auch der Code der Hana<\/span>-DB f\u00fcr diese Architektur optimiert werden. Im Folgenden wird auf einige Szenarien eingegangen, wo Numa-Effekte in der Hana<\/span>-DB relevant sind und wie die Hana<\/span>-DB damit umgehen kann.<\/p>\nWenn eine Anfrage die Hana<\/span>-DB erreicht, wird diese Anfrage zun\u00e4chst einem Thread zugewiesen. Generell erlauben Threads eine leichtgewichtige nebenl\u00e4ufige Verarbeitung mehrerer Anfragen (im Vergleich zu Prozessen im Betriebssystem).<\/p>\nAktive Threads werden zu einem Zeitpunkt auf genau einem Core<\/span> ausgef\u00fchrt.\u00a0 W\u00e4hrend der Verarbeitung einer Anfrage muss die Datenbank in den meisten F\u00e4llen Speicher allokieren, zum Beispiel um das Ergebnis der Anfrage f\u00fcr die Datenbankanwendung aufzusammeln. Der Speicher sollte dann in dem Speicherbereich allokiert werden, der dem Prozessor und Core<\/span> zugewiesen wurde, damit Speicherzugriffe nicht durch Zugriffe auf entfernten Speicher verz\u00f6gert werden.<\/p>\nModerne Betriebssysteme ber\u00fccksichtigen bereits Numa-Architekturen: Sowohl Microsoft Windows<\/span> 7 bzw. Windows Server 2008R2 als auch Linux<\/span> (ab Kernel 2.5) versuchen, den Speicher in dem Bereich zu allokieren, der dem Prozessor des Threads oder Betriebssystemprozess zugeordnet ist. Damit profitieren Anwendungen automatisch von Optimierungen im Betriebssystem.<\/p>\nHier ist zu beachten, dass Virtualisierungsl\u00f6sungen wie VMware ESX von der physischen Hardware abstrahieren. Da die Software mit logischen CPUs und einer Virtualisierungsschicht f\u00fcr den Speicher arbeitet, k\u00f6nnen Optimierungen f\u00fcr eine Numa-Architektur auf einem virtualisierten System sogar zu negativen Effekten f\u00fchren.<\/p>\n
Das automatische Speichermanagement des Betriebssystems kann zu unerw\u00fcnschten Effekten f\u00fchren, wenn eine Anwendung Speicher selbst verwaltet, um teure Systemaufrufe beim Allokieren und Freigeben von Speicher zu vermeiden. Dann kann Speicher beim Wiederverwenden des Speichers im falschen Bereich vorliegen. Quasi jede Datenbank implementiert ein eigenes Speichermanagement, das auf der Anwendungsebene arbeitet.<\/p>\n
Ein weiterer Effekt besteht darin, dass ein Thread Speicher (lokal) allokiert, aber viele andere Threads mit diesem Speicher arbeiten wollen.<\/p>\n
Als Beispiel sei der Speicher einer Spalte genannt: Dieser Speicher wird einmal beim Laden der Spalte in den Hauptspeicher allokiert, aber viele Anfragen lesen die Daten der Spalte.<\/p>\n
In beiden genannten Szenarien, Speichermanagement auf Anwendungsebene und Speicherzugriff durch viele Threads, kann ein effektives Scheduling der Threads helfen. Auch hier implementieren moderne Betriebssysteme Strategien, Threads dort auszuf\u00fchren, wo die verwendeten Daten allokiert sind.<\/p>\n
Das kann so weit f\u00fchren, dass ein Thread von einem Core<\/span> auf einen anderen verschoben wird, damit Speicherzugriffe von lokalem Speicher bearbeitet werden k\u00f6nnen. Das Betriebssystem st\u00f6\u00dft jedoch an Grenzen, wo beispielsweise Wissen des Datenbanksystems zu besseren Ergebnissen Entscheidungen f\u00fchren kann.<\/p>\nNuma-Unterst\u00fctzung in Hana<\/span><\/h3>\nIm vorherigen Abschnitt wurden Strategien auf Numa-Architekturen besprochen, die jeder Anwendung auf modernen Servern und modernen Betriebssystemen zur Verf\u00fcgung stehen.<\/p>\n
Diese Techniken allein f\u00fchren jedoch zu suboptimalen Entscheidungen, weil die speziellen Eigenschaften eines Datenbanksystems nicht ber\u00fccksichtigt werden k\u00f6nnen. Auf Datenbank-spezifische Optimierungsm\u00f6glichkeiten in der Hana<\/span>-DB geht dieser Abschnitt ein.<\/p>\nSpeichermanagement<\/h3>\n
Wie oben angedeutet, implementiert die Hana<\/span>-DB aus Effizienzgr\u00fcnden ein Speichermanagement, das auf der Speicherverwaltung des Betriebssystems aufbaut. Dabei wird Speicher normalerweise nicht an das Betriebssystem zur\u00fcckgegeben, wenn er im Datenbank-Code freigegeben wird.<\/p>\nGleichzeitig wird bereits allokierter Speicher wiederverwendet. Dadurch soll zum einen die Fragmentierung des Hauptspeichers, aber auch die Anzahl der System-Aufrufe an das Betriebssystem reduziert werden. An dieser Stelle er\u00f6ffnen sich M\u00f6glichkeiten, die spezifischen Eigenschaften einer Numa-Architektur auszunutzen:<\/p>\n
1. Wenn ein Thread Speicher anfordert, so wird dem Thread lokaler Speicher des Prozessors bereitgestellt, damit Zugriffe auf diesen Speicher durch den lokalen Speicher-Controller<\/span> verarbeitet werden und die Speicherbusse zwischen den Prozessoren entlastet werden. Diese Strategie erscheint besonders in Szenarien sinnvoll, wo der Speicher von Threads auf demselben Prozessor verwendet wird.<\/p>\n2. In einigen F\u00e4llen erscheint es hingegen sinnvoller, den angeforderten Speicher auf mehrere Prozessoren zu verteilen. In aktuellen Systemen scheinen in bestimmten Szenarien die Speicher-Controller<\/span> einen Flaschenhals darzustellen. In diesen F\u00e4llen ist es sinnvoller, sowohl den Speicher also auch die Threads, die den Speicher verwenden, auf verschiedene Prozessoren zu verteilen. Auf diese Weise kann, zum Beispiel beim Zugriff auf gro\u00dfe und h\u00e4ufig verwendete Spalten, der Flaschenhals vermieden werden.<\/p>\nJob Scheduling<\/h3>\n
Ein modernes Betriebssystem trifft in vielen F\u00e4llen eine gute Entscheidung, welche Threads auf welchem Core<\/span> ausgef\u00fchrt werden sollen.<\/p>\nBei der Entscheidung wird ber\u00fccksichtigt, ob es auf einem Prozessor noch Cores gibt, die aktuell keine Berechnungen durchf\u00fchren, in welchem Aktivit\u00e4tszustand einzelne Cores und Prozessoren sind (um Energie zu sparen, lohnt es sich, Arbeit auf einzelne Prozessoren zu b\u00fcndeln und andere Prozessoren zu deaktivieren), ob einzelne Prozessoren aktuell \u201e\u00fcbertaktet\u201c laufen (TurboBoost bei Intel<\/span>) sowie auf welche Daten ein Thread zugreift.<\/p>\nNeben dieser automatischen Entscheidung des Betriebssystems kann ein Anwendungsentwickler die Zuordnung von Threads zu Prozessoren oder Cores beeinflussen.<\/p>\n
Im Grunde sind die damit verbundenen Optimierungsm\u00f6glichkeiten beim Scheduling der Threads im System abh\u00e4ngig vom Speichermanagement zu sehen:<\/p>\n
\n- Wenn Daten, die ein Thread benutzt, lokal einem Prozessor zugeordnet sind, dann sollte der Thread auch auf diesem Prozessor abgearbeitet werden.\u00a0 Etwas \u00fcberraschend ist es manchmal lohnend, mehr Threads auf einem Prozessor ausf\u00fchren zu lassen, als der Prozessor verarbeiten kann (Anzahl Cores, mit Hyperthreading theoretisch zweimal Anzahl der Cores).Das ist insbesondere der Fall, wenn diese Threads auf gemeinsamen Speicher zugreifen und dieser Speicher dann bereits in den Caches verf\u00fcgbar ist.<\/li>\n
- Manche komplexe Datenbankoperationen lesen und schreiben gro\u00dfe Datenmengen und lasten damit den Speicher-Controller<\/span> eines Prozessors aus.Wenn die Daten f\u00fcr diese Operationen bereits auf den lokalen Speicher mehrerer Prozessoren verteilt sind, dann sollten die Threads f\u00fcr den Zugriff auf die Daten auf mehrere Prozessoren verteilt sein. Dadurch werden einzelne Speicher-Controller<\/span> entlastet, und die Arbeitslast wird auf mehrere Speicherverbindungen und Speicher-Controller<\/span> verteilt.<\/li>\n
- In einigen F\u00e4llen sollten Datenbank-Operationen wie Join-Operationen mit einem besonderen Augenmerk auf die Numa-Architektur implementiert werden. Erste \u201eRichtlinien\u201c f\u00fcr derartige Implementierungen werden in der Forschungsliteratur diskutiert (Albutiu, Kemper & Neumann, 2012).<\/li>\n<\/ol>\n
Zukunft von Numa<\/h3>\n
Nicht nur Datenbank-Software wurde mehrere Jahrzehnte unter der Pr\u00e4misse erstellt, dass die Verarbeitungsgeschwindigkeit mit der n\u00e4chsten Prozessor-Generation zunimmt, unter anderem deshalb, weil sich die Taktfrequenz erh\u00f6ht. Aus technischen Gr\u00fcnden gilt dieser Automatismus seit Beginn des Jahrtausends nicht mehr.<\/p>\n
Anbieter wie Intel oder AMD<\/span> propagieren Systeme, in denen die Arbeit auf mehrere Prozessoren mit jeweils mehreren Cores verteilt wird. Wie in dem Artikel diskutiert, scheint sich eine Architektur durchzusetzen, in der der Speicherzugriff unterschiedlich aufw\u00e4ndig ist \u2013 abh\u00e4ngig davon, wo der Speicher physisch allokiert wurde (mit Numa bezeichnet).<\/p>\nAnwendungssoftware muss daher \u00fcberarbeitet werden, damit sie die Parallelit\u00e4t ausnutzen kann, die mit der Verf\u00fcgbarkeit von Mehrkern-Architekturen einherging. Damit verbunden, muss die Software die Eigenheiten der Numa-Architektur ber\u00fccksichtigen und die Allokation von Speicher und den Zugriff darauf optimieren.<\/p>\n
W\u00e4hrend moderne Betriebssysteme einige Optimierungen in dem Bereich bereitstellen, m\u00fcssen Performance-kritische Anwendungen wie die Hana<\/span>-DB deutlich dar\u00fcber hinausgehende Verbesserungen realisieren.<\/p>\nIn der Hana<\/span>-Datenbank ist bereits eine Reihe dieser Verbesserungen integriert. Dennoch steht die Implementierung von Datenbanken auf Numa-Architekturen erst am Anfang, und weitere Verbesserungen sind zu erwarten.<\/p>\n","protected":false},"excerpt":{"rendered":"Wenn die Daten einer Hana-Anwendung nicht mehr von einem einzelnen Serverknoten verarbeitet werden k\u00f6nnen (Scale-up), dann m\u00fcssen die Daten auf mehrere Knoten verteilt werden (Scale-out). Da Numa den Zugriff auf den lokalen Hauptspeicher betrifft, geht dieser Artikel nicht genauer auf Aspekte von verteilten Systemen ein.<\/p>\n","protected":false},"author":41,"featured_media":882,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"pmpro_default_level":"","footnotes":""},"categories":[5],"tags":[65,67,59,352,353],"coauthors":[22374],"class_list":["post-399","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-it-management","tag-hana","tag-linux","tag-microsoft","tag-orlando","tag-sapphire","pmpro-has-access"],"acf":[],"featured_image_urls_v2":{"full":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/01\/2shutterstock_313779428.jpg",1000,563,false],"thumbnail":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/01\/2shutterstock_313779428-150x150.jpg",150,150,true],"medium":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/01\/2shutterstock_313779428.jpg",400,225,false],"medium_large":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/01\/2shutterstock_313779428-768x432.jpg",768,432,true],"large":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/01\/2shutterstock_313779428.jpg",1000,563,false],"image-100":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/01\/2shutterstock_313779428-100x56.jpg",100,56,true],"image-480":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/01\/2shutterstock_313779428-480x270.jpg",480,270,true],"image-640":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/01\/2shutterstock_313779428-640x360.jpg",640,360,true],"image-720":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/01\/2shutterstock_313779428-720x405.jpg",720,405,true],"image-960":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/01\/2shutterstock_313779428-960x540.jpg",960,540,true],"image-1168":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/01\/2shutterstock_313779428.jpg",1000,563,false],"image-1440":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/01\/2shutterstock_313779428.jpg",1000,563,false],"image-1920":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/01\/2shutterstock_313779428.jpg",1000,563,false],"1536x1536":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/01\/2shutterstock_313779428.jpg",1000,563,false],"2048x2048":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/01\/2shutterstock_313779428.jpg",1000,563,false],"trp-custom-language-flag":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/01\/2shutterstock_313779428.jpg",18,10,false],"bricks_large_16x9":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/01\/2shutterstock_313779428.jpg",1000,563,false],"bricks_large":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/01\/2shutterstock_313779428.jpg",1000,563,false],"bricks_large_square":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/01\/2shutterstock_313779428.jpg",1000,563,false],"bricks_medium":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/01\/2shutterstock_313779428.jpg",600,338,false],"bricks_medium_square":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/01\/2shutterstock_313779428.jpg",600,338,false],"profile_24":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/01\/2shutterstock_313779428-24x24.jpg",24,24,true],"profile_48":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/01\/2shutterstock_313779428-48x48.jpg",48,48,true],"profile_96":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/01\/2shutterstock_313779428-96x96.jpg",96,96,true],"profile_150":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/01\/2shutterstock_313779428-150x150.jpg",150,150,true],"profile_300":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/01\/2shutterstock_313779428-300x300.jpg",300,300,true]},"post_excerpt_stackable_v2":"
Wenn die Daten einer Hana-Anwendung nicht mehr von einem einzelnen Serverknoten verarbeitet werden k\u00f6nnen (Scale-up), dann m\u00fcssen die Daten auf mehrere Knoten verteilt werden (Scale-out). Da Numa den Zugriff auf den lokalen Hauptspeicher betrifft, geht dieser Artikel nicht genauer auf Aspekte von verteilten Systemen ein.<\/p>\n","category_list_v2":"IT-Management<\/a>","author_info_v2":{"name":"Norman May, SAP","url":"https:\/\/e3mag.com\/de\/author\/norman-may\/"},"comments_num_v2":"0 comments","_links":{"self":[{"href":"https:\/\/e3mag.com\/de\/wp-json\/wp\/v2\/posts\/399","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/e3mag.com\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/e3mag.com\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/e3mag.com\/de\/wp-json\/wp\/v2\/users\/41"}],"replies":[{"embeddable":true,"href":"https:\/\/e3mag.com\/de\/wp-json\/wp\/v2\/comments?post=399"}],"version-history":[{"count":0,"href":"https:\/\/e3mag.com\/de\/wp-json\/wp\/v2\/posts\/399\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/e3mag.com\/de\/wp-json\/wp\/v2\/media\/882"}],"wp:attachment":[{"href":"https:\/\/e3mag.com\/de\/wp-json\/wp\/v2\/media?parent=399"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/e3mag.com\/de\/wp-json\/wp\/v2\/categories?post=399"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/e3mag.com\/de\/wp-json\/wp\/v2\/tags?post=399"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/e3mag.com\/de\/wp-json\/wp\/v2\/coauthors?post=399"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
![\"\"](\"https:\/\/e3mag.com\/wp-content\/uploads\/2026\/03\/banner_26_06_24_1200x150.jpg\")
<\/a><\/div><\/div>\n