Dlaczego jest taki hype na NoSQL?

1

DynamoDB, CosmoDB, MongoDB, Elasticsearch i 50 innych...

Skąd to się bierze?

Dlaczego tyle osób, które i tak nie wychodzą z danymi poza pewien schemat pcha się w np. Mongo?

Czy jest jakaś większa firma, która postawiła na np. bazy grafowe? czy to po prostu takie zabawki?

1

Niedawno pojawił się artykuł o tym, że Guardian przechodzi z Mongo na Postgresa
https://www.theguardian.com/info/2018/nov/30/bye-bye-mongo-hello-postgres

Oraz dyskusja na Hacker Newsach na ten temat
https://news.ycombinator.com/item?id=18717168

4

Zapewne chodzi o hipsterstwo. Innego wytłumaczenia nie mam. I tak patrząc po ofertach pracy czy firmach i ich stacku danego projektu zauważyłem pewną zasadę. Jak ktoś używa parcha typu Ruby to tak samo cudownie dobiera do tego bazę typu Mongo, Kongo, Srongo. Jak ogłoszenie zawiera poważne technologie albo firma ma projekt w poważnych technologiach to i w db nie ma hipsteriady :-)

1

Niektórzy uważają SQL za trudny i myślą że bez bazy SQL można zatrudnić słabych programistów czytaj tanich programistów

5

To zależy które NoSQL. Są hipsterskie, ale są też takie które mają poważne zastosowania.

Nie wypowiem się o innych, ale bazy takie jak Cassandra (w tym komercyjne odmiany: DataStax Enterprise oraz ScyllaDB) stosuje się gdy:

  • wymagana jest wysoka niezawodność - brak takiego punktu, który gdy zawiedzie, to baza przestaje działać
  • system jest mocno rozproszony geograficznie, globalny - trudno zrobić wydajny system na scentralizowanym RDBMSie, który stoi w USA, a klienci są też w Europie, Indiach i Japonii.
  • wymagana jest duża wydajność, przekraczająca moc pojedynczego serwera - jakiś RDBMS zrobi milion zapisów na sekundę na jednym serwerze? No raczej nie. A DSE lub Scylla owszem. Dodasz drugi serwer i masz 2 miliony. Trzeci i masz trzy. Itd.
  • wymagana jest wysoka dostępność kosztem nawet spójności
  • wymagana jest możliwość aktualizacji bazy bez zatrzymywania systemu
0

Zarówno Elasticsearch jak i Redis to praktyczne rozwiązania, świetnie uzupełniają relacyjne bazy,

1
Krolik napisał(a):

To zależy które NoSQL. Są hipsterskie, ale są też takie które mają poważne zastosowania.

  • wymagana jest duża wydajność, przekraczająca moc pojedynczego serwera - jakiś RDBMS zrobi milion zapisów na sekundę na jednym serwerze? No raczej nie. A DSE lub Scylla owszem. Dodasz drugi serwer i masz 2 miliony. Trzeci i masz trzy. Itd.

To mi wygląda na podejrzane stwierdzenie o tym milionie zapisów. Żadna baza nie zapisze więcej niż storage jest w stanie łyknąć.
Najszybsze dyski ssd (https://smartiops.com/worlds-fastest-ssds/) oferują 1.7M IOPS.

To DSE czy Scylla to o jakim hardware mowa?

0

@WeiXiao: akurat ElasticSearch ma praktyczne zastosowania i nijak się kłóci z używaniem baz relacyjnych ;). Jak masz sklep internetowy (mówie o powaznym sklepie takim np. amazon) to ciężkobyłoby oprzeć wyszukiwarkę o postgresa samego, nie sądzisz?

0
scibi92 napisał(a):

@WeiXiao: akurat ElasticSearch ma praktyczne zastosowania i nijak się kłóci z używaniem baz relacyjnych ;). Jak masz sklep internetowy (mówie o powaznym sklepie takim np. amazon) to ciężkobyłoby oprzeć wyszukiwarkę o postgresa samego, nie sądzisz?

Nie napisałem, że nie ma praktycznego zastosowania :P Ba, każda z w/w baz ma jakieś swoje use-casy

Bardziej z tym Hype chodzi mi o sytuacje, gdy ktoś używa takich narzędzi do sklepu z 20 produktami i 20 klientami dziennie.

Można, ale po co?

0

