Data Warehouse-Server. Wie berechnen Sie die RAM / CPU-Spezifikationen?

Ich versuche, eine Spezifikation für einen Data Warehouse-Server für unser geplantes Data Warehouse-Upgrade zu schreiben.

Da wir virtuelle Server auf VMWare-Hosts ausführen, können wir nach Bedarf Ressourcen hinzufügen oder entfernen. In der Vergangenheit haben wir RAM und CPU nach Bedarf schrittweise hinzugefügt. Da unsere Anforderungen gestiegen sind, haben wir uns für mehr Ressourcen eingesetzt. (hauptsächlich Festplatte & RAM).

Wir bitten um mehr. Sie geben uns so wenig wie möglich.

Wenn wir jedoch kürzlich über Ressourcen sprechen, werden wir jetzt dafür kritisiert, dass wir den Computer überhaupt nicht richtig spezifiziert haben, und mir wird jetzt mitgeteilt, dass die Entwickler-Hosts maximal ausgelastet sind und kein RAM mehr verfügbar ist.

Wir sind eine kleine lokale Regierungsorganisation mit ~ 50 regulären Nutzern der DW. Im normalen täglichen Gebrauch läuft es gut. Wir erhalten eine gute mdx-Abfrageleistung und unsere Berichte und Dashboards sind schnell. Benutzer sind glücklich.

Unsere ETL-Prozesse laufen jedoch die ganze Nacht über, und wir sehen allmählich Anzeichen von Speicherdruck, wenn wir Datenmarts gleichzeitig verarbeiten. Letzte Nacht ist SSIS mit Warnungen vor einem "Speichermangel" fehlgeschlagen.

Unser vorhandener DW-Server ist Win 2008 R2 mit 4 CPUs und 16 GB RAM unter SQL 2012 Std. Ich habe den maximalen Serverspeicher auf 12 GB eingestellt, so dass 4 GB für Betriebssysteme und Dienste usw. übrig bleiben. Unser vorhandener DW verfügt über 3 Datamarts / OLAP-Cubes, und wir entwickeln 2 weitere.

+----------+----------+---------------+-----------+---------------+
| Datamart | Files GB |  Fact (Rows)  | Fact (Mb) | ETL & Process |
| OLAP cube|          |               |           | Time (hours)  |
+----------+----------+---------------+-----------+---------------+
| PBI      |       3  |  190,000      |  180      |  0.2          |
| FBI      |      30  |  26,100,000   |  10,000   |  1.5          |
| RBI      |     175  |  62,000,000   |  32,000   |  8.3          |
| ABI*     |     100  |  44,050,000   |  21,000   |  4.0          |
| EBI*     |      11  |  100,000,000  |  6,000    |  2.0          |
+----------+----------+---------------+-----------+---------------+
* Planned/Estimated

Unser neuer Server soll Win 2012 mit SQL 2016 Enterprise sein. Es werden SQL, SSIS, SSRS und SSAS ausgeführt. Speicher ist kein Problem, aber ich bin nicht sicher über RAM & CPU.

Laut dem Fast Track Data Warehouse-Referenzhandbuch für SQL Server 2012 sollte ich mindestens 128 GB für einen 2-Socket-Computer haben ... was etwas übertrieben erscheint. Die Hardware- und Softwareanforderungen für die Installation von SQL Server 2016 empfehlen mindestens 4 GB RAM für SQL 2016. Das ist ein ziemlicher Unterschied!

Also .. Was ist ein guter Ausgangspunkt? 32 GB? 64 GB? Wie rechtfertige ich meine Startposition (Spezifikation) gegenüber der IT?

Gibt es gute Anleitungen zur Berechnung der Serverressourcen?

Gibt es gute Faustregeln?

Was sind die Hauptbestandteile / Metriken für die RAM-Größe in einem DW-Kontext?

• Das Datenvolumen?
• Die Anzahl der Würfel?
• Wie lange dauert es, ETL durchzuführen oder einen Cube zu verarbeiten?
• Spitzenverarbeitungslast über Nacht oder Leistung, wie sie von Endbenutzern tagsüber gesehen wird?

Gute Frage, und ich habe vor einigen Jahren bei TechEd eine Sitzung mit dem Titel "Erstellen der schnellsten SQL-Server" durchgeführt:

https://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/DBI328

Darin erkläre ich, dass Sie für Data Warehouses Speicher benötigen, der Daten schnell genug bereitstellen kann, damit SQL Server sie nutzen kann. Microsoft hat eine große Reihe von Whitepapers erstellt, die als Fast Track Data Warehouse-Referenzarchitektur bezeichnet werden und sich mit Hardwaredetails befassen. Die Grundidee ist jedoch, dass Ihr Speicher eine sequentielle Leseleistung von 200 bis 300 MB / s pro CPU-Kern in bereitstellen muss um die CPUs beschäftigt zu halten.

