2010-03-11 8 views
5

Potrzebuję przechowywać dużą liczbę małych obiektów danych (miliony wierszy na miesiąc). Gdy zostaną zapisane, nie będą się zmieniać. Muszę:Bezpłatna hurtownia danych - Infobright, Hadoop/Hive lub co?

  • przechowywać je bezpiecznie
  • ich używać do analizy (głównie czasu zorientowanych)
  • odzyskać niektóre dane surowe sporadycznie
  • Byłoby miło, gdyby mógł być używany z JasperReports lub BIRT

Mój pierwszy strzał był Infobright Społeczność - tylko kolumna zorientowane tylko do odczytu mechanizm przechowywania MySQL

Z drugiej strony, ludzie mówią, że podejście NoSQL może być lepsze. Hadoop + Hive wygląda obiecująco, ale dokumentacja wygląda marnie, a numer wersji jest mniejszy niż 1.0.

Słyszałem o Hypertable, Pentaho, MongoDB ....

Czy masz jakieś zalecenia?

(Tak, znalazłem kilka tematów, ale to było rok czy dwa lata temu)

Edit: Inne rozwiązania: MonetDB, InfiniDB, LucidDB - Co o tym sądzisz?

+0

Numer wersji nie jest ważny. HDFS/Hadoop działają dobrze - ale są interesujące tylko, jeśli masz kilka węzłów na dane i analizy. – Leonidas

+0

Jeśli chcesz szybki start, polecam używanie pentaho i bazy danych obsługujących pentaho. Myślę, że odpowiedzi poniżej koncentrują się bardziej na dostępie do danych, ale w rozwoju hurtowni danych ważne są również narzędzia. – elprup

+0

@Piotr: To jest dwuletnie pytanie bez odpowiedzi. Potrzebuję rozwiązania mającego prawie te same specyfikacje. Co zdecydowałeś się użyć na końcu? –

Odpowiedz

0

Jeśli szukasz kompatybilności z narzędziami do raportowania, najlepszym rozwiązaniem może być coś na bazie MySQL. Jeśli chodzi o to, co będzie dla Ciebie skuteczne, Infobright może działać. Istnieje również kilka innych rozwiązań, jednak możesz również zajrzeć do zwykłego MySQL i tabeli Archive. Każdy rekord jest skompresowany i przechowywany, a IIRC jest przeznaczony do twojego rodzaju pracy, jednak myślę, że Infobright powinien uzyskać lepszą kompresję. Tak naprawdę nie używałem żadnej z nich, więc nie jestem pewien, która z nich będzie dla ciebie najlepsza.

Jeśli chodzi o magazyny klucz-wartość (np. NoSQL), tak, mogą one również działać i istnieje wiele alternatyw. Wiem, że CouchDB ma "widoki", ale nie miałem okazji ich użyć, więc nie wiem, jak dobrze któryś z nich działa.

Moja jedyna troska związana z Twoim zestawem danych polega na tym, że od czasu, o którym wspomniałeś, możesz chcieć, aby każde używane rozwiązanie pozwoliło na archiwizowanie danych po pewnym czasie. Częstą praktyką hurtowni danych jest przechowywanie tylko N miesięcy danych online i archiwizowanie pozostałych. W tym miejscu bardzo przydatne jest partycjonowanie zaimplementowane w RDBMS.

2

Można również rozważyć GridSQL. Nawet dla pojedynczego serwera można tworzyć wiele "węzłów" logicznych, aby wykorzystać wiele rdzeni podczas przetwarzania zapytań.

GridSQL używa PostgreSQL, więc możesz również skorzystać z tabel partycjonowania w podtabelatach w celu szybszej oceny zapytań. Wspomniałeś, że dane są zorientowane na czas, więc byłby to dobry kandydat do tworzenia podtytułów.

+0

Po prostu dodam, tak, pracuję dla EnterpriseDB , który sponsoruje GridSQL. – Mason

+0

Wygląda na to, że GridSQL zmarł niedawno, a deweloperzy przenieśli się do Stado. –

3

Mam ten sam problem i przeprowadziłem badania; dwa typy magazynów dla BI:

  • zorientowana kolumnowo. Darmowe i znane: monetDB, LucidDb, Infobright.InfiniDB
  • Ukazuje: hTable Cassandra (również kolumna zorientowane teoretycznie)
  • dokumentu zorientowany/MongoDB, CouchDB

Odpowiedź zależy od tego, czego naprawdę potrzebujesz:

http://www.mysqlperformanceblog.com/2010/01/07/star-schema-bechmark-infobright-infinidb-and-luciddb/

  • Jeśli wiersze są dodawane w czasie rzeczywistym .. następnie kolumna zorientowane DB są złe. Możesz wybrać jedną z dwóch oddzielnych DB (to mój wybór: jeden noSQL do prawdziwego podawania statystyk z przodu i statystyki w czasie rzeczywistym.) Inne kolumny DB zorientowane na BI). Lub skręć w stronę czegoś, co miesza kolumny (na żądanie) i dystrybucji (do pisania)/jak Cassandra.

zorientowane Dokumentu DB nie nadają się do BI, są bardziej przydatne do zagadnień CRM/CMS gdzie trzeba częstego dostępu do danego rzędu

chodzi o dokładny wybór wewnątrz kategorii, nadal jestem niezdecydowany. Cassandra w dystrybucji i Monet lub InfiniDB dla CODB, są liderami. Monet ma problem z ładowaniem bardzo dużych tabel, ponieważ uruchamia indeksy w pamięci.

Powiązane problemy