Kiedy NIE należy używać Cassandry?


199

Ostatnio dużo mówi się o Cassandrze .

Używają go Twitter, Digg, Facebook itp.

Kiedy ma sens:

  • użyj Cassandry,
  • nie używać Cassandry i
  • użyj RDMS zamiast Cassandry.

7
Prawdopodobnie powinno być CW? Jest to w zasadzie tylko NoSQL vs. Relacyjne bazy danych, co jest dość subiektywnym IMO.
Ed James

3
Chciałbym wiedzieć, czy nadaje się do systemu przesyłania wiadomości. Zakładam, że jeśli Twitter go użyje, to będzie w porządku, ale mogą nie używać go na wszystkich Twitterze?
Luke

Odpowiedzi:


164

Nie ma to jak srebrna kula, wszystko zbudowane jest w celu rozwiązania konkretnych problemów i ma swoje zalety i wady. Od Ciebie zależy, jakie stwierdzenie problemu masz i jakie jest najlepsze rozwiązanie tego problemu.

Postaram się odpowiadać na pytania jeden po drugim w tej samej kolejności, w jakiej je zadałeś. Ponieważ Cassandra jest oparta na rodzinie baz danych NoSQL, ważne jest, aby zrozumieć, dlaczego warto korzystać z bazy danych NoSQL, zanim odpowiem na pytania.

Dlaczego warto korzystać z NoSQL

W przypadku RDBMS dokonanie wyboru jest dość łatwe, ponieważ wszystkie bazy danych, takie jak MySQL, Oracle, MS SQL, PostgreSQL w tej kategorii, oferują prawie takie same rozwiązania ukierunkowane na właściwości ACID. Jeśli chodzi o NoSQL, decyzja staje się trudna, ponieważ każda baza danych NoSQL oferuje różne rozwiązania i musisz zrozumieć, która z nich najlepiej pasuje do twoich wymagań aplikacji / systemu. Na przykład MongoDB nadaje się do zastosowań, w których system wymaga magazynu dokumentów bez schematu. HBase może być odpowiedni do wyszukiwarek, analiz danych dziennika lub dowolnego miejsca, w którym wymagane jest skanowanie ogromnych, dwuwymiarowych tabel bez łączenia. Redis został zbudowany w celu wyszukiwania w pamięci różnych struktur danych, takich jak drzewa, kolejki, listy połączone itp., I może dobrze pasować do tworzenia tabel liderów w czasie rzeczywistym, systemu podobnego do pubu. Podobnie istnieją inne bazy danych w tej kategorii (w tym Cassandra), które nadają się do różnych stwierdzeń problemów. Teraz przejdźmy do oryginalnych pytań i odpowiedzmy na nie po kolei.

Kiedy stosować Cassandra

Będąc częścią rodziny NoSQL, Cassandra oferuje rozwiązanie problemów, w których jednym z twoich wymagań jest posiadanie bardzo ciężkiego systemu zapisu, a chcesz mieć dość responsywny system raportowania oprócz przechowywanych danych. Rozważ przypadek użycia analityki internetowej, w której dane dziennika są przechowywane dla każdego żądania, a chcesz zbudować wokół niego platformę analityczną do zliczania odwiedzin na godzinę, według przeglądarki, adresu IP itp. W czasie rzeczywistym. Możesz odnieść się do tego postu na blogu, aby dowiedzieć się więcej o przypadkach użycia, w których pasuje Cassandra.

Kiedy używać RDMS zamiast Cassandry

Cassandra jest oparta na bazie danych NoSQL i nie zapewnia właściwości ACID i relacyjnych danych. Jeśli masz silne wymagania dotyczące właściwości ACID (na przykład dane finansowe), Cassandra nie byłaby w tym przypadku odpowiednia. Oczywiście można to obejść, ale w końcu napiszesz dużo kodu aplikacji, aby zasymulować właściwości ACID i stracisz na czasie, aby źle sprzedawać. Również zarządzanie tego rodzaju systemem za pomocą Cassandry byłoby dla Ciebie skomplikowane i uciążliwe.

Kiedy nie należy używać Cassandry

Nie sądzę, że należy na nie odpowiedzieć, jeśli powyższe wyjaśnienie ma sens.


