ElasticSearch for Time Series Data

Question

Oceniam wiele różnych baz danych NoSQL do przechowywania danych JSON szeregu czasowego. ElasticSearch jest bardzo interesujący ze względu na mechanizm zapytań, po prostu nie wiem, jak dobrze nadaje się do przechowywania danych szeregów czasowych.

Dane składają się z różnych danych i statystyk zebranych w różnych odstępach czasu od urządzeń. Każdy fragment danych jest obiektem JSON. Spodziewam się zebrać około 12 GB/dzień, ale wystarczy przechowywać dane w ES przez 180 dni.

Czy ElasticSearch byłby odpowiedni dla tych danych w porównaniu z MongoDB lub Hbase?

Answer 1

Stosowanie indeksów opartych na czasie, na przykład indeksu dziennie, wraz z funkcją indeksu i aliasu do sprawdzania wszystkich indeksów jednocześnie, może być dobrym dopasowaniem. Nadal istnieje wiele czynników, które należy wziąć pod uwagę, takich jak: - rodzaj zapytania - Struktura wymagań dotyczących dokumentu i zapytania w stosunku do tej struktury. - Kwota czyta kontra pisze - dostępność, kopie zapasowe, monitorowanie - etc

Nie jest to łatwe pytanie odpowiedzieć tak lub nie, obawiam się, trzeba zrobić więcej badań siebie, zanim tak naprawdę powiedzieć, że jest to najlepsze narzędzie do pracy.

Answer 2

Możesz przeczytać w przykładzie użycia serii ElasticSearch z użyciem przykładów: here.

Ale myślę, że kolumnowe bazy danych lepiej pasują do twoich wymagań.

Rozumiem, że ElasticSearch działa najlepiej, gdy zapytania zwracają niewielki podzbiór wyników, i buforuje takie parametry, które zostaną użyte później. Jeśli te same parametry zostaną użyte ponownie w zapytaniach, może wykorzystać te wyniki z pamięci podręcznej w połączeniu, dzięki czemu wyniki są naprawdę szybkie. Jednak w danych szeregów czasowych zwykle trzeba agregować dane, co oznacza, że ​​będziesz przechodzić wiele wierszy i kolumn razem. Takie zachowanie jest dość uporządkowane i łatwe do modelowania, w którym to przypadku nie wydaje się, aby ElasticSearch działał lepiej niż w kolumnowych bazach danych. Z drugiej strony może zapewniać łatwość obsługi, mniej tuningu itp., Z których wszystkie mogą sprawić, że będzie bardziej preferowany.

Bazy kolumnowe zazwyczaj zapewniają bardziej wydajną strukturę danych dla szeregów czasowych. Jeśli twoje struktury zapytań są znane z dużym wyprzedzeniem, możesz użyć Cassandry. Pamiętaj, że jeśli twoje zapytania będą prośby bez użycia klucza podstawowego, Cassandra nie będzie działać. Może być konieczne utworzenie różnych tabel z tymi samymi danymi dla różnych zapytań, ponieważ szybkość odczytu zależy od sposobu zapisywania na dysku. Musisz nauczyć się jego zawiłości, przykładem serii czasowej jest here.

Inną kolumnową bazą danych, którą można wypróbować, jest rozszerzenie kolumnowe przewidziane dla PostgreSQL. Biorąc pod uwagę, że twój maksymalny rozmiar bazy danych wynosi około 180 * 12 = 2,16 TB, ta metoda powinna działać idealnie i może być najlepszą opcją. Możesz także oczekiwać znacznej kompresji rozmiaru około 3x. Możesz dowiedzieć się więcej na ten temat here.