Złożone zapytania za pomocą datastore GAE

Question

Jestem na wczesnym etapie tworzenia strony statystyk sportowych (ostateczna frisbee) i chciałbym poznać twoje opinie, jeśli Google App Engine jest odpowiedni dla mnie.

Piszę to w Pythonie używając Django i od lat czuję się komfortowo ze standardowymi RDBMS, ale ta strona jest projektem długoterminowym i spodziewam się bardzo dużej ilości danych, więc chciałbym "nieskończonego" skalowania, które GAE oferty datastore. Ogromna większość zapytań do bazy danych zwróci bardzo standardowe wyniki, które sprawiają, że datastore wydaje się logicznym wyborem. Chciałbym jednak móc w przyszłości wykonywać niezwykle złożone zapytania, aby wymyślić nowe dane statystyczne lub po prostu wymyślić interesujące wyniki. Planuję zrobić dużo tego w przyszłości, ale nie będę wiedział, jakie są te zapytania, dopóki dane nie zostaną już zebrane.

Na przykład często widzisz analityków statystyk baseballowych, którzy wymyślają absurdalne statystyki, takie jak "To jest tylko pierwszy raz w ciągu ostatnich 50 lat, że dwóch leworęcznych dzbanów, których nazwiska zaczynają się od" Z ", rzuciło jeden raz hit shutouts w dni powracające do tyłu ". Chciałbym mieć elastyczność w podejmowaniu jakichkolwiek pytań w przyszłości. :)

Mam jednak wrażenie, że nierelacyjna baza danych, taka jak bigtable, wymaga wcześniejszego opracowania modeli zawierających nadmiarowe dane, a cała praca odbywa się na insertach, a nie w pobieraniu. Zbudowałem już modele django, które zawierałyby praktycznie wszystkie dane, których potrzebuję do zapytania, ale nie mam pojęcia, jakie denormalizowane modele będę potrzebować od roku lub dwóch. Dlatego mam wrażenie, że tworzenie złożonych zapytań w przyszłości byłoby niezwykle trudne w magazynie danych GAE i wymagałoby ode mnie wyciągnięcia mnóstwa informacji z serwera przed przetworzeniem go w pythonie.

Czy dane magazynu aplikacji wyszukiwarki Google są po prostu złe dla tego, co chcę zrobić? Albo po prostu czegoś brakuje. Dziękuję bardzo z góry!

Dzięki za odpowiedzi do tej pory. Zdaję sobie sprawę, że muszę również wspomnieć, że wiele z tych złożonych zapytań to zapytania, które chciałbym, aby użytkownicy mogli wykonywać, co czyni z bazy danych offline naprawdę nierealną opcję. Na przykład, użytkownicy powinni mieć dostęp do różnych statystyk dotyczących tego, jak dobrze dwoje dwóch konkretnych graczy gra, gdy są na polu w tym samym czasie w określonych grach lub porach roku. Chociaż zapytania te nie są tak częste jak standardowe statystyki zagregowane, nadal będą występować z regularnością.

Posiadanie relacyjnej bazy danych, a także bazy danych GAE, byłoby wspaniałe, ale django domyślnie nie obsługuje wielu baz danych, a łatanie rozwiązania razem wydaje się trudne i niechlujne. Eric Florenzano ma numer nice solution dla dwóch baz danych, które używają modeli django, ale gdybym miał użyć magazynu danych GAE, musiałbym zamiast tego użyć modelu db silnika aplikacji. A znalezienie dobrego rozwiązania, takiego jak w przypadku tego złożonego problemu, jest w tym momencie nieco poza moim poziomem umiejętności.

Obecnie moje ulubione dwie opcje używają kolejki zadań GAE do wykonywania trudnych zapytań lub przechodzenia do bardziej standardowego webhostingu, takiego jak webfaction, a następnie denormalizują moje tabele później, gdy moje dane będą rosły i potrzebuję zwiększyć wydajność.

