Jak myśleć w magazynach danych zamiast w bazach danych?

Na przykład Google App Engine używa Google Datastore, a nie standardowej bazy danych, do przechowywania danych. Czy ktoś ma jakieś wskazówki dotyczące korzystania z Google Datastore zamiast baz danych? Wygląda na to, że wytrenowałem umysł, aby myśleć w 100% w relacjach obiektowych, które odwzorowują bezpośrednio na struktury tabel, a teraz ciężko jest zobaczyć coś innego. Rozumiem niektóre zalety Google Datastore (np. Wydajność i zdolność do dystrybucji danych), ale niektóre dobre funkcje bazy danych są poświęcone (np. Przyłączenia).

Czy ktoś, kto współpracował z Google Datastore lub BigTable, ma jakieś dobre rady dotyczące współpracy z nimi?

Istnieją dwie główne rzeczy, do których należy się przyzwyczaić w magazynie danych App Engine w porównaniu do „tradycyjnych” relacyjnych baz danych:

• Magazyn danych nie rozróżnia wstawień i aktualizacji. Gdy wywołasz metodę put () na encji, encja ta jest zapisywana w magazynie danych z unikalnym kluczem, a wszystko, co ma ten klucz, zostaje nadpisane. Zasadniczo każdy rodzaj encji w magazynie danych działa jak ogromna mapa lub posortowana lista.
• Zapytanie, jak wspomniałeś, jest znacznie bardziej ograniczone. Na początek nie dołącza.

Kluczową rzeczą do zrealizowania - i przyczyną obu tych różnic - jest to, że Bigtable zasadniczo działa jak ogromny uporządkowany słownik. Zatem operacja put ustawia tylko wartość dla danego klucza - niezależnie od jakiejkolwiek poprzedniej wartości dla tego klucza, a operacje pobierania ograniczają się do pobierania pojedynczych kluczy lub ciągłych zakresów kluczy. Bardziej zaawansowane zapytania są możliwe dzięki indeksom, które są w zasadzie tylko własnymi tabelami, co pozwala na implementację bardziej złożonych zapytań, takich jak skanowanie w sąsiadujących zakresach.

Po przyswojeniu tego masz podstawową wiedzę potrzebną do zrozumienia możliwości i ograniczeń magazynu danych. Ograniczenia, które mogły wydawać się arbitralne, prawdopodobnie mają większy sens.

Kluczową rzeczą jest to, że chociaż są to ograniczenia dotyczące tego, co można zrobić w relacyjnej bazie danych, te same ograniczenia sprawiają, że praktyczne jest skalowanie do wielkości, którą Bigtable jest w stanie obsłużyć. Po prostu nie można wykonać zapytania, które wygląda dobrze na papierze, ale jest okropnie wolne w bazie danych SQL.

Jeśli chodzi o sposób zmiany sposobu reprezentowania danych, najważniejsze jest wstępne obliczenie. Zamiast wykonywać sprzężenia w czasie zapytania, wstępnie oblicz dane i przechowuj je w magazynie danych, o ile to możliwe. Jeśli chcesz wybrać losowy rekord, wygeneruj losową liczbę i zapisz ją z każdym rekordem. Jest cała książka kucharska z tych rodzaju porad i wskazówek tutaj Edycja: książka kucharska nie jest już w istnieniu.

Sposób, w jaki podchodziłem do zmiany umysłu, to całkowite zapomnienie o bazie danych.

W relacyjnym świecie db zawsze musisz martwić się o normalizację danych i strukturę tabeli. Porzuć to wszystko. Po prostu ułóż swoją stronę internetową. Rozłóż je wszystkie. Teraz spójrz na nie. Już tam jesteś 2/3.

Jeśli zapomnisz, że rozmiar bazy danych ma znaczenie, a dane nie powinny być duplikowane, to jesteś tam 3/4 i nawet nie musiałeś pisać żadnego kodu! Niech twoje poglądy dyktują Twoje modele. Nie musisz już brać swoich obiektów i uczynić z nich dwuwymiarowych, jak w świecie relacyjnym. Możesz teraz przechowywać obiekty z kształtem.

Tak, jest to uproszczone wytłumaczenie tej próby, ale pomogło mi zapomnieć o bazach danych i po prostu stworzyć aplikację. Do tej pory stworzyłem 4 aplikacje App Engine, korzystając z tej filozofii i jest ich więcej.