1
Problem z odpowiedzią polega na tym, że łączy wszystkie rozwiązania NoSQL razem. Więcej informacji można znaleźć na stronie dataconomy.com/sql-vs-nosql-need-know W krajobrazie NoSQL podstawowe podziały to dokument, klucz-wartość, wykres i duża tabela. Mają różne cechy charakterystyczne dla różnych problemów. Rozwiązanie, które jest dobre dla mongo, może nie być dobre dla Cassandry.
Yehosef

17
Jedynym sposobem, w jaki ta odpowiedź „łączy wszystkie rozwiązania NoSQL razem” jest kategoria NoSQL; poza tym post znakomicie wskazuje, że każda baza danych NoSQL „oferuje inne rozwiązanie” dla różnych problemów. Nie miałem wrażenia, że ​​autor nawet nieznacznie wskazał, że mongo, cassandra lub jakakolwiek inna baza danych NoSQL rozwiązuje te same problemy.
Nick Suwyn

NoSQL databaseto nie jest rzecz. NoSQLjest tylko terminem używanym w przypadku nowoczesnych nierelacyjnych baz danych (patrz wiki ).
eddyP23

2
Zauważ też, że nie wszystkie bazy danych NoSQL nie są ACID. Wykresy DB są zwykle ACID.
eddyP23

Cassandra obsługuje operacje atomowe na poziomie wiersza oraz atomową i izolację na partycję przy użyciu niewielkich transakcji. Jeśli moim wymaganiem jest posiadanie ACID na poziomie wiersza, czy nie mogę używać Cassandry? Nawet w przypadku krytycznych danych?
TechEnthusiast

52

Oceniając rozproszone systemy danych, należy wziąć pod uwagę twierdzenie CAP - możesz wybrać dwa z poniższych: spójność, dostępność i tolerancję partycji.

Cassandra jest dostępnym systemem tolerującym partycje, który wspiera ostateczną spójność. Więcej informacji można znaleźć w tym poście na blogu: Visual Guide to NoSQL Systems .


Kiedy ostatni raz widziałeś partycję, w której obie partycje były duże? Zobacz moje pytanie stackoverflow.com/questions/7969874/…
Aaron Watters

5
Cassandra najwyraźniej pozwala również określić wymagania dotyczące spójności w czasie zapytania, co może być użytecznym kompromisem w niektórych przypadkach użycia
Richard Marr

30

Cassandra jest odpowiedzią na konkretny problem: co robisz, gdy masz tyle danych, że nie mieszczą się one na jednym serwerze? Jak przechowujesz wszystkie dane na wielu serwerach i nie psujesz konta bankowego i nie doprowadzasz programistów do szaleństwa? Facebook dostaje 4 terabajty nowych skompresowanych danych KAŻDEGO DNIA. Liczba ta najprawdopodobniej wzrośnie ponad dwukrotnie w ciągu roku.

Jeśli nie masz tak dużo danych lub masz miliony, aby zapłacić za instalację klastra Oracle Oracle / DB2 i specjalistów wymaganych do jej skonfigurowania i obsługi, nie masz problemu z bazą danych SQL.

Jednak Facebook nie używa już Cassandry, a teraz MySQL prawie wyłącznie przenosi partycjonowanie w górę w stosie aplikacji dla szybszej wydajności i lepszej kontroli.


27

Ogólna idea NoSQL polega na tym, że powinieneś używać dowolnego magazynu danych, który najlepiej pasuje do Twojej aplikacji. Jeśli masz tabelę danych finansowych, użyj SQL. Jeśli masz obiekty wymagające skomplikowanych / wolnych zapytań do odwzorowania na schemat relacyjny, użyj obiektu lub magazynu kluczy / wartości.

Oczywiście prawie każdy problem w prawdziwym świecie, z którym się spotkasz, znajduje się gdzieś pomiędzy tymi dwiema skrajnościami i żadne z tych rozwiązań nie będzie idealne. Musisz wziąć pod uwagę możliwości każdego sklepu i konsekwencje używania jednego nad drugim, które będą bardzo ściśle związane z problemem, który próbujesz rozwiązać.


3
Schemat prawdopodobnie nie ulegnie zmianie, dobrze wpasowuje się w strukturę tabeli, a utrata / niespójność danych może powodować prawdziwe problemy.
Tom Clarkson

