Cassandra zamiast MySQL do aplikacji sieci społecznościowej

Question

Jestem w trakcie budowania nowej aplikacji, która będzie miała bardzo podobne funkcje do Facebooka i choć oczywiście nie będzie miała do czynienia z podobnymi do 400 000 000 milionów użytkowników, będzie nadal używana przez znaczną bazę użytkowników, a większość z nich zażąda, aby działała bardzo szybko.

Mam duże doświadczenie z MySQL, ale aplikacja społecznościowa oferuje zawiłości, których MySQL również nie nadaje się dobrze. Wiem, że Facebook, Twitter itp. Przeniosły się w stronę Cassandry z powodu wielu danych, ale nie jestem pewien, jak daleko się posunąć.

Na przykład można przechowywać takie dane, jak dane użytkownika - nazwa użytkownika, hasła, adresy itp. W Cassandra? Czy możesz przechowywać e-maile, komentarze, aktualizacje statusu itp. W Cassandrze? Dużo czytałem też, że coś takiego jak neo4j jest o wiele lepsze do reprezentowania relacji przyjacielskich używanych przez aplikacje społecznościowe, ponieważ jest to baza danych wykresów. Właśnie rozpoczynam trasę NoSQL, więc wszelkie wskazówki są mile widziane.

Czy ktoś mógłby mi doradzić w tej sprawie? Mam nadzieję, że nie jestem zbyt ogólna!

Answer 1

Na przykład można przechowywać takie dane, jak dane użytkownika - nazwa użytkownika, hasła, adresy itp. W Cassandra?

Nie, ponieważ nie gwarantuje spójności. Cassandra jest ostatecznie zgodna. Z pewnością nie powinno być współbieżności na danych niektórych kont użytkowników, ale nie chciałbym się na nie postawić. Możesz nie potrzebować spójności w wyszukiwaniu pełnotekstowym, skrzynce odbiorczej wiadomości itp.ale chcesz spójności w wszystkim, co związane z bezpieczeństwem.

Mam również czytać dużo, że coś takiego neo4j jest znacznie lepiej do reprezentowania relacji przyjaciół używane przez aplikacje społecznych, ponieważ jest to baza danych wykresu.

Jestem wielkim fanem odpowiedniego narzędzia do właściwej pracy. Nie używałem neo4j, ale korzystałem z db4o (który jest bazą danych obiektów) i uważam, że jest to bardzo pomocne. Ułatwia to programowanie, które natywnie wspiera Twoje potrzeby. Ponieważ potrzebujesz wykresów i pracy z wykresami w SQL to jest ból, polecam go rzucić okiem i ocenić, czy pasuje on do twoich konkretnych potrzeb.

Mieszanie baz danych brzmi dla mnie jak dobry pomysł, o ile wybór jest naturalny (tj. Odpowiednia baza danych jest pomocna dla konkretnych zadań, wykresy baz danych dla wykresów, tabela dla tabel, bazy danych ACID dla wszystkiego, co wymaga transakcji bezpieczeństwo itp.).

Answer 2

Facebook nie zrobił przenieść do Cassandra, stworzyli go. :) Według mojej wiedzy, DBMS noSQL nie wymagają ani nawet nie wspominają o (dzięki mnemosynowi za korektę, Facebook korzysta z Oracle i Cassandry) działającym równolegle z relacyjną bazą danych. This jest przeciwstawnym przykładem (przechowywanie informacji o użytkowniku w bazie danych noSQL DB).

Powiedziałbym, że jeśli Cassandra jest wystarczająco dobra dla Facebooka, prawdopodobnie będzie wystarczająco dobra dla twojego projektu. To nie zaszkodzi spróbować streścić logikę wytrwałości, abyś miał możliwość przejścia na coś innego, jeśli absolutnie do tego dojdzie.

Nota prawna: Nie miałem (jeszcze?) Żadnych doświadczeń z bazami danych noSQL: to, co wiem, pochodzi z lektury.

Answer 3

Proponuję zrobić kilka testów z MySQL i Cassandrą. Kiedy musieliśmy dokonać wyboru między PostgreSQL i MongoDB w jednym z moich zadań, porównaliśmy czas zapytania z milionami rekordów w obu i odkryliśmy, że przy około 10M rekordach Postgres zapewniłby nam odpowiednie czasy odpowiedzi.

Wiedzieliśmy, że nie dojdziemy do tej liczby rekordów przez co najmniej kilka lat, a my mieliśmy doświadczenie z Postgresem (podczas gdy MongoDB nie był wtedy bardzo dojrzały), więc zdecydowaliśmy się na Postgres.

Chodzi mi o to, że prawdopodobnie możesz spojrzeć na benchmarki MySQL, sam wykonać testy wydajności, oszacować rozmiar zbioru danych i jego wzrost, i podjąć świadomą decyzję w ten sposób.

Jeśli chodzi o mieszanie relacyjnych i nierelacyjnych baz danych, to jest to coś, co również uważaliśmy, ale zdecydowaliśmy, że byłoby to zbyt dużym kłopotem, ponieważ oznaczałoby to utrzymanie dwóch rodzajów oprogramowania i napisanie całkiem sporo kleju kod, aby pobrać dane z obu. Myślę, że Cassandra byłaby w stanie przechowywać wszystkie twoje dane.

Answer 4

Cassandra dostarcza ładne rozwiązanie rozproszone i prawdopodobnie lepsze na platformie typu Facebook niż MySQL (jeśli będzie wymagać skalowania). Ale Cassandra nie jest odpowiednia dla relacji danych, w której będziesz mieć wyzwanie związane z wieloma osobami. Baza danych wykresów powiązana z Cassandrą zapewnia zarówno ogólne zapotrzebowanie na wolumen, jak i bardzo szybką funkcję zapytań o relacje. Pracujemy nad czymś, co łączy obie technologie i zawsze interesuje nas rodzaj wymagań, które Twoja platforma mogłaby zaprezentować. Jeśli masz jakieś pytania dotyczące obsługi niektórych problemów związanych z danymi, chciałbym je usłyszeć, może uda nam się to rozwiązać.