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

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

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.

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.

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)