Wyb\u00f3r bazy danych to jedna z tych decyzji, kt\u00f3re podejmuje si\u0119 raz \u2013 a potem przez lata p\u0142aci si\u0119 za ni\u0105 w postaci spowolnie\u0144, koszt\u00f3w utrzymania i utraconych mo\u017cliwo\u015bci. Widz\u0119 to u wielu klient\u00f3w, kt\u00f3rzy przychodz\u0105 do nas z problemem: \u201estrona dzia\u0142a wolno\u201d, \u201eskalowanie jest koszmarne\u201d, \u201ekoszty infrastruktury rosn\u0105\u201d. Cz\u0119sto okazuje si\u0119, \u017ce \u017ar\u00f3d\u0142em problemu jest nie tyle kod, co fundament, na kt\u00f3rym stoi aplikacja \u2013 czyli baza danych.<\/p>\n
W tym artykule poka\u017c\u0119 trzy typowe b\u0142\u0119dy w doborze bazy danych, kt\u00f3re obserwuj\u0119 w firmach od startup\u00f3w po \u015brednie przedsi\u0119biorstwa. Opowiem o nich na konkretnych przyk\u0142adach i podpowiem, jak ich unikn\u0105\u0107.<\/p>\n
Relacyjne bazy danych, jak PostgreSQL czy MySQL, s\u0105 niesamowicie pot\u0119\u017cne. Ale to nie znaczy, \u017ce s\u0105 najlepsze do ka\u017cdego zadania. Cz\u0119sto widz\u0119 projekty, gdzie wszystko l\u0105duje w relacyjnej bazie \u2013 dane u\u017cytkownik\u00f3w, logi, sesje, produkty, nawet dane czasowe czy geolokalizacyjne. Skutek? Przy wzro\u015bcie obci\u0105\u017cenia zapytania staj\u0105 si\u0119 skomplikowane, indeksy rosn\u0105, a koszty utrzymania eksploduj\u0105.<\/p>\n
Przyk\u0142ad z \u017cycia: Klient e-commerce z 50 tys. produkt\u00f3w.<\/strong> Lekcja:<\/strong> U\u017cywaj odpowiedniego narz\u0119dzia do zadania. Do relacji i transakcji \u2013 relacyjna baza. Do cache\u2019u \u2013 Redis. Do wyszukiwania pe\u0142notekstowego \u2013 Elasticsearch. Do danych grafowych \u2013 Neo4j. \u0141\u0105czenie r\u00f3\u017cnych baz jest dzi\u015b standardem (polyglot persistence).<\/p>\n Z drugiej strony mam klient\u00f3w, kt\u00f3rzy przeczytali, \u017ce NoSQL jest super, i wybrali MongoDB do wszystkiego. Problem? Je\u015bli potrzebujesz skomplikowanych transakcji ACID, sp\u00f3jno\u015bci danych i z\u0142o\u017conych relacji, MongoDB mo\u017ce nie by\u0107 najlepszym wyborem. Oczywi\u015bcie, ma wsparcie dla transakcji, ale nie jest to jego naturalne \u015brodowisko.<\/p>\n Przyk\u0142ad z \u017cycia: Aplikacja fintech licz\u0105ca prowizje.<\/strong> Lekcja:<\/strong> NoSQL jest \u015bwietny do elastycznych schemat\u00f3w, danych nierelacyjnych, wysokiej przepustowo\u015bci. Ale je\u015bli potrzebujesz silnych gwarancji sp\u00f3jno\u015bci i z\u0142o\u017conych zapyta\u0144 JOIN \u2013 pomy\u015bl dwa razy.<\/p>\n Nowe technologie kusz\u0105: \u201eKafka to przysz\u0142o\u015b\u0107\u201d, \u201eGoogle Spanner rozwi\u0105\u017ce problem skalowania\u201d. Tylko \u017ce one wi\u0105\u017c\u0105 si\u0119 z ogromn\u0105 z\u0142o\u017cono\u015bci\u0105 operacyjn\u0105. Ma\u0142a firma z jednym zespo\u0142em deweloperskim mo\u017ce nie ud\u017awign\u0105\u0107 utrzymania klastra Kafki. Zamiast tego czasem wystarczy dobrze skonfigurowana kolejka w RabbitMQ czy Amazon SQS.<\/p>\n Przyk\u0142ad z \u017cycia: Startup z 3 developerami.<\/strong> Lekcja:<\/strong> Wybierz baz\u0119 danych, kt\u00f3r\u0105 Tw\u00f3j zesp\u00f3\u0142 zna i kt\u00f3ra pasuje do profilu obci\u0105\u017cenia. Prostota to cz\u0119sto najwi\u0119ksza zaleta.<\/p>\n Zamiast ulega\u0107 modzie, zadaj sobie pytania:<\/p>\n Warto te\u017c rozwa\u017cy\u0107 podej\u015bcie \u201estart with what you know\u201d \u2013 zacznij od sprawdzonej relacyjnej bazy, a dopiero gdy pojawi si\u0119 konkretny problem, doklej kolejn\u0105 baz\u0119. To pozwoli unikn\u0105\u0107 over-engineeringu.<\/p>\n Z\u0142a baza danych to jak fundament z dziurami \u2013 pr\u0119dzej czy p\u00f3\u017aniej ca\u0142a konstrukcja zacznie si\u0119 chwia\u0107. Wyb\u00f3r bazy to decyzja strategiczna, kt\u00f3ra wp\u0142ywa na wydajno\u015b\u0107, koszty i tempo rozwoju. Unikaj trzech pu\u0142apek: traktowania relacyjnej bazy jako panaceum, bezkrytycznego rzucania si\u0119 na NoSQL oraz wybierania modnych technologii bez wzgl\u0119du na realia zespo\u0142u.<\/p>\n Je\u015bli potrzebujesz pomocy w doborze architektury danych lub audycie istniej\u0105cego rozwi\u0105zania \u2013 w JurskiTech mamy do\u015bwiadczenie w projektowaniu skalowalnych system\u00f3w, kt\u00f3re nie rujnuj\u0105 bud\u017cetu. Daj zna\u0107, a pomo\u017cemy Ci znale\u017a\u0107 fundament, na kt\u00f3rym zbudujesz stabilny biznes.<\/p>\n","protected":false},"excerpt":{"rendered":" Dlaczego Twoja firma traci na z\u0142ym doborze bazy danych? 3 pu\u0142apki Wyb\u00f3r bazy danych to jedna z tych decyzji, kt\u00f3re podejmuje si\u0119 raz \u2013 a potem przez lata p\u0142aci si\u0119 za ni\u0105 w postaci spowolnie\u0144, koszt\u00f3w utrzymania i utraconych mo\u017cliwo\u015bci. Widz\u0119 to u wielu klient\u00f3w, kt\u00f3rzy przychodz\u0105 do nas z problemem: \u201estrona dzia\u0142a wolno\u201d, \u201eskalowanie<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[10,467,379,431],"class_list":["post-1667","post","type-post","status-publish","format-standard","hentry","category-warto-wiedziec","tag-ai-w-e-commerce","tag-bazy-danych","tag-globalne-skalowanie","tag-optymalizacja-wydajnosci"],"_links":{"self":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/1667","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/comments?post=1667"}],"version-history":[{"count":0,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/1667\/revisions"}],"wp:attachment":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media?parent=1667"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/categories?post=1667"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/tags?post=1667"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\nMieli wszystko w MySQL: produkty, kategorie, zam\u00f3wienia, a tak\u017ce sesje u\u017cytkownik\u00f3w. Gdy ruch wzr\u00f3s\u0142, zapytania o sesje zacz\u0119\u0142y blokowa\u0107 zapytania o produkty. Znale\u017ali\u015bmy rozwi\u0105zanie: przenie\u015bli\u015bmy sesje do Redis (baza klucz-warto\u015b\u0107 w pami\u0119ci). Efekt? Zapytania o produkty posz\u0142y 3 razy szybciej, a koszt infrastruktury spad\u0142 o 20%.<\/p>\nPu\u0142apka 2: NoSQL jako odpowied\u017a na wszystko<\/h3>\n
\nKlient u\u017cywa\u0142 MongoDB do przechowywania transakcji i wyliczania prowizji. Wymaga\u0142o to skomplikowanych agregacji, kt\u00f3re stawa\u0142y si\u0119 coraz wolniejsze. Po miesi\u0105cach walki przenie\u015bli\u015bmy cz\u0119\u015b\u0107 danych do PostgreSQL. Zrobi\u0142o si\u0119 pro\u015bciej, szybciej i taniej.<\/p>\nPu\u0142apka 3: Skupienie si\u0119 na modzie, a nie na profilu obci\u0105\u017cenia<\/h3>\n
\nCEO chcia\u0142 wdro\u017cy\u0107 Cassandra do obs\u0142ugi log\u00f3w, bo \u201eto nowoczesna baza danych\u201d. Problem: zesp\u00f3\u0142 nie mia\u0142 do\u015bwiadczenia z Cassandr\u0105, konfiguracja klastera by\u0142a skomplikowana, a tak naprawd\u0119 potrzebowali tylko prostego przechowywania log\u00f3w z mo\u017cliwo\u015bci\u0105 szybkiego odczytu. Wystarczy\u0142o u\u017cy\u0107 Elasticsearcha \u2013 znanego, z dobr\u0105 dokumentacj\u0105, \u0142atwego do postawienia.<\/p>\nJak podejmowa\u0107 dobr\u0105 decyzj\u0119?<\/h3>\n
\n
Podsumowanie<\/h3>\n