Sugestia bazy danych dla sieci społecznościowej / społeczności baz wiedzy?

12

Przeglądam różne typy baz danych i DBMS dla nowego projektu, który chcę rozpocząć latem.

Zbudowałem systemy w MySQL i postgreSQL, teraz chcę poszerzyć swoją wiedzę i doświadczenie w bazach danych.

Mój projekt będzie rodzajem wiedzy na temat sieci społecznościowych / agregacji wiedzy. (wciąż nie opracowałem jeszcze terminu, aby to opisać).

Patrzyłem na:

  • Cassandra (użyj własnego języka zapytań); Wydaje się być dobry w przypadku treści bogatych w funkcje i zapewniających wysoką wydajność wykonywania zapytań. Jednak nie jestem tym zbytnio zainteresowany, ponieważ wymaga środowiska Java do pracy i wolałbym nie mieć nic wspólnego z Oracle.
  • MongoDB (DBMS typu noSQL); świetna skalowalność, jednak tracisz wszystkie możliwości już dostępne w sprawdzonym języku SQL, takie jak zapytania informacji biznesowych.

Wymagania systemu:

  • Tekst danych , daty, godziny, xml, small ints, blob,
  • Struktura / behawior : znormalizowany 3NF, nie czasie rzeczywistym, relacyjny, skalowalny, solidny
  • Środowisko: unix / linux, bez JAVA !, najlepiej działa na C

Zastanawiałem się, czy możesz wskazać mi jakieś inne systemy baz danych, które powinienem zbadać.

Przyjrzałem się także obiektowym relacyjnym bazom danych, bardzo podoba mi się pomysł pracy z obiektami PHP (PDO), jednak ich wydajność wydaje się nieco słaba.

Biorąc pod uwagę, że będą tutaj DBA, mile widziane będą wszelkie opinie na temat obsługiwanych systemów.

Dzięki

tomaytotomato
źródło
3
Jeśli chcesz znormalizować 3nf, musisz zrobić sklep relacyjny. Kropka.
JNK
2
Nie powaliłbym Javy tylko dlatego, że jest to „Oracle”. Użyj odpowiedniego narzędzia do pracy. Jeśli Java jest najlepszym narzędziem, skorzystałbym z niego. Jeśli C to właściwa praca, użyj jej. Skoncentruj się na tym, co daje ci każde narzędzie, plusy i minusy. Podejmij dobrze wykształconą decyzję (podobnie jak po stronie DB), a nie na podstawie uczuć.
Chris Aldrich

Odpowiedzi:

4

Twoje abstrakcyjne wymagania krzyczą do mnie „PostgreSQL”. Myślę jednak, że warto być na bieżąco z planami burżuazji, więc oto lista różnych rzeczy, które możesz sprawdzić.

Darmowe rzeczy

  • CouchDB - jedna z pierwszych baz danych NoSQL, potężny system zapytań map / redukcja, wysoce rozproszony i odporny na uszkodzenia. Jeden z lepszych pretendentów NoSQL.
  • Hyperdex - bardzo nowa, rozproszona tabela skrótów z możliwością wyszukiwania.
  • Riak - rozproszony stół haszujący godny szacunku.

Dziwne darmowe rzeczy

  • Metakit - bardziej osadzona baza danych, taka jak SQLite, ale nie oparta na SQL, więc bardziej proceduralna.
  • FramerD - podobnie jak klasyczna baza „sieciowa”, bardzo skoncentrowana na wskaźnikach. Może nie żyje?
  • Magma - Smalltalk OODBMS. Fajnie, ale słabo udokumentowane.

Niewolne rzeczy

  • AllegroGraph - baza danych RDF (wykres), obsługuje SPARQL. O smaku Lisp.
  • Caché - hybrydowa relacyjna / OO baza danych, pierwotnie oparta na MUMPS (IIRC).
  • Obiektywność - jeden z kilku ostatnich naprawdę dużych OODB. Bardzo mocny, imponujący i drogi.
  • VoltDB - wysoce skalowalna głównie relacyjna baza danych. Obsługuje „większość” SQL. Bardzo nowy. Sądzę, że mają też wersję społecznościową.

Wniosek

Żadnej z tych rzeczy nie używałem zbyt często. Grałem z większością z nich trochę i zawsze skończyłem z PostgreSQL. Patrząc na twoje wymagania, jedynym, którego PostgreSQL nie spełnia po wyjęciu z pudełka, jest skalowalność. Z drugiej strony, dla moich celów o wiele łatwiej jest wrzucić 4000 USD sprzętu na jedną dedykowaną maszynę bazodanową, niż wrzucić 4000 USD węzłów w chmurze lub maszyn z niższej półki na ten problem. Istnieją sposoby osiągnięcia skalowalności za pomocą PostgreSQL, na przykład EnterpriseDB .

