Niedawno dowiedziałem się, że (mówią, że z powodu zmian w licencji). To sprawiło, że zacząłem się zastanawiać, dlaczego przez ostatnie kilka lat widziałem mnóstwo artykułów o tym, jak straszna jest MongoDB i że nikt nie powinien jej używać. Ale w tym czasie MongoDB stała się znacznie bardziej dojrzałym produktem. Co się stało? Czy rzeczywiście cała nienawiść jest skutkiem błędów z początku marketingu tej nowej bazy danych? A może ludzie po prostu stosują MongoDB tam, gdzie nie powinni?
Jeśli wydaje się wam, że bronię MongoDB, proszę przeczytajcie na końcu artykułu.
Nowy trend
Pracuję w przemyśle oprogramowania więcej lat, niż przyzwoicie powiedzieć, ale i tak zdarzyła mi się tylko niewielka część trendów, które uderzyły w naszą branżę. Byłem świadkiem wzrostu 4GL, AOP, Agile, SOA, Web 2.0, AJAX, blockchainu… lista jest nieskończona. Każdego roku pojawiają się nowe tendencje. Niektóre szybko gasną, a inne zasadniczo zmieniają sposoby tworzenia oprogramowania.
Wokół każdego nowego trendu powstaje pewne ogólne poruszenie: ludzie albo sami wskakują do łodzi, albo widzą hałas generowany przez innych — i idą za tłumem. Ten proces został skodyfikowany przez firmę Gartner w . Choć kontrowersyjny, ten wykres mniej więcej opisuje, co dzieje się z technologiami, zanim ostatecznie staną się użyteczne.
Jednak od czasu do czasu pojawia się (lub następuje drugie przyjście, jak to ma miejsce w tym przypadku) nowa innowacja, napędzana tylko jedną jej konkretną realizacją. W przypadku NoSQL hype był silnie związany z pojawieniem się i szybkim wzrostem MongoDB. To nie MongoDB zapoczątkowała ten trend: w rzeczywistości w dużych firmach internetowych zaczęły się problemy z przetwarzaniem dużych ilości danych, które doprowadziły do powrotu nierelacyjnych baz danych. Ogólny ruch rozpoczął się od takich projektów, jak Bigtable od Google i Cassandra od Facebooka, ale to właśnie MongoDB stała się najsłynniejszą i najbardziej dostępną realizacją bazy danych NoSQL, do której mieli dostęp większość deweloperów.
Uwaga: możecie pomyśleć, że mieszam bazy danych dokumentowych z bazami danych kolumnowymi, magazynami klucz/wartość lub jakimkolwiek z licznych innych typów magazynów danych, które mieszczą się w ogólnym definicji NoSQL. I macie rację. Ale w tym czasie panował chaos. Wszyscy oszaleli na punkcie NoSQL, wszystkim się to stało absolutnie jest konieczne, chociaż wielu nie widziało różnic w różnych technologiach. Dla wielu MongoDB stała się synonimem NoSQL.
I deweloperzy rzucili się na nią. Zasada bazy danych bez schemy, która magicznie skalowalnie rozwiązuje każdy problem, była dość kusząca. Około 2014 roku wydawało się, że wszędzie tam, gdzie jeszcze rok temu używano relacyjnych baz danych, takich jak MySQL, Postgres czy SQL Server, zaczęto wdrażać bazy MongoDB. Na pytanie, dlaczego, można było usłyszeć od bananowego "to ze względu na skalę sieci" do bardziej przemyślanej odpowiedzi "moje dane są bardzo słabo ustrukturyzowane i dobrze pasują do bazy danych bez schemy."
Ważne jest, aby pamiętać, że MongoDB i bazy danych dokumentów w ogóle rozwiązują szereg problemów związanych z tradycyjnymi relacyjnymi bazami danych:
- Ścisła schema: w relacyjnej bazie danych, jeśli masz dynamicznie formowane dane, jesteś zmuszony albo stworzyć mnóstwo przypadkowych "różnych" kolumn danych, wcisnąć tam blobów danych albo użyć konfiguracji … wszystkie te rozwiązania mają znaczne wady.
- Trudność skalowania: gdy danych jest na tyle dużo, że nie mieszczą się na jednym serwerze, MongoDB oferowała mechanizmy umożliwiające skalowanie na wielu maszynach.
- Skomplikowane modyfikacje schemy: brak migracji! W relacyjnej bazie danych zmiana struktury bazy danych może stać się ogromnym problemem (szczególnie gdy danych robi się bardzo dużo). MongoDB znacząco uprościła ten proces. I uczyniła go na tyle prostym, że możesz po prostu aktualizować schemę w locie i bardzo szybko iść dalej.
- Wydajność zapisu: wydajność MongoDB była dobra, szczególnie przy odpowiedniej konfiguracji. Nawet konfiguracja MongoDB prosto z pudełka, za którą często ją krytykowano, wykazywała imponujące wyniki wydajności.
Wszystkie ryzyka na ciebie
Potencjalne korzyści z MongoDB były ogromne, szczególnie dla określonych klas problemów. Jeśli przeczytasz powyższą listę bez zrozumienia kontekstu i nie mając doświadczenia, możesz odnieść wrażenie, że MongoDB to naprawdę rewolucyjna SGBD. Jedynym problemem było to, że wymienione powyżej korzyści były związane z pewnymi zastrzeżeniami, z których niektóre są poniżej.
Dla sprawiedliwości, nikt w 10gen/MongoDB Inc. nie powie, że to, co następuje, jest nieprawdą, to po prostu kompromisy.
- Utrata transakcji: transakcje są kluczową cechą wielu relacyjnych baz danych (nie wszystkich, ale większości). Transakcyjność oznacza, że możesz wykonywać kilka operacji atomowo i możesz zagwarantować, że dane pozostaną spójne. Oczywiście, w bazach danych NoSQL transakcyjność może być ograniczona do jednego dokumentu lub możesz używać dwuetapowych zatwierdzeń, aby uzyskać semantykę transakcyjną. Ale będziesz musiał samodzielnie zaimplementować tę funkcjonalność... co może być skomplikowanym i czasochłonnym zadaniem. Często nie zdajesz sobie sprawy z problemów, dopóki nie zobaczysz, że dane w bazie danych trafiają w nieprawidłowe stany, ponieważ nie można zagwarantować atomowości operacji. Uwaga: wiele osób informowało mnie, że w MongoDB 4.0 wprowadzono transakcje, ale z pewnymi ograniczeniami. Wniosek z artykułu pozostaje niezmienny: oceń, jak technologia odpowiada Twoim potrzebom.
- Utrata integralności relacyjnej (klucze obce): jeśli w Twoich danych są relacje, będziesz musiał je zastosować w aplikacji. Posiadanie bazy danych przestrzegającej tych relacji znacznie zredukuje pracę w aplikacji i, co za tym idzie, obciążenie programistów.
- Brak możliwości zastosowania struktury danych: ścisłe schemy czasami stanowią duży problem, ale są także potężnym mechanizmem dobrego strukturalizowania danych, jeśli używa się ich właściwie. Bazy danych dokumentowe, takie jak MongoDB, zapewniają niesamowitą elastyczność schemy, ale ta elastyczność zdejmuje odpowiedzialność za utrzymanie danych w porządku. Jeśli nie zadbasz o nie, w końcu będziesz musiał napisać w aplikacji dużo kodu, aby uwzględnić dane, które nie są przechowywane w oczekiwanej formie. Jak często mówi się w naszej firmie Simple Thread… aplikację pewnego dnia przepiszą, a dane będą żyły wiecznie. Uwaga: MongoDB obsługuje walidację schematów: jest przydatna, ale nie zapewnia tych samych gwarancji co relacyjne bazy danych. Przede wszystkim dodanie lub zmiana walidacji schematów nie wpływa na istniejące dane w kolekcji. Musisz sam upewnić się, że aktualizujesz dane zgodnie z nowym schematem. Sam decydujesz, czy to wystarcza do Twoich potrzeb.
- Własny język zapytań / utrata ekosystemu narzędzi: pojawienie się SQL stanowiło absolutną rewolucję, a od tego czasu nic się nie zmieniło. To niezwykle potężny język, ale też dość skomplikowany. Konieczność konstruowania zapytań do bazy danych w nowym języku, składającym się z fragmentów JSON, jest postrzegana jako duży krok w tył przez osób z doświadczeniem w SQL. Istnieje cały wszechświat narzędzi, które współdziałają z bazami danych SQL: od IDE po narzędzia do raportowania. Przejście do bazy danych, która nie obsługuje SQL, oznacza, że nie możesz korzystać z większości tych narzędzi lub musisz przetłumaczyć dane na SQL, aby ich użyć, co może okazać się trudniejsze, niż myślisz.
Wielu programistów, którzy przeszli na MongoDB, nie do końca rozumiało kompromisy i często nurkowali na głęboko wprowadzając ją jako główne przechowywanie danych. Po tym było niezwykle trudno wrócić.
Co można było zrobić inaczej?
Nie wszyscy rzucili się na główkę i wpadli w dno. Ale wiele projektów zainstalowało MongoDB tam, gdzie po prostu nie pasowała - i będą musieli z nią żyć przez wiele lat. Gdyby te organizacje poświęciły trochę czasu na staranne przemyślenie wyboru technologii, wiele z nich dokonałoby innego wyboru.
Jak wybrać odpowiednią technologię? Było kilka prób stworzenia systematycznego frameworku do oceny technologii, takich jak i , ale wydaje mi się, że to zbyteczna komplikacja.
Wiele technologii można rozsądnie ocenić, zadając tylko dwa podstawowe pytania. Problem polega na znalezieniu ludzi, którzy mogą odpowiedzialnie na nie odpowiedzieć, poświęcając czas na szukanie odpowiedzi i bez uprzedzeń.
Jeśli nie napotykasz żadnego problemu, nie potrzebujesz nowego narzędzia. Kropka.
Pytanie 1: Jakie problemy próbuję rozwiązać?
Jeśli nie borykasz się z żadnym problemem, nie potrzebujesz nowego narzędzia. Kropka. Nie szukaj rozwiązania, a potem wymyślaj problem. Jeśli nie napotkałeś problemu, który nowa technologia rozwiązuje znacznie lepiej niż Twoja dotychczasowa technologia, nie ma o czym dyskutować. Jeśli rozważasz wykorzystanie tej technologii, ponieważ widziałeś, jak korzystają z niej inni, pomyśl, z jakimi problemami się borykają i spytaj, czy masz podobne trudności. Łatwo jest przyjąć technologię, bo używają jej inni, trudność polega na zrozumieniu, czy masz te same problemy.
Pytanie 2: Czego się pozbywam?
To zdecydowanie trudniejsze pytanie, ponieważ będziesz musiał zagłębić się w zrozumienie zarówno starej, jak i nowej technologii. Czasami nie możesz naprawdę zrozumieć nowej, dopóki nie stworzysz z jej pomocą czegoś lub nie zatrudnisz kogoś, kto ma takie doświadczenie.
Jeśli nie masz ani jednego, ani drugiego, warto pomyśleć o minimalnych inwestycjach, aby określić wartość tego narzędzia. A jeśli zdecydujesz się na inwestycje, jak trudno będzie cofnąć tę decyzję?
Ludzie zawsze wszystko psują
Starając się odpowiedzieć na te pytania jak najbardziej bezstronnie, pamiętaj o jednej rzeczy: będziesz musiał zmierzyć się z ludzką naturą. Istnieje szereg poznawczych zniekształceń, które trzeba przezwyciężyć, aby skutecznie ocenić technologię. Oto kilka z nich:
- — wszyscy o nim wiedzą, ale wciąż trudno z nim walczyć. Upewnij się, że technologia naprawdę odpowiada Twoim rzeczywistym potrzebom.
- — wielu programistów ma tendencję do niedoceniania technologii, z którymi pracowali przez długi czas, i przeceniania korzyści płynących z nowej technologii. Nie tylko programiści, wszyscy są podatni na to poznawcze zniekształcenie.
- — tendencja do dostrzegania tego, co jest, i ignorowania tego, czego brakuje. To może prowadzić do chaosu w połączeniu z efektem nowości, ponieważ nie tylko zasadniczo przeceniasz nową technologię, ale także ignorujesz jej wady..
Obiektywna ocena nie jest łatwa do dokonania, ale zrozumienie podstawowych zniekształceń poznawczych pomoże podjąć bardziej racjonalne decyzje.
Podsumowanie
Gdy pojawia się nowa innowacja, należy ostrożnie odpowiedzieć na dwa pytania:
- Czy to narzędzie rozwiązuje rzeczywisty problem?
- Czy dobrze rozumiemy kompromisy?
Jeśli nie możesz pewnie odpowiedzieć na te dwa pytania, cofnij się na chwilę i zastanów.
Czy MongoDB była rzeczywiście dobrym wyborem? Oczywiście, że tak; jak w przypadku większości technologii inżynieryjnych, zależy to od wielu czynników. Wśród tych, którzy odpowiedzieli na te dwa pytania, wielu skorzystało z MongoDB i nadal korzysta. Mam nadzieję, że ci, którzy tego nie zrobili, zdobyli cenną i niezbyt bolesną lekcję na temat cyklu hype'u.
Wyłączenie odpowiedzialności
Chcę zaznaczyć, że nie czuję ani miłości, ani nienawiści do MongoDB. Po prostu nie mieliśmy problemów, które najlepiej rozwiązywałaby MongoDB. Wiem, że 10gen/MongoDB Inc. początkowo działało bardzo odważnie, ustalając niebezpieczne domyślne wartości i promując MongoDB wszędzie (zwłaszcza na hackatonach) jako uniwersalne rozwiązanie do pracy z danymi. Prawdopodobnie była to zła decyzja. Jednak potwierdza to opisane tutaj podejście: problemy te można było szybko zidentyfikować nawet przy powierzchownej ocenie technologii.
Źródło: habr.com
