Jakie problemy ze skalowalnością napotkałeś podczas używania magazynu danych NoSQL? [Zamknięte]

NoSQL odnosi się do nierelacyjnych magazynów danych, które zrywają z historią relacyjnych baz danych i gwarancji ACID. Popularne magazyny danych NoSQL typu open source to:

• Cassandra (tabelaryczna, napisana w Javie, używana przez Cisco, WebEx, Digg, Facebook, IBM, Mahalo, Rackspace, Reddit i Twitter)
• CouchDB (dokument napisany w Erlang, używany przez BBC i Engine Yard)
• Dynomite (klucz-wartość, napisany w Erlang, używany przez Powerset)
• HBase (klucz-wartość, napisany w Javie, używany przez Bing)
• Hypertable (tabelaryczny, napisany w C ++, używany przez Baidu)
• Kai (klucz-wartość, napisane w Erlang)
• MemcacheDB (klucz-wartość, napisany w C, używany przez Reddit)
• MongoDB (dokument napisany w C ++, używany przez Electronic Arts, Github, NY Times i Sourceforge)
• Neo4j (wykres napisany w Javie, używany przez niektóre szwedzkie uniwersytety)
• Projekt Voldemort (klucz-wartość, napisany w Javie, używany przez LinkedIn)
• Redis (klucz-wartość, napisany w C, używany przez Craigslist, Engine Yard i Github)
• Riak (klucz-wartość, napisany w Erlang, używany przez Comcast i Mochi Media)
• Ringo (klucz-wartość, napisany w Erlang, używany przez Nokię)
• Scalaris (klucz-wartość, napisany w Erlang, używany przez OnScale)
• Terrastore (dokument napisany w Javie)
• ThruDB (dokument napisany w C ++, używany przez JunkDepot.com)
• Tokyo Cabinet / Tokyo Tyrant (klucz-wartość, napisane w C, używane przez Mixi.jp (japoński portal społecznościowy))

Chciałbym wiedzieć o konkretnych problemach, które ty - czytelnik SO - rozwiązałeś za pomocą magazynów danych i jakiego magazynu danych NoSQL używałeś.

Pytania:

• Jakie problemy ze skalowalnością wykorzystałeś do przechowywania magazynów danych NoSQL?
• Z jakiego magazynu danych NoSQL korzystałeś?
• Z jakiej bazy danych korzystałeś przed przejściem do magazynu danych NoSQL?

Szukam doświadczeń z pierwszej ręki, więc proszę nie odpowiadać, chyba że masz to.

Zmieniłem mały podprojekt z MySQL na CouchDB, aby móc obsłużyć obciążenie. Wynik był niesamowity.

Około 2 lata temu wydaliśmy samodzielnie napisane oprogramowanie na stronie http://www.ubuntuusers.de/ (prawdopodobnie jest to największa niemiecka strona społeczności Linuksa). Witryna została napisana w języku Python i dodaliśmy oprogramowanie pośrednie WSGI, które było w stanie wychwycić wszystkie wyjątki i wysłać je do innej małej witryny opartej na MySQL. Ta niewielka strona internetowa używała skrótu do określania różnych błędów i zapisywała liczbę wystąpień oraz ostatnie wystąpienie.

Niestety, wkrótce po wydaniu strona internetowa traceback-logger już nie odpowiadała. Mieliśmy pewne problemy z blokowaniem bazy danych produkcyjnych naszej głównej witryny, która zgłaszała wyjątki prawie do każdego żądania, a także kilka innych błędów, których nie zbadaliśmy na etapie testowania. Klaster serwerów w naszej głównej witrynie, zwany traceback-logger, przesyła stronę kilka razy na sekundę. I to było zdecydowanie za dużo dla małego serwera, na którym znajdował się rejestrator śledzenia (był to już stary serwer, który służył tylko do celów programistycznych).

