W poprzednim poście napisałem o problemach z niebywale dużym zużyciem CPU podczas operacji zapisu do datastore Google App Engine. Od kilku dni zastanawiałem się, jak zaradzić temu problemowi – rozwiązanie znalazłem i zaimplementowałem dosłownie przed chwileczką.

Struktura rekordu z danymi zapisywany podczas zapytania do API była dość rozgałęziona – coś w stylu drzewa o 3 poziomach na drugim poziomie około 3-4 rekordów – na kolnym po około 2-3 dla każdego elementu z poziomu wyżej. Co ważne, żaden z elementów poniżej głównego rekordu nie był używany w zapytaniach.

Po kilku nieudanych próbach ograniczenia ilości zapisywanych danych postanowiłem zapisać obiekty poniżej głównego rekordu jako pole serializowane. Takie pole zapisywane jest jako BLOB, i Google App Engine używa standardowej serializacji Java.

Wystarczy dodać adnotację @Persistent(serialized = “true”, defaultFetchGroup = “true”) oraz upewnić się, że wszystkie klasy składające się na elementy pola implementują interfejs Serializable.

Przed zamianą pola na serializowalny obiekt, używając hierarchii referencji zapytanie zajmowało średnio około 8-10 sekund czasu API datastore. Po zmianach – to samo zapytanie, serializując obiekty do BLOB’a zajmuje już tylko 2-3 sekundy API. Więc było warto… Co warte odnotowania – ilość zapytań (na kiepskim internecie, z laptopa) wzrosła z 2 do 4 na sekundę.

Ale uwaga, są pewne konsekwencje. Zmiany w obiektach serializowalnych muszą gwarantować kompatybilność – gdyż datastore będzie po prostu próbował zdeserializować bajty z pola BLOB na nową strukturę obiektów, co może spowodować błędy.

Warto również przeczytać ten wpis na blogu Google, zaoszczędzi on dużo czasu, jeżeli będziemy zastanawiali się dlaczego zmiany do pola serializowanego nie są odzwierciedlane w bazie danych – z pewnością datastore nie wykrył zmian, i uaktualnienie referencji do serializowanego pola pomoże zlikwidować problemy.