Ich arbeite mit einem Datenbankschema, das Skalierbarkeitsprobleme aufweist. Eine der Tabellen im Schema ist auf etwa 10 Millionen Zeilen angewachsen, und ich erkläre Möglichkeiten für das Sharting und die Partitionierung, damit dieses Schema auf viel größere Datenmengen (etwa 1 Milliarde bis 100 Milliarden Zeilen) skaliert werden kann. Unsere Anwendung muss auch auf verschiedenen Datenbankprodukten implementiert werden können, einschließlich, aber nicht beschränkt auf Oracle, MS SQL Server und MySQL.
Das ist ein großes Problem im Allgemeinen, und ich würde gerne lesen, welche Optionen verfügbar sind. Welche Ressourcen gibt es (Bücher, Whitepaper, Websites) für Datenbank-Sharting- und Partitionierungsstrategien?
Ich stimme den anderen Antworten zu, dass Sie sich Ihr Schema und Ihre Indizes ansehen sollten, bevor Sie auf Sharding zurückgreifen. 10 Millionen Zeilen gehören zu den Möglichkeiten der wichtigsten Datenbank-Engines.
Wenn Sie jedoch einige Ressourcen zum Lernen über das Thema Sharding benötigen, versuchen Sie Folgendes:
Ich stimme der Beobachtung von Mike Woodhouse zu, dass die derzeitige Größe kein Problem sein sollte - und der Fragesteller stimmt zu.
Die meisten kommerziellen DBMS bieten Unterstützung für fragmentierte Tabellen in einigen oder anderen, unter einem Namen oder mehreren anderen. Eine der Schlüsselfragen ist, ob es eine sinnvolle Möglichkeit gibt, die Daten in Fragmente zu zerlegen. Ein gängiger Weg besteht darin, dies auf der Basis eines Datums zu tun, so dass alle Werte für, sagen wir, November 2008 in ein Fragment, diejenigen für Oktober 2008 in ein anderes und so weiter gehen. Dies hat Vorteile, wenn es darum geht, alte Daten zu entfernen. Sie können wahrscheinlich das Fragment mit den Daten vom Oktober 2001 (sieben Jahre Datenspeicherung) fallen lassen, ohne die anderen Fragmente zu beeinflussen. Diese Art der Fragmentierung kann auch bei der "Fragment-Eliminierung" helfen; Wenn die Abfrage die Daten eines bestimmten Fragments eindeutig nicht lesen muss, wird sie ungelesen bleiben, was Ihnen einen großartigen Leistungsvorteil bringen kann. (Wenn der Optimierer beispielsweise weiß, dass die Abfrage für ein Datum im Oktober 2008 vorgesehen ist, ignoriert er alle Fragmente außer dem, der die Daten vom Oktober 2008 enthält.)
Es gibt andere Fragmentierungstechniken - Round Robin verteilt die Last auf mehrere Festplatten, bedeutet aber, dass Sie nicht von der Fragmententfernung profitieren können.
10 Millionen Zeilen sind in DBMS-Begriffen wirklich nicht groß und ich würde zuerst nach meinen Indizierungs- und Abfrageplänen suchen, bevor ich anfange, eine physische Verteilung von Daten mit Shards oder Partitionen zu planen, was eigentlich erst in der Tabelle erforderlich sein sollte gewachsen um ein paar Größenordnungen.
Alle IMHO natürlich.
Nach meiner Erfahrung treffen große Tabellen Sie immer auf der I / O-Seite. Die günstigste Lösung besteht darin, genügend mehrspaltige Indizes hinzuzufügen, damit alle Ihre Abfragen die Daten direkt aus dem Index abrufen können, ohne die Hauptdatenseiten laden zu müssen. Dies macht Ihre Einfügungen und Aktualisierungen mehr I / O-intensiv, aber das kann OK sein. Die nächste einfache Option ist es RAM in Ihrem Server zu maximieren. Kein Grund, weniger als 32GB zu haben, wenn Ihre Datenbank groß ist. Aber am Ende werden Sie immer noch I / O-gebunden sein, und Sie werden eine Menge Festplatten kaufen und ein komplexes Partitionierungsschema pflegen, das ein Vermögen zwischen Hardware und Arbeit kostet. Ich hoffe, dass es heutzutage eine bessere Alternative gibt - die Datenbank von sich drehenden Festplatten auf Solid-State-Laufwerke von SLC zu verlagern - dies sollte Ihre zufälligen Lese- und Schreibvorgänge hundertmal schneller machen als die der obersten SAS-Laufwerke und die E / A entfernen Engpass. SSDs beginnen bei $ 10 pro Gigabyte, also werden Sie ein paar Gigs ausgeben, aber es ist immer noch viel billiger als SANs, etc.
Tags und Links sql database sharding scalability database-cluster