Jakie są charakterystyki wydajności sqlite z bardzo dużymi plikami baz danych? [zamknięte]

Używamy DBS 50 GB+ na naszej platformie. no complains działa świetnie. Upewnij się, że robisz wszystko dobrze! Używasz predefiniowanych instrukcji ? *SQLITE 3.7.3

1. transakcje
2. wstępnie złożone oświadczenia

3. Zastosuj te ustawienia (zaraz po utworzeniu DB)

   PRAGMA main.page_size = 4096;
   PRAGMA main.cache_size=10000;
   PRAGMA main.locking_mode=EXCLUSIVE;
   PRAGMA main.synchronous=NORMAL;
   PRAGMA main.journal_mode=WAL;
   PRAGMA main.cache_size=5000;
   

Mam nadzieję, że to pomoże innym, działa świetnie tutaj

Stworzyłem bazy danych SQLite o rozmiarze do 3,5 GB bez zauważalnych problemów z wydajnością. Jeśli dobrze pamiętam, myślę, że SQLite2 może mieć jakieś niższe limity, ale nie sądzę, że SQLite3 ma takie problemy.

Zgodnie ze stroną SQLite Limits , Maksymalny rozmiar każdej strony bazy danych wynosi 32K. a maksymalna liczba stron w bazie danych to 1024^3. Według mojej matematyki to 32 terabajty jako maksymalny rozmiar. Myślę, że przekroczysz limity swojego systemu plików zanim uderzam w SQLite ' a!

Wiele z powodów, dla których wykonanie wstawek zajęło > 48 godzin, wynika z Twoich indeksów. Jest niesamowicie szybszy:

1-upuść wszystkie indeksy 2-Czy wszystkie wkładki 3-Utwórz ponownie indeksy

Oprócz zwykłej rekomendacji:

1. indeks upuszczania dla wkładki zbiorczej.
2. wsadowe wstawianie / aktualizacje w dużych transakcjach.
3. Tune your buffer cache / disable journal / w PRAGMAs.
4. Użyj 64-bitowej maszyny(aby móc korzystać z dużej ilości pamięci podręcznej™).
5. [dodano lipiec 2014] użyj common table expression (CTE) zamiast uruchamiania wielu zapytań SQL! Wymaga wydania SQLite 3.8.3.

Z moich doświadczeń z SQLite3:

1. dla maksymalnej prędkości wstawiania, nie używaj schematu z żadnym ograniczeniem kolumn. (zmiana tabeli później w razie potrzeby nie można dodawać ograniczeń za pomocą zmiany tabeli).
2. zoptymalizuj swój schemat, aby przechowywać to, czego potrzebujesz. Czasami oznacza to rozbicie tabel i / lub nawet kompresję / przekształcenie danych przed włożeniem ich do bazy danych. Świetnym przykładem jest przechowywanie adresów IP jako (długich) liczb całkowitych.
3. jedna tabela na plik db - aby zminimalizować spór o blokadę. (Użycie załącz bazę danych jeśli chcesz mieć pojedynczy obiekt połączenia.
4. SQLite może przechowywać różne typy danych w tej samej kolumnie( dynamiczne pisanie), użyj tego na swoją korzyść.

Pytanie/komentarz mile widziany. ;-)

Mam bazę danych SQLite 7GB. Wykonanie konkretnego zapytania z łączeniem wewnętrznym zajmuje 2,6 s Aby to przyspieszyć, próbowałem dodać indeksy. W zależności od tego, który indeks(y) dodałem, czasami zapytanie spadło do 0.1 s, a czasami wzrosło do 7s. Myślę, że problem w moim przypadku polegał na tym, że jeśli kolumna jest wysoce duplikowana, to dodanie indeksu obniża wydajność : (

Myślę, że główne skargi na skalowanie sqlite to:

1. zapis pojedynczego procesu.
Nie ma lustrzanego odbicia. Brak replikacji.

W dokumentacji SQLite było kiedyś stwierdzenie, że praktyczny limit rozmiaru pliku bazy danych wynosił kilkadziesiąt GB: s. wynikało to głównie z potrzeby, aby SQLite "przydzielił bitmapę brudnych stron", gdy rozpoczynasz transakcję. Tak więc dla każdego MB w bazie danych wymagane było 256 bajtów pamięci RAM. Wstawianie do pliku DB o pojemności 50 GB wymagałoby dużej (2^8)*(2^10)=2^18=256 MB PAMIĘCI RAM.

Ale od najnowszych wersji SQLite, to nie jest już potrzebne. Czytaj więcej TUTAJ .

Miałem problemy z dużymi plikami sqlite podczas używania polecenia vacuum.

Nie próbowałem jeszcze funkcji auto_vacuum. Jeśli spodziewasz się często aktualizować i usuwać dane, warto na to spojrzeć.