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
performance
database-recommendation
nosql
scalability
tomaytotomato
źródło
źródło
Odpowiedzi:
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
Dziwne darmowe rzeczy
Niewolne rzeczy
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.
źródło
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.
źródło
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)
źródło