1BRC: Kto Najszybciej Przetworzy Miliard Rekordów w Javie? – JVM Weekly vol. 160

1. 1BRC – Kto Najszybciej Przetworzy Miliard Rekordów w Javie?

Jak już nie raz wspominałem, grudzień zarówno mnie, jak i wielu innym członkom naszej programistycznej społeczności, przebiega pod znakiem Advent of Code – programistycznego konkursu, w którym ludzie rozwiązują każdego poranka często bardzo abstrakcyjne zadania. I o ile większość ludzi – tak jak zresztą ja – walczy o to, żeby utrzymać tempo i nie odpaść przed końcem, co większości – tak jak i zresztą mnie 🥲 – się nie udaje, o tyle każdego rodzaju zbiera się też grono pasjonatów. Ci są już tak znudzeni zajmowaniem szczytu leaderboardu, że starają się całą zabawę dodatkowo utrudnić, czy to poprzez optymalizacje całości, czy poprzez wykręcone wizualizacje (czemu na pewno sprzyjają wymyślne „fabuły” poszczególnych zadań).

Przychodzi jednak styczeń, i wydawałoby się, że wszyscy wymęczeni po grudniowych wyzwaniach. Jednak okazało się, że gdy Gunar Morling ogłosił The One Billion Row Challenge, to społeczność programistyczna obudziła się z zimowego snu i zdecydowała jeszcze raz podnieść rękawicę.

Wyzwanie „Miliard Wierszy” (1BRC) to projekt mający na celu przetestowanie wydajności nowoczesnego Java w przetwarzaniu dużych zbiorów danych, dokładnie miliarda wierszy z pliku tekstowego. Uczestnicy mogą wykorzystać wszystkie dostępne środki, takie jak wątki wirtualne, SIMD, optymalizację GC i inne triki, aby stworzyć najszybszą implementację tego zadania. Plik tekstowy zawiera dane temperatury z różnych stacji meteorologicznych, a każdy wiersz składa się z nazwy stacji i pomiaru temperatury z dokładnością do jednego miejsca po przecinku. Zadanie polega na napisaniu programu w Java, który odczyta plik, obliczy minimalną, średnią i maksymalną temperaturę dla każdej stacji, a następnie wyświetli wyniki.

Do udziału w wyzwaniu wymagane jest używanie Java 21, choć nie wyobrażam sobie raczej sytuacji, w której ktoś świadomie będzie chciał wykorzystać starszą – chyba że właśnie jako challenge. Uczestnicy muszą wczytać plik z danymi, a następnie obliczyć średnie wartości temperatur. Możliwe jest dowolne optymalizowanie programu, z zachowaniem określonych zasad, a same wyniki będą oceniane na podstawie średniej z trzech prób na dedykowanym serwerze. Uczestnicy mogą wykorzystać dowolną dystrybucje OpenJDK (już widzę przestrzeń dla każdego z vendorów), jednak nie mogą używać zewnętrznych bibliotek i muszą dostarczyć implementację w pojedynczym pliku źródłowym. Wyzwanie jest otwarte do końca stycznia 2024 roku.

Dla mnie cała sytuacja jest dowodem na dwie rzeczy. Po pierwsze, programiści lubią wyzwania, porównywanie między sobą rozwiązań – ale to chyba nie jest dla nikogo zaskoczeniem. Druga obserwacja jest nieco innej natury – cała ta otoczka świąteczna w Advent Of Codę jest fajnym, budującym klimat dodatkiem, ale zdecydowanie nie jest niezbędna. Nawet wydawałoby się banalne zadanie (wczytanie danych) może trafić na podatny grunt, jeśli tylko będzie wystarczająco wymagające, aby móc się „wyżyć”. Na ten moment już ponad 100 osób zaproponowało swoje rozwiązania.

I jeszcze jedno nawiązanie do przeszłości – tydzień temu w moim podsumowaniu rocznym zżymałem się, że Java trafia na języki społeczności programistów tylko wtedy, gdy mamy dramę pokroju zmiany pricingu czy Log4Shell. Dlatego serce rośnie kiedy człowiek widzi, że również ambitniejsze kwestie, pokroju Billion-Rows-Challenge potrafią przebić się do szerszej świadomości.

Na moment pisania tego tekstu, doczekała się ona dwóch tysięcy gwiazdek na GitHubie i ponad setki proponowanych rozwiązań, w tym min. od Thomasa Wuerthingera, twórcy GraalVM. Prowadzi obecnie Roy van Rijn, założyciel JUG Rotterdam. Polecam zapoznać się z listą rozwiązań – im wyżej góry listy, tym większa czarna magia się tam odbywa.

Co ciekawe, do zabawy przyłączają się ludzie z innych języków programowania i próbują swoich sił w kontrze z rozwiązaniami w Javie. To wyjście z banieczki bardzo cieszy – wierzę, że takie inicjatywy najlepiej pokazują, jak bardzo Java ewoluowała w ostatnich latach i że jest to język, który nie ustępuje innym, modnym rozwiązaniom jeśli chodzi o możliwości pracy na wielkich zbiorach danych.

Odkryj więcej treści IT dopasowanych do Ciebie

W aplikacji Vived znajdziesz artykuły moderowane przez developerów.
Zainstaluj teraz i czytaj tylko dobre teksty!

2. Release Radar

Phoenix – a modern template engine for Spring

Radar zaczniemy sobie dzisiaj od ciekawego projektu Springowego.

