Jak skalowalny jest SQLite? [Zamknięte]

Niedawno przeczytałem to pytanie o SQLite vs. MySQL, a odpowiedź wskazała, że ​​SQLite nie skaluje się dobrze i oficjalna strona internetowa potwierdza to .

Jak skalowalny jest SQLite i jakie są jego najwyższe limity?

Wczoraj wypuściłem małą stronę ^*do śledzenia twojego przedstawiciela, który korzystał ze wspólnej bazy danych SQLite dla wszystkich odwiedzających. Niestety, nawet przy niewielkim obciążeniu mojego hosta działało dość wolno. Wynika to z faktu, że cała baza danych była blokowana za każdym razem, gdy ktoś przeglądał stronę, ponieważ zawierała ona aktualizacje / wstawki. Wkrótce przeszedłem na MySQL i chociaż nie miałem zbyt wiele czasu na przetestowanie go, wydaje się, że jest znacznie bardziej skalowalny niż SQLite. Pamiętam tylko powolne ładowanie strony i czasami błąd blokady bazy danych podczas próby wykonania zapytań z powłoki w sqlite. To powiedziawszy, dobrze uruchamiam inną witrynę z SQLite. Różnica polega na tym, że strona jest statyczna (tzn. Jestem jedyną, która może zmienić bazę danych), więc działa dobrze dla równoczesnych odczytów. Morał historii:

edycja : Właśnie zdałem sobie sprawę, że mogłem nie być uczciwy wobec SQLite - nie indeksowałem żadnych kolumn w bazie danych SQLite, kiedy serwowałem je ze strony internetowej. To częściowo spowodowało spowolnienie, którego doświadczałem. Jednak obserwacja podstaw blokowania bazy danych - jeśli masz szczególnie uciążliwe aktualizacje, wydajność SQLite nie będzie pasować do MySQL lub Postgres.

kolejna edycja: odkąd opublikowałem to prawie 3 miesiące temu, miałem okazję dokładnie zbadać skalowalność SQLite, a przy kilku sztuczkach może być całkiem skalowalny. Jak wspomniałem w mojej pierwszej edycji, indeksy baz danych znacznie skracają czas zapytań, ale jest to bardziej ogólne spostrzeżenie dotyczące baz danych niż SQLite. Istnieje jednak inna sztuczka, której można użyć do przyspieszenia transakcji SQLite: transakcje . Ilekroć musisz wykonać wiele zapisów w bazie danych, umieść je w transakcji. Zamiast zapisywać do pliku (i blokować) za każdym razem, gdy wysyłane jest zapytanie o zapis, zapis nastąpi tylko raz po zakończeniu transakcji.

Witryna, o której wspomniałem, którą opublikowałem w pierwszym akapicie, została z powrotem przełączona na SQLite i działa dość płynnie po dostrojeniu kodu w kilku miejscach.

^{* strona nie jest już dostępna}

Sqlite jest skalowalny pod względem pojedynczego użytkownika, mam wielogigabajtową bazę danych, która działa bardzo dobrze i nie miałem z nią większych problemów.

Ale jest to jeden użytkownik, więc zależy to od rodzaju skalowania, o którym mówisz.

W odpowiedzi na komentarze. Zauważ, że nic nie stoi na przeszkodzie, aby używać bazy danych Sqlite w środowisku wielu użytkowników, ale każda transakcja (w efekcie każda instrukcja SQL modyfikująca bazę danych) blokuje plik , co uniemożliwi innym użytkownikom dostęp do bazy danych w wszystko .

Więc jeśli wykonałeś wiele modyfikacji bazy danych, zasadniczo bardzo szybko trafisz na problemy ze skalowaniem. Z drugiej strony, jeśli masz dużo dostępu do odczytu w porównaniu do dostępu do zapisu, może nie być tak źle.

Ale Sqlite będzie oczywiście działał w środowisku wielu użytkowników, ale nie będzie działał dobrze.

SQLite napędza witrynę sqlite.org i inne, które mają duży ruch. Sugerują, że jeśli masz mniej niż 100 000 działań dziennie, SQLite powinien działać dobrze. I to zostało napisane przed udostępnieniem funkcji „Writeahead Logging”.

Jeśli chcesz przyspieszyć działanie SQLite, wykonaj następujące czynności:

• uaktualnij do SQLite 3.7.x
• Włącz rejestrowanie z wyprzedzeniem
• Uruchom następującą pragmę: „PRAGMA cache_size = liczba stron;” Domyślny rozmiar (liczba stron) to 2000 stron, ale jeśli zwiększysz tę liczbę, zwiększysz ilość danych, która kończy się w pamięci.

Możesz rzucić okiem na mój film na YouTube zatytułowany „ Popraw wydajność SQLite dzięki Writeahead Logging ”, który pokazuje, jak korzystać z rejestrowania z wyprzedzeniem zapisu i demonstruje 5- krotną poprawę prędkości zapisu.

Sqlite to komputerowa lub przetwarzana baza danych. SQL Server, MySQL, Oracle i ich bracia to serwery .

Pulpitowe bazy danych z natury nie są dobrym wyborem dla żadnej aplikacji, która musi obsługiwać równoczesny dostęp do zapisu do magazynu danych. Obejmuje to na pewnym poziomie większość stron internetowych, jakie kiedykolwiek stworzono. Jeśli musisz się nawet zalogować, prawdopodobnie potrzebujesz dostępu do bazy danych.