Zawsze chichoczę, kiedy ludzie wychodzą - to nie jest relacja. Napisałem cellectr w django, a poniżej fragment mojego modelu. Jak zobaczysz, mam ligi, które są zarządzane lub trenowane przez użytkowników. Mogę z ligi uzyskać wszystkich menedżerów, a od danego użytkownika mogę zwrócić ligę, którą trenuje lub menedżerów.

To, że nie ma określonej obsługi klucza obcego, nie oznacza, że ​​nie możesz mieć modelu bazy danych z relacjami.

Moje dwa pensy.

class League(BaseModel):
    name = db.StringProperty()    
    managers = db.ListProperty(db.Key) #all the users who can view/edit this league
    coaches = db.ListProperty(db.Key) #all the users who are able to view this league

    def get_managers(self):
        # This returns the models themselves, not just the keys that are stored in teams
        return UserPrefs.get(self.managers)

    def get_coaches(self):
        # This returns the models themselves, not just the keys that are stored in teams
        return UserPrefs.get(self.coaches)      

    def __str__(self):
        return self.name

    # Need to delete all the associated games, teams and players
    def delete(self):
        for player in self.leagues_players:
            player.delete()
        for game in self.leagues_games:
            game.delete()
        for team in self.leagues_teams:
            team.delete()            
        super(League, self).delete()

class UserPrefs(db.Model):
    user = db.UserProperty()
    league_ref = db.ReferenceProperty(reference_class=League,
                            collection_name='users') #league the users are managing

    def __str__(self):
        return self.user.nickname

    # many-to-many relationship, a user can coach many leagues, a league can be
    # coached by many users
    @property
    def managing(self):
        return League.gql('WHERE managers = :1', self.key())

    @property
    def coaching(self):
        return League.gql('WHERE coaches = :1', self.key())

    # remove all references to me when I'm deleted
    def delete(self):
        for manager in self.managing:
            manager.managers.remove(self.key())
            manager.put()
        for coach in self.managing:
            coach.coaches.remove(self.key())
            coaches.put()            
        super(UserPrefs, self).delete()    

Pochodzę ze świata Relational Database, a potem znalazłem ten magazyn danych. zrozumienie go zajęło kilka dni. cóż, niektóre z moich ustaleń.

Musisz już wiedzieć, że magazyn danych jest zbudowany na skalę i to właśnie go oddziela od RDMBS. Aby skalować lepiej przy użyciu dużego zestawu danych, App Engine dokonał pewnych zmian (niektóre oznaczają wiele zmian).

Struktura magazynu danych RDBMS VS.
W bazie danych zwykle strukturyzujemy nasze dane w tabelach. Wiersze znajdujące się w magazynie danych stają się rodzajami i jednostkami .

Relacje
W RDBMS, większość ludzi przestrzega relacji jeden do jednego, wiele do jednego, wiele do wielu, w magazynie danych, ponieważ ma „Brak połączeń”, ale nadal możemy osiągnąć naszą normalizację za pomocą „ ReferenceProperty „np . przykład relacji jeden do jednego .

Indeksy
Zwykle w RDMBS tworzymy indeksy, takie jak klucz główny, klucz obcy, klucz unikalny i klucz indeksu, aby przyspieszyć wyszukiwanie i zwiększyć wydajność naszej bazy danych. W magazynie danych musisz utworzyć co najmniej jeden indeks dla każdego rodzaju (automatycznie wygeneruje to, czy ci się to podoba, czy nie), ponieważ magazyn danych przeszukuje twoją jednostkę na podstawie tych indeksów i uwierz mi, że to najlepsza część. W RDBMS możesz wyszukiwać za pomocą pole nieindeksowane, choć zajmie to trochę czasu, ale będzie. W magazynie danych nie można wyszukiwać za pomocą właściwości nieindeksowanej.

Policz
W RDMBS łatwiej jest liczyć (*), ale w magazynie danych, nawet nie myśl o tym w normalny sposób (tak, istnieje funkcja zliczania), ponieważ ma limit 1000 i będzie kosztować tyle samo małych operacji, co jednostka, która nie jest dobre, ale zawsze mamy dobry wybór, możemy użyć Liczników Odłamków .