Je mehr Daten Sie im Speicher zwischenspeichern können, desto langsamer können Sie mit dem Speicher davonkommen. Sie haben jedoch weniger Speicher als erforderlich, um die von Ihnen behandelten Faktentabellen zwischenzuspeichern, sodass die Speichergeschwindigkeit sehr wichtig wird.

Hier sind Ihre nächsten Schritte:

• Sehen Sie sich das Video an
• Testen Sie Ihren Speicher mit CrystalDiskMark ( So geht's )
• Mit 4 Kernen möchten Sie einen sequentiellen Lesedurchsatz von mindestens 800 MB / s
• Wenn Sie das nicht haben, sollten Sie Speicher hinzufügen, bis die Schmerzen verschwunden sind (und das Zwischenspeichern der gesamten Datenbank im RAM ist nicht undenkbar).

Angenommen, Sie haben eine 200-GB-Datenbank, mit der Sie zu tun haben, und Sie können nicht genügend Speicherdurchsatz erzielen, um Ihre Kerne zu beschäftigen. Es ist nicht undenkbar, nicht nur 200 GB RAM zu benötigen, sondern noch mehr - denn schließlich möchten SSIS und SSAS ihre Arbeit wirklich im Speicher erledigen, sodass Sie die Daten der Engine sowie Arbeitsbereich für SSIS und SSAS zur Verfügung haben müssen.

Aus diesem Grund versuchen die Benutzer auch, SSIS und SSAS auf verschiedene VMs aufzuteilen - alle benötigen gleichzeitig Speicher.

Das Fast Track Data Warehouse-Referenzhandbuch für SQL Server 2012 ist tatsächlich etwas veraltet, insbesondere wenn Sie auf SQL Server 2016 umsteigen (wirklich? Rufen Sie mich an), nicht nur in Bezug auf die Zeit, sondern auch in Bezug auf die Funktionen.

In SQL Server 2012, der Version, auf der Fast-Track basiert, konnten nur nicht gruppierte Columnstore-Indizes verwendet werden. Dies sind separate Strukturen, die von der Haupttabelle getrennt sind, sodass aufgrund komprimierter Kopien der Daten zusätzlicher Speicher- und Verarbeitungsaufwand entsteht.

Ab SQL Server 2014 können Sie Spaltenspeicherindizes gruppieren. Diese bieten massive Komprimierung und potenzielle Leistungssteigerung für aggregierte / zusammenfassende Abfragen. Sie sind absolut geeignet für Faktentabellen, sodass Ihre 32-GB-Faktentabelle eher wie ~ 8-12 GB aussehen könnte. YMMV. Das verändert die Landschaft leicht, nicht wahr? Wenn Sie auf Ihren Tisch (und den Daumen in der Luft) schauen, könnten Sie vielleicht mit 32 GB davonkommen, aber ich würde für 64 GB schießen (es ist nicht so, als würden Sie nach 1 TB fragen) und einen Raum für andere Dienste und Wachstum lassen, wobei die Rechtfertigung darin besteht Sie können Ihren größten Tisch im Gedächtnis behalten, Raum für Wachstum und Raum für andere Dienste schaffen. Sie müssen ihnen nichts über die Komprimierung erzählen. Eine Sache, die Sie bei der Größenbestimmung berücksichtigen müssen, ist, dass Sie nicht nur Ihre Daten jetzt dimensionieren, sondern auch, wie es sein wird, sagen wir in einem Jahr. Beachten Sie jedoch auch, dass die Leistung für Punktsuchen schrecklich sein kann. Wenn Sie jedoch zu SQL Server 2016 wechseln, können Sie zusätzliche Indizes hinzufügen oder Columnstore-Indizes für Echtzeit-Betriebsanalysen in Betracht ziehen, obwohl Sie dafür mehr Speicher benötigen :)

Wie kommen Sie übrigens mit den CTPs zurecht? Derzeit sind in CTP3.3 die meisten Funktionen verfügbar, die Sie möglicherweise verwenden möchten. Sie sagen also, Sie haben keine Ressourcen für Testversionen, aber Sie könnten eine Windows Azure-Testversion erhalten , starten Sie eine VM, erstellen Sie einige Beispieldaten, testen Sie die Komprimierung, Leistung der wichtigsten Funktionen und Abfragen usw. kostenlos. Wenn Sie über eine MSDN-Lizenz verfügen, ist diese integriert.

Zusammenfassend lässt sich sagen, dass die Größe so bemessen ist, dass sich Ihre größte Tabelle im Speicher befindet (plus andere Dinge), oder dass Sie eine einfache Testversion (kostenlos in der Cloud) einrichten, um die gewünschten Beweise zu erhalten. Denken Sie daran, die Zuordnung Ihrer VM aufzuheben, wenn Sie fertig sind :)

