Kiedyś pracowałem z bardzo dużą (Terabajt+) bazą danych MySQL. Największy stół, jaki mieliśmy, miał dosłownie ponad miliard wierszy.
Zadziałało. MySQL przez większość czasu przetwarzał dane poprawnie. Był jednak wyjątkowo nieporęczny.
Samo tworzenie kopii zapasowych i przechowywanie danych było wyzwaniem. Gdyby trzeba było, przywrócenie tabeli zajęłoby kilka dni.
Mieliśmy wiele tabel w zakresie 10-100 milionów wierszy. Wszelkie znaczące sprzężenia przy stołach były zbyt czasochłonne i trwały wiecznie. Napisaliśmy więc procedury składowane, aby „przejść” tabele i sprzężenia procesów z zakresami „id”. W ten sposób przetwarzalibyśmy dane 10-100 000 wierszy na raz (Połącz z identyfikatorem 1-100 000, a następnie 100 000-200 000 itd.). Było to znacznie szybsze niż dołączenie do całego stołu.
Używanie indeksów na bardzo dużych tabelach, które nie są oparte na kluczu podstawowym, jest również znacznie trudniejsze. Mysql przechowuje indeksy w dwóch częściach — przechowuje indeksy (inne niż indeks podstawowy) jako indeksy do wartości klucza podstawowego. Tak więc wyszukiwania indeksowane są wykonywane w dwóch częściach:najpierw MySQL przechodzi do indeksu i pobiera z niego wartości klucza głównego, które musi znaleźć, a następnie wykonuje drugie wyszukiwanie w indeksie klucza głównego, aby znaleźć te wartości.
Wynika z tego, że w przypadku bardzo dużych tabel (1-200 milionów plus wiersze) indeksowanie tabel jest bardziej restrykcyjne. Potrzebujesz mniej, prostszych indeksów. A wykonanie nawet prostych instrukcji Select, które nie znajdują się bezpośrednio w indeksie, może nigdy nie wrócić. Gdzie klauzule musi uderzaj w indeksy lub o tym zapomnij.
Ale biorąc to wszystko pod uwagę, rzeczy faktycznie działały. Udało nam się użyć MySQL z tymi bardzo dużymi tabelami, wykonać obliczenia i uzyskać poprawne odpowiedzi.