Answer 1

To, co opisujesz, to zasadniczo OLAP - Online Analytical Processing. OLAP to jedna rzecz, z której "tradycyjne" RDBMS są bardzo dobre, częściowo ze względu na elastyczność i moc SQL - a nierelacyjne bazy danych, takie jak magazyn danych App Engine, nie są. To brzmi jak twoje zapytań OLAP typu będzie stosunkowo rzadkie w porównaniu do normalnego dostępu, choć, więc sugeruję jedną z dwóch metod:

• Lustro wszystkie dane z App Engine magazynu danych do relacyjnej bazy danych w odstępach i wykonywać zapytania analityczne w relacyjnej bazie danych. Ruch danych użytkownika jest nadal obsługiwany przez magazyn danych, więc masz wszystkie zalety tego, ale masz kopię offline, z którą możesz wykonywać złożone zapytania.
• Obsługa obsługi kolejki zadań App Engine w celu wykonywania zapytań sprawdzających duże zestawy danych. Możesz napisać zapytanie w języku Python lub Java, a następnie użyć Kolejki zadań, aby wykonać je w bardzo dużym zestawie danych, i po zakończeniu odbierać wyniki asynchronicznie. Oczywiście jest trochę pracy wymagającej infrastruktury, aby było to łatwe (ale miej oko na my blog dla przyszłego projektu z tym związanego;).

Answer 2

Powiedziałbym, że przechowywanie typu bigtable jest mniej odpowiednie dla aplikacji statystycznych, z samych powodów, o których wspominasz. Ale to jest klasyczny handel, który musisz zrobić. Rzadko zdarzało mi się korzystać z elastyczności bardzo skomplikowanych zapytań, ale wiele razy byłem zmuszony wymyślić bardziej wyspecjalizowane rozwiązania dla rzeczy, które w ogóle nie powinny być w bazie danych.

Jeśli pozostaniesz przy RDBMS, możesz zrobić logiczne partycjonowanie i denormalizację dość łatwo np. Poprzez strategie wytrwałości Hibernatesa i Hibernate Shards. Jeśli możesz żyć z nieco wolniejszym przetwarzaniem, możesz również wykonywać kwerendy SQL w pamięci typu bigtable (zobacz na przykład hadoop pig latin).

Answer 3

Magazyn danych GAE to zupełnie inne zwierzę niż RDBMS. Jest łatwy w relacyjnej DB napisać coś takiego:

SELECT STDEV(player_score) 
FROM Table 
WHERE player_id = 1234 
    AND game_date BETWEEN '2007-01-01' AND '2009-11-10' 
    AND city <> 'London' 

GAE kwerenda ma wiele ograniczeń - see here - więc nie jest łatwo przetłumaczyć. W przypadku funkcji agregujących (sum, stdev, itp.) Należy przeciągnąć wszystkie dane do warstwy aplikacji i obliczyć lub utrzymywać zagregowane jednostki, które aktualizują każdą wstawienie/aktualizację danych.

Aktualizacja
Można rozważyć użycie GAE dla interfejsu użytkownika i logiki biznesowej, ale mający odrębną relacyjnej DB gdzieś indziej w chmurze, takich jak: Microsoft SQL, DB2, MySQL na Amazon gdzie indziej - i danych niż przy użyciu GAE-sklep dla wstępnie obliczone agregacje i statystyki. Więc statystyki są nadal obliczane w RDBMS, ale przechowujesz wyniki (częściowe, wstępnie obliczone statystyki) w pamięci GAE; podobne do przechowywania wymiarowego w kostkach analitycznych.

Answer 4

Chcę wspierać odniesienie MindWire do korzystania z Google CloudSQL.

Mój obecny projekt faktycznie działa z magazynu danych, głównie z większą liczbą zadań SQL wykonywanych w Cloud SQL.

Refernce Docs for App Engine Python SDK