Baza danych bez schematu / elastyczna + ACID?

Zastanawiam się nad przepisaniem aplikacji lokalnej VB (zainstalowanej lokalnie) (fakturowanie + inwentaryzacja) jako aplikacji Clojure dla małych firm. Zamierzam to zaoferować jako aplikację SaaS dla klientów w podobnych branżach.

Patrzyłem na opcje bazy danych: Moim wyborem był RDBMS: Postgresql / MySQL. Mogę skalować do 400 użytkowników w pierwszym roku, z zwykle 20-40 odsłonami na dzień na użytkownika - głównie w przypadku transakcji, które nie są widokami statycznymi. Każdy widok będzie wymagał pobierania danych i aktualizacji danych. Zgodność z ACID jest konieczna (a przynajmniej tak mi się wydaje). Więc wolumen transakcji nie jest ogromny.

Wybór jednego z nich na podstawie moich preferencji byłby oczywisty, ale w przypadku tego jednego wymagania, które moim zdaniem jest typowe dla aplikacji SaaS: schemat będzie się zmieniać wraz z dodawaniem większej liczby klientów / użytkowników i dla każdego klienta zmiana wymagań biznesowych (będę oferować pewną ograniczoną elastyczność tylko na początek). Ponieważ nie jestem ekspertem od DB, w oparciu o to, co mogę myśleć i czytać, mogę sobie z tym poradzić na wiele sposobów:

1. Posiadaj tradycyjny projekt schematu RDBMS w MySQl / Postgresql z jednym DB obsługującym wielu najemców. I dodaj wystarczającą liczbę swobodnie zmieniających się kolumn w każdej tabeli, aby umożliwić przyszłe zmiany w miarę dodawania kolejnych klientów lub zmian dla istniejącego klienta. Może to mieć wadę propagowania zmian w bazie danych za każdym razem, gdy wprowadzana jest niewielka zmiana w schemacie. Pamiętam, że czytałem, że w schemacie Postgresql aktualizacje można wykonywać w czasie rzeczywistym bez blokowania. Ale nie jestem pewien, jak bolesne lub praktyczne w tym przypadku użycia. A także, ponieważ zmiany schematu mogą również wprowadzać nowe / drobne zmiany SQL.
2. Posiadaj RDBMS, ale projektuj schemat bazy danych w elastyczny sposób: z wartością zbliżoną do atrybutu encji lub po prostu jako magazyn klucz-wartość. (Na przykład dzień roboczy, FriendFeed)
3. Miej wszystko w pamięci jako obiekty i okresowo przechowuj je w plikach dziennika (np. Edval, lmax)
4. Wybierz DB NoSQL, takie jak MongoDB lub Redis. Ale w oparciu o to, co mogę zebrać, nie nadają się do tego przypadku użycia i nie są w pełni zgodne z ACID.
5. Wybierz niektóre DBS NewSQL, takie jak VoltDb lub JustoneDb (oparte na chmurze), które zachowują zachowanie zgodne z SQL i ACID i są RDBMS „nowej generacji”.
6. Patrzyłem na neo4j (graphdb), ale nie jestem pewien, czy to pasuje do tego przypadku użycia

W moim przypadku zastosowania, oprócz skalowalności lub przetwarzania rozproszonego, szukam lepszego sposobu na osiągnięcie „Elastyczności w schemacie + ACID + pewnej rozsądnej wydajności”. Większość artykułów, które mogłem znaleźć w sieci, mówi o elastyczności schematu jako przyczynie prowadzącej do wydajności (w przypadku baz danych NoSQL) i skalowalności, pomijając stronę ACID / Transakcje.

Czy jest to przypadek „albo” albo „transakcji schematu vs ACID”, czy jest lepsze wyjście?

opcja 1

Istnieje kilka powodów, które wyjaśnię poniżej. Po pierwsze, oto jak to zrobić.

• Skorzystaj z wyboru standardowej platformy RDBMS.

• Skonfiguruj schemat z kilkoma konfigurowalnymi przez użytkownika polami i spraw, aby aplikacja ułatwiała konfigurację dla poszczególnych dzierżawców.

