Przetwarzanie danych na dużą skalę Hbase vs Cassandra [zamknięte]

Prawie wylądowałem na Cassandrze po moich badaniach nad rozwiązaniami do przechowywania danych na dużą skalę. Ale ogólnie mówi się, że Hbase jest lepszym rozwiązaniem do przetwarzania i analizy danych na dużą skalę.

Chociaż oba są tym samym magazynem kluczy / wartości i oba są / mogą działać (ostatnio Cassandra) warstwa Hadoop, to co sprawia, że ​​Hadoop jest lepszym kandydatem, gdy wymagane jest przetwarzanie / analiza dużych danych.

Znalazłem również dobre szczegóły na temat obu na http://ria101.wordpress.com/2010/02/24/hbase-vs-cassandra-why-we-moved/

ale wciąż szukam konkretnych zalet Hbase.

Chociaż jestem bardziej przekonany o Cassandrze ze względu na prostotę dodawania węzłów i bezproblemową replikację oraz brak funkcji punktu awarii. Zachowuje również funkcję dodatkowego indeksu, więc jest to dobry plus.

Próba ustalenia, która z nich jest dla ciebie najlepsza, naprawdę zależy od tego, do czego ją wykorzystasz, każda z nich ma swoje zalety i bez dalszych szczegółów staje się bardziej wojną religijną. Ten post, o którym wspomniałeś, ma również ponad rok i od tego czasu przeszedł wiele zmian. Proszę również pamiętać, że nie znam najnowszych osiągnięć Cassandry.

Powiedziawszy to, sparafrazuję Andrew Purtella, który jest odpowiedzialny za HBase i dodam kilka moich własnych doświadczeń:

• HBase znajduje się w większych środowiskach produkcyjnych (1000 węzłów), chociaż nadal jest to typowe dla instalacji ~ 400 węzłów Cassandry, więc jest to naprawdę marginalna różnica.

• Zarówno HBase, jak i Cassandra obsługują replikację między klastrami / centrami danych. Uważam, że HBase udostępnia użytkownikowi więcej, więc wydaje się bardziej skomplikowany, ale wtedy zyskujesz także większą elastyczność.

• Jeśli Twoja aplikacja potrzebuje silnej spójności, prawdopodobnie lepiej pasuje HBase. Został zaprojektowany od podstaw, aby był spójny. Na przykład pozwala na prostszą implementację liczników atomowych (myślę, że Cassandra właśnie je dostała), a także operacji Check and Put.

• Wydajność pisania jest świetna, z tego, co rozumiem, był to jeden z powodów, dla których Facebook zdecydował się na HBase dla swojego komunikatora.

• Nie jestem pewien aktualnego stanu zamówionego partycjonera Cassandry, ale w przeszłości wymagało to ręcznego ponownego równoważenia. Jeśli chcesz, HBase zajmie się tym za Ciebie. Zamówiony partycjoner jest ważny dla przetwarzania w stylu Hadoop.

• Cassandra i HBase są złożone, Cassandra po prostu lepiej to ukrywa. HBase eksponuje go bardziej, używając HDFS do przechowywania, jeśli spojrzysz na bazę kodu, Cassandra jest tak samo warstwowa. Jeśli porównasz dokumenty Dynamo i Bigtable, zobaczysz, że teoria działania Cassandry jest w rzeczywistości bardziej złożona.

• HBase ma więcej testów jednostkowych FWIW.

• Wszystkie RPC Cassandra to Thrift, HBase ma Thrift, REST i natywną Javę. Thrift i REST oferują tylko podzbiór całkowitego interfejsu API klienta, ale jeśli chcesz czystej szybkości, dostępny jest natywny klient Java.

• Zarówno peer to peer, jak i master to slave mają zalety. Konfiguracja master-slave ogólnie ułatwia debugowanie i redukuje trochę złożoności.

• HBase nie jest powiązany tylko z tradycyjnym HDFS, możesz zmienić bazową pamięć masową w zależności od potrzeb. MapR wygląda dość interesująco i słyszałem dobre rzeczy, chociaż sam z niego nie korzystałem.

Jako programista Cassandra lepiej odpowiadam na drugą stronę pytania:

• Cassandra lepiej się skaluje. Wiadomo, że Cassandra skaluje się do ponad 400 węzłów w klastrze ; kiedy Facebook wdrożył Messaging na bazie HBase, musiał podzielić go na 100-węzłowe podklastry HBase .
• Cassandra obsługuje setki, a nawet tysiące rodzin ColumnFamilies. „ HBase obecnie nie radzi sobie dobrze z czymkolwiek powyżej dwóch lub trzech rodzin kolumn ”.
• Jako w pełni rozproszony system bez „specjalnych” węzłów lub procesów , Cassandra jest prostsza w konfiguracji i obsłudze , łatwiejsza do rozwiązywania problemów i bardziej niezawodna.
• Obsługa Cassandry dla replikacji z wieloma wzorcami oznacza, że ​​nie tylko uzyskujesz oczywistą moc wielu centrów danych - nadmiarowość geograficzną, lokalne opóźnienia - ale możesz także podzielić obciążenia w czasie rzeczywistym i obciążenia analityczne na oddzielne grupy, z replikacją dwukierunkową w czasie rzeczywistym między nimi . Jeśli nie rozdzielisz tych obciążeń, będą walczyć spektakularnie.
• Ponieważ każdy węzeł Cassandra zarządza własnym magazynem lokalnym, Cassandra ma znaczną przewagę w zakresie wydajności, która prawdopodobnie nie zostanie znacząco zawężona. (Np. Standardową praktyką jest umieszczanie dziennika zatwierdzenia Cassandry na oddzielnym urządzeniu, aby mógł wykonywać swoje sekwencyjne zapisy bez przeszkód przez losowe operacje we / wy z żądań odczytu).
• Cassandra pozwala wybrać, jak silna ma wymagać spójności w poszczególnych operacjach. Czasami jest to błędnie rozumiane jako „Cassandra nie zapewnia silnej spójności”, ale to nieprawda.
• Cassandra oferuje RandomPartitioner, a także bardziej podobny do Bigtable OrderedPartitioner. RandomPartitioner jest znacznie mniej podatny na gorące punkty.
• Cassandra oferuje buforowanie na stosie lub poza nim z wydajnością porównywalną do memcached, ale bez problemów ze spójnością pamięci podręcznej lub złożoności wymagającej dodatkowych ruchomych części
• Klienci inni niż Java nie są obywatelami drugiej kategorii

O ile mi wiadomo, główną zaletą HBase w tej chwili (HBase 0.90.4 i Cassandra 0.8.4) jest to, że Cassandra nie obsługuje jeszcze przezroczystej kompresji danych. (Zostało to dodane dla Cassandry 1.0 , planowane na początek października, ale dziś jest to prawdziwa zaleta dla HBase.) HBase może być również lepiej zoptymalizowana pod kątem rodzajów skanów zakresu wykonywanych przez przetwarzanie wsadowe Hadoop.

Są też rzeczy, które niekoniecznie są lepsze lub gorsze, po prostu inne. HBase ściśle przestrzega modelu danych Bigtable, w którym każda kolumna jest niejawnie wersjonowana. Cassandra porzuca wersjonowanie i zamiast tego dodaje SuperColumns.

Mam nadzieję, że to pomoże!

Powodem używania klastrów hBase 100 węzłów nie jest to, że HBase nie skaluje się do większych rozmiarów. Dzieje się tak, ponieważ łatwiej jest wykonywać aktualizacje oprogramowania hBase / HDFS w sposób ciągły bez wyłączania całej usługi. Innym powodem jest zapobieganie temu, by pojedynczy NameNode był SPOFem dla całej usługi. Ponadto HBase jest używany w różnych usługach (nie tylko w komunikatach FB) i rozsądne jest podejście ograniczające pliki cookie do konfigurowania wielu klastrów HBase w oparciu o podejście 100-węzłowe. Liczba 100 jest ad hoc, nie skupialiśmy się na tym, czy 100 jest optymalne, czy nie.