Vermutlich verwenden Sie beim Entwickeln und Verwalten der ETL-Pakete auf lokalen Entwicklungsmaschinen manchmal Testdaten in ähnlichem oder größerem Maßstab als in der Produktion erwartet, und wenn nicht, würden Sie dies möglicherweise in Betracht ziehen (anonymisierte reale Daten oder algorithmisch generierte Testdaten). wenn Ihre realen Daten überhaupt sensibel sind).

Wenn dies der Fall ist, können Sie den Prozess unter verschiedenen Speicherbedingungen ausführen und profilieren, um zu sehen, wo mehr RAM keinen massiven Unterschied mehr macht - so nützlich wie Faustregeln und fundierte Vermutungen, nichts Benchmarking und Profiling kann viel konkretere Antworten liefern und als Bonus können offensichtliche Engpässe hervorgehoben werden, die leicht zu optimieren sind. Natürlich stimmen Ihre Entwicklungs- / Testumgebungen möglicherweise nicht genau mit der Produktion überein. Daher müssen Sie möglicherweise Erfahrung verwenden, um zu interpretieren, wie sich die Ergebnisse ändern können.

Wenn Sie SSIS auf demselben Computer wie die Datenbanken ausführen, sollten Sie auf jeden Fall sicherstellen, dass die SQL Server-Engine-Instanzen so eingestellt sind, dass sie niemals den gesamten Speicher beanspruchen. Speichermangel kann nicht nur OOM-Fehler in SSIS verursachen, sondern auch lange vor diesem Zeitpunkt erhebliche Leistungsprobleme verursachen, da Puffer auf die Festplatte gespult werden, wenn sie sonst im RAM verbleiben könnten. Wie viel Sie für SSIS und andere Aufgaben reservieren müssen, hängt stark von Ihrem Prozess ab. Auch hier ist die Profilerstellung eine gute Möglichkeit, dies zu beurteilen. Es wird häufig empfohlen, SSIS auf einem separaten Computer auszuführen, um die Verwaltung zu vereinfachen. Möglicherweise müssen Sie dort jedoch Probleme mit dem Netzwerkdurchsatz und der Lizenzierung berücksichtigen.

Aktualisieren

Wenn gemäß Ihrem Kommentar keine Ressource verfügbar ist, um realistische Benchmarks durchzuführen, um zu messen, wo die Leistung abnimmt (und / oder OOM-Fehler und damit verbundene Probleme auftreten), wenn zu wenig RAM zugewiesen wird, werden die Dinge erheblich wellenförmiger ohne genaue Kenntnis der Lager- und ETL-Prozesse. Eine Faustregel für die Warehouse-Datenbank selbst: Sie möchten, dass genügend RAM vorhanden ist, um dann die Gesamtheit aller am häufigsten verwendeten Indizes zu speichern, und einige, um weniger häufig verwendete Daten und mehr zu ermöglichen, um ein erwartetes Wachstum in naher Zukunft zu ermöglichen / mittlere Zukunft.

Die Berechnung kann faf sein - sp_spaceUsed gliedert die Dinge nicht nach Index, sodass Sie sys.allocation_units und Freunde direkt selbst abfragen müssen. Es gibt jedoch einige Beispiele, die Ihnen den Einstieg erleichtern sollen: http://blog.sqlauthority.com/2010/05/09/sql-server-size-of-index-table-for-each-index-solution-2 Ich sehe aus wie das Beste der ersten paar, die aus einer schnellen Suche hervorgegangen sind.

Denken Sie daran, zusätzlich zu den Anforderungen für die Ausführung der Warehouse-Datenbank selbst die RAM-Anforderungen für SSIS hinzuzufügen, wenn diese auf demselben Computer ausgeführt werden sollen, und stellen Sie sicher, dass in SQL Server RAM-Grenzwerte vorhanden sind, um sicherzustellen, dass dieser Speicher tatsächlich verfügbar ist SSIS.

Aus den Gesamtdatengrößen, die Sie auflisten, geht hervor, dass 32 GB das absolute Minimum sind, das ich nur für das Datenbankmodul und SSIS empfehlen würde. Stellen Sie die SQL-Instanz (en) so ein, dass sie höchstens 26 davon verwenden, und da Sie auch ausgeführt werden SSRS und andere Dienste auf demselben Computer wären ein vernünftiges Minimum mit einer gewissen Zukunftssicherheit von 64 GB (zwei Drittel Ihrer aktuellen Daten sollten dazu passen, nachdem andere Dienste und Reservierungen gekürzt wurden). Wenn Sie meinen Bauch zitieren, werden Sie in Gesprächen mit Ihren Infrastrukturmitarbeitern natürlich nicht weit kommen ...