Kiedy NIE należy używać Cassandry?

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.

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.

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 .

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.

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ć.

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ę.

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.

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ć.

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.

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.

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.

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.

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.

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.

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.

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)

• 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.

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.