4
Nie rozumiem, dlaczego niespójne dane mogą powodować prawdziwe problemy z bankami. Scenariusz: masz jedno konto bankowe z limitem 100 USD powyżej i dwie karty bankowe. Kiedy spróbujesz wypłacić pieniądze za pomocą dwóch kart jednocześnie w 2 różnych bankomatach, otrzymasz 2 razy 100 USD i list z dodatkową opłatą w skrzynce pocztowej. Bank zarabia pieniądze (dodatkowa opłata za przekroczenie limitu) za pomocą niespójnych danych. Trudno jest połączyć wszystkie bankomaty na świecie za pośrednictwem jednej dużej relacyjnej bazy danych. Czy możesz podać przykład, w którym niespójne dane finansowe mogą stanowić problem?
Paco

5
Wszystko to składa się z COBOL-a i przetwarzania wsadowego i nie jest tak dobrze zaprojektowane / stabilne, jak mogłoby się wydawać. Bankomaty nie łączą się z żadnym zunifikowanym magazynem danych, więc nie są dobrym przykładem. To tak, jakby powiedzieć, że SQL nie jest odpowiedni dla aplikacji internetowych, ponieważ nie można zapewnić wszystkim w Internecie bezpośredniego dostępu do bazy danych. Poza tym nigdy nie mówiłem nic o bankach - myślę o zamówieniach na stronie e-commerce, gdzie nie musisz zajmować się tak konserwatywną organizacją, że SQL jest uważany za nowy i niezaufany.
Tom Clarkson

6
@Paco: Pierwszy bankomat odczytuje saldo (100 USD), a drugi bankomat robi to samo. Oba bankomaty odejmują 100 USD od 100 USD i zapisują saldo końcowe 0 USD z powrotem na konto. Wynik: bank traci 100 USD.
Seun Osewa

9
@Paco: Chodzi o to, że bez odpowiedniej izolacji transakcji normalny bank nawet nie będzie wiedział, że konto zostało przelane. Nawet się nie dowiedzą.
Seun Osewa

14

Poza powyższymi odpowiedziami na temat tego, kiedy używać, a kiedy nie używać Cassandry, jeśli zdecydujesz się użyć Cassandry, możesz rozważyć nieużywanie samej Cassandry, ale jednego z jej wielu kuzynów.

Niektóre powyższe odpowiedzi wskazywały już na różne systemy „NoSQL”, które mają wiele właściwości z Cassandrą, z pewnymi niewielkimi lub dużymi różnicami, i mogą być lepsze niż sama Cassandra do twoich konkretnych potrzeb.

