Frage bezüglich Begrenzung von Inhaltsdatenbank- / Websitesammlungsgröße

Andi Fandrich Als Antwort am 31 Juli 2014 12:58

Die Werte von 200 bzw. 100 GB sind ja zunächst nur Empfehlungen. Die wirkliche technische Grenze sind 4 TB. Microsoft kommt auf solche Werte durch ausführliche Tests und praktische Erfahrungen von Kunden. Unterm Strich heißt das nur, daß Du Dich danach richten kannst, es aber nicht mußt.

Große Datenbanken machen nicht unbedingt sofort ein (Performance-)Problem in SharePoint, aber man muß auch an andere Dinge denken. Hier sind es z.B. oft die Backups, die nicht mehr in vernünftiger Zeit gezogen werden können.

[quote user="RedArt"]IOPS pro GB[/quote]

Auch das sind ja Empfehlungen und besagen im Prinzip nur, daß man für größere Datenbanken auch schnellere Platten verwenden soll. Bei einer 100 GB DB also z.B. 0,25 x 100 = 25 IOPs

RedArt Als Antwort am 31 Juli 2014 13:41

Programme und PDF Dateien die um die 40Megabyte liegen, sollten diese deiner Meinung nach aus Sharepoint rausgehalten werden?

Ich benutze Sharepoint 2013 Foundation mit SQL Server 2012 Standard (nicht express).

Sollte ich diese Dateien programmatisch auf den Fileserver ablegen, oder hast du eine bessere Idee, wie man diese Dateien mit Versionierung wirklich gut in Sharepoint einbinden kann. (Für jeden der Dateitypen die 40MB überschreiten eigene Websitesammlungen und dann programmatisch look-Ups setzen?)

Würde mich freuen wenn du einen Rat für mich hättest.

mfg

Andi Fandrich Als Antwort am 31 Juli 2014 14:26

Das kann man gar nicht so generell beantworten...

Das Problem mit der Versionierung ist in 2013 nicht mehr so groß. Stichwort: shredded Storage

Dann kommt es noch auf die Gesamtmenge der Daten an. Einzelne große Dateien sind ja wurscht, aber wenn es in Summe dann mehrere TB werden...

Man kann SQL Server zum externen Speichern der Dateien veranlassen (Stichwort File Stream bzw. Remote Blob Storage). Das kann man pro Datenbank einrichten und SQL Server kümmert sich dann darum - SharePoint bekommt davon gar nichts mit. Dazu braucht man aber einen vernünftigen Filestream-Provider (kostenpflichtig) und man muß Backups anders organisieren, weil die Dateien und die Datenbanken synchron gehalten werden müssen.

Der Aufwand lohnt sich nur, wenn man es wirklich mit sehr großen Datenmengen zu hat. Und wenn auch wirklich die Mehrzahl der Dateien relativ groß ist. Bei vielen kleinen Dateien hat man sonst Performanceeinbußen.

RedArt Als Antwort am 31 Juli 2014 15:31

Also wenn man jetzt davon ausgeht, dass man Programmierdateien in ZIP files speichert und diese jeweils so 40mb groß sind und dazu eben auch die 40mb großen PDFs und so weiter. Dann kommt mit den verschiedenen Versionen natürlich, wenn viele verschiedene Programme da sind schnell an große Datenmengen. 

1000 mal Programm mit X(nehme mal 10 an) Versionen mal 40MB =~ 400.000MB =~ 400GB

Und das jetzt mal 4, weil die PDF ähnlich groß sind und andere Dateien dazukommen so weiter =~ 1,6TB

Wie kann ich nun diese Dinge auslagern? Ist dafür eine spezielle Sharepoint Struktur benötigt, wie zum Beispiel alle Dateien die vom RBS ausgelagert werden sollen müssen sich in einer Dokumentenbibliothek befinden? 

Verstehe glaube ich nicht ganz den Punkt der RBS / Filestream Provider die Pro Datenbank eingerichtet werden sollen. Würden dann ALLE Dokumente die sich in dieser Datenbank befinden ausgelagert werden, sofern es um Files geht? (Listen usw bleiben in der Datenbank?)

Andi Fandrich Als Antwort am 31 Juli 2014 16:56