W tym czasie CouchDB był dość popularny, więc postanowiłem go wypróbować i napisać z nim mały rejestrator śledzenia. Nowy program rejestrujący składał się tylko z jednego pliku python, który zawierał listę błędów z opcjami sortowania i filtrowania oraz stronę przesyłania. A w tle rozpocząłem proces CouchDB. Nowe oprogramowanie bardzo szybko zareagowało na wszystkie żądania i byliśmy w stanie wyświetlić ogromną liczbę automatycznych zgłoszeń błędów.

Interesującą rzeczą jest to, że poprzednie rozwiązanie działało na starym dedykowanym serwerze, gdzie nowa strona oparta na CouchDB działała tylko na wspólnej instancji xen z bardzo ograniczonymi zasobami. I nawet nie użyłem siły sklepów z kluczowymi wartościami do skalowania w poziomie. Zdolność CouchDB / Erlang OTP do obsługi równoczesnych żądań bez blokowania czegokolwiek była już wystarczająca do zaspokojenia potrzeb.

Teraz szybko napisany rejestrator śledzenia CouchDB nadal działa i jest pomocnym sposobem na badanie błędów na głównej stronie internetowej. W każdym razie mniej więcej raz w miesiącu baza danych staje się zbyt duża i proces CouchDB zostaje zabity. Ale potem komenda compact-db CouchDB ponownie zmniejsza rozmiar z kilku GB do niektórych KB, a baza danych jest ponownie uruchomiona (może powinienem rozważyć dodanie cronjob ... 0o).

Podsumowując, CouchDB był z pewnością najlepszym wyborem (lub przynajmniej lepszym wyborem niż MySQL) dla tego podprojektu i dobrze sobie radzi.

Właściwie mój obecny projekt.

Przechowywanie 18 000 obiektów w znormalizowanej strukturze: 90 000 wierszy w 8 różnych tabelach. Zajęło 1 minutę, aby je pobrać i zmapować do naszego modelu obiektowego Java, to wszystko z poprawnie zaindeksowanym itd.

Przechowywanie ich jako par klucz / wartość za pomocą lekkiej reprezentacji tekstu: 1 tabela, 18 000 wierszy, 3 sekundy, aby je wszystkie pobrać i zrekonstruować obiekty Java.

W kategoriach biznesowych: pierwsza opcja była niewykonalna. Druga opcja oznacza, że ​​nasza aplikacja działa.

Szczegóły technologii: działa na MySQL zarówno dla SQL, jak i NoSQL! Trzymanie się MySQL dla dobrego wsparcia transakcji, wydajności i udokumentowanych osiągnięć w zakresie nie uszkadzania danych, dość dobre skalowanie, obsługa klastrowania itp.

Nasz model danych w MySQL jest teraz tylko kluczowymi polami (liczbami całkowitymi) i dużym polem „wartości”: po prostu dużym polem TEKST.

Nie poszliśmy z żadnym z nowych odtwarzaczy (CouchDB, Cassandra, MongoDB itp.), Ponieważ chociaż każdy z nich oferuje same w sobie świetne funkcje / wydajność, zawsze były wady naszych okoliczności (np. Brak / niedojrzałe wsparcie Java).

Dodatkowa korzyść (ab) przy użyciu MySQL - bity naszego modelu, które działają relacyjnie, można łatwo połączyć z naszymi danymi magazynu kluczy / wartości.

Aktualizacja: oto przykład, w jaki sposób reprezentowaliśmy treść tekstową, a nie naszą rzeczywistą domenę biznesową (nie pracujemy z „produktami”), gdy mój szef mnie zastrzelił, ale przekazuje pomysł, w tym aspekt rekurencyjny (tutaj jedna jednostka, tutaj produkt „zawierający” inne). Mamy nadzieję, że jasne jest, jak w znormalizowanej strukturze może to być kilka tabel, np. Łączenie produktu z jego gamą smaków, które zawierają inne produkty itp.

Name=An Example Product
Type=CategoryAProduct
Colour=Blue
Size=Large
Flavours={nice,lovely,unpleasant,foul}
Contains=[
Name=Product2
Type=CategoryBProduct
Size=medium
Flavours={yuck}
------
Name=Product3
Type=CategoryCProduct
Size=Small
Flavours={sublime}
]

Highscalability.com Todda Hoffa ma wiele świetnych relacji z NoSQL, w tym niektóre studia przypadków.

Komercyjny DBMS z kolumną Vertica może pasować do twoich celów (nawet jeśli obsługuje SQL): jest bardzo szybki w porównaniu z tradycyjnymi relacyjnymi DBMS dla zapytań analitycznych. Zobacz najnowszy artykuł CACM autorstwa Stonebraker i in kontrastujący Vertica z redukcją mapy.

Aktualizacja: I Cassandra wybrała Twittera spośród kilku innych, w tym HBase, Voldemort, MongoDB, MemcacheDB, Redis i HyperTable.

Aktualizacja 2: Rick Cattell właśnie opublikował porównanie kilku systemów NoSQL w magazynach danych o wysokiej wydajności . I artykuł highscalability.com na temat papieru Ricka jest tutaj .

Przenieśliśmy część naszych danych z mysql do mongodb, nie tyle ze względu na skalowalność, co więcej, ponieważ lepiej pasuje do plików i danych nie tabelarycznych.

W produkcji obecnie przechowujemy:

• 25 tysięcy plików (60 GB)
• 130 milionów innych „dokumentów” (350 GB)

przy dziennym obrocie około 10 GB.

Baza danych jest wdrażana w konfiguracji „sparowanej” na dwóch węzłach (6x450GB sas raid10) z klientami apache / wsgi / python za pomocą interfejsu API mongodb python api (pymongo). Konfiguracja dysku jest prawdopodobnie przesadna, ale właśnie tego używamy do mysql.

Oprócz niektórych problemów z pulami wątków pymongo i blokującym charakterem serwera mongodb było to dobre doświadczenie.

Przepraszam za sprzeczanie się z twoim odważnym tekstem, ponieważ nie mam doświadczenia z pierwszej ręki, ale ten zestaw postów na blogu jest dobrym przykładem rozwiązania problemu z CouchDB.

CouchDB: studium przypadku

Zasadniczo aplikacja tekstowa wykorzystała CouchDB do rozwiązania problemu z eksplodującymi danymi. Odkryli, że SQL jest zbyt wolny, aby poradzić sobie z dużą ilością danych archiwalnych, i przenieśli go na CouchDB. To doskonała lektura, a on omawia cały proces ustalania, jakie problemy CouchDB może rozwiązać i jak je rozwiązał.

Przenieśliśmy część naszych danych, które przechowywaliśmy w Postgresql i Memcached do Redis . Magazyny kluczowych wartości znacznie lepiej nadają się do przechowywania danych obiektów hierarchicznych. Możesz przechowywać dane obiektów blob znacznie szybciej i przy znacznie mniejszym czasie i wysiłku programistycznym niż przy użyciu ORM do mapowania obiektu blob na RDBMS.

Mam klienta redis c # open source, który pozwala przechowywać i pobierać dowolne obiekty POCO z 1 linią:

var customers = redis.Lists["customers"]; //Implements IList<Customer>
customers.Add(new Customer { Name = "Mr Customer" });

Magazyny kluczowych wartości są również znacznie łatwiejsze do „skalowania”, ponieważ można dodać nowy serwer, a następnie równomiernie podzielić obciążenie, aby uwzględnić nowy serwer. Co ważne, nie ma centralnego serwera, który ograniczałby twoją skalowalność. (choć nadal będziesz potrzebować strategii spójnego mieszania, aby rozpowszechniać swoje żądania).

Uważam Redis za „zarządzany plik tekstowy” na sterydach, który zapewnia szybki, równoczesny i atomowy dostęp dla wielu klientów, więc wszystko, czego użyłem do użycia pliku tekstowego lub wbudowanej bazy danych, teraz używam Redis. np. aby uzyskać łączony dziennik błędów kroczących w czasie rzeczywistym dla wszystkich naszych usług (co było dla nas bardzo trudnym zadaniem), można teraz osiągnąć za pomocą tylko kilku wierszy, po prostu oczekując błędu na bocznej liście serwerów Redis i następnie przycinanie listy, aby zachować tylko ostatnie 1000, np .:

var errors = redis.List["combined:errors"];
errors.Insert(0, new Error { Name = ex.GetType().Name, Message = ex.Message, StackTrace = ex.StackTrace});
redis.TrimList(errors, 1000);

Nie mam doświadczenia z pierwszej ręki., Ale uważam, że ten wpis na blogu jest dość interesujący.

Próbuję zmapować obiekty domeny oprogramowania (np. ASalesOrder, aCustomer ...) do dwuwymiarowej relacyjnej bazy danych (wiersze i kolumny) wymaga dużo kodu, aby zapisać / zaktualizować, a następnie ponownie utworzyć wystąpienie obiektu domeny z wielu tabel . Nie wspominając już o wydajności związanej z posiadaniem wszystkich tych złączeń, wszystkich odczytów dysku ... tylko po to, aby wyświetlić / manipulować obiektem domeny, takim jak zamówienie sprzedaży lub rekord klienta.

Przeszliśmy na Object Management Systems (ODBMS). Wykraczają one poza możliwości wymienionych systemów noSQL. Przykładem tego jest GemStone / S (dla Smalltalk). Istnieją inne rozwiązania ODBMS, które mają sterowniki dla wielu języków. Kluczową korzyścią dla programistów jest to, że hierarchia klas jest automatycznie schematem bazy danych, podklasami itp. Wystarczy użyć języka obiektowego, aby obiekty były trwałe w bazie danych. Systemy ODBMS zapewniają integralność transakcji na poziomie ACID, więc działałyby również w systemach finansowych.

Zmieniłem z MySQL (InnoDB) na Cassandra dla systemu M2M, który zasadniczo przechowuje szeregi czasowe czujników dla każdego urządzenia. Każde dane jest indeksowane według (identyfikator_urządzenia, data) i (identyfikator_urządzenia, typ_czujnika, data). Wersja MySQL zawierała 20 milionów wierszy.

MySQL:

• Konfiguracja synchronizacji master-master. Pojawił się kilka problemów związanych z utratą synchronizacji . To było stresujące, a zwłaszcza na początku naprawa mogła potrwać kilka godzin.
• Czas wstawiania nie był problemem, ale zapytania wymagały coraz więcej pamięci miarę wzrostu danych. Problem polega na tym, że indeksy są traktowane jako całość. W moim przypadku korzystałem tylko z bardzo cienkich części indeksów, które były niezbędne do załadowania do pamięci (tylko kilka procent urządzeń było często monitorowanych i znajdowały się na najnowszych danych).
• Trudno było wykonać kopię zapasową . Rsync nie jest w stanie wykonywać szybkich kopii zapasowych dużych plików tabel InnoDB.
• Szybko stało się jasne, że nie można zaktualizować schematu ciężkich tabel , ponieważ zajęło to zbyt dużo czasu (godzin).
• Importowanie danych trwało godziny (nawet jeśli indeksowanie zostało wykonane w końcu). Najlepszym planem ratunkowym było zawsze przechowywanie kilku kopii bazy danych (plik danych + logi).
• Przeniesienie się z jednej firmy hostingowej do drugiej było naprawdę wielką sprawą . Z replikacją trzeba było postępować bardzo ostrożnie.

Cassandra:

• Jeszcze łatwiejszy w instalacji niż MySQL.
• Wymaga dużo pamięci RAM. Wystąpienie o pojemności 2 GB nie mogło sprawić, że będzie działać w pierwszych wersjach, teraz może działać na wystąpieniu o pojemności 1 GB, ale to nie jest pomysł (zdecydowanie za dużo opróżnień danych). W naszym przypadku wystarczyło 8 GB.
• Po zrozumieniu sposobu organizacji danych przechowywanie jest łatwe. Żądanie jest nieco bardziej złożone. Ale kiedy go obejdziesz, jest naprawdę szybki (naprawdę nie możesz popełnić błędu, chyba że naprawdę chcesz).
• Jeśli poprzedni krok został zrobiony dobrze, jest i pozostaje bardzo szybki.
• Wygląda na to, że dane są zorganizowane w celu tworzenia kopii zapasowych. Każde nowe dane są dodawane jako nowe pliki. Ja osobiście, ale to nie jest dobra rzecz, opróżniam dane każdej nocy i przed każdym zamknięciem (zwykle w celu aktualizacji), aby przywracanie trwało krócej, ponieważ mamy mniej dzienników do odczytania. Nie tworzy wielu plików, ponieważ są one kompaktowane.
• Importowanie danych jest szybkie jak diabli. Im więcej hostów, tym szybciej. Eksportowanie i importowanie gigabajtów danych nie stanowi już problemu.
• Brak schematu jest bardzo interesującą rzeczą, ponieważ możesz sprawić, że twoje dane ewoluują w celu dostosowania się do twoich potrzeb. Co może oznaczać jednoczesne używanie różnych wersji danych w tej samej rodzinie kolumn.
• Dodanie hosta było łatwe (choć nie szybkie), ale nie zrobiłem tego w konfiguracji z wieloma centrami danych.

Uwaga: Użyłem również elasticsearch (zorientowanego na dokument oparty na lucenie) i myślę, że należy go traktować jako bazę danych NoSQL. Jest dystrybuowany, niezawodny i często szybki (niektóre złożone zapytania mogą działać dość źle).

Ja nie. Chciałbym skorzystać z prostego i darmowego sklepu z kluczami i wartościami, który mogę wywoływać w trakcie procesu, ale takie rzeczy nie istnieją na platformie Windows. Teraz używam Sqlite, ale chciałbym użyć czegoś takiego jak Tokyo Cabinet. BerkeleyDB ma „problemy” z licencją.

Jednak jeśli chcesz korzystać z systemu operacyjnego Windows, wybór baz danych NoSQL jest ograniczony. I nie zawsze jest dostawca C #

Próbowałem MongoDB i było 40 razy szybsze niż Sqlite, więc może powinienem go użyć. Ale wciąż mam nadzieję na proste rozwiązanie procesowe.

Użyłem redis do przechowywania logów na różnych komputerach. Było bardzo łatwe do wdrożenia i bardzo przydatne. Redis naprawdę się kołysze

Zastąpiliśmy bazę danych postgres bazą danych dokumentów CouchDB, ponieważ brak stałego schematu był dla nas silną zaletą. Każdy dokument ma zmienną liczbę indeksów używanych do uzyskania dostępu do tego dokumentu.

W przeszłości korzystałem z Couchbase i napotkaliśmy problemy ze zrównoważeniem i wiele innych problemów. Obecnie używam Redis w kilku projektach produkcyjnych. Korzystam z redislabs.com, która jest usługą zarządzaną dla Redis, która zajmuje się skalowaniem twoich klastrów Redis. Opublikowałem film na temat trwałości obiektów na moim blogu pod adresem http://thomasjaeger.wordpress.com, który pokazuje, jak używać Redis w modelu dostawcy i jak przechowywać twoje obiekty C # w Redis. Spójrz.

Zachęcam każdego, kto to czyta, do wypróbowania Couchbase jeszcze raz, gdy wersja 3.0 jest już dostępna. Na początek jest ponad 200 nowych funkcji. Wydajność, dostępność, skalowalność i funkcje łatwego zarządzania serwerem Couchbase Server zapewniają niezwykle elastyczną, wysoce dostępną bazę danych. Interfejs zarządzania jest wbudowany, a interfejsy API automatycznie wykrywają węzły klastra, więc nie ma potrzeby równoważenia obciążenia z aplikacji do bazy danych. Chociaż w tej chwili nie mamy usługi zarządzanej, możesz uruchamiać bazę na rzeczy takie jak AWS, RedHat Gears, Cloudera, Rackspace, Docker Containers, takie jak CloudSoft i wiele więcej. Jeśli chodzi o równoważenie, zależy to od tego, o czym konkretnie mówisz, ale Couchbase nie automatycznie ponownie równoważy po awarii węzła, zgodnie z projektem, ale administrator może skonfigurować automatyczne przełączanie awaryjne dla awarii pierwszego węzła, a korzystając z naszych interfejsów API można również uzyskać dostęp do replik vbuckets w celu odczytania przed ich aktywowaniem lub za pomocą RestAPI można wymusić przełączenie awaryjne za pomocą narzędzia do monitorowania. Jest to szczególny przypadek, ale można to zrobić.

Zwykle nie przywracamy równowagi w prawie żadnym trybie, chyba że węzeł jest całkowicie offline i nigdy nie wraca lub nowy węzeł nie jest gotowy do automatycznego zrównoważenia. Oto kilka poradników, które pomogą wszystkim zainteresowanym zobaczyć, na czym polega jedna z najbardziej wydajnych baz danych NoSQL.

1. Serwer Couchbase 3.0
2. Przewodnik administracji
3. Interfejs API REST
4. Przewodniki dla programistów

Na koniec zachęcam również do sprawdzenia N1QL do rozproszonych zapytań:

1. Samouczek N1QL
2. Przewodnik po N1QL

Dziękujemy za przeczytanie i daj mi lub innym znać, jeśli potrzebujesz dodatkowej pomocy!

Austin

W przeszłości korzystałem z Vertica, która polega na kompresji kolumnowej i przyspiesza odczytywanie dysku i zmniejsza zapotrzebowanie na miejsce na dysku, aby maksymalnie wykorzystać sprzęt. Szybsze ładowanie danych i większa współbieżność umożliwiają podawanie danych analitycznych większej liczbie użytkowników przy minimalnym opóźnieniu.

Wcześniej sprawdzaliśmy bazę danych Oracle o miliardy rekordów, a wydajność była bardzo nieoptymalna. Uruchomienie kwerend trwało od 8 do 12 sekund, nawet po optymalizacji przy użyciu dysku SSD. Dlatego odczuliśmy potrzebę korzystania z szybszej, zoptymalizowanej, zorientowanej na analizy bazy danych. Dzięki klastrom Vertica za warstwą Lean Service mogliśmy uruchamiać interfejsy API z wydajnością poniżej sekundy.

Vertica przechowuje dane w rzutach w formacie, który optymalizuje wykonanie zapytania. Podobnie jak w widokach zmaterializowanych, prognozy przechowują zestawy wyników na dysku LUB na dysku SSD, zamiast obliczać je za każdym razem, gdy są używane w zapytaniu. Projekcje zapewniają następujące korzyści:

1. Kompresuj i koduj dane, aby zmniejszyć przestrzeń dyskową.
2. Uprość dystrybucję w klastrze baz danych.
3. Zapewnij wysoką dostępność i odzyskiwanie.

Vertica optymalizuje bazę danych, dystrybuując dane w klastrze za pomocą segmentacji.

1. Segmentacja umieszcza część danych w węźle.
2. Równomiernie rozprowadza dane we wszystkich węzłach. W ten sposób każdy węzeł wykonuje część procesu zapytania.
3. Zapytanie jest uruchamiane w klastrze, a każdy węzeł otrzymuje plan zapytań.
4. Wyniki zapytań są agregowane i wykorzystywane do tworzenia danych wyjściowych.

Aby uzyskać więcej informacji, zapoznaj się z dokumentacją Vertica @ https://www.vertica.com/knowledgebase/