Czy byłoby dobrym pomysłem byłoby użycie Terracotta jako rozwiązania trwałości (zastąpienie bazy danych)? Zastanawiam się szczególnie nad kwestiami integralności danych i obsługą systemów transakcyjnych.O używaniu Terracotta jako rozwiązania trwałości
Terakota to transactional (bloki synchronizowane tworzą transakcje zmodyfikowanych obiektów), ale nie jest i nie chce być zgodna z JTA. Istnieje dość długa dyskusja na temat transakcji i kilka powszechnych nieporozumień dotyczących Terracotta here.
Napisałem blog post about data lifetimes i jak to powinno wpłynąć na twoje myślenie o identyfikacji możliwości wykorzystania Terracotta. W skrócie, słodka plama Terracotta jest przypadkiem, w którym potrzebujesz wytrwałości i dostępności (Twoja aplikacja może się zawiesić, ale wciąż potrzebujesz danych), ale tam, gdzie dane niekoniecznie są krytyczne długoterminowo.
Przykładem kanonicznym są dane ważne w kontekście sesji użytkownika w aplikacji internetowej, takie jak informacje o koszyku na zakupy. Chcesz zachować te dane trwałe, aby po awarii aplikacji internetowej zachować koszyk. Ale sam wózek może, ale nie musi, zostać kupiony. Przechowuje się go w Terracotta do momentu zakupu, a następnie zapisuje w bazie danych jako dane "systemu rekordów".
Historycznie rzecz biorąc, dane, które przechowywane są w bazie danych są zawsze „system nagrywania” danych, który był kluczem do długoterminowego sukcesu Twojej firmy: klientów, zamówień itp z dzisiejszym „bezpaństwowiec” architektur (który naprawdę aren bezstanowe), przenosimy wszystkie dane średnioterminowe do bazy danych. Oznacza to, że niepotrzebnie karamy naszą bazę danych (dodatkową pracą i pamięcią masową) oraz naszych programistów (którzy muszą radzić sobie z niedopasowaniem impedancji obiektowo-relacyjnej, nawet jeśli korzysta się z ORM). Lepszym rozwiązaniem jest pozostawienie go w obiektach i połączenie go z Terakotą. Wielu ostatnich użytkowników Terracotta wykorzystało tę technikę, aby znacznie zmniejszyć ślad bazy danych (oszczędzając miliony dolarów), jednocześnie zwiększając ich zdolność skalowania.
Istnieje kwestia punktu integracji z bazą danych i sposobu, w jaki należy wykonać rzetelny przekaz. Widzieliśmy to jako przypadek użycia w niedawno opublikowanej aplikacji Examinator (aplikacja sieciowa Spring/Terracotta/Tomcat/MySql). Kiedy trwają egzaminy, stan (odpowiedzi na pytania, losowe zamówienia, pytania oznaczone do recenzji) jest przechowywany w Terracotta. Ale po zakończeniu egzaminów uzyskany wynik jest obliczany i przechowywany długoterminowo w bazie danych.
Aby to zrobić bezpiecznie, stosujemy strategię klucza hibernacji, która generuje identyfikator wiersza bazy danych w obiekcie w Terracotta, a następnie zapisuje dane do bazy danych, a następnie usuwa z Terakoty. Ten scenariusz ma potencjalny stan wyścigowy, jeśli aplikacja ulegnie awarii po zapisaniu w bazie danych, ale przed usunięciem z Terakty. W takim przypadku aplikacja może spróbować ponownie zapisać dane w bazie danych, prawdopodobnie tworząc dwa wiersze. Jednak ze względu na wstępnie wygenerowany identyfikator możemy stwierdzić, czy wiersz został wcześniej pomyślnie napisany, czy też nie, i uniknąć tego problemu.
Podsumowując, nie sądzę, że Terracotta zastąpi w najbliższym czasie wasze db. Jest zbyt nowy operacyjnie, aby w takich sklepach nawet tak go traktować. Model użytkowania jest inny. W stercie nie ma możliwości zapytania ani SQL (możliwości tworzenia zapytań są zdefiniowane przez model obiektu). Myślę, że może i zaczyna zastępować wykorzystanie danych w połowie okresu, w którym jest to znacznie tańsza i łatwiejsza alternatywa. Jednak niektórzy ludzie zaczynają eksperymentować z nim w celu długoterminowego przechowywania.
Terakota to tylko Jawa. Jeśli możesz być zamknięty w tej technologii, bez możliwości pisania skryptów (bez JVM) w innych językach, to zrób to.
Artykuł Kill Your Database with Terracotta był naprawdę miły.