[n.....m]

#programowanie #bazydanych #nosql
Witam Mireczków, interesuje mnie rozwiązanie pewnego problemu, który przedstawię na prostym przykładzie. Na przykład bierzemy bank, gdzie mamy klienta oraz jego przychody i wydatki. Zakładając, że mamy 100 000 klientów i każdy z nich wykona średnio 200 transakcji to mamy 20 000 000 rekordów w tabeli. Chyba zgodzicie się, że przeszukanie takiej tabeli jest bardzo czasochłonne, więc jak to zrobić by miało RENCE I NOGI.

Na obecny stan mój wiedzy wydaje mi się, że najłatwiej było by to zrobić w NoSQL, ale interesuje mnie rozwiązanie w relacyjnej bazie danych.

[Yahoo_]

@nihilm 20kk rekordów to wcale nie tak dużo :)

[oko_strusia]

@nihilm: Dobre indeksy i przeszukanie wcale nie będzie czasochłonne.

[n.....m]

@Yahoo_: Ale umówmy się, 200 transakcji na jednego klienta to pęknie w pierwsze kilka miesięcy, a mnie interesuje rozwiązanie

[Yahoo_]

@nihilm a banki stać na dobre serwery :p
A tak serio to szczerze nie wiem jak to rozwiązują, strzelam, że w bazie maja tylko część rekordów (np. 2 lata), a resztę archiwizują i mają do tego bazy w trybie read only.

[T.....n]

@nihilm: generalnie dzielisz transakcje na 2 części
1. część - transakcje bieżące (np z pół roku) i trzymasz je w normalnej bazce relacyjnej
2. część - pakujesz resztę do hurtowni danych z odpowiednim indeksowaniem
masz szybki system z danymi od razu do robienia analiz

problem solved

[Ununoctium]

@nihilm: Tak jak piszą koledzy wyżej. Wyszukiwanie działa szybko póki indeks mieści się w pamięci RAM. Aktualnie serwery potrafią mieć 256GB pamięci RAM.

Jeśli dalej jest problem i nie możemy go rozwiązać archiwizacją, to możemy wykorzystać np. sharding.

[GhoulPolonofag]

Aktualnie serwery potrafią mieć 256GB pamięci RAM.

@Ununoctium: Witamy w 2012. Nawet Amazon oferuje instancje mające 4TB RAMu, a dedykowany sprzęt pod wysokowydajne bazy danych potrafi mieć więcej.

[GhoulPolonofag]

@nihilm:

Chyba zgodzicie się, że przeszukanie takiej tabeli jest bardzo czasochłonne, więc jak to zrobić by miało RENCE I NOGI.

Nie jest, opisywane przez Ciebie dane są malutkie i trywialne do zaindeksowania, bo partycjonujesz wg użytkownika i primary key jest zawsze rosnący (data lub liczba), więc wszystko pięknie się wstawia.

[Ununoctium]

@GhoulPolonofag Amazon to raczej chmura. Zdaje sobie sprawe że są pewnie instalacje z większą ilością ram, nie napisałem przecież że to max. Chodziło raczej o pokazanie rzędu wielkości.

[plushy]

@nihilm: Nie waż się wsadzać NoSQL do projektu jeśli nie jesteś specjalistą od baz relacyjnych. NoSQL ma swoje zastosowania ale to nie jest jedno z nich.

[Supaplex]

@nihilm: Poczytaj o partycjonowaniu tabeli.
Dzięki temu rozwiązaniu logicznie jest np. jedna tabela z transakcjami, ale transakcje są miesiącami porozrzucane na osobnych tablespace, a co za tym idzie osobnych storage czy nawet całych instancjach. Dzięki temu szukani transakcji w danym miesiącu - już powoduje szukanie tylko w jednym miejscu wg jednego "małego" indexu.

Jest to rozwiązania m.in oracla w wersji enterpice i z tego się korzysta.

[GhoulPolonofag]

@Supaplex: Partycjonowanie wg dat nie ma tu większego sensu, bo nie ma sensu nigdy szukać wg dat bez wskazania użytkownika. Bank to taki przypadek, że jeden użytkownik widzi dane tylko swoje - i nigdy nie przegląda jakiegoś ogólnego widoku "pokaż transakcje wszystkich klientów banku z poprzedniego miesiąca". Analizy można odpalać na archiwalnej kopii tutaj.

Partycjonowanie wg użytkowników i primary key na numer transakcji albo datę zlecenia.

[Supaplex]

@GhoulPolonofag: No w sumie racja. Po użytkowniku jet efektowniej.
Później i tak do hurtowni, odpowiednie agregacje i voila.

[maniac777]

Chyba zgodzicie się, że przeszukanie takiej tabeli jest bardzo czasochłonne, więc jak to zrobić by miało RENCE I NOGI.

@nihilm: Relacyjna baza danych (nie noSQL) i indeks. Możesz mieć setki milionów rekordów i nadal wyszukiwanie transakcji danego klienta to zagadnienie na kilka milisekund.

Wyszukiwanie działa szybko póki indeks mieści się w pamięci RAM.

@Ununoctium: Indeks nie musi mieścić się w całości w pamięci RAM.

[Ununoctium]

@maniac777 Nie musi, ale wtedy baza działa najlepiej.

[maniac777]

@Ununoctium: oczywiscie ze najlepiej ogolnie jak cala zmiesci sie w RAM ale w ram zawsze sa i bloki z indeksami i z danymi najczesciej nie masz kontroli nad tym ile blokow indeksow i ile blokow danych jest tam aktualnie. Najzadziej uzywane po prostu wypadaja z cache.

Poza tym by siegnac so konkretnego rekordu nie trzeba skanowac calego indeksu.

[Ununoctium]

@maniac777 By po prostu sięgnąć nie, ale są operacje wymagajace full scanu. Poza tym raczej nie chcemy wchodzić w technikalia zarządzania pamięcią, bo każdy DBMS ma swoje mechanizmy, a nie to było przedmiotem pytania.

Po prostu używam uproszczeń, nikogo chyba nie wprowadziłem w błąd?

[maniac777]

By po prostu sięgnąć nie, ale są operacje wymagajace full scanu

@Ununoctium: sa ale powinno sie ich unikac tak samo jak pelnego skanu tabeli.

Po prostu używam uproszczeń, nikogo chyba nie wprowadziłem w

[Andrew7642]

@nihilm: Nie waż się wsadzać NoSQL do projektu jeśli nie jesteś specjalistą od baz relacyjnych. NoSQL ma swoje zastosowania ale to nie jest jedno z nich.

@plushy: ZWŁASZCZA tutaj, przy operacjach finansowych, gdzie jak słyszy się o braku ACIDu i eventual consistency to właśnie jakiś gruby dyrektor schodzi na zawał.

[plushy]

Wyszukiwanie po indeksie dziala o wiele rzedow wielkosci wydajniej bez wzgledu na to czy zmiesci sie on w RAM czy nie.

@maniac777: Jak już mamy wchodzić w technikalia to nie zawsze działa szybciej ale z reguły tak.