Phoenix Template Engine to pozostający we wczesnej fazie rozwoju, eksperymentalny silnik szablonów. Ma na celu ułatwienie tworzenia złożonych aplikacji internetowych poprzez dostarczenie łatwej w użyciu i zrozumiałej składni do templatingu kodu HTML generowanego po stronie backendu – tak zwanego Server-Side-Rendering (SSR).

Phoenix wyróżnia się na tle innych dostępnych silników szablonów dla Springa tym, że używa tylko jednego specjalnego znaku @ do oddzielania kodu HTML od programowalnej części szablonu i umożliwia bezpośrednie użycie Java w szablonie, eliminując potrzebę nauki nowej składni języka. Phoenix umożliwia tworzenie szablonów z użyciem konstruktorów, importowanie klas Java, definiowanie zmiennych, pętli for, instrukcji warunkowych if, a także zabezpiecza inputy przed atakami CSRF. Dodatkowo chwali się byciem szybszym i lżejszy od Thymeleaf, dzięki kompilacji plików szablonów.

W beczce miodu jest łyżka dziegciu – każdy kontroler wykorzystujący Phoenix musi dziedziczyć po klasie PhoenixController, co pewnie dla wielu osób może być przynajmniej żółtym światłem, ale za to daje kilka całkiem interesujących możliwości. Jedną z nich jest odwrócony routing, który staje się coraz popularniejszy we frameworkach frontentdowych. Oznacza to, że pozwala na dynamiczne tworzenie URL-i w naszych templatkach – zamiast na sztywno pisać href=/uzytkownik/profil/123, możesz użyć funkcji odwróconego routingu, aby wygenerować ten URL, podając nazwę konkretnego route i podanie parametru (np. ID użytkownika).

<a href="@routes.ProfileController.renderPage(123)">Go to this page</a>

Ja sobie spokojnie poczekam na stabilną wersje i się pobawię. Twórcom życzę powodzenia w rozwoju projektu!

Instancio 4.0

Instancio to biblioteka, która automatycznie tworzy i wypełnia obiekty danych testowych dla testów jednostkowych. Zamiast ręcznego przygotowywania danych testowych, Instancio pozwala na generowanie kompletnych obiektów (w tym zagnieżdżonych) i kolekcji, za pomocą jednej linijki kodu. Obiekty są wypełniane losowymi danymi, które mogą być odtworzone w przypadku błędu w teście.

Kod jest podobno warty tysiąca akapitów tekstu, więc całość używa się w następujący sposób – zamiast:

Address address  = new Address();
address.setStreet("street");
address.setCity("city");

Person person = new Person();
person.setFirstName("first-name");
person.setLastName("last-name");
person.setAddress(address);

Można po prostu stworzyć taki obiekt za pomocą poniższej fabryczki:

Person person = Instancio.create(Person.class);

Wersji 4.0 to dalsza rozbudowa przypadków brzegowych, w tym ulepszenie przypisywania metod, które umożliwia dynamiczne wypełnianie obiektów nawet bez odpowiadających im pól, co jest przydatne przy obiektach z dynamicznymi atrybutami. Dodano również wsparcie dla sekwencyjnych kolekcji w Java 21, co ułatwia manipulację danymi. Nowe API do generowania produktu kartezjańskiego pozwala na tworzenie skomplikowanych zestawów danych. Zmieniono także zachowanie generatorów stanowych w funkcji stream(), czyniąc wygenerowane obiekty całkowicie niezależnymi od siebie.

jOOQ 3.19

Jedna z najpopularniejszych bibliotek do obsługi SQL-a w Javie robi spory krok do przodu – jej darmowa wersja porzuca bowiem wsparcie dla Javy 1.8. To co prawda pozostanie, ale tylko dla użytkowników Enterprise Editon.

Co wydaje się być uczciwym podejściem. Jak na kimś zarabiać, to właśnie na legacy projektach w firmach typu Enteprise – niech ten koszt wrzucą w swoje fitness function architektury.

A firmy będą miały zdecydowanie chętkę na upgrade, ponieważ jOOQ 3.19 przynosi też kilka naprawdę przydatnych funkcji:

Explicit Path Joins Funkcja umożliwia jawne deklarowanie ścieżek dołączeń w zapytaniach
Przykład:
java<br> ctx.select(CUSTOMER.FIRST_NAME, CUSTOMER.LAST_NAME, CUSTOMER.address().city().country().NAME)<br> .from(CUSTOMER)<br> .leftJoin(CUSTOMER.address().city().country())<br> .fetch();<br>

To-Many Path Joins: Funkcja obsługuje dołączenia jeden-do-wielu przy użyciu ścieżek
java<br> ctx.select(ACTOR.FIRST_NAME, ACTOR.LAST_NAME, ACTOR.film().TITLE)<br> .from(ACTOR)<br> .leftJoin(ACTOR.film())<br> .fetch();<br>

Implicit Join Path Correlation: Funkcja ułatwia korelowanie podzapytań z zewnętrznymi zapytaniami za pomocą ścieżek

ctx.select(ACTOR.FIRST_NAME, ACTOR.LAST_NAME)
  .from(ACTOR)
  .where(exists(
      selectOne()
      .from(ACTOR.film())
      .where(ACTOR.film().TITLE.like("A%"))
  ))
  .fetch();

Każda z tych funkcji ułatwia tworzenie złożonych zapytań SQL, poprawiając czytelność kodu.