To świetna zabawa, aby bawić się tymi rzeczami na boku, ale kiedy przychodzi czas na umieszczenie w czymś cennych, niepowtarzalnych danych produkcyjnych, na pierwszy plan wysuwa się kilka nudnych atrybutów, takich jak niezawodność, stabilność i długoterminowa rentowność.

Eksperyment myślowy dla Ciebie

Rozważ to. Wyobraź sobie, że jesteś Mark Zuckerberg i musisz albo zrezygnować z bazy danych, albo z danych. Możesz zatrzymać cały personel programistyczny, ale albo musisz zrezygnować z całego kodu - w każdym wierszu, powiedzmy, że nawet wszystkie wspomnienia programistów o tym, jak zaimplementowali wszystko, zniknęło - ale możesz zachować wszystkie konta użytkowników i wszystkich użytkowników przesłane dane i tak dalej, albo możesz zrezygnować ze wszystkich danych. Zachowaj wszystkie struktury i serwery oraz konfigurację, konfigurację, ale stracisz każdy wiersz w każdej tabeli w każdej bazie danych.

Powinno być oczywiste, że byłoby gorzej stracić dane. Dlaczego wszyscy twoi użytkownicy zregenerują wszystkie te dane? Pomyśl o wszystkich utraconych danych marketingowych, bo tak zarabia Facebook. I jest mnóstwo przedsiębiorców śliniących się z okazji, aby zachęcić ludzi do korzystania z ich klonów na Facebooku - teraz wszyscy ci pozbawieni prawa do korzystania z byłych użytkowników Facebooka będą tam rozważać alternatywy. Z drugiej strony, jeśli stracą bazę kodu, mogą ją odbudować, prawdopodobnie nawet lepiej niż obecnie, ale mogą mieć coś online w bardzo krótkim czasie. Cholera - prawdopodobnie mogliby kupićczyjaś baza kodu na Facebooku klonuje i ładuje ją prawdziwymi danymi, ale nie możesz po prostu skopiować ich danych. Jeśli Facebook nadal ma ważne dane wszystkich na swoich serwerach, motywacja do opuszczenia jest znacznie niższa. Wciąż źle, ale o wiele mniej. Zaskakująco mniej.

Ironią jest to, że o wiele łatwiej jest stracić wszystkie dane w dziwnym wypadku niż stracić cały kod. Dla większości firm internetowych, choć dane jest firma, to jest twój największy atut. I to jest silny powód, aby rozważyć użycie tradycyjnej, sprawdzonej w czasie, staromodnej, nieseksualnej relacyjnej bazy danych.

Daniel Lyons
źródło
Podsumowanie długiego komentarza skasowanego stąd: „Niesprawiedliwe jest sugerowanie, że sklepy NOSQL w jakiś sposób zwiększą prawdopodobieństwo utraty danych”.
Jack mówi, że spróbuj topanswers.xyz
To, co mówię, ma związek z wiekiem i powszechnym użytkowaniem, a nie z konstrukcją silnika pamięci masowej.
Daniel Lyons,
6

Weź również pod uwagę, że nie ma powodu, dla którego nie można używać relacyjnej bazy danych dla niektórych rzeczy, a bazy danych nosql dla innych rzeczy.

HLGEM
źródło
0

Mówiąc o nosql, mam tylko jedną rzecz do dodania do referencji na Facebooku:

Jeśli planujesz skalować bardzo duże, sugeruję, aby uzyskać silnik DB przyjazny dla systemu sysadmin lub przyjazny dla programisty.

Wyjdź z przyjaznej dla programistów i bardzo szybkiej MongoDB, która nie może skalować rozproszenia geograficznego i nie ma możliwości wydajnego i łatwego tworzenia kopii zapasowych. Chociaż tutaj używamy MongoDB, wygląda na to, że Riak lub CouchDB wyglądają lepiej w specyfikacjach sysadmins (nie mam doświadczenia z Riak lub CouchDB)

użytkownik92471
źródło
2
Jeśli zdecydujesz się na skalowanie dużych rozmiarów, dzieje się tak dlatego, że skalowałeś już z mikro na malutkie i od malutkiego na małe, a po drodze nauczyłeś się kilku rzeczy, które pomogą ci dokonać właściwych wyborów. Kiedy będziesz gotowy na skalowanie, możesz pozwolić sobie na inżynierów, którzy wiedzą, jak skalować.
jcolebrand