In SQL Server der Unterteilungszyklus wie Tabelle hat -> auf Partition Schema -> auf Dateigruppe (f1, f2, f3, f4, ....)Dateigruppe in MariaDB
Zum Beispiel in Oracle:
Eine Dateigruppe in SQL Server ähnelt den Tabellenbereichen in Oracle. Sie ist ein logischer Speicher für Tabellen- und Indexdaten, die eine oder mehrere Betriebssystemdateien enthalten können.
aber wie wäre es mit MariaDB hat es Dateigruppe?
Nicht als solche. Was versuchst du zu erreichen? Beachten Sie, dass einige dieser Dinge existieren, weil Festplatten früher kleiner als Datenbanken waren. Heute gibt es selten ein Problem. Darüber hinaus eliminieren RAID-Controller, SANs usw. die Notwendigkeit (oder sogar die Erwünschtheit), manuell zu entscheiden, welche Datei wohin geht. Betriebssysteme haben Möglichkeiten, mehrere Volumes miteinander zu verketten, sogar im laufenden Betrieb. Usw.
MyISAM hat die Fähigkeit zu sagen, wohin die Daten gehen und wohin die Indexdatei geht. Aber MyISAM ist fast tot. Selbst dort war es Unsinn, die Daten auf ein Laufwerk und die Indizes auf ein anderes zu legen. Beim Ausführen einer Abfrage wird zuerst auf den Index und anschließend auf die Daten zugegriffen. Das ist wenig, wenn irgendeine Leistung erzielt wurde. Einfaches RAID-Striping wird es wahrscheinlich besser machen.
InnoDB hat eine Möglichkeit, ibdata1, ibdata2 usw. zu buchstabieren. Das stammt aus den Tagen, als das Betriebssystem keine Datei größer als 2GB oder 4GB erstellen konnte. Es wird im Wesentlichen nie heute verwendet.
InnoDB-Tabellen können entweder alle in ibdata1 oder unter einzelnen .ibd-Dateien verteilt sein. Aber ich denke nicht, dass du darüber redest. Mit dieser "Datei pro Tabelle" werden winzige Tabellen ineffizient gespeichert. MySQL 8.0 wird dies leicht verbessern, indem Sie mehrere Tabellen in einem bestimmten "Tablespace" platzieren können, ähnlich wie bei der .ibd-Datei.
Ein InnoDB Tabellen enthält alle Daten und Indizes für eine bestimmte Tabelle oder ein Satz von Tabellen. Bei partitionierten Tabellen, die file_per_table enthielten, wurde jede Partition in einer anderen .ibd-Datei gespeichert. Dies kann sich mit 8.0 ändern.
All diese sind kaum erwähnenswert. Ich würde vermuten, dass nur 1% der Systeme darüber nachdenken müssen. Lassen Sie MySQL/MariaDB einfach tun, was es will; es ist gut genug.
Eine verwandte Sache ... In den 80er und 90er Jahren hatten einige Anbieter "Raw Device" Zugriff, weil sie dachten, sie könnten besser als durch das OS gehen. Auch hier haben sich OS's verbessert, RAID-Controller sind ausgereift und SANs existieren. So roh ist es nicht mehr wichtig. (Ich glaube nicht, dass es MySQL je gab.) Es wird zwangsläufig ein großes Entwicklungs- und Wartungsproblem für den Anbieter geben.
Wie viele DBAs haben tmpdir in eine separate Partition, nur um zu finden, dass die Dinge abstürzen, weil es nicht groß genug war. Dito für RAM-Disk.
Sogar mit optimierten Anweisungen können riesige Tabellen und Indizes langsam sein - wenn die Tabelle partitioniert ist, können Anweisungen, die eine kleine Anzahl von Partitionen lesen, viel schneller sein. Die Sicherung ist möglicherweise auch schneller, wenn Sie nur eine Partition anstelle der gesamten Tabelle sichern müssen. –
Ich glaube nicht, dass es "Sicherung durch Partition" gibt, entweder "PARTITION" oder Festplattenpartitionierung. –
Die einzige Zeit, in der das Scannen einer kleinen Anzahl von Partitionen von Vorteil sein kann, ist, wenn Sie die gesamten Partitionen scannen müssen, da Sie keinen anständigen Index haben. Selbst dann könnte der Index die Partitionierung adäquat simulieren. –