Niedawno się tego dowiedziałem (powiedzmy, ze względu na zmiany licencji). Pomyślałem, że w ciągu ostatnich kilku lat widziałem wiele artykułów o tym, jak okropny jest MongoDB i że nikt nigdy nie powinien go używać. Ale w tym czasie MongoDB stał się znacznie bardziej dojrzałym produktem. Co się stało? Czy cała nienawiść jest naprawdę spowodowana błędami na początku marketingu nowego DBMS? A może ludzie po prostu używają MongoDB w niewłaściwym miejscu?
Jeśli nagle poczujesz, że bronię MongoDB, przeczytaj na końcu artykułu.
Nowy trend
Jestem w branży oprogramowania od lat więcej, niż można to uczciwie powiedzieć, ale nadal byłem tylko częścią trendów, które uderzyły w naszą branżę. Byłem świadkiem powstania 4GL, AOP, Agile, SOA, Web 2.0, AJAX, blockchain… lista nie ma końca. Co roku pojawiają się nowe trendy. Niektóre szybko zanikają, podczas gdy inne zasadniczo zmieniają sposób tworzenia oprogramowania.
Wokół każdego nowego trendu powstaje ogólna ekscytacja: ludzie albo sami wskakują do łodzi, albo widzą hałas generowany przez innych - i podążają za tłumem. Proces ten został skodyfikowany przez firmę Gartner w . Choć dyskusyjny, ten wykres z grubsza opisuje, co dzieje się z technologiami, zanim ostatecznie staną się przydatne do użytku.
Ale od czasu do czasu pojawia się (lub jak w tym przypadku powtórne nadejście) nowa innowacja, napędzana tylko jedną konkretną implementacją. W przypadku NoSQL hype był w dużym stopniu napędzany pojawieniem się i błyskawicznym rozwojem MongoDB. MongoDB nie zapoczątkował tego trendu: tak naprawdę duże firmy internetowe zaczęły mieć problemy z przetwarzaniem dużych ilości danych, co doprowadziło do powrotu nierelacyjnych baz danych. Ogólny ruch rozpoczął się od projektów takich jak Bigtable firmy Google i Cassandra Facebooka, ale to MongoDB stało się najbardziej znaną i dostępną implementacją bazy danych NoSQL, do której dostęp miała większość programistów.
Uwaga: możesz pomyśleć, że mylę bazy danych dokumentów z bazami danych kolumn, magazynami kluczy/wartości lub dowolnymi innymi typami magazynów danych, które mieszczą się w ogólnej definicji NoSQL. I masz rację. Ale wtedy panował chaos. Wszyscy mają obsesję na punkcie NoSQL, stał się wszystkim absolutnie konieczne, chociaż wielu nie dostrzegało różnic w różnych technologiach. Dla wielu stał się MongoDB równoznaczny NoSQL.
I twórcy na to wpadli. Pomysł na bezschematyczną bazę danych, która magicznie skaluje się w celu rozwiązania dowolnego problemu, był dość kuszący. 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, wdrażano bazy danych MongoDB. Na pytanie dlaczego można było uzyskać odpowiedzi od banalnych „taka jest skala sieci” do bardziej przemyślanych „moje dane są bardzo luźno ustrukturyzowane i dobrze mieszczą się w bazie danych bez schematu”.
Należy pamiętać, że MongoDB i ogólnie bazy danych dokumentów rozwiązują szereg problemów z tradycyjnymi relacyjnymi bazami danych:
- Ścisły schemat: w relacyjnej bazie danych, jeśli masz dynamicznie generowane dane, jesteś zmuszony albo utworzyć kilka losowych „różnych” kolumn danych, wepchnąć tam obiekty blob danych, albo użyć konfiguracji … wszystko to ma istotne wady.
- Trudność skalowania: Jeśli danych jest tak dużo, że nie mieszczą się one na jednym serwerze, MongoDB oferuje mechanizmy umożliwiające skalowanie ich na wielu komputerach.
- Złożone modyfikacje obwodów: żadnych migracji! W relacyjnej bazie danych zmiana struktury bazy danych może być ogromnym problemem (zwłaszcza gdy danych jest dużo). MongoDB był w stanie znacznie uprościć ten proces. I uczynił to tak łatwym, że możesz po prostu zaktualizować schemat w ruchu i przejść naprawdę szybko.
- Napisz wydajność: Wydajność MongoDB była dobra, zwłaszcza po odpowiednim dostrojeniu. Nawet gotowa konfiguracja MongoDB, za którą często była krytykowana, wykazała imponujące wyniki wydajności.
Całe ryzyko spoczywa na tobie
Potencjalne korzyści MongoDB były ogromne, szczególnie w przypadku niektórych klas problemów. Jeśli czytasz powyższą listę bez zrozumienia kontekstu i bez doświadczenia, możesz odnieść wrażenie, że MongoDB to tak naprawdę rewolucyjny DBMS. Jedynym problemem było to, że wymienione powyżej korzyści wiązały się z wieloma zastrzeżeniami, z których niektóre wymieniono poniżej.
Szczerze mówiąc, nikt w 10gen/MongoDB Inc. nie powie, że poniższe nie jest prawdą, to są tylko kompromisy.
- Utrata transakcjiO: Transakcje są podstawową funkcją wielu relacyjnych baz danych (nie wszystkich, ale większości). Transakcja oznacza, że możesz wykonywać wiele operacji w sposób atomowy i możesz zapewnić spójność danych. Oczywiście w przypadku bazy danych NoSQL transakcyjność może dotyczyć pojedynczego dokumentu lub można użyć zatwierdzeń dwufazowych w celu uzyskania semantyki transakcyjnej. Ale będziesz musiał sam zaimplementować tę funkcjonalność… co może być trudnym i czasochłonnym zadaniem. Często nie zdajesz sobie sprawy z problemu, dopóki nie zobaczysz, że dane w bazie danych przechodzą w nieprawidłowe stany, ponieważ nie można zagwarantować niepodzielności operacji. Uwaga: wiele osób mówiło mi, że transakcje zostały wprowadzone w MongoDB 4.0 w zeszłym roku, ale z pewnymi ograniczeniami. Wniosek z artykułu pozostaje ten sam: oceń, jak technologia odpowiada Twoim potrzebom.
- Utrata integralności relacji (klucze obce): jeśli Twoje dane mają powiązania, będziesz musiał zastosować je w aplikacji. Posiadanie bazy danych, która szanuje te relacje, odciąży aplikację, a tym samym programistów.
- Niemożność zastosowania struktury danych: Ścisłe schematy mogą czasami stanowić duży problem, ale są również potężnym mechanizmem dobrej strukturyzowania danych, jeśli są używane mądrze. Bazy danych dokumentów, takie jak MongoDB, zapewniają niesamowitą elastyczność schematów, ale ta elastyczność usuwa odpowiedzialność za utrzymanie danych w czystości. Jeśli o nie nie zadbasz, skończysz pisząc dużo kodu w swojej aplikacji, aby uwzględnić dane, które nie są przechowywane w oczekiwanej formie. Jak często mówią w naszej firmie Simple Thread… aplikacja kiedyś zostanie napisana od nowa, ale dane będą żyły wiecznie. Uwaga: MongoDB obsługuje sprawdzanie poprawności schematu, co jest przydatne, ale nie zapewnia takich samych gwarancji jak relacyjna baza danych. Przede wszystkim dodanie lub zmiana walidacji schematu nie wpływa na istniejące dane w kolekcji. Musisz upewnić się, że aktualizujesz dane zgodnie z nowym schematem. Sam zdecyduj, czy to wystarczy na Twoje potrzeby.
- Własny język zapytań / utrata ekosystemu narzędzi: Pojawienie się SQL było absolutną rewolucją i od tego czasu nic się nie zmieniło. To niezwykle potężny język, ale także dość złożony. Konieczność konstruowania zapytań do baz danych w nowym języku, składającym się z fragmentów JSON, przez osoby mające doświadczenie z SQL jest postrzegana jako duży krok wstecz. Istnieje całe spektrum narzędzi współpracujących 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 przekonwertować dane na SQL, aby z nich korzystać, co może być trudniejsze niż myślisz.
Wielu programistów, którzy zwrócili się do MongoDB, tak naprawdę nie rozumiało kompromisów i często rzuciło się na skonfigurowanie go jako podstawowego magazynu danych. Potem powrót był często niewiarygodnie trudny.
Co można było zrobić inaczej?
Nie wszyscy skoczyli głową do przodu i runęli na dno. Ale wiele projektów zainstalowało bazę MongoDB tam, gdzie po prostu nie pasowała - i będą musieli z nią żyć jeszcze przez wiele lat. Gdyby organizacje te poświęciły trochę czasu na metodyczne rozważenie swoich wyborów technologicznych, wiele z nich dokonałoby innego wyboru.
Jak wybrać odpowiednią technologię? Było kilka prób stworzenia systematycznych ram oceny technologii, takich jak и , ale wydaje mi się, że jest to niepotrzebna złożoność.
Wiele technologii można inteligentnie wycenić, zadając tylko dwa podstawowe pytania. Problem polega na znalezieniu ludzi, którzy mogą odpowiedzieć na nie w sposób odpowiedzialny, poświęcając czas na znalezienie odpowiedzi i bez uprzedzeń.
Jeśli nie napotkasz jakiegoś problemu, nie potrzebujesz nowego narzędzia. Kropka.
Pytanie 1: Jakie problemy próbuję rozwiązać?
Jeśli nie napotkasz jakiegoś problemu, nie potrzebujesz nowego narzędzia. Kropka. Nie trzeba szukać rozwiązania, a potem wymyślać problemu. Jeśli nie masz do czynienia z problemem, którego nowa technologia nie rozwiązuje znacznie lepiej niż istniejąca technologia, nie ma tu nic do omawiania. Jeśli rozważasz użycie tej technologii, ponieważ widziałeś, jak używają jej inni, pomyśl o problemach, jakie mają oni i zapytaj, czy masz te problemy. Łatwo jest objąć technologię, ponieważ inni z niej korzystają, trudność polega na tym, aby wiedzieć, czy masz do czynienia z tymi samymi problemami.
Pytanie 2: Czego mi brakuje?
Jest to z pewnością trudniejsze pytanie, ponieważ trzeba dobrze kopać i rozumieć zarówno starą, jak i nową technologię. Czasami nie możesz naprawdę zrozumieć nowego, dopóki czegoś z nim nie zbudujesz lub nie będziesz mieć kolegi z takim doświadczeniem.
Jeśli nie masz żadnego z nich, warto pomyśleć o minimalnej możliwej inwestycji, aby określić wartość tego instrumentu. A jeśli dokonasz inwestycji, jak trudno będzie odwrócić decyzję?
Ludzie zawsze wszystko psują
Próbując odpowiedzieć na te pytania w sposób możliwie bezstronny, pamiętaj o jednym: musisz walczyć z naturą ludzką. Istnieje wiele błędów poznawczych, które należy przezwyciężyć, aby skutecznie ocenić technologię. Oto tylko kilka:
- Wszyscy o nim wiedzą, ale nadal trudno z nim walczyć. Po prostu 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 podlegają temu zniekształceniu poznawczemu.
- Mamy tendencję do dostrzegania tego, co jest, i tracimy z oczu to, czego nie ma. Może to prowadzić do chaosu połączonego z efektem nowości, ponieważ nie tylko z natury przeceniasz nową technologię, ale także ignorujesz jej wady..
Obiektywna ocena nie jest łatwa, ale zrozumienie podstawowych błędów poznawczych pomoże ci podejmować bardziej racjonalne decyzje.
Streszczenie
Kiedy pojawia się innowacja, należy bardzo ostrożnie odpowiedzieć na dwa pytania:
- Czy to narzędzie rozwiązuje rzeczywisty problem?
- Czy jesteśmy dobrzy w zrozumieniu kompromisów?
Jeśli nie możesz z całą pewnością odpowiedzieć na te dwa pytania, cofnij się o kilka kroków i pomyśl.
Czy la MongoDB był ogólnie właściwym wyborem? Oczywiście, że tak; podobnie jak w przypadku większości technologii inżynierskich, 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 to robi. Mam nadzieję, że ci z was, którzy tego nie zrobili, nauczyli się cennej i niezbyt bolesnej lekcji na temat przechodzenia przez cykl szumu.
Zrzeczenie się
Chcę wyjaśnić, że ani nie kocham, ani nie nienawidzę MongoDB. Po prostu nie mieliśmy problemów, do rozwiązania których najlepiej nadaje się MongoDB. Znam 10gen/MongoDB Inc. początkowo działał bardzo odważnie, ustawiając niepewne ustawienia domyślne i promując MongoDB wszędzie (zwłaszcza na hackathonach) jako kompleksowe rozwiązanie do pracy z dowolnymi danymi. To była chyba zła decyzja. Potwierdza to jednak podejście opisane tutaj: problemy te można było wykryć bardzo szybko, nawet przy powierzchownej ocenie technologii.
Źródło: www.habr.com