Ressourcen für das Sharding und die Partitionierung von Datenbanken

Question

Ich arbeite mit einem Datenbankschema, bei dem Skalierbarkeitsprobleme auftreten. Eine der Tabellen im Schema ist auf etwa 10 Millionen Zeilen angewachsen, und ich untersuche Optionen für das Partitionieren und Sharting, um dieses Schema auf viel größere Datensätze (etwa 1 Milliarde bis 100 Milliarden Zeilen) skalieren zu lassen. Unsere Anwendung muss auch in verschiedenen Datenbankprodukten implementiert werden können, einschließlich, aber nicht beschränkt auf Oracle, MS SQL Server und MySQL.

Dies 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-Sharing- und Partitionierungsstrategien?

Answer 1

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.

Allerdings, wenn Sie für das Lernen über das Thema sharding einige Ressourcen wollen diese dann versuchen:

• Scalability Best Practices: Lessons from eBay
• Randy Shoup on eBay's Architectural Principles - Video and Presentation
• High Scalability Site
• Mr. Moore gets to punt on sharding (when not to do it)

Answer 2

10 Millionen Zeilen sind in DBMS-Begriffen wirklich nicht groß und ich würde zuerst meine Indizierung und Abfragepläne betrachten, bevor ich anfange, eine physische Verteilung von Daten mit Shards oder Partitionen zu planen, was eigentlich erst notwendig sein sollte Tisch ist um ein paar Größenordnungen gewachsen.

Alle IMHO, natürlich.

Answer 3

Ich stimme mit Mike Woodhouse Beobachtung überein, dass die aktuelle Größe kein Problem sein sollte - und der Fragesteller stimmt zu.

Die meisten kommerziellen DBMS bieten Unterstützung für fragmentierte Tabellen in einigen für die andere, 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 Laden über mehrere Festplatten, bedeutet jedoch, dass Sie nicht von der Eliminierung von Fragmenten profitieren können.

Answer 4

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 es maximale RAM in Ihrem Server. Kein Grund, weniger als 32GB zu haben, wenn Ihre Datenbank groß ist. Aber am Ende werden Sie immer noch I/O gebunden finden, und Sie werden eine Menge Festplatten kaufen und ein komplexes Partitionierungsschema verwalten, 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 wirst du ein paar Gigs ausgeben, aber es ist immer noch viel billiger als SANs usw.