Unikalne ograniczenia
W RDMBS, kochamy tę funkcję, prawda? ale Datastore ma swoją własną drogę. nie można zdefiniować właściwości jako unikalnej :(.

Kwerenda
GAE Datatore zapewnia lepszą funkcjonalność LIKE (o nie! Magazyn danych nie ma LIKE słowa kluczowego) SQL, którym jest GQL .

Wstawianie / aktualizowanie / usuwanie / wybieranie danych
To miejsce, w którym wszyscy jesteśmy zainteresowani, ponieważ w RDMBS potrzebujemy jednego zapytania o wstawianie, aktualizację, usuwanie i wybieranie, tak jak RDBMS, magazyn danych umieścił, usunął, dostał (nie bądź zbyt podekscytowany), ponieważ magazyn danych umieścić lub uzyskać w zakresie zapisu, odczytu, małych operacji ( koszty odczytu w przypadku wywołań do magazynu danych ) i to tam, gdzie rozpoczyna się modelowanie danych. musisz zminimalizować te operacje i utrzymać działanie aplikacji. Do operacji zmniejszania odczytu możesz użyć Memcache .

Spójrz na dokumentację Objectify. Pierwszy komentarz na dole strony mówi:

„Fajnie, chociaż napisałeś to, aby opisać Objectify, jest to również jedno z najbardziej zwięzłych wyjaśnień samego magazynu danych aplikacji, jakie kiedykolwiek czytałem. Dziękuję.”

https://github.com/objectify/objectify/wiki/Concepts

Jeśli jesteś przyzwyczajony do myślenia o obiektach odwzorowanych na ORM, to w zasadzie tak działa magazyn danych oparty na bytach, taki jak Google App Engine. Dla czegoś takiego jak złączenia, możesz spojrzeć na właściwości referencyjne . Naprawdę nie musisz się martwić, czy używa BigTable jako backendu, czy czegoś innego, ponieważ backend jest abstrakcyjny przez interfejsy GQL i API Datastore.

Sposób, w jaki patrzę na magazyn danych, to rodzaj identyfikuje tabelę per se, a jednostka to pojedynczy wiersz w tabeli. Gdyby Google wyjął coś innego niż tylko jeden duży stół bez struktury i możesz zrzucić wszystko, co chcesz w jednostce. Innymi słowy, jeśli encje nie są powiązane z rodzajem, możesz mieć dowolną strukturę do encji i przechowywać ją w jednym miejscu (rodzaj dużego pliku bez struktury, każda linia ma własną strukturę).

Wracając do oryginalnego komentarza, Google DataStore i Bigtable to dwie różne rzeczy, więc nie mylić Google Data Store z sensem przechowywania danych. Bigtable jest droższy niż bigquery (główny powód, dla którego nie poszliśmy z nim). Bigquery ma odpowiednie sprzężenia i RDBMS, takie jak język sql i jest tańszy, dlaczego nie użyć bigquery. Biorąc to pod uwagę, bigquery ma pewne ograniczenia, w zależności od rozmiaru twoich danych, które możesz napotkać lub nie.

Ponadto, jeśli chodzi o myślenie w odniesieniu do magazynu danych, myślę, że właściwym stwierdzeniem byłoby „myślenie w oparciu o bazy danych NoSQL”. Obecnie jest ich zbyt wiele, ale jeśli chodzi o produkty Google oprócz Google Cloud SQL (czyli mySQL), wszystko inne to NoSQL.

Będąc zrootowanym w świecie baz danych, magazyn danych byłby dla mnie gigantyczną tabelą (stąd nazwa „bigtable”). BigTable jest jednak złym przykładem, ponieważ robi wiele innych rzeczy, których typowa baza danych może nie zrobić, a mimo to jest bazą danych. Są szanse, chyba że wiesz, że musisz zbudować coś takiego jak „Bigtable” Google, prawdopodobnie będziesz w porządku ze standardową bazą danych. Potrzebują tego, ponieważ przetwarzają razem szalone ilości danych i systemów, a żaden komercyjnie dostępny system nie jest w stanie wykonać zadania dokładnie tak, jak potrafiłby wykazać, że musi to zrobić.

(odniesienie do Bigtable: http://en.wikipedia.org/wiki/BigTable )