Projektowanie: architektura baz danych

Transkrypt

1 2012 Projektowanie: architektura baz danych Paweł Sieniawski, Columb Technologies S.A. Wyzwania w projektowaniu i programowaniu e-usługi Poznań, 11 października 2012

2 Dobra architektura czyli jaka?

3 Taxxo nasze doświadczenie Codziennie integrujemy bazy danych ponad 2500 klientów głównie spółek Współdziałamy z ponad 25 różnymi systemami księgowymi W internetowej Platformie Taxxo obsługiwane są firmy o łącznym obrocie rocznym > 1,2mld zł Sieć Taxxo to ponad 50 biur rachunkowych w całej Polsce

4 Architektura bazy danych, czyli: 1. Silnik bazy danych 2. Hosting - infrastruktura 3. Model danych - sposób organizacji danych w bazie 4. Procedury dotyczące rozwoju i wdrażania

5 JAK WYBRAĆ SILNIK BAZY DANYCH?

6 Dane serce e-usługi ebay - 26 mld zapytań SQL / dzień do 2 petabyte ów danych [2008 rok]!

7 Wymagania charakter usługi / danych Czy zgubienie jednego rekordu to problem? GOOGLE vs NBP Czy wszyscy natychmiast muszą widzieć modyfikację? FACEBOOK vs PKP Czu użytkownik poczeka 1 minutę? RYANAIR vs WIKIPEDIA

8 Wymagania inwestor czyli $$$ Wymagania cenowe odnośnie rozwiązania OPEN SOURCE vs BAZA Z PEŁNYM WSPARCIEM Preferencje np. Microsoft Partner, członek Open Software Foundation Wizja bezpieczeństwa inwestycji stabilny duży producent, powszechnie używana technologia, kod źródłowy a MySQL przejęty przez Oracle?

9 Wymagania dostępna wiedza & zasoby

10 Wymagania wykonawca Język programowania / środowisko programistyczne PHP,.NET, JAVA/J2EE,. Posiadane kompetencje ludzie z doświadczeniem PL/SQL, T-SQL, CQL, Hibernate, Posiadane licencje, narzędzia, komponenty

11 Wymagania - architekt Determinacja architekta rozwiązania krytyczny wpływ na końcowy wybór W tej technologii dostarczymy dobrej jakości produkt na czas vs To jest takie fajne, nowe chętnie bym w tym to zrobił

12 Jaki silnik wybrać? MySQL, Oracle, PostgreSQL, MS SQL Server, Amazon S3, MonoDB, Apache Cassandra, IBM DB/2, Teradata, SQL Azure, Amazon SimpleDB, BigTable, Jet Engine (MS Access), Btrieve, PervasiveSQL, InnoDB, Firebird, FoxPro, SQLite, Sybase, Netezza, Panorama, OpenOffice Base, Clarion, Informix, InterBase, SAS DB, Apache CouchDB, FlockDB, objectdb, Virtuoso Ten najlepiej spełniający kryteria

13 Silnik bazy danych typowe wybory: Nie róbcie swojego silnika Najczęściej w Internecie PHP + MySQL (np. Joomla, Wordpress) Dla wymagających rozbudowanej darmowej bazy danych do PHP PostgreSQL (np. Skype) Dla.NET MS SQL Server (np. Taxxo) Duże, transakcyjne bazy Oracle (np. Allegro) Duże ilości danych, do bardzo szybkiego przetwarzania BigTable, Apache Cassandra (np. Google Earth, Facebook search) Bazy w chmurze Dla.NET najczęściej wybierane SQL Azure bardzo rozbudowane, praktycznie (95%) zgodne z bazą tradycyjną Dla pozostałych środowisk Amazon Web Services (S3, SDB)

14 HOSTING INFRASTURKTURA BAZY DANYCH

15 Hosting jakie mamy opcje? Niewiele użytkowników Ogromna popularność Współdziel ony VPS Serwer dedykowany Kilka serwerów Farma serwerów Usługa hostingowa Własna serwerownia Data center Chmura

16 Co możemy zyskać dzięki odpowiedniej infrastrukturze? Wydajność czas obsługi użytkownika nie przekracza dopuszczalnej normy Wysoka dostępność pełne działanie usługi w przypadku awarii części podsystemu Skalowalność możliwość łatwego obsłużenia większej liczby użytkowników Spokój

17 Infrastruktura bazy danych podstawowa

18 Infrastruktura bazy danych wysoka dostępność

19 Infrastruktura bazy danych wydajność i skalowalność

20 Infrastruktura bazy danych wysoka dostępność, wydajność, skalowalność

