Dlaczego QuickBooks nie może być przechowywany na Google Drive dla wielu użytkowników

Zanim przejdziemy do szczegółów, ważne jest zrozumienie, że mamy tu do czynienia z ogólną koncepcją, którą możemy sprowadzić do pytania: “dlaczego aplikacje klient/serwer lub aplikacje ze współdzielonymi plikami baz danych nie mogą być przechowywane w zsynchronizowanej przestrzeni dyskowej (np. Google Drive, DropBox, NextCloud itp.), gdy dostęp nie jest ograniczony do jednego użytkownika?” QuickBooks korzysta z mechanizmu współdzielonych plików bazy danych, typowego dla aplikacji z lat 80., w których pojedynczy plik lub zestaw plików jest udostępniany poprzez mechanizm współdzielenia plików, a poszczególne kopie aplikacji korzystają z tego pliku i modyfikują go. Google Drive to mechanizm synchronizacji danych: oznacza to, że tworzy kopie danych z jednej lokalizacji do innej. Użytkownicy pracujący jednocześnie na tym samym pliku mogą, i często to robią, nadpisywać wzajemnie swoje zmiany, a oczekuje się, że zmiany te zostaną później ręcznie uzgodnione, zignorowane, albo że użytkownicy będą kontrolowani, aby zapobiec jednoczesnej pracy.

W przypadku niektórych typów aplikacji wieloużytkownikowych zsynchronizowana przestrzeń dyskowa może być wykorzystywana, ale tylko w sytuacjach, gdy aplikacja jest w stanie zostać zablokowana przez system przechowywania tak, aby zezwalać na zmiany tylko wtedy, gdy nie robią tego inni użytkownicy. Wymaga to poziomu integracji niepraktycznego w przypadku ogólnego synchronizowania plików. Większość systemów, które to robią, używa mechanizmu synchronizacji wbudowanego w warstwę bazy danych lub aplikacji, a nie ogólnego mechanizmu, który musi działać bez znajomości kontekstu. Aby zachować integralność danych przy użyciu zsynchronizowanej przestrzeni dyskowej, konieczne jest, aby tylko jedna osoba edytowała plik w danym momencie, czekała aż wszyscy potencjalni użytkownicy otrzymają aktualizacje dokonane po “zapisaniu” tego pliku, a następnie inny użytkownik może edytować plik i powtórzyć ten proces. Ale tylko jeden użytkownik na raz może pracować na pliku i musi otrzymać aktualizacje innych użytkowników przed otwarciem pliku do edycji. W przeciwnym razie system musi pytać użytkowników, które zmiany zachować, a które odrzucić w każdym przypadku.

Tego procesu zapewnienia integralności nie można w żaden realistyczny sposób zastosować do pliku bazy danych. Plik jest zaprojektowany tak, aby być otwarty i dostępny przez cały czas, a nie tylko do szybkiego otwarcia, edycji i zapisania. Zapisywanie nie jest też czynnością ręczną i nie zawsze przewidywalną. Ogólnie zakładamy, że zapisywanie odbywa się w sposób ciągły podczas użytkowania, ale buforowanie może sprawić, że nawet te operacje zapisu będą niemożliwe do ręcznego kontrolowania. Jest to jednak konieczne ze względów wydajnościowych.

Zamieszanie często wynika z tego, że pojedynczy użytkownik, bez obawy przed innym użytkownikiem korzystającym z systemu w tym samym czasie, może używać zsynchronizowanej przestrzeni dyskowej, takiej jak Google Drive lub Apple iCloud, jako mechanizmu tworzenia kopii zapasowych (po prostu automatycznie tworzy odległy duplikat) i/lub jako sposobu replikacji pliku, tak aby pojedynczy użytkownik mógł korzystać z niego najpierw z jednej lokalizacji, a następnie z innej bez potrzeby ręcznego przenoszenia pliku. Dopóki ten pojedynczy użytkownik poświęca wystarczająco dużo czasu na zmianę lokalizacji, aby upewnić się, że wszelkie dane z bufora zostały zapisane, synchronizacje i blokady zostały ukończone, lub upewnił się, że nie pozostawił pierwszej instancji aplikacji otwartej, może w rozsądnym stopniu przyjąć, że system jest bezpieczny (ale nie może tego całkowicie zagwarantować – mechanizm niesie ze sobą minimalne ryzyko wyścigów o zasoby nawet wtedy). Ponieważ istnieje “sposób” na bezpieczne korzystanie ze zsynchronizowanej przestrzeni dyskowej z aplikacją w trybie jednego użytkownika, wielu niewtajemniczonych technicznie pracowników działu księgowości lub finansów błędnie zakłada, że wieloużytkownikowy jednoczesny dostęp, który jest zupełnie innym zagadnieniem, również będzie działał. Jest to jednak niemożliwe.

To, co się dzieje, to wyścig o zasoby (race condition) pomiędzy wieloma użytkownikami i nigdy nie można być całkowicie pewnym, że nie miał on miejsca. Czasami dane będą po prostu błędne i nie ma wątpliwości, że doszło do wyścigu o zasoby, ponieważ liczby będą rażąco niedokładne. Ale częściej pewne transakcje będą po prostu utracone nawet po ich zweryfikowaniu.

Podajmy przykład. Użytkownik 1 jest w domu i wprowadza nowe potwierdzenie odbioru do QuickBooks. Zmiana zaczyna być zapisywana na lokalnym komputerze, a po jej zakończeniu zaczyna przesyłać nowy plik do Google Drive w chmurze (online). Użytkownik 2 jest w biurze i w tym czasie zaczyna wprowadzać płatność od klienta na fakturze. Kopia pliku danych QuickBooks Użytkownika 2 jest otwarta i nie może zostać nadpisana podczas użytkowania, więc kopia wysyłana do Google Drive nie może dotrzeć do Użytkownika 2. Gdy Użytkownik 2 zapisze swoją zmianę, jego kopia również chce wysłać ją do Google Drive. Google Drive musi teraz coś zrobić z dwoma dokumentami, które zaczęły tak samo, ale teraz mają dwie radykalnie różne zmiany, przy czym żadna kopia nie zawiera obu. Nie ma możliwości ich scalenia, więc może albo zaakceptować Użytkownika 1 jako wzorzec i odrzucić zmiany Użytkownika 2 (np. priorytet pierwszeństwa). Albo może zaakceptować zmiany Użytkownika 2 i odrzucić zmiany Użytkownika 1 (np. priorytet ostatniej zmiany). Albo, oczywiście, może odrzucić wszystkie zmiany i nie zaakceptować żadnej. W żadnym przypadku nie zostaną zachowane wszystkie transakcje finansowe użytkowników, nawet po tym, jak zostały przez nich zapisane lokalnie. Użytkownik 1 lub Użytkownik 2 (lub potencjalnie obaj) stracą dane, które uważali za zapisane. Im więcej użytkowników, tym problem staje się poważniejszy.

Część problemu polega na tym, że podczas pracy na poziomie dostępu do pliku i synchronizacji oraz udostępniania danych na poziomie całego pliku, nie ma możliwości zablokowania tylko jednego rekordu lub wiersza, ani oddzielenia transakcji, ani scalenia zmian. Plik jest pojedynczą jednostką i uległ zmianie. To wszystko albo nic. Poszczególne aplikacje QuickBooks nie mogą bezpośrednio komunikować się ze sobą, ani za pośrednictwem pliku bazy danych, aby koordynować zapisy, odczyty itp. w celu obejścia tego problemu. Są ślepe i nie mogą wiedzieć, że inne aplikacje próbują pracować z plikiem w tym samym czasie, ponieważ każda ma własną unikalną kopię pliku; nie ma nic “współdzielonego” między nimi, co pozwalałoby na komunikację. Kopie nie są ze sobą powiązane, nie ma tu żadnych stanów kwantowych. A do tego możemy dodać potencjalne problemy z jedną lub kilkoma instancjami aplikacji używanymi przy wolnym lub niestabilnym połączeniu internetowym, albo co gorsza, gdy instancja jest offline. Może być wiele godzin lub dni zmian, które muszą nadpisać lub zostać nadpisane, gdy synchronizacja w końcu nastąpi. Rzadko mówimy o milisekundach, ale często o dniach danych.

Sposób, w jaki ten problem jest rozwiązywany, gdy jest rozwiązywany, przez lokalnie współdzielone pliki jest wieloaspektowy. Po pierwsze, istnieje tylko jeden plik, a nie kopie tego pliku. Zatem wszystkie zmiany są dostępne dla wszystkich kopii aplikacji jednocześnie i natychmiastowo. Gdy jedna instancja aplikacji ma zamiar zapisać dane do pliku, używa mechanizmu blokowania i alertowania podobnego do tego, w jaki sposób klastrowe systemy plików (Clustered File Systems) umożliwiają pracę sieci SAN, gdzie może sygnalizować innym instancjom aplikacji, że zmiana jest wprowadzana i że muszą poczekać na jej zakończenie, a następnie odświeżyć swoją kopię danych przed kontynuowaniem. Tylko jedna instancja może zapisywać, a wszystkie pozostałe muszą czekać. Nie ma wyścigów o zasoby, ponieważ blokada jest uzyskiwana przed rozpoczęciem i zwalniana po zakończeniu. Wszystkie instancje działają tylko dopóki dane są aktualnie dostępne; jeśli połączenie zostanie utracone, nie są w stanie kontynuować. Jest to kluczowy mechanizm ochrony integralności danych. Niektóre aplikacje podnoszą ten mechanizm na jeszcze wyższy poziom i dodają bezpośrednie (a nie przez współdzielony plik) kanały komunikacji, aby przyspieszyć ten proces dla lepszej wydajności. Jednak niewiele posunie się aż tak daleko, ponieważ gdy osiągnie się ten poziom, generalnie o wiele łatwiej jest po prostu przejść na nowoczesną aplikację, niż próbować wtłoczyć nowoczesne systemy wieloużytkownikowe w projekty sprzed dziesięcioleci.

Mamy nadzieję, że wyjaśniło to, dlaczego księgowi mogą powszechnie myśleć, że zsynchronizowane pliki będą działać i dlaczego często twierdzą, że “u mnie działało”, gdy powinni mówić “miałem szczęście” lub “używałem tego w zupełnie innym scenariuszu, który nie ma zastosowania do środowiska wieloużytkownikowego”, oraz dlaczego absolutnie można używać Google Drive, NextCloud, iCloud, DropBox i innych z QuickBooks i innymi aplikacjami starszego typu do tworzenia kopii zapasowych i transferu danych, ale nie można próbować używać ich jako sposobu na uzyskanie dostępu wieloużytkownikowego, ponieważ po prostu nie jest możliwe zachowanie integralności danych.