Witryny do użytku wewnętrznego: Czy istnieje przekonujący argument przeciwko SQLite?

Wiele frameworków internetowych, takich jak Flask lub Django, używa SQLite jako domyślnej bazy danych. SQLite jest atrakcyjny, ponieważ jest zawarty w Pythonie, a obciążenie administracyjne jest dość niskie.

Jednak większość publicznych witryn produkcyjnych o dużym natężeniu ruchu korzysta z cięższej bazy danych: mySQL, Oracle lub postgresql.

Pytania :

Założyć:

• Ruch w witrynie jest umiarkowany i nastąpi jednoczesny dostęp do odczytu / zapisu bazy danych
• Użyjemy SQLAlchemy z blokadami zapisu SQLite (chociaż ten komentarz mnie trochę denerwuje)
• Baza danych będzie zawierać prawdopodobnie 60 000 rekordów
• Struktury danych nie wymagają zaawansowanych funkcji znajdujących się w cięższych bazach danych

Czy jest kiedykolwiek przekonujący argument przeciwko współbieżności SQLite dla stron internetowych, które służą jako wewnętrzne narzędzia korporacyjne o średnim natężeniu ruchu? Jeśli tak, jakie warunki spowodują problemy z współbieżnością SQLite ?

Szukam znanych konkretnych przyczyn, zamiast ogólnego strachu / bezpodstawnego wskazywania palcem.

Zalecam przeczytanie oficjalnej odpowiedzi na twoje pytanie: Odpowiednie zastosowania dla SQLite . W szczególności „Sytuacje, w których inny RDBMS może działać lepiej” ostrzega, że ​​SQLite nie obsługuje jednoczesnego zapisu:

SQLite obsługuje nieograniczoną liczbę jednoczesnych czytników, ale pozwoli tylko na jednego pisarza w dowolnym momencie. W wielu sytuacjach nie stanowi to problemu. Każda aplikacja działa szybko i działa baza danych, a blokada nie trwa dłużej niż kilkadziesiąt milisekund. Istnieją jednak aplikacje wymagające większej współbieżności, które mogą wymagać innego rozwiązania.

Z punktu widzenia adekwatności mam tendencję do postrzegania SQLite jako bardzo wyrafinowanego formatu plików, który obsługuje zapytania SQL. Miałem tendencję do unikania SQLite, gdybym chciał oddzielić moją bazę danych od mojej aplikacji internetowej, ponieważ nie jest ona zoptymalizowana do tego przypadku. Krótko mówiąc, SQLite jest niewystarczająco skalowalny do użycia w niektórych scenariuszach, więc osobom prowadzącym strony internetowe, które kiedyś będą popularne, lepiej będzie zacząć od czegoś skalowalnego, niż przejść na SQLite, a później zostać zmuszonym do zmiany.

Biorąc to wszystko pod uwagę, SQLite jest prawdopodobnie w porządku dla większości wewnętrznych stron internetowych; zazwyczaj wewnętrzne strony internetowe nie wymagają tego samego poziomu współbieżności i skalowalności.

Zakładając kapelusz dyrektora IT, widzę tutaj kilka nie-go:

• Ryzyko uszkodzenia danych. Być może bardziej postrzegany niż rzeczywisty, ale na koniec dnia jest to plik typu DB, który nie zawiera transakcji, i nie ma wiele, jeśli w ogóle, złych zapisów, poza pytaniem, czy masz ostatnią kopię zapasową. A propos . . .
• Jak mogę to zrobić? W pewien sposób wiem, że mam dobrą kopię. Najlepiej bez przełączania aplikacji w tryb offline.
• Jak mogę zabezpieczyć dostęp do bazy danych? Ogólnie rozumiem, że SQL Lite nie ma dostępu poza systemem plików, co jest przyzwoitym początkiem, ale nie wszystkim. Zwłaszcza dla aplikacji internetowych, w których możesz chcieć więcej stopniowanych uprawnień niż DBA lub nic.

Z punktu widzenia dewelopera uważam, że ważne jest, aby wiedzieć, dlaczego SqlLite jest domyślny - dzieje się tak, ponieważ jest łatwy i dobrze demonstruje. Jeśli „sprzedajesz” platformę nowym programistom, kluczem jest możliwość uruchomienia działającej aplikacji internetowej przy minimalnym zamieszaniu. A konieczność wstania i prawidłowej konfiguracji serwera bazy danych byłaby ogromną przeszkodą, której należy unikać.