w czasie rzeczywistym kwerendy/agregowanie milionów rekordów - hadoop? hbase? Kasandra?

Question

Mam rozwiązanie, które można zsynchronizować, ale nie mam (jeszcze) doświadczenia z hadoop/nosql i nie jestem pewien, które rozwiązanie jest najlepsze dla moich potrzeb. Teoretycznie, gdybym miał nieograniczoną liczbę procesorów, moje wyniki powinny natychmiast wrócić. Tak więc każda pomoc będzie doceniona. Dzięki!

Oto co mam:

• 1000S zbiorów danych
• klucze Dataset:
  • wszystkich zbiorów danych mają takie same klucze
  • 1 milion klucze (może później być 10 lub 20 milionów)
• Kolumn zestawu danych:
  
  • każdy zbiór danych ma te same kolumny
  • 10 do 20 kolumn
  • większość kolumny są wartości liczbowe dla której musimy zsumować na (średnio, OdchStd i używać R obliczyć statystykę)
  • kilka kolumn „type_id” kolumny, ponieważ w danym zapytaniu możemy chcą tylko zawierać pewne type_ids
• aplikacji internetowych
  
  • użytkownik może wybrać, które dane osobowe ETS są zainteresowani (w dowolnym miejscu od 15 do 1000)
  • aplikacja musi przedstawić: klucz, a zagregowane wyniki (AVG, OdchStd) każdej kolumnie
• aktualizacje danych:
  • cały zestawu danych można dodać, upuścić lub wymienić/zaktualizować
  • byłoby fajnie, aby móc dodawać kolumny. Ale jeśli to konieczne, może po prostu zastąpić cały zestaw danych.
  • nigdy dodać wiersze/klucze do zbioru danych - więc nie potrzebny jest system z wieloma szybko pisze
• infrastruktura:
  
  • obecnie dwie maszyny z 24 rdzeni każdy
  • końcu chcą możliwość również uruchomić to na Amazon

nie mogę wcześniej obliczyć moje zagregowane wartości, ale ponieważ każdy klawisz i Niezależna, powinna być łatwo skalowalna. Obecnie mam te dane w bazie danych postgres, gdzie każdy zestaw danych znajduje się we własnej partycji.

• partycje są ładne, ponieważ można łatwo dodać/drop/wymienić partycje
• baza danych jest miłe dla filtrowania na podstawie type_id
• bazy danych nie są łatwe do pisania równoległe zapytaniami
• baz danych są dobre dla uporządkowany dane, a moje dane nie są skonstruowane

Jako dowód koncepcji starałem się Hadoop:

• stworzyliśmy kartę oddzielone plik za zbiorze danych dla danej type_id
• przesłanym do HDFS
• mapę: pobierana jest wartość/kolumny dla każdego kluczowego
• ograniczenia: obliczona średnia i odchylenie standardowe

Od mój prymitywny proof-of-concept, widzę, że to ładnie się skaluje, ale widzę, że hadoop/hdfs ma opóźnienie Czytałem, że generalnie nie jest ono używane do kwerend w czasie rzeczywistym (mimo że jestem w porządku z powrotem wyników z powrotem do użytkowników w 5 sekund).

Wszelkie sugestie dotyczące tego, jak powinienem się do tego podejść? Zastanawiałem się, czy nie spróbować HBase'a, żeby to wyczuć. Czy powinienem raczej spojrzeć na Hive? Cassandra? Voldemort?

dziękuję!

Answer 1

Ula lub świnia nie wydają się być pomocne. Zasadniczo każdy z nich kompiluje się do jednego lub więcej zadań mapowania/zmniejszania, więc odpowiedź nie może być w ciągu 5 sekund.

HBase może działać, chociaż twoja infrastruktura jest trochę mała dla optymalnej wydajności. Nie rozumiem, dlaczego nie można wstępnie obliczać statystyk podsumowujących dla każdej kolumny. Powinieneś spojrzeć na średnie wartości obliczeniowe, abyś nie musiał zmniejszać wagi ciężkiej.

Wyjazd http://en.wikipedia.org/wiki/Standard_deviation

OdchStd (X) = sqrt (E [X^2] - (E [X])^2)

Oznacza to, że można uzyskać OdchStd AB wykonując

sqrt (E [AB^2] - (E [AB])^2). E [AB^2] to (suma (A^2) + suma (B^2))/(| A | + | B |)

Answer 2

Jest to poważny problem bez dobrego rozwiązania w przestrzeni open source. W przestrzeni komercyjnej powinny działać bazy danych MPP, takie jak greenplum/netezza. Idealnie potrzebowałbyś Google'a Dremel (silnik za BigQuery). Rozwijamy klon open source, ale zajmie to trochę czasu ... Niezależnie od używanego silnika, myślę, że rozwiązanie powinno obejmować przechowywanie całego zbioru danych w pamięci - powinno dać wyobrażenie o tym, jakiego rozmiaru klastra potrzebujesz.

Answer 3

Jeśli rozumiem zostanie poprawnie i trzeba tylko agregują na pojedynczych kolumn naraz Można przechowywać swoje dane w różny sposób dla uzyskania lepszych rezultatów w HBase że będzie wyglądać tabeli na kolumnie danych w dzisiejszym konfiguracji i kolejny singiel tabela dla pól filtrujących (type_ids) wiersz dla każdego klucza w dzisiejszej konfiguracji - możesz chcieć pomyśleć o włączeniu pól filtru do klucza w celu wydajnego filtrowania - w przeciwnym razie musiałbyś wykonać odczyt dwufazowy ( dla każda tabela w dzisiejszej konfiguracji (np. kilka tysięcy kolumn) HBase nie ma nic przeciwko dodawaniu nowych kolumn i jest rzadki w tym sensie, że nie przechowuje danych dla kolumn, które nie istnieją. Gdy przeczytasz wiersz, otrzymasz całą istotną wartość, którą możesz zrobić średnio. itp. całkiem łatwo

Answer 4

Ponieważ twoje dane wydają się być prawie jednorodne, na pewno przyjrzę się Google BigQuery - Możesz spożywać i analizować dane bez kroku MapReduce (z twojej strony), a RESTful API pomoże tworzysz aplikację internetową na podstawie zapytań. W rzeczywistości, w zależności od tego, jak chcesz zaprojektować swoją aplikację, możesz stworzyć dość "realną" aplikację.

Answer 5

Do tego celu może być użyta zwykła stara baza danych. To nie brzmi tak, jakbyś miał system transakcyjny. W rezultacie prawdopodobnie możesz użyć tylko jednego lub dwóch dużych tabel. SQL ma problemy, gdy trzeba dołączyć do dużych danych. Ale ponieważ twój zestaw danych nie brzmi tak, jakbyś musiał się przyłączyć, powinieneś być w porządku. Możesz ustawić indeksy, aby znaleźć zestaw danych i albo zrobić w SQL lub w matematyce aplikacji.