Zasoby dotyczące dzielenia bazy danych i partycjonowania

Question

Używam schematu bazy danych, który ma problemy z skalowalnością. Jedna z tabel w schemacie wzrosła do około 10 milionów wierszy, a ja badam opcje shardowania i partycjonowania, aby umożliwić skalowanie tego schematu do znacznie większych zestawów danych (powiedzmy od 1 miliarda do 100 miliardów wierszy). Nasza aplikacja musi być również możliwa do wdrożenia na kilka produktów bazodanowych, w tym między innymi Oracle, MS SQL Server i MySQL.

Jest to ogólnie duży problem i chciałbym się dowiedzieć, jakie opcje są dostępne. Jakie zasoby są dostępne (książki, oficjalne dokumenty, strony internetowe) dotyczące fragmentacji bazy danych i strategii partycjonowania?

Answer 1

Zgadzam się z pozostałymi odpowiedziami, że powinieneś spojrzeć na swój schemat i indeksy zanim skorzystasz ze skrytki . 10 milionów wierszy znajduje się w zasięgu dowolnego z głównych silników baz danych.

Jednak jeśli chcesz jakieś środki na poznanie przedmiotu sharding następnie spróbuj tych:

• 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 milionów wierszy nie jest naprawdę duże w warunkach DBMS, a ja bym najpierw szukał planów indeksowania i zapytań przed rozpoczęciem planowania fizycznej dystrybucji danych za pomocą shardów lub partycji, co nie powinno być konieczne, dopóki stół rośnie o kilka rzędów wielkości.

Wszystkie IMHO, oczywiście.

Answer 3

Zgadzam się z obserwacją Mike'a Woodhouse'a, że ​​obecny rozmiar nie powinien stanowić problemu - i pytający zgadza się z tym.

Większość komercyjnych DBMS zapewnia wsparcie dla pofragmentowanych tabel w niektórych lub innych, pod jedną nazwą lub kilkoma innymi. Jednym z kluczowych pytań jest to, czy istnieje rozsądny sposób podziału danych na fragmenty. Jednym z popularnych sposobów jest zrobienie tego na podstawie daty, więc wszystkie wartości, na przykład, listopad 2008 r. Idą w jednym fragmencie, w październiku 2008 w innym, i tak dalej. Ma to zalety, gdy przychodzi czas na usunięcie starych danych. Prawdopodobnie możesz upuścić fragment zawierający dane z października 2001 (siedem lat przechowywania danych) bez wpływu na pozostałe fragmenty. Tego rodzaju fragmentacja może również pomóc w "eliminacji fragmentów"; jeśli zapytanie wyraźnie nie może wymagać odczytania danych z danego fragmentu, pozostanie ono nieprzeczytane, co może dać wspaniałe korzyści w zakresie wydajności. (Na przykład, jeśli optymalizator wie, że zapytanie dotyczy daty z października 2008 r., Zignoruje wszystkie fragmenty z wyjątkiem tych, które zawierają dane z października 2008 r.)

Istnieją inne techniki fragmentacji - round robin dystrybuuje ładowanie na wielu dyskach, ale oznacza, że ​​nie można czerpać korzyści z eliminacji fragmentów.

Answer 4

Z mojego doświadczenia wynika, że ​​duże stoły zawsze uderzają w stronę wejścia/wyjścia. Najtańszym rozwiązaniem jest dodanie wystarczającej liczby indeksów wielokolumnowych, aby wszystkie zapytania mogły pobierać dane bezpośrednio z indeksu, bez konieczności ładowania głównych stron danych. To sprawia, że ​​twoje wstawki i aktualizacje wymagają intensywniejszego I/O, ale może to być w porządku. Następna łatwa opcja to max RAM na serwerze. Nie ma powodu, aby mieć mniej niż 32 GB, jeśli baza danych jest duża. Ale na końcu nadal będziesz się wiązać I/O, a będziesz szukał kupowania wielu dysków twardych i utrzymania złożonego schematu partycjonowania, co kosztuje fortunę między sprzętem a pracą. Mam nadzieję, że obecnie istnieje lepsza alternatywa - przenieś bazę danych z obracających się dysków twardych na dyski półprzewodnikowe SLC - powinno to sprawić, że Twoje losowe odczyty i zapisy będą stukrotnie szybsze niż w przypadku dysków SAS najwyższej klasy, i usuń I/O szyjka. Dyski SSD zaczynają się od 10 USD za gigabajt, więc masz zamiar wydać kilka kawałków, ale wciąż jest dużo taniej niż SAN, itd.