Zapytania NoSQL i Ad Hoc - Miliony wierszy

Question

Obecnie prowadzę witrynę internetową z obsługą MySQL, w której użytkownicy promują reklamy i uzyskują przychód za każdym razem, gdy ktoś je wykona. Logujemy za każdym razem, gdy ktoś wyświetli reklamę ("wyświetlenie"), za każdym razem, gdy użytkownik kliknie reklamę ("kliknięcie") i za każdym razem, gdy ktoś ukończy reklamę ("ołów").

Ponieważ mamy tak duży ruch, mamy miliony rekordów w każdej z tych tabel. Następnie musimy zapytać o te tabele, aby umożliwić użytkownikom sprawdzenie, ile zarobili, więc w efekcie wykonujemy wiele zapytań na tabelach z milionami i milionami wierszy kilka razy w jednym żądaniu, setki razy równolegle.

Chcemy odejść od MySQL i do magazynu klucz-wartość lub czegoś podobnego. Potrzebujemy czegoś, co pozwoli nam przechowywać wszystkie te miliony wierszy, sprawdzać je w milisekundach, a NAJWAŻNIEJSZE, używać zapytań ad hoc, w których możemy wyszukiwać dowolną pojedynczą kolumnę, abyśmy mogli wykonać następujące czynności:

Z odprowadzeń WHERE kraj = 'nas' i user_id = 501 (odpowiednik NoSQL, oczywiście)

z kliknięć GDZIE ad_id = 1952 AND user_id = 200 i kraj = 'GB'

itp

Czy ktoś ma jakieś dobre propozycje ? Rozważałem MongoDB lub CouchDB, ale nie jestem pewien, czy potrafią obsłużyć miliony rekordów kilka razy na sekundę i jakiego rodzaju zapytania ad hoc potrzebujemy.

Dzięki!

Answer 1

Jeśli twój zestaw roboczy mieści się w pamięci i indeksujesz odpowiednie pola w dokumencie, wszystko zostanie ustawione. Twoje zapytanie nie jest czymś bardzo typowym i jestem pewien, że przy odpowiednim sprzęcie, odpowiednim projekcie kolekcji (denormalize!) I indeksowaniu powinieneś być gotowy. Czytaj na temat zapytań Mongo i używaj explain() do testowania zapytań. Trzymaj się z dala od klauzul IN i NOT IN, które byłyby moją sugestią.

Answer 2

Z tymi wymaganiami prawdopodobnie lepiej będzie trzymać się kodu SQL i konfigurować replikację/tworzenie klastrów, jeśli występują problemy z obciążeniem. Możesz ustawić indeksowanie w bazie danych dokumentów, aby umożliwić te zapytania, ale tak naprawdę nie zyskujesz nic ponad bieżącym systemem.

Systemy NoSQL na ogół poprawiają wydajność, pomijając niektóre bardziej złożone funkcje systemów relacyjnych. Oznacza to, że będą one pomocne tylko wtedy, gdy Twój scenariusz nie wymaga tych funkcji. Prowadzenie zapytań ad hoc na danych tabelarycznych jest dokładnie tym, na co zaprojektowano SQL.

Answer 3

CouchDB's map/reduce to incremental co oznacza, że ​​przetwarza dokument tylko raz i przechowuje wyniki.

Załóżmy przez chwilę, że CouchDB jest najwolniejszą bazą danych na świecie. Twoje pierwsze zapytanie z milionami wierszy zajmuje około 20 godzin. To brzmi okropnie. Jednak drugie zapytanie, trzecie zapytanie, czwarta kwerenda i setne zapytanie będą trwać 50 milisekund, prawdopodobnie 100, w tym HTTP i opóźnienie sieci.

Można powiedzieć, że CouchDB nie spełnia kryteriów, ale otrzymuje wyróżnienie w szkole ciężkich uderzeń.

Nie martwię się o wydajność, ale raczej jeśli CouchDB będzie w stanie spełnić wymagania dotyczące zapytań ad-hoc. CouchDB chce wiedzieć, jakie zapytania będą występować, więc może wykonać ciężką pracę z góry, zanim pojawi się zapytanie. Po otrzymaniu zapytania odpowiedź jest już przygotowana i wychodzi!