Ja genau. RBS wird pro Datenbank eingerichtet und SQL Server sorgt dann dafür, daß alles was als Blob gespeichert werden soll in eine Datei gespeichert wird. Im Falle SharePoint sind das alle Dateien, die in diese Datenbank sollen, aber nicht Listenelemente, die eigentlichen Websitestrukturen usw.

RedArt Als Antwort am 31 Juli 2014 17:18

Wenn ich nun einen RBS Verwenden würde, so würden ja die Blobs ausgelagert werden.

Microsoft bezog sich ja nun auf eine Inhaltsdatenbank mit der Größe von 200GB, da die Blobs allerdings nun ausgelagert werden sind diese nicht mehr in der eigentlich Datenbank vorhanden sondern werden durch den RBS automatisch irgendwo auf dem fileserver gespeichert. So ist also auch die Inhaltsdatenbank deutlich kleiner wenn man RBS verwendet und eine Websitesammlung kann deshalb durchaus eine Unmenge von Daten speichern?

Würdest du in diesem oben beschriebenen Fall (1000x10x40MB x 4Daten) + viele Word Dokumente und Schriftverkehr und Excel-Arbeitsblätter sowie Bilder, zu einem RBS greifen?

mfg

Florian Adler Als Antwort am 1 Aug. 2014 09:58

Sofern die Leute nicht gerade weit verstreut voneinander, sondern nach Möglichkeit im gleichen Netz sitzen, würde ich die SP-/ bzw. RBS-Variante gar nicht erst in Betracht ziehen, sondern eher auf ein echtes NAS (ggf. mit Versionskontrollsoftware, usw.) setzen. Schließlich müssen die Dateien erst auf den SP "hochgeladen" und anschließend vom RBS (eventl. mit Shredded Storage) noch weiterverarbeitet werden. Auch könnte man das Versionshandling mit einem entsprechenden NAS eleganter handhaben.

Wird hingegen über mehrere Standorte hinweg an diesen zip-files gearbeitet, könnte man die SP-Lösung in Betracht ziehen. Das hängt aber mehr davon ab, wie die Leute arbeiten. Unsere Entwickler nutzen beispielsweise Gitlab und ähnliches

RedArt Als Antwort am 1 Aug. 2014 11:18

Nun ja laut einem Entwickler von uns gibt es ein solches Versionierungstool für unseren Anwendungsbereich nicht. Es handelt sich um SPS Programmierung mit verschiedenen Herstellern Siemens, Rockwell, ... 

Ja es befinden sich alle im gleichen Netzwerk und man versucht eine gesamtheitliche Lösung von Unternehmensdaten zu finden. Dabei sind nur die 100GB Websitesammlungsgrenze und die Inhaltsdatenbankgrenze von 200GB äußerst störende faktoren.

Ein anderer Ansatz von jemandem war es diese Dateien über Sharepoint automatisiert auf den Fileserver zu laden (programmierte Lösung) und nur noch die Links zu den Dateien im Sharepoint zu speichern. Allerdings verliert man doch so die ganze Berechtigungsstruktur von Sharepoint, da so wieder direkt über den Fileserver zugegriffen werden kann.

Ich suche immer noch nach einer Lösung :(

Matthias_M Als Antwort am 1 Aug. 2014 13:53

Hallo,

es gibt Lösungen für die Anforderungen. Das ist wie so oft eine Frage des Budgets und der Wichtigkeit..., die von Drittherstellern schon fertig vorhanden sind:

Die erhalten auch bei einer Speicherung auf Fileservern die SP Berechtigungen und können große Dateien über SharePoint, aber am SQL Server vorbei speichern

Da ich hier für niemand Werbung machen möchte, einfach bei Interesse eine PM an mich!

Viele Grüße,

Matthias

RedArt Als Antwort am 18 Sept. 2014 15:18

Hi nochmals,

Ich habe nun einen Test gemacht mit SQLIO usw. dieser ist natürlich je nachdem welche Chunksize oder Blockgröße man wählt höchst unterschiedlich. Verwende ich:

IOP/s:

8KB Blöcke ergeben sich Read Sequentiell 9000, read random 4000, write random 2000, write sequentiell 9000

64KB Blöcke ergeben sich Read Sequentiell 1750, read random 1750, write random 850, write sequentiell  1750

Wie lässt sich nun abschätzen, wieviele Daten dieses System maximal aufnehmen kann?