Jaka jest atrakcyjność systemów baz danych bez systemu?

Question

Słyszałem dużo mówi się o schemat mniej (często dystrybuowane) systemy baz danych, takich jak MongoDB, CouchDB, SimpleDB, itp ...

ile mogę zrozumieć, mogą być cenne dla pewnych celów, w większości moich aplikacji próbuję utrwalać obiekty, które mają określoną liczbę pól określonego typu, i po prostu automatycznie myślę w modelu relacyjnym. Zawsze myślę w kategoriach wierszy z unikalnymi liczbami całkowitymi, polami null/not null, typami danych SQL i wybranymi zapytaniami, aby znaleźć zestawy.

Podczas gdy jestem zainteresowany rozproszonym charakterem i łatwym interfejsem JSON/RESTful tych nowych systemów, nie rozumiem, jak luźno wpisane skróty klawiszowe/wartościowe pomogą mi w rozwoju. Dlaczego luźny, napisany na maszynie, pozbawiony schematów system byłby dobry do przechowywania czystych zestawów danych? Jak mogę na przykład znaleźć wszystkie przedmioty z datami między X i Y, kiedy mogą nie mieć dat? Czy istnieje koncepcja łączenia?

Rozumiem, że wiele systemów ma swoje własne różnice i mocne strony, ale zastanawiam się nad różnicą w paradygmacie. Przypuszczam, że jest to pytanie otwarte, ale być może odpowiedzi społeczności i sposoby, w jakie osobiście widzieli zalety tych systemów, pomogą mi i innym wyjaśnić, kiedy chciałbym skorzystać z tych (wprawdzie bardziej biodrowych) systemów zamiast tradycyjne RDBMS.

Answer 1

Ja po prostu wywołać jedną lub dwie typowe przyczyny (Jestem pewien, że ludzie będą pisać odpowiedzi esej)

1. przypadku systemów wysoce rozproszonych, każdy dany zestaw danych może być rozłożone na wielu serwerach. Kiedy tak się dzieje, ograniczenia relacyjne, które silnik DB może zagwarantować, są znacznie zredukowane. Część Twojej referencyjnej integralności będzie musiała być obsługiwana w kodzie aplikacji.Dokonując tego, można szybko dowiedzieć się kilka punktów bólu:

   • logika jest rozłożone na wielu warstwach (APP i db)
   • logika jest rozłożone na wiele języków (SQL i app języku wyboru)

   W rezultacie logika jest mniej zamknięta, mniej przenośna, a DUŻO droższa do zmiany. Wielu programistów znajduje sobie więcej logiki w kodzie aplikacji, a mniej w bazie danych. Podsumowując, schemat bazy danych staje się nieistotny.

2. Zarządzanie schematami - szczególnie w systemach, w których przestój nie wchodzi w grę - jest trudne. zmniejszenie złożoności schematu zmniejsza tę trudność.

3. ACID nie działa zbyt dobrze w systemach rozproszonych (BASE, CAP itp.). Język SQL (i cały model relacyjny do pewnego stopnia) jest zoptymalizowany pod kątem świata transakcji ACID. Niektóre funkcje języka SQL i sprawdzone metody są bezużyteczne, a inne szkodliwe. Niektórzy deweloperzy czują się niekomfortowo w stosunku do "przeciw" i wolą zrzucić SQL całkowicie na korzyść języka, który został zaprojektowany od podstaw pod kątem ich wymagań.

4. Koszt: większość systemów RDBMS nie jest bezpłatna. Liderzy skalowania (Oracle, Sybase, SQL Server) są produktami komercyjnymi. W przypadku dużych systemów ("sieciowych") koszty licencjonowania bazy danych mogą osiągnąć lub przewyższyć koszty sprzętu! Koszty są na tyle wysokie, aby zmienić normalny build/kupić względy drastycznie w kierunku budowania niestandardowych rozwiązań na szczycie oferty OSS (wszystkie znaczące ofiary NoSQL są OSS)

Answer 2

Grałem tylko z MongoDB, ale naprawdę interesowało mnie to, w jaki sposób można zagnieździć dokumenty. W MongoDB dokument jest zasadniczo jak zapis. Jest to naprawdę miłe, ponieważ tradycyjnie, w RDBMS, jeśli musisz pobrać rekord "Person" i uzyskać powiązany adres, informacje o pracodawcy itp., Często musiałbyś iść do wielu tabel, łączyć je, tworzyć wiele baz danych połączenia. W rozwiązaniu NoSQL, takim jak MongoDB, można po prostu zagnieździć skojarzone rekordy (dokumenty) i nie musieć mieszać z kluczami obcymi, łącząc się, wiele wywołań baz danych. Wszystko, co wiąże się z tym jednym rekordem, zostaje wyciągnięte.

Jest to szczególnie przydatne podczas pracy z przedmiotami. W wielu przypadkach można po prostu przechowywać obiekt jako serię zagnieżdżonych dokumentów.

Answer 3

Zwykle atrakcją jest olej wężowy - większość osób, które je faworyzują, nie ma pojęcia o twierdzeniu o relacjach i mówi językiem SQL na poziomie profesjonalisty rzygając. Nie mam pojęcia, jakie są warunki ACID, dlaczego są ważne itd.