Wszystkie twoje przykłady są dostępne z CouchDB na. Tak zwane połączenie łączenie (wiele warunków równości) nie stanowi problemu. Jednak CouchDB nie może jednocześnie obsługiwać wielu zapytań o nierówności. Nie można poprosić CouchDB, w jednym zapytaniu, dla użytkowników w wieku od 18 do 40 lat, którzy również kliknęli mniej niż 10 razy.

Zaletą interfejsu HTTP i JavaScript CouchDB jest to, że łatwo jest przeprowadzić szybkie studium wykonalności. Proponuję wypróbować to!

Answer 4

To naprawdę zależy od zestawów danych. Zasada numer jeden dla projektu NoSQL polega na zdefiniowaniu najpierw scenariuszy zapytań. Gdy naprawdę zrozumiesz, w jaki sposób chcesz wysyłać zapytania do danych, możesz zapoznać się z różnymi rozwiązaniami NoSQL. Domyślną jednostką dystrybucji jest klucz. Dlatego musisz pamiętać, że musisz mieć możliwość dzielenia danych między komputerami węzłów, w przeciwnym razie skończysz z horyzontalnie skalowalnym systemem, w którym wszystkie prace będą nadal wykonywane w jednym węźle (aczkolwiek lepsze będą zapytania zależne od przypadku).

Musisz także przemyśleć twierdzenie CAP, większość baz danych NoSQL jest ostatecznie zgodna (CP lub AP), podczas gdy tradycyjne Relacyjne DBMS to CA. Wpłynie to na sposób przetwarzania danych i tworzenia pewnych rzeczy, na przykład generowanie kluczy może być oszustwem.

Pamiętaj również, że w niektórych systemach, takich jak HBase, nie ma koncepcji indeksowania. Wszystkie twoje indeksy będą musiały zostać zbudowane według logiki aplikacji, a wszelkie aktualizacje i usuwanie będą musiały być zarządzane jako takie. Dzięki Mongo możesz tworzyć indeksy na polach i stosunkowo szybko je wyszukiwać, istnieje również możliwość integracji Solr z Mongo. Nie musisz pytać o identyfikator w Mongo, tak jak w HBase, która jest rodziną kolumn (inaczej baza danych Google BigTable), w której zasadniczo masz zagnieżdżone pary klucz-wartość.

Po raz kolejny dochodzimy do danych użytkownika, tego, co chcemy przechowywać, sposobu jego przechowywania i, co najważniejsze, sposobu uzyskania do niego dostępu. Projekt Lily wygląda obiecująco. W pracy, z którą się angażuję, pobieramy dużą ilość danych z sieci i przechowujemy ją, analizujemy, usuwamy, analizujemy, przesyłamy, aktualizujemy itp. Nie używamy tylko jednego systemu, ale wielu które najlepiej pasują do wykonywanej pracy. Do tego procesu używamy różnych systemów na różnych etapach, ponieważ daje nam szybki dostęp tam, gdzie jest potrzebny, zapewnia możliwość przesyłania strumieniowego i analizowania danych w czasie rzeczywistym i co ważne, śledzenie wszystkiego w trakcie naszej podróży (jak utrata danych w prod. system to wielka sprawa). Używam Hadoop, HBase, Hive, MongoDB, Solr, MySQL, a nawet dobrych starych plików tekstowych. Pamiętaj, że do produkcji systemu wykorzystującego te technologie jest nieco trudniej niż instalacja MySQL na serwerze, niektóre wydania nie są tak stabilne i naprawdę musisz najpierw wykonać test. Pod koniec dnia zależy to od poziomu oporu biznesowego i krytycznego charakteru systemu.

Inna ścieżka, o której nikt dotąd nie wspomniał, to NewSQL - czyli skalowalne poziomowo RDBMS ... Jest kilka takich, jak klaster MySQL (jak sądzę) i VoltDB, które mogą odpowiadać twojej sprawie.

Znów dochodzi do zrozumienia danych i wzorców dostępu, systemy NoSQL są również niezwiązane, tzn. Nie są relacyjne i mają lepsze dopasowanie do nierelacyjnych zestawów danych. Jeśli twoje dane są z natury relacyjne i potrzebujesz pewnych funkcji zapytań SQL, które naprawdę muszą robić takie rzeczy jak produkty kartezjańskie (również łączenia), być może lepiej będzie trzymać się Oracle i zainwestować trochę czasu w indeksowanie, dzielenie i dostrajanie wydajności.

