Ka\u017cda firma SaaS, kt\u00f3ra zaczyna rosn\u0105\u0107, pr\u0119dzej czy p\u00f3\u017aniej staje przed \u015bcian\u0105. System dzia\u0142a\u0142 dobrze przy setkach u\u017cytkownik\u00f3w, ale przy tysi\u0105cach zaczyna zwalnia\u0107, generowa\u0107 b\u0142\u0119dy, a czasem wr\u0119cz si\u0119 sypa\u0107. Wini si\u0119 monolit, baz\u0119 danych, a nawet samych developer\u00f3w. Rzadko kto patrzy na architektur\u0119 danych \u2013 czyli to, jak dane s\u0105 modelowane, przechowywane i przep\u0142ywaj\u0105 mi\u0119dzy serwisami. A to w\u0142a\u015bnie tam cz\u0119sto tkwi \u017ar\u00f3d\u0142o problem\u00f3w.<\/p>\n
W swoim wieloletnim do\u015bwiadczeniu widzia\u0142em wiele firm, kt\u00f3re inwestowa\u0142y w skalowanie horyzontalne, mikroserwisy i chmur\u0119, a nadal mia\u0142y problemy z wydajno\u015bci\u0105. Pow\u00f3d? B\u0142\u0119dy w architekturze danych. Oto trzy najcz\u0119stsze, kt\u00f3re hamuj\u0105 rozw\u00f3j SaaS.<\/p>\n
Wielu developer\u00f3w na pocz\u0105tku tworzy aplikacj\u0119 z jedn\u0105 wielk\u0105 tabel\u0105 lub dokumentem, kt\u00f3ry przechowuje wszystko, co dotyczy u\u017cytkownika \u2013 profil, ustawienia, histori\u0119 zam\u00f3wie\u0144, subskrypcje, notatki. To wygodne przy ma\u0142ej skali. Ale gdy u\u017cytkownik\u00f3w s\u0105 tysi\u0105ce, a operacje odczytu i zapisu si\u0119 mno\u017c\u0105, ten model staje si\u0119 w\u0105skim gard\u0142em.<\/p>\n
Przyk\u0142ad z \u017cycia:<\/strong> Co by\u0142o przyczyn\u0105?<\/strong> Lekcja:<\/strong> Indeksy to miecz obosieczny. Przyspieszaj\u0105 odczyty, ale spowalniaj\u0105 zapisy i zajmuj\u0105 miejsce. Typowy b\u0142\u0105d: developerzy indeksuj\u0105 wszystko \u201ena zapas\u201d, albo \u2013 przeciwnie \u2013 nie indeksuj\u0105 niczego, bo \u201ebaza jest ma\u0142a\u201d.<\/p>\n Przyk\u0142ad z \u017cycia:<\/strong> Rozwi\u0105zanie:<\/strong> Lekcja:<\/strong> Ma\u0142o kto my\u015bli o tym na pocz\u0105tku, ale dane rosn\u0105. Logi, zdarzenia, historyczne zam\u00f3wienia \u2013 wszystko to z czasem zbiera kurz i spowalnia baz\u0119. Wiele firm utrzymuje wszystkie dane w jednej tabeli latami. Efekt? Degradacja wydajno\u015bci, rosn\u0105ce koszty i frustracja.<\/p>\n Przyk\u0142ad z \u017cycia:<\/strong> Rozwi\u0105zanie:<\/strong> Lekcja:<\/strong> Skalowanie SaaS to nie tylko dodawanie serwer\u00f3w czy mikroserwis\u00f3w. To przede wszystkim m\u0105dre zarz\u0105dzanie danymi. Prze\u0142adowane encje, brak strategii indeksowania i nieplanowane przechowywanie danych to trzy b\u0142\u0119dy, kt\u00f3re widz\u0119 najcz\u0119\u015bciej. Ka\u017cdy z nich jest do naprawienia, ale im p\u00f3\u017aniej, tym dro\u017cej.<\/p>\n A Ty? Sprawd\u017a, czy Tw\u00f3j system nie pope\u0142nia kt\u00f3rego\u015b z tych b\u0142\u0119d\u00f3w. Cz\u0119sto wystarczy audyt architektury danych i kilka tygodni refaktoringu, \u017ceby odetchn\u0105\u0107. A je\u015bli potrzebujesz wsparcia \u2013 w JurskiTech.pl pomagamy firmom przej\u015b\u0107 przez ten proces bezbole\u015bnie. Bo dobrze zaprojektowane dane to podstawa skalowalnego SaaS.<\/p>\n","protected":false},"excerpt":{"rendered":" Wprowadzenie Ka\u017cda firma SaaS, kt\u00f3ra zaczyna rosn\u0105\u0107, pr\u0119dzej czy p\u00f3\u017aniej staje przed \u015bcian\u0105. System dzia\u0142a\u0142 dobrze przy setkach u\u017cytkownik\u00f3w, ale przy tysi\u0105cach zaczyna zwalnia\u0107, generowa\u0107 b\u0142\u0119dy, a czasem wr\u0119cz si\u0119 sypa\u0107. Wini si\u0119 monolit, baz\u0119 danych, a nawet samych developer\u00f3w. Rzadko kto patrzy na architektur\u0119 danych \u2013 czyli to, jak dane s\u0105 modelowane, przechowywane i<\/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":[479,617,513,379],"class_list":["post-2122","post","type-post","status-publish","format-standard","hentry","category-warto-wiedziec","tag-architektura-danych","tag-b2b-saas","tag-bledy-ai","tag-globalne-skalowanie"],"_links":{"self":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2122","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=2122"}],"version-history":[{"count":0,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2122\/revisions"}],"wp:attachment":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media?parent=2122"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/categories?post=2122"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/tags?post=2122"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\nKlient prowadzi\u0142 platform\u0119 SaaS do zarz\u0105dzania projektami. Ka\u017cdy projekt mia\u0142 setki zada\u0144, a ka\u017cde zadanie mia\u0142o wiele p\u00f3l, za\u0142\u0105cznik\u00f3w i komentarzy. Wszystko trzymali w jednej tabeli PostgreSQL. Przy 50 u\u017cytkownikach dzia\u0142a\u0142o. Przy 500 zacz\u0119\u0142y si\u0119 timeouty. Przy 1000 aplikacja by\u0142a praktycznie niedost\u0119pna w godzinach szczytu.<\/p>\n
\nKa\u017cde zapytanie o list\u0119 projekt\u00f3w ci\u0105gn\u0119\u0142o gigantyczne z\u0142\u0105czenia i przetwarza\u0142o miliony wierszy. Tabela by\u0142a tak szeroka, \u017ce nawet indeksy nie pomaga\u0142y. Rozwi\u0105zaniem by\u0142o rozbicie modelu na osobne tabele: projekty, zadania, komentarze, za\u0142\u0105czniki. I zastosowanie CQRS (Command Query Responsibility Segregation) \u2013 oddzielenie operacji odczytu od zapisu. Koszt? Kilka tygodni refaktoringu. Zysk? 10-krotny wzrost wydajno\u015bci przy tych samych kosztach chmury.<\/p>\n
\nProjektuj encje tak, aby odpowiada\u0142y konkretnym kontekstom. Nie tw\u00f3rz uniwersalnych modeli. U\u017cywaj bounded contexts z DDD. To nie tylko kwestia wydajno\u015bci, ale te\u017c utrzymania kodu.<\/p>\n2. Brak strategii indeksowania: nie ka\u017cda kolumna potrzebuje indeksu<\/h2>\n
\nFirma e-commerce (ale SaaS te\u017c) mia\u0142a baz\u0119 z milionem produkt\u00f3w i dziennym przyrostem 10 tysi\u0119cy nowych. Wyszukiwarka dzia\u0142a\u0142a wolno, bo ka\u017cde zapytanie skanowa\u0142o ca\u0142\u0105 tabel\u0119. Z drugiej strony, przy ka\u017cdej aktualizacji ceny (a by\u0142o ich wiele), baza muli\u0142a, bo indeksy na ka\u017cdej kolumnie powodowa\u0142y kosztowne przebudowy.<\/p>\n
\nPrzeanalizowali\u015bmy wzorce zapyta\u0144. Okaza\u0142o si\u0119, \u017ce najcz\u0119\u015bciej wyszukiwano po kategorii, marce i przedziale cenowym. Indeksy na tych trzech kolumnach rozwi\u0105za\u0142y problem odczyt\u00f3w. Z kolei indeksy na rzadko u\u017cywanych polach (jak waga czy kolor) usun\u0119li\u015bmy, co przyspieszy\u0142o zapisy o 30%.<\/p>\n
\nIndeksy musz\u0105 by\u0107 projektowane pod realne zapytania, nie pod wyobra\u017cone. Monitoruj slow query log i analizuj u\u017cycie indeks\u00f3w w EXPLAIN. To powinien by\u0107 ci\u0105g\u0142y proces, nie jednorazowe dzia\u0142anie.<\/p>\n3. Zarz\u0105dzanie danymi w skali: zapomniane archiwizacje i partycjonowanie<\/h2>\n
\nSaaS zbieraj\u0105cy dane analityczne (eventy) \u2013 10 milion\u00f3w event\u00f3w dziennie. Po roku mieli 3,6 miliarda rekord\u00f3w w jednej tabeli. Nawet z indeksami odczyty agregat\u00f3w miesi\u0119cznych trwa\u0142y minuty. A koszt przechowywania w chmurze r\u00f3s\u0142 lawinowo.<\/p>\n
\nPartycynacja po dacie \u2013 ka\u017cdy miesi\u0105c osobna partycja. Dodali\u015bmy archiwizacj\u0119 danych starszych ni\u017c 6 miesi\u0119cy do ta\u0144szego magazynu (np. Amazon S3 z Athena). Na zapytania na \u017cywo zostawili\u015bmy tylko ostatnie 6 miesi\u0119cy. To skr\u00f3ci\u0142o czas zapyta\u0144 z minut do sekund i obni\u017cy\u0142o koszty o 40%.<\/p>\n
\nPlanuj strategi\u0119 lifecycle danych od pocz\u0105tku. Nie czekaj, a\u017c baza zacznie umiera\u0107. Partycjonowanie, archiwizacja, purging danych \u2013 to nie s\u0105 fanaberie, a konieczno\u015b\u0107 przy skali.<\/p>\nPodsumowanie<\/h2>\n