Chciałbym zobaczyć warzywniak ze stroną korzystająca z NoSQL :D Wiem, wiem- to była tylko przenośnia. Co do samego pytania to nie wydaje mi się żeby naprawdę był taki hype. A co do tego że można gdzieś zastosować "zwykłą" bazę SQL, to dla czego koniecznie ma być to lepsza alternatywą? Jeśli ktoś ma proste modele, i może sobie wszystko wrzucać jako bloby- dla czego miałby nie skorzystać z jakiegos document db? Po co na siłę pakować wszystko w model relacyjny, albo jeszcze lepiej bawić się w hacki w postaci pakowania całego dokumentu jako kolumna w tabeli?

1

@Aventus:

Chciałbym zobaczyć warzywniak ze stroną korzystająca z NoSQL

W Krakowie masz Ocado :)

2

Jedna z większych europejskich linii lotniczych ma intranet (powiedzmy - trudno precyzyjnie nazwać) postawiony na jednym z NoSQLi. Działa dobrze, 40 tysięcy użytkowników, widze użycie na lotniskach. . Konkurencja wtedy robiła podobny (technologicznie) mniejszy system na SQL (DB2 ... można zgadnąć jaka konkurencja). Nie wiem czy się im udało, bo mieli dramatyczne problemy wydajnościowe.
NoSQL to wiele bardzo różnych rozwiązań - Cassandra, Redis, Neo4J itd.. Popolarne MongoDb, kojarzone z NoSQL... nawet nigdy nie widziałem w użyciu w moich firmach.

Do pewnych rzeczy SQL się słabo nadaje. Na przykład jeśli, masz dość skomplikowany model danych :-). SQL jest jednak prymitywnie prostokątny.

1

Akurat jeżeli chodzi o SBD jak Cassandra, Riak, HBase to jestem w stanie zrozumieć dlaczego ktoś chciałby z nich skorzystać zamiast z czegoś relacyjnego. Kwestia skalowalności horyzontalnej i dostępności w przypadku naprawdę dużych wdrożeń. Tak samo swoje praktyczne zastosowania ma Redis.

W książce "Beautiful Data: The Stories Behind Elegant Data Solutions" jest rozdział o analizie "clickstream" przez Facebooka, który próbowali zrobić przy pomocy rozwiązań do tworzenia magazynów danych od Oracle. Bardzo ładnie się wyłożyło, szybko przepisali na własne rozwiązanie, a zaraz potem przemigrowali się na Hadoopa i paradygmat MapReduce.

Chociaż patrząc na projekty jak Vitess, CockroachDB, Spanner i tren NewSQL to jednak programiści tęsknią za SQLem ;).

0

Przeczytałem z uwagą ten temat i z kilkoma argumentami się zgadzam, a kilkoma nie.

0

@jarekr000000: jak zapatrujesz się na fakt, że do bazy nosqlowej bez ściśle określonej schemy łatwiej niż w sqlu z constraintami wpakować jakieś niespójne dane? Masz jakieś podejście ułatwiające uniknięcie tego? Wiem, że baza relacyjna i tak nie daje takiej elastyczności jak model obiektowy, ale zawsze to jakieś lepsze zabezpieczenie IMHO.

1
mad_penguin napisał(a):

@jarekr000000: jak zapatrujesz się na fakt, że do bazy nosqlowej bez ściśle określonej schemy łatwiej niż w sqlu z constraintami wpakować jakieś niespójne dane? Masz jakieś podejście ułatwiające uniknięcie tego? Wiem, że baza relacyjna i tak nie daje takiej elastyczności jak model obiektowy, ale zawsze to jakieś lepsze zabezpieczenie IMHO.

Jeśli użytkownicy końcowi dostają konsolę do wykonywania zapytań (w tym insert/update) to rzeczywiście baza SQL z constraintami jest lepsza.
Jeśli jednak w aplikacji w jakikolwiek sposób walidujesz dane przed ich wstawieniem do bazy to ta przewaga nie jest już tak oczywista.

0
mad_penguin napisał(a):

@jarekr000000: jak zapatrujesz się na fakt, że do bazy nosqlowej bez ściśle określonej schemy łatwiej niż w sqlu z constraintami wpakować jakieś niespójne dane?

To potrzebuje dłuższej odpowiedzi, ale krótka jest taka:

W życiu, w odróżnieniu od relacyjnych baz danych, dane są niespójne.

1 użytkowników online, w tym zalogowanych: 0, gości: 1