Nie mówię, że nie mają ważnych zastosowań ... tylko dlatego, że głównie atrakcją są ludzie, którzy nie wiedzą, co powinni wiedzieć i wyciągają głupie wnioski. Ponownie, nie wszyscy są tacy, ale większość deweloperów faworyzujących ich nie jest w stanie zrozumieć, za co system bazy danych jest ostro odpowiedzialny.

Answer 4

Podstawową troską powinno być to, czego potrzebujesz zrobić z twoimi danymi. Jeśli masz ogromny zestaw danych i uważasz, że tradycyjny RDBMS jest wąskim gardłem, możesz poeksperymentować z szablonem lub rozwiązaniem NOSQL.

Większość środowisk, o których wiem, że korzystam z rozwiązań NOSQL, również korzysta z rozwiązania RDBMS w pewnej formie lub w inny sposób. Rozwiązania oparte na RDBMS są normą, w której integralność danych jest niezwykle ważna i potrzebne są transakcje ACID. Jeśli jednak twój system nie jest oparty na dużej ilości transakcji, ale musisz skalować lub skalować się naprawdę szybko, może być pożądane rozwiązanie NOSQL.

Answer 5

Bazy danych NoSQL nie są bezzasadne; schemat jest osadzony w danych. Są właściwie nazwane semistrukturą. Jednak w niektórych magazynach danych KV schemat może być nawet osadzony w kodzie. Zaletą podejścia półstrukturalnego jest dwojakie: elastyczność, w której kolumny są częścią rzędu (jeden wiersz może mieć 5 kolumn, a drugi 5 różnych kolumn i elastyczność w charakterystyce kolumn (np. O zmiennej długości)

Answer 6

Schemaless jest idealne dla dwóch powodów.

1. mózgu optymalizacji intuicyjności przechowywania dokumentów
2. postanawia Sparse-Matrix i Entity-Attribute-Value problemów związanych z przechowywaniem

Użyłem Bo th SQL i No-SQL dla aplikacji produkcyjnych w Ruby on Rails. Nie jestem ekspertem od baz danych i muszę przyznać, że szukałem w Google hasła ACID i podobnych terminów, ponieważ nie są mi one znane.

"Ah ha!" Można powiedzieć, że jest to kolejna osoba, która śledzi trendy w sieci. Ale tak naprawdę jestem bardzo zadowolony z mojej decyzji o użyciu MongoDB w naszej najnowszej 2-letniej aplikacji i oto dlaczego ...

Odwrotną intuicyjną intuicją w zakresie optymalizacji mózgu było moje doświadczenie z e-mailem Magento. system handlu. Nie chcę go bashować, ponieważ dobrze mi wtedy służyło, ale naprawdę mocno uderzyło w procesor, próbując obliczyć atrybuty każdego produktu. Podstawową przyczyną było przechowywanie danych produktów w postaci atrybut-wartość-wartości. Pamięć podręczna lub cholerna była rozwiązaniem.

Główną zaletą jest dla mnie optymalizacja w jedynym miejscu, które naprawdę ma znaczenie - Twój własny mózg. Tak wiele technologii jest krytykowanych pod kątem ich wydajności w pamięci, procesorach, sprzęcie, a jednak posiadanie bazy danych, która jest niezwykle intuicyjna w zrozumieniu, ma swoje zalety. Szybko dodaliśmy funkcje do naszego kodu, ponieważ baza danych wygląda po prostu tak, jak w rzeczywistym świecie, który modelujemy. Kiedy poprosiłem klientów e-commerce, aby zaprezentowali mi swoją listę produktów, będą naturalnie korzystać z Excela (think table store). Pierwsze kolumny są proste:

1. Nazwa produktu
2. Cena
3. Product Type (

Wtedy staje się trudniejsze i pokryte notatki, kolory i linki do innych tabel (tak .. relacje)

4. Kolor (Tylko niektóre produkty)
5. Size (X Duży, Duży, SM wszystkie) - tylko dla produktów 8'9'10, kije golfowe mają inną skalę
6. Kolor 2. Obroże dla kota mają dwa wybory kolorów.
7. Moc
8. typ Mocowanie (Mężczyzna, Kobieta)

Tak kończy się to w strasznym bałaganie tabelach Excela które sprawiają, że nie ma sensu do mnie, a nie większego sensu dla ludzi, którzy pracują z dnia produktów w i dzień wolny. Rzucamy ramiona w powietrze i decydujemy się przejść przez katalog, a potem uderza mnie! Czy nie byłoby wspaniale, gdybyś mógł przechowywać dane tak, jak pojawiają się w katalogu !? Tylko kolekcje rekordów na temat każdego produktu, które po prostu wymieniają atrybut tego produktu. Następnie możesz wybrać wspólne atrybuty do indeksowania w celu pobrania w późniejszym terminie. Oczywiście, że to sklep z dokumentami.

Podsumowując, magazyny dokumentów są świetne, gdy masz problem z rzadką macierzą lub obiekty, które zmieniają swoje atrybuty w czasie. Po 2 latach życia w świecie bez SQL nie mogę sobie wyobrazić prawdziwego świata, który nie ma tych funkcji, ponieważ świat wygląda jak sklep z dokumentami.