21 Model danych PRZECHOWYWANIE DANYCH WIELU KLIENTÓW

22 Model danych przechowywanie danych wielu klientów Wariant 1. Jedna tabela dla danych wszystkich klientów BAZA: MojaBaza TABELA: FAKTURY ID_KLIENT NR_FAKT DATA KONTRAHENT /10/ Firma Krzak 1 2/10/ PKN Orlen 2 17/ Columb Tech 3 1/10/ PARP

23 Model danych przechowywanie danych wielu klientów Wariant 2. Osobna baza dla danych każdego klienta BAZA: Klient1 TABELA: FAKTURY NR_FAKT DATA KONTRAHENT 1/10/ Firma Krzak 2/10/ PKN Orlen BAZA: Klient2 TABELA: FAKTURY NR_FAKT DATA KONTRAHENT 17/ Columb Tech

24 Model danych porównanie wariantów 1. Jedna tabela Zalety: Łatwe modelowanie relacji (akcji) pomiędzy klientami Łatwe wdrożenie / aktualizacja jedna instancja danych Łatwe zarządzanie (np. backup danych) Wady: Łatwo o błąd programisty - pomieszanie danych Wymaga implementacji filtrowania danych przy każdym dostępie Skalowanie wymaga zaawansowanych mechanizmów 2. Osobna baza Zalety: Izolowanie danych klientów (np. odporność na błąd programisty) Łatwość implementacji (użytkownik powiązany z nazwą bazy) Łatwa skalowalność poprzez rozrzucenie danych na różne serwery Wady: Kosztowne (limity baz danych / opłaty per baza) Kłopotliwe wdrożenie / aktualizacja Kłopotliwy backup

25 Jak to robiliśmy w Taxxo? Wymagania do modelu bazy danych Taxxo Odporność na błędy programisty niedopuszczalne aby klienci zobaczyli nawzajem swoje dane! Brak potrzeby odzwierciedlenia relacji pomiędzy klientami Łatwa i szybka implementacja rozwiązania Wysoka skalowalność zbliżona do liniowej Niski koszt użytkowania Łatwe zarządzanie i wdrażanie nowych wersji Możliwość wybrania różnych wariantów hostingu rozwiązania

26 Jak to robiliśmy w Taxxo? BAZA: Fizyczna1 TABELA: Klient1_FAKTURY NR_FAKT DATA KONTRAHENT 1/10/ Firma Krzak 2/10/ PKN Orlen BAZA: Fizyczna2 TABELA: Klient3_... TABELA: Klient2_FAKTURY NR_FAKT DATA KONTRAHENT 17/ Columb Tech

27 Jak to robiliśmy w Taxxo? Wirtualizacja: Separacja fizycznych baz danych od instancji danych klienta Zalety: Izolowanie danych klientów (np. odporność na błąd programisty) Łatwość implementacji (użytkownik powiązany z nazwą bazy i prefixem) Łatwa skalowalność poprzez rozrzucenie danych klientów na różne serwery Wady Kosztowne (limity baz danych / opłaty per baza) Kłopotliwy backup Kłopotliwe wdrożenie / aktualizacja Wyeliminowaliśmy wady dzięki modelowi i narzędziom

28 Procedury ROZWÓJ APLIKACJI W OBSZARZE BAZY DANYCH

29 Procedury: Rozwój struktury bazy danych Przemyślana konwencja nazewnicza Proces modyfikacji struktury bazy Gromadzenie informacji o zmianach w strukturze Ochrona struktury bazy

30 Jak to robiliśmy w Taxxo?

31 Komunikacja z bazą wytyczne dla programistów Używaj mapowania obiektowo-relacyjnego (ORM) - automatyczne tłumaczenie świata tabel i rekordów na świat kolekcji i obiektów (np. Hibernate, Linq2SQL, Zend/Doctrine) Unikaj tworzenia poleceń SQL bezpośrednio w kodzie słabo zarządzalne, narażone na ataki SQL Injection Używaj tej samej metody dostępu w ramach całej aplikacji Jeżeli przetwarzasz dane (np. sumujesz rekordy, liczysz średnią) optymalniej wykona to silnik bazy danych niż Twój kod

32 Podsumowanie: POZNAJ WYMAGANIA

33 Podsumowanie: NIE KIERUJ SIĘ MODĄ

34 Podsumowanie: PRZEWIDUJ ZMIANY

35 Architektura to nauka i sztuka projektowania, konstruowania i wykonywania (Wikipedia / MySQL) Dziękuję za uwagę! p.sieniawski@ctsa.pl