Ponadto niedawno (kilka lat po pierwotnym zadaniu tego pytania ) został wydany klon Cassandra o nazwie Scylla (patrz https://en.wikipedia.org/wiki/Scylla_(database) ). Scylla jest ponowną implementacją Cassandry w C ++, która twierdzi, że ma znacznie wyższą przepustowość i mniejsze opóźnienia niż oryginalna Java Cassandra, przy czym jest w większości zgodna z nią (pod względem funkcji, interfejsów API i formatów plików). Więc jeśli już zastanawiasz się nad Cassandrą, możesz również rozważyć Scyllę.


9

Rozmowa z kimś w trakcie wdrażania Cassandry nie radzi sobie dobrze z wieloma do wielu. Robią hakowanie, aby przeprowadzić wstępne testy. Rozmawiałem o tym z konsultantem Cassandrą i powiedział, że nie poleciłby tego, gdybyś miał ustawiony ten problem.


4

Powinieneś zadać sobie następujące pytania:

  1. (Tom, prędkość) Czy będziesz pisać i czytać TONY informacji, tak wiele informacji, że żaden komputer nie poradziłby sobie z zapisami.
  2. (Globalny) Czy będziesz potrzebować tej zdolności do pisania i czytania na całym świecie, aby zapisy w jednej części świata były dostępne w innej części świata?
  3. (Niezawodność) Czy potrzebujesz, aby ta baza danych działała cały czas i nigdy nie działała bez względu na to, która chmura, w jakim kraju, czy to VM, kontenerze czy gołym metalu?
  4. (Możliwość skalowania) Czy potrzebujesz tej bazy danych, aby móc nadal łatwo się rozwijać i skalować liniowo
  5. (Spójność) Czy potrzebujesz spójności TUNABLE, gdy niektóre zapisy mogą się odbywać asynchronicznie, a inne wymagają certyfikacji?
  6. (Umiejętność) Czy chcesz zrobić wszystko, aby nauczyć się tej technologii i modelowania danych, które towarzyszą tworzeniu globalnie rozproszonej bazy danych, która może być szybka dla wszystkich, wszędzie?

Jeśli na którekolwiek z tych pytań pomyślałeś „może” lub „nie”, powinieneś użyć czegoś innego. Jeśli odpowiedziałeś „piekło tak” na wszystkie z nich, powinieneś użyć Cassandry.

Użyj RDBMS, gdy możesz zrobić wszystko na jednym urządzeniu. Jest to prawdopodobnie łatwiejsze niż większość i każdy może z tym pracować.


3

Ciężkie pojedyncze zapytanie vs. obciążenie gazillionowe lekkie zapytanie to kolejny punkt do rozważenia, oprócz innych odpowiedzi tutaj. Z natury trudniej jest automatycznie zoptymalizować pojedyncze zapytanie w bazie danych w stylu NoSql. Użyłem MongoDB i napotkałem problemy z wydajnością podczas próby obliczenia złożonego zapytania. Nie korzystałem z Cassandry, ale spodziewam się, że będzie miał ten sam problem.

Z drugiej strony, jeśli spodziewane jest obciążenie bardzo wielu małych zapytań i chcesz mieć możliwość łatwego skalowania, możesz skorzystać z ostatecznej spójności oferowanej przez większość baz danych NoSql. Zauważ, że ostateczna spójność nie jest tak naprawdę cechą nierelacyjnego modelu danych, ale o wiele łatwiej jest ją wdrożyć i skonfigurować w systemie opartym na NoSql.

W przypadku pojedynczego, bardzo ciężkiego zapytania dowolny nowoczesny silnik RDBMS może wykonać przyzwoitą pracę równolegle do części zapytania i wykorzystać tyle procesora i pamięci, ile w niego wrzucisz (na jednym komputerze). Bazy danych NoSql nie mają wystarczającej ilości informacji o strukturze danych, aby móc przyjąć założenia, które umożliwią naprawdę inteligentną równoległość dużego zapytania. Pozwalają na łatwe skalowanie większej liczby serwerów (lub rdzeni), ale gdy zapytanie osiągnie poziom złożoności, jesteś w zasadzie zmuszony do ręcznego podzielenia go na części, z którymi silnik NoSql wie, jak postępować inteligentnie.

Z mojego doświadczenia z MongoDB, ostatecznie ze względu na złożoność zapytania, Mongo niewiele mógł zrobić, aby go zoptymalizować i uruchomić jego części na wielu danych. Mongo równolegle wiele zapytań, ale nie jest tak dobry w optymalizacji jednego.


3

Przeczytajmy kilka prawdziwych przypadków:

http://planetcassandra.org/apache-cassandra-use-cases/

W tym artykule: http://planetcassandra.org/blog/post/agentis-energy-stores-over-15-billion-records-of-time-series-usage-data-in-apache-cassandra

Opracowali powód, dla którego nie wybrali MySql, ponieważ synchronizacja db jest zbyt wolna.

(Również z powodu zatwierdzenia 2-frazowego, FK, PK)


Cassandra oparta jest na papierze Amazon Dynamo

Cechy:

Stabilność

Duża dostępność

Kopia zapasowa działa dobrze

Odczyt i zapis jest lepszy niż HBase (klon BigTable w Javie).

wiki http://en.wikipedia.org/wiki/Apache_Cassandra

Ich wniosek jest następujący:

We looked at HBase, Dynamo, Mongo and Cassandra. 

Cassandra was simply the best storage solution for the majority of our data.

Od 2018 r.

Polecam użycie ScyllaDB zamiast klasycznej Cassandra, jeśli potrzebujesz wsparcia z tyłu.

Wtyczka Postgres kv jest również szybsza niż Cassandra. Jednak nigdy nie będzie miał skalowalności wielu instancji.


Nie musisz zadowolić się tylko jedną technologią baz danych. Możesz faktycznie mieć kombinację i używać tego, co jest odpowiednie dla konkretnego problemu.
Pepito Fernandez,

3

Skoncentruję się tutaj na niektórych ważnych aspektach, które mogą pomóc ci zdecydować, czy naprawdę potrzebujesz Cassandry. Lista nie jest wyczerpująca, tylko niektóre kwestie, które mam na myśli -

  • Nie traktuj Cassandry jako pierwszego wyboru, jeśli masz ścisłe wymagania dotyczące relacji (w całym zestawie danych).

  • Cassandra domyślnie jest systemem AP (CAP). Ale obsługuje regulowaną spójność, co oznacza, że ​​można go skonfigurować do obsługi również jako CP. Więc nie ignoruj ​​tego tylko dlatego, że czytasz gdzieś, że to AP i szukasz systemów CP. Cassandra jest bardziej precyzyjnie określana jako „dostrajająco spójna”, co oznacza, że ​​pozwala łatwo zdecydować, jaki poziom spójności potrzebujesz, w równowadze z poziomem dostępności.

  • Nie używaj Cassandry, jeśli twoja skala nie jest duża lub jeśli możesz poradzić sobie z nierozproszoną bazą danych.

  • Zastanów się, czy Twój zespół myśli, że wszystkie problemy zostaną rozwiązane, jeśli użyjesz rozproszonych baz danych, takich jak Cassandra. Rozpoczęcie od tych baz danych jest bardzo proste, ponieważ zawiera wiele domyślnych ustawień, ale optymalizacja i opanowanie go w celu rozwiązania określonego problemu wymagałoby dużego (jeśli nie dużego) wysiłku inżynieryjnego.

  • Cassandra jest zorientowana na kolumny, ale jednocześnie każdy wiersz ma również unikalny klucz. Warto więc pomyśleć o tym jak o indeksowanym sklepie zorientowanym na wiersze. Możesz nawet użyć go jako magazynu dokumentów.

  • Cassandra nie zmusza cię do wcześniejszego zdefiniowania pól. Więc jeśli jesteś w trybie uruchamiania lub twoje funkcje ewoluują (jak w zwinnym) - Cassandra to obejmuje. Więc lepiej, najpierw pomyśl o zapytaniach, a następnie pomyśl o danych, aby na nie odpowiedzieć.

  • Cassandra jest zoptymalizowana pod kątem naprawdę wysokiej przepustowości zapisu. Jeśli Twój przypadek użycia jest obciążony odczytem (jak pamięć podręczna), Cassandra może nie być idealnym wyborem.


2

inną sytuacją, która ułatwia wybór, jest to, że gdy chcesz użyć funkcji agregujących, takich jak suma, min, maks., itp. i złożonych zapytań (jak w systemie finansowym wspomnianym powyżej), relacyjna baza danych jest prawdopodobnie wygodniejsza niż baza danych nosql, ponieważ oba są nie jest to możliwe w przypadku bazy danych nosql, chyba że użyjesz naprawdę wielu indeksów odwróconych. Kiedy używasz nosql, musiałbyś wykonywać funkcje agregujące w kodzie lub przechowywać je osobno w swojej własnej rodzinie kolumn, ale to wszystko sprawia, że ​​wszystko jest dość złożone i zmniejsza wydajność, którą zyskałeś używając nosql.


Na przykład CouchdB pozwala bardzo łatwo obliczać funkcje agregujące: wiki.apache.org/couchdb/… . Technicznie rzecz biorąc, jest to „w kodzie”, ale nie jest aż tak „skomplikowane”, jak w przypadku Cassandry.
user359996,

2
Właściwie zgadzam się, że napisanie agregatu w kodzie może zająć dzień, ale możesz napisać go, aby działał na serwerze zaplecza, który będzie korzystał z prawie 0 cykli bazy danych. Dzięki bazie danych SQL otrzymasz wynik zapisania jednego wiersza, co może zająć 5 minut. ale spowalnia całą bazę danych przy każdym uruchomieniu. Istnieją więc zalety i wady obu sposobów. Na przykład mój bank zamyka dostęp do stron w środku nocy na około 10–15 minut. Z pewnością używają COBOL, ale to bardzo podobny problem.
Alexis Wilke

1

Jeśli potrzebujesz w pełni spójnej bazy danych z semantyką SQL, Cassandra NIE jest rozwiązaniem dla Ciebie. Cassandra obsługuje wyszukiwanie kluczowych wartości. Nie obsługuje zapytań SQL. Dane w Cassandrze są „w końcu spójne”. Jednoczesne wyszukiwania danych mogą być niespójne, ale ostatecznie wyszukiwania są spójne.

Jeśli potrzebujesz ścisłej semantyki i potrzebujesz obsługi zapytań SQL, wybierz inne rozwiązanie, takie jak MySQL, PostGres lub połącz użycie Cassandry z Solr.


1
Cassandra Query Language (CQL) jest jednak bardzo podobna do SQL. W rzeczywistości powiedziałbym, że CQL jest przewagą Cassandry nad innymi opcjami NoSQL dla tych, którzy szukają interfejsu podobnego do SQL.
arussell84

1
Cassandra nie jest ostatecznie technicznie spójna. Cassandra pozwala na kompromis w zakresie dostępności. Cassandra zasadniczo równoważy twierdzenie CAP. Możesz mieć w końcu spójny zapis, a następnie spójny odczyt, odwrotnie lub spójny w obu przypadkach, a wszystko to zależy od współczynnika replikacji w połączeniu z poziomem odczytu / zapisu. Dostaję odpowiedź, że „ostatecznie spójne” w cytatach prawdopodobnie z tego powodu, ale wydaje mi się, że pewna jasność jest w porządku.
tsturzl

1

Cassandra to dobry wybór, jeśli:

  1. Nie potrzebujesz właściwości ACID ze swojej bazy danych.

  2. Na DB byłaby ogromna i ogromna liczba zapisów.

  3. Wymagana jest integracja z Big Data, Hadoop, Hive i Spark.

  4. Potrzebna jest analiza danych w czasie rzeczywistym i generowanie raportów.

  5. Wymagany jest imponujący mechanizm odporny na uszkodzenia.

  6. Istnieje wymóg jednorodnego systemu.

  7. Istnieje wiele dostosowań do tuningu.


0

Mongodb ma bardzo potężne funkcje agregujące i ekspresyjną strukturę agregującą. Ma wiele funkcji, z których programiści są przyzwyczajeni korzystać ze świata relacyjnych baz danych. Struktura danych / przechowywania dokumentów pozwala na tworzenie bardziej złożonych modeli danych niż na przykład Cassandra.

Wszystko to oczywiście wiąże się z kompromisami. Kiedy więc wybierzesz bazę danych (NoSQL, NewSQL lub RDBMS), spójrz na problem, który próbujesz rozwiązać, i na twoje potrzeby w zakresie skalowalności. Żadna baza danych nie robi wszystkiego.


0

Według DataStax Cassandra nie jest najlepszym przypadkiem użycia, gdy jest taka potrzeba

1- Sprzęt wysokiej klasy. 2- Zgodny z ACID bez wycofywania (transakcja bankowa)


0
  • Nie obsługuje pełnego zarządzania transakcjami w tabelach.
  • Indeks pomocniczy nie jest obsługiwany.
  • Muszę polegać na wyszukiwaniu elastycznym / Solr dla indeksu dodatkowego i należy napisać niestandardowy komponent synchronizacji.
  • System niezgodny z ACID.
  • Obsługa zapytań jest ograniczona.

0

Apache cassandra to rozproszona baza danych do zarządzania dużymi ilościami danych strukturalnych na wielu serwerach towarowych, zapewniając jednocześnie wysoką dostępność usług i brak pojedynczego punktu awarii.

Archichektura opiera się wyłącznie na twierdzeniu o czapce, którym jest dostępność i tolerancja podziału, a co ciekawe konsekwentnie konsekwentne.

Nie używaj go, jeśli nie przechowujesz woluminów danych w szafach klastrowych, Nie używaj, jeśli nie przechowujesz danych szeregów czasowych, Nie używaj, jeśli nie patujesz na swoje serwery, Nie używaj, jeśli potrzebujesz silnej spójności.


Gwarantuje silną spójność, serwer zawsze wykonuje zapis, a każdy odczyt zapewnia najnowsze.
Remario,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.