NoSQL (Cassandra/Mongo) kontra RDBMS

Relacyjne bazy danych i bazy danych nosql to różne bestie. Relacyjne bazy danych dobrze sprawdzają się w większości przypadków użycia, ale nie są w stanie obsłużyć danych w skali internetowej, w których miliony rekordów pojawiają się w ułamku czasu. W celu rozwiązania tych problemów (dane w skali internetowej) opracowano rozwiązania nosql. Nie myśl więc, że organizacje wolą nosql tylko ze względu na tanie utrzymanie, to przypadek użycia określa, jakiego rodzaju technologii bazodanowej użyć.

przeczytaj, że wiele dużych firm używa shard rmdb

W mojej ostatniej pracy moja organizacja obsługiwała ręcznie shardowane rozwiązanie Postgres. Było to dla nas źródłem ogromnego bólu, ponieważ było trudne w utrzymaniu i utrzymaniu ze względu na swoje rozmiary. Pamiętaj, że RDBMS nie zostały zaprojektowane do pracy w ten sposób.

jedyną zaletą nosql ... jest to, że jest to rozwiązanie dystrybuowane z półki

Decyzja dotyczy tak naprawdę kompromisów. Gdy Twoje obciążenia danych nie mogą być obsługiwane przez pojedynczą instancję bazy danych lub potrzebujesz czasu pracy bez pojedynczego punktu awarii, NoSQL może Ci pomóc. Bazy danych, które poświęcają spójność ze względu na tolerancję i dostępność partycji (bazy danych „AP”), często są w stanie przetwarzać duże obciążenia z niewielkim opóźnieniem ze względu na ich zdolność do rozprzestrzeniania danych (a tym samym zapytań) na wiele instancji serwera.

Ponadto, jeśli Twoje dane muszą być świadome lokalizacji geograficznej lub centrum danych, będziesz potrzebować bazy danych, która to obsługuje. Próba sprawienia, aby produkty bazodanowe działały w sposób, którego nie uwzględniał ich oryginalny projekt, jest receptą na ból.

tanie w utrzymaniu

Zapytaj każdego, kto prowadzi korporacyjną organizację bazodanową, a powie Ci, że NoSQL nie jest tani (ani łatwy) w utrzymaniu. Oczywiście, możesz otrzymać produkt open source, którego nie musisz „kupować”, ale będziesz potrzebować (często wysoko opłacanych) inżynierów baz danych, aby go utrzymać.