Czy czytałeś te dokumenty SQLite - http://www.sqlite.org/whentouse.html ?

SQLite zwykle działa świetnie jako silnik bazy danych dla witryn o niskim i średnim ruchu (czyli 99,9% wszystkich witryn). Ilość ruchu w sieci, którą SQLite może obsłużyć, zależy oczywiście od tego, jak intensywnie witryna wykorzystuje swoją bazę danych. Ogólnie rzecz biorąc, każda witryna, która otrzymuje mniej niż 100 000 działań dziennie, powinna dobrze działać z SQLite. Liczba 100 000 trafień / dzień jest ostrożnym szacunkiem, a nie twardą górną granicą. Wykazano, że SQLite działa z 10-krotnym natężeniem ruchu.

Skalowalność SQLite będzie w dużej mierze zależeć od użytych danych i ich formatu. Miałem ciężkie doświadczenia z bardzo długimi stołami (rekordy GPS, jeden rekord na sekundę). Doświadczenie pokazało, że SQLite zwalnia stopniowo, częściowo z powodu ciągłego przywracania równowagi rosnącym drzewom binarnym posiadającym indeksy (a dzięki indeksom ze znacznikiem czasu po prostu wiesz, że drzewo będzie bardzo zrównoważone, ale jest to bardzo ważne dla twojego wyszukiwania). W końcu około 1 GB (bardzo ballpark, wiem), w moim przypadku zapytania stają się powolne. Twój przebieg będzie się różnić.

Należy pamiętać, że pomimo wszystkich przechwałek, SQLite NIE jest przeznaczone do hurtowni danych. Istnieją różne zastosowania niezalecane dla SQLite. Świetni ludzie stojący za SQLite mówią sami:

Innym sposobem spojrzenia na SQLite jest: SQLite nie jest przeznaczony do zastąpienia Oracle. Jest przeznaczony do zastąpienia fopen ().

Prowadzi to do głównego argumentu (nie ilościowego, przepraszającego, ale jakościowego), SQLite nie jest do wszystkich zastosowań, podczas gdy MySQL może obejmować wiele różnych zastosowań, nawet jeśli nie idealnie. Na przykład możesz mieć MySQL do przechowywania plików cookie Firefox (zamiast SQLite), ale potrzebujesz tej usługi przez cały czas. Z drugiej strony, możesz mieć transakcyjną stronę internetową działającą na SQLite (jak robi to wiele osób) zamiast na MySQL, ale spodziewaj się wielu przestojów.

myślę, że na zapleczu pojawia się serwer (w liczbach 1) obsługujący setki klientów z pojedynczym połączeniem z bazą danych, prawda?

Nie ma więc równoczesnego dostępu do bazy danych, dlatego możemy powiedzieć, że baza danych działa w trybie „pojedynczego użytkownika”. Nie ma sensu dyskutować o dostępie dla wielu użytkowników w takich okolicznościach, dlatego SQLite działa tak samo, jak każda inna baza danych oparta na serwerze.

Pomyśl o tym w ten sposób. SQL Lite będzie blokowany za każdym razem, gdy ktoś go użyje (SQLite nie blokuje się podczas czytania). Jeśli więc serwujesz stronę internetową lub aplikację, która ma wielu współbieżnych użytkowników, tylko jedna może korzystać z Twojej aplikacji jednocześnie z SQLLite. Więc jest problem ze skalowaniem. Jeśli aplikacja jednoosobowa powie bibliotekę muzyczną, w której przechowywane są setki tytułów, ocen, informacji, użytkowania, odtwarzania, czasu odtwarzania, SQL Lite będzie się pięknie skalować, przechowując tysiące, jeśli nie miliony rekordów (jeśli jest to możliwe na dysku twardym)

Z drugiej strony MySQL działa dobrze w aplikacjach serwerowych, gdzie ludzie na całym świecie będą go używać jednocześnie. Nie blokuje się i ma dość duży rozmiar. Tak więc dla twojej biblioteki muzycznej MySql byłby zbyt zabójczy, jak zobaczyłaby go tylko jedna osoba, chyba że jest to wspólna biblioteka muzyczna, w której tysiące dodają lub aktualizują ją. Wtedy użyje MYSQL.

Więc teoretycznie MySQL skaluje się lepiej niż Sqllite, ponieważ może obsługiwać wielu użytkowników, ale jest przesadą w przypadku aplikacji dla jednego użytkownika.

Witryna SQLite (część, do której się odwołujesz) wskazuje, że może być używana w różnych sytuacjach dla wielu użytkowników.

Powiedziałbym, że poradzi sobie całkiem sporo. Z mojego doświadczenia wynika, że ​​zawsze było bardzo szybko. Oczywiście musisz zindeksować swoje tabele, a podczas kodowania przeciwko niemu musisz upewnić się, że używasz sparamerizowanych zapytań i tym podobnych. Zasadniczo takie same czynności, jak w przypadku dowolnej bazy danych w celu poprawy wydajności.

Warto sprawdzić REAL SQL Server , który jest serwerem bazy danych zbudowanym na SQLite.