• Na podstawie metadanych dla najemcy można utworzyć widok dla ich najemcy z wbudowanymi filtrami i kolumnami nazwanymi z metadanych. Wszelkie dostarczone raporty mogą również dziedziczyć metadane. Jeśli chcą zrobić MI poza danymi, dostarcz im wyciąg danych transakcyjnych, a może jakąś dodatkową aplikację MIS na innym serwerze, jeśli zapłacą za to.

• Nie próbuj zapewniać większej liczby dostosowań niż to (tj. Bez radykalnych zmian w schemacie), chyba że klient jest przygotowany na zapłacenie za własną prywatną instancję i utrzymanie niestandardowej kompilacji.

Przyczyny tego są:

• Te systemy baz danych będą obsługiwać rodzaj woluminów, które opisujesz na dość zwykłym sprzęcie. Tak naprawdę nie ma takiej wielkości transakcji, która zasługuje na bazę danych NoSQL. Jeśli nie masz innego architektonicznego powodu, aby go chcieć, nie ma sensu wybierać się na najnowocześniejsze rozwiązania.

• Są dojrzałymi, dobrze zrozumiałymi technologiami.

• Zarządzanie systemem, tworzenie kopii zapasowych / przywracanie, replikacja, raportowanie i odzyskiwanie po awarii są dobrze posortowane na platformach RDBMS.

• Możesz pobrać biblioteki klienta, w tym JDBC dla wszystkich głównych platform RDBMS.

• Widoki mogą być używane do dostosowywania poszczególnych użytkowników i generowane z metadanych aplikacji.

• Jest znacznie wydajniejszy niż pola XML lub struktury EAV.

Dzięki PostgreSQL masz możliwość korzystania z oddzielnych baz danych, oddzielnych schematów lub widoków w celu obsługi wielu najemców.

Korzystanie z wielu baz danych (na tym samym serwerze bazy danych) sprawia, że ​​administracja jest bardziej złożona, ponieważ każdą bazą danych należy zarządzać indywidualnie. Dlatego jest to wskazane tylko wtedy, gdy bezpieczeństwo między najemcami jest sprawą najwyższej wagi.

Oddzielne schematy oferują dużą elastyczność i bezpieczeństwo, ale komplikują aktualizacje, ponieważ muszą być stosowane indywidualnie i prawdopodobnie są konieczne tylko wtedy, gdy dzierżawcy używają zupełnie innych struktur tabel; co jest mało prawdopodobne, jeśli używają tej samej aplikacji.

Widoki pozwalają dzierżawcom zobaczyć różne części wspólnej struktury tabel i pozwalają kontrolować, które tabele, kolumny i wiersze mają dostęp. Jedynym zastrzeżeniem jest to, że aplikacja musi upewnić się, że używa tylko tych widoków, a nie tabel podstawowych, w przeciwnym razie istnieje ryzyko przypadkowych wycieków danych między najemcami z powodu wad oprogramowania.

Tak naprawdę nie trzeba tworzyć kolumn przed wymaganiami aplikacji. Kolumny można dynamicznie dodawać do tabel (bez zauważalnego wpływu na użytkowników), a widoki można również dynamicznie aktualizować. Trzeba tylko pomyśleć o kolejności wprowadzania zmian - tj. zmień tabele, następnie widoki, a następnie kod aplikacji.

Twoim jedynym potencjalnym problemem jest to, czy musisz dodać nową kolumnę, którą należy dodać do istniejącego indeksu lub wymaga nowego indeksu. To jest, kiedy tabela może zostać zablokowana przed użyciem podczas budowania indeksu - ale PostgreSQL obsługuje możliwość jednoczesnego budowania indeksów bez blokowania tabeli. Działa to dobrze, chyba że nowy indeks musi być unikalny i znajdzie naruszenie wyjątkowości.

Prawdopodobnie nie potrzebujesz bazy danych NoSQL, ponieważ skutecznie usuwają one schemat z bazy danych i zamiast tego wymagają aplikacji do zarządzania nim. Nie brzmi to tak, jakby twoje tomy wymagały tego rodzaju poświęcenia.