Moja rada brzmiałaby tak, że można grać z kilkoma różnymi systemami.Jednak dla twojego przypadku użycia wydaje mi się, że najlepszym rozwiązaniem jest baza danych Family Column, myślę, że jest kilka miejsc, w których zaimplementowano podobne rozwiązania do bardzo podobnych problemów (myślę, że NYTimes używa HBase do monitorowania kliknięć strony użytkownika). Kolejnym świetnym przykładem jest Facebook i podobni, używają do tego HBase. Tutaj jest naprawdę dobry artykuł, który może ci pomóc po drodze i wyjaśnić kilka punktów powyżej. http://highscalability.com/blog/2011/3/22/facebooks-new-realtime-analytics-system-hbase-to-process-20.html

Ostatnim punktem byłoby to, że systemy NoSQL nie są wszystkim i kończą wszystko. Umieszczenie danych w bazie danych NoSQL nie oznacza, że ​​będzie działać lepiej niż MySQL, Oracle, a nawet plików tekstowych ... Na przykład zobacz ten wpis na blogu: http://mysqldba.blogspot.com/2010/03/cassandra-is-my-nosql-solution-but.html

Chciałbym rzucić okiem na;

MongoDB - Dokument - CP

CouchDB - Dokument - AP

Redis - w pamięci klucza wartością (nie kolumna rodzin) - CP

Cassandro - Rodzina kolumn - dostępna & Partition Tolerant (AP)

HBase - kolumna Family - Konsekwentne & Partition tolerancyjny (CP)

Hadoop/Hive - Mają również spojrzeć na Hadoop streamingu ...

Hypertable - Kolejny CF CP DB.

VoltDB - Produkt naprawdę dobrze wyglądający, baza relacji, która jest rozprowadzana i może działać w twoim przypadku (może być łatwiejszy ruch). Wydają się również zapewniać wsparcie dla przedsiębiorstw, które może być bardziej odpowiednie dla prod env (tj. Zapewniać użytkownikom biznesowym poczucie bezpieczeństwa).

Jakikolwiek sposób to jest mój 2c. Zabawa z systemami to jedyny sposób, aby dowiedzieć się, co naprawdę działa w twoim przypadku.

Answer 5

Większość ludzi prawdopodobnie poleciłaby MongoDB dla systemu śledzenia/analitycznego takiego jak ten, z ważnych powodów. Powinieneś przeczytać rozdział „MongoDB for Real-Time Analytics” w książce "Definicje MongoDB". W zależności od rozmiaru danych i potrzeb związanych z skalowaniem, możesz uzyskać całą wydajność, wolną od schematów pamięć masową i funkcje zapytań ad-hoc. Będziesz musiał sam zdecydować, czy problemy z trwałością i nieprzewidywalnością systemu są dla ciebie ryzykowne, czy nie.

Dla prostszego systemu śledzenia, Redis byłby bardzo dobrym wyborem, oferującym bogatą funkcjonalność, niesamowitą szybkość i realną trwałość. Aby zorientować się, jak taki system zostanie wdrożony w Redis, zobacz: this gist. Minusem jest to, że musisz sam zdefiniować wszystkie "wskaźniki", a nie "za darmo", jak w przypadku MongoDB. Niemniej jednak nie ma darmowego lunchu, a indeksy MongoDB zdecydowanie nie są darmowym lunchem.

Myślę, że należy spojrzeć na to, jak ElasticSearch by umożliwić Ci:

• prędkości Blazing
• Schema wolne przechowywania
• sharding i rozproszona architektura
• Potężne wyrażeń pierwotnych analityczne w formularz facets
• Łatwa implementacja typu "przesuwne okno" - typ przechowywania danych z indeksem ali ases

Jest w sercu "wyszukiwarką pełnotekstową", ale nie daj się tym pomylić. Przeczytaj artykuł o numerze „Data Visualization with ElasticSearch and Protovis“, aby poznać rzeczywisty przypadek użycia ElasticSearch jako silnika wyszukiwania danych.

Zobacz, jak wygląda these slides dla rzeczywistego zastosowania w przypadku scenariusza "przesuwania okna".

Dostępnych jest wiele bibliotek klienckich dla ElasticSearch, takich jak Tire dla Ruby, więc łatwo jest szybko zejść z ziemi z prototypem.

Dla zapisu (z całym szacunkiem dla @jhs :), na podstawie mojego doświadczenia, nie mogę sobie wyobrazić realizacji, w której Couchdb jest wykonalną i przydatną opcją. Byłoby to niesamowite miejsce do przechowywania kopii zapasowych danych.