Dwie aplikacje django, jedna baza danych, czy to możliwe?

Dzień dobry.

Chciałbym aby 2 aplikacje korzystały z jednej i tej samej bazy. Jedna będzie odpowiedzialna za wyświetlanie i będzie pisać do bazy sporadycznie, w mało kluczowych tabelach, natomiast ta sama aplikacja, będzie się komunikować z drugą, która będzie przetwarzać dane i pisać do bazy w sprawach kluczowych i ważnych. Chodzi o to, że 1 aplikacja będzie na tyle prosta, że nie będzie się tam miało co zawiesić. Natomiast druga, jak się zawiesi to trzeba będzie ją ubijać, a nie chciałbym wtedy, by cały serwis padł. Czy jest możliwe, żeby 2 aplikacje korzystały z tej samej bazy? Jak rozumiem, migracje mogę wygenerować tylko w jednej? Bo w obu będą te same modele, jednak w bazie, django, przechowuje dane, które mogą się gryźć.

Jak to załagodzić?

Misio

Moim zdaniem jest to możliwe, nie ma większego znaczenia, w czym akurat piszesz aplikacje. Należy zadbać„ o to, żeby obie aplikacje wykonywały operacje w transakcjach w ten sposób, że jakaś czynność biznesowa otwiera transakcję, wykonuje czynności, a potem zamyka transakcję. Transakcje i odpowiednio wybrany poziom izolacji zapewnią, że dane nie będą się psuć w bazie danych.

Nie wiem, jaką masz bazę danych, ale w typowych bazach SQL może wystąpić deadlock w szczególnych przypadkach. Kiedyś sam się o to pytałem, akurat w kontekście MS SQL, nie wiem, jak sprawa wygląda w innych SQL.

Wstępne zablokowanie tabel i rekordów, żeby nie powstał deadlock
https://4programmers.net/Forum/Bazy_danych/279230-wstepne_blokowanie_tabel_w_transakcji_ms_sql?p=1711506#id1711506

Nadawanie priorytetów transakcji, np. aplikacja, wazniejsza, na której zablokowanie i ubijanie nie możesz sobie pozwolić, powinna mieć wyższy priorytet w transakcjach:
https://4programmers.net/Forum/Bazy_danych/344475-deadlock_w_ms_sql?p=1710977#id1710977

Architektura samej bazy danych, rozkład danych ma kluczowe znaczenie dla prawidłowej współpracy obu aplikacji. Należy wymyślić taki, żeby przy operacjach biznesowych nie było ryzyka zakleszczenia.

Możliwe. Nie wiem jak w pythonie, ale w Javie po prostu ustala sie ilość połączeń do bazy i to jakoś chroni żeby jedna baza nie zeżarła całego czasu bazy dla siebie.

UPDATE Ewentualnie rozwiazania enterprise są takie iż skoro pierwsza aplikacja głównie czyta to może pracować na replice, tylko trzeba zrobić klaster slave master. No ale to dopiero jak będziesz miał problemy wydajnościowe

UPDATE 2 ogólnie takie współdzielenie bazy źle się kojarzy bo jak cos padnie to nie wiadomo gdzie szukać, ale przez lata tak były pisane aplikacje np w Javie iż X aplikacji uderzało do wspólnej bazy i integracja [rzez bazę byął uważana nawet za dobry wzorzec

@misio_ ten case masz na myśli?

Dziękuję za odpowiedzi. Moje pytanie było ściśle związane z frameworkiem Django. Jak większość frameworków ma on mechanizm migracji. Jego owocem są nowe tabele i wpisy do istniejących tabel. Czy nie zniszczy się jej struktura, jeżeli uruchomię migracje w obu aplikacjach? W django jest np. taka tabela jak django_content_type. Zawiera ona połączenia między aplikacją a modelem

Czy nie nadpisze mi się ta tabela? I czy istniejące tabele będą wspólne dla obu aplikacji, czy migracja utworzy duplikaty?

Czy nie nadpisze mi się ta tabela? I czy istniejące tabele będą wspólne dla obu aplikacji, czy migracja utworzy duplikaty?

Jeżeli dopiero uruchamiasz nową bazę danych na potrzeby swoich apek, to co Ci szkodzi zrobić próbę i zobaczyć, co zrobi narzędzie do migracji?

Nie odpowiem na pytanie, bo to:

Natomiast druga, jak się zawiesi to trzeba będzie ją ubijać, a nie chciałbym wtedy, by cały serwis padł

sugeruje XY problem. Dlaczego miałaby się zawieszać? To nie jest aplikacja pisana przez ciebie? Obchodzisz jakiś problem architektoniczny?

Jeśli piszesz 2 nowe mikroserwisy o bardzo różnych wymaganiach SLA - to taki podział często ma sens (jeden serwis "ważny" drugi "nice to have"), ale chyba to nie ten przypadek.

@kelog serwis 2 będzie zapisywał do bazy wyniki swojej pracy, a serwis 1 będzie je czytał i pukał do 2, gdy takich danych jeszcze nie ma.

Odnośnie migracji to sprawdziłem.
Okazuje się, że żeby móc współdzielić bazę i pisać do tych samych tabel, aplikacje (nie projekty!) muszą mieć takie same nazwy.

Możliwe. Najlepiej zrób to na postgresie.