Aktywne Wpisy
bArrek +147
Do j-----j pracy jutro
karolina-oska +68
#rolnikszukazony
To straszne jak większość chłopów na tym targu w ogóle nie rozumie Karoliny od Rolanda....
Chłop na każdym spotkaniu się na nia patrzy i uśmiecha. Wyżyny jego możliwości rozmowy z kobietą to opracowanie planu przeprowadzki i ślubu za rok.
Karolina widze że nie idzie do łba mu nic przełożyć więc pisze list żeby typo przeczytał w samotności i sie zastanowił.
Ona czuje się jak ładny przedmiot do patrzenia, bo typ nie pyta
To straszne jak większość chłopów na tym targu w ogóle nie rozumie Karoliny od Rolanda....
Chłop na każdym spotkaniu się na nia patrzy i uśmiecha. Wyżyny jego możliwości rozmowy z kobietą to opracowanie planu przeprowadzki i ślubu za rok.
Karolina widze że nie idzie do łba mu nic przełożyć więc pisze list żeby typo przeczytał w samotności i sie zastanowił.
Ona czuje się jak ładny przedmiot do patrzenia, bo typ nie pyta
Aktywne Znaleziska
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.
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.
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
Jeśli dalej jest problem i nie możemy go rozwiązać archiwizacją, to możemy wykorzystać np. sharding.
@Ununoctium: Witamy w 2012. Nawet Amazon oferuje instancje mające 4TB RAMu, a dedykowany sprzęt pod wysokowydajne bazy danych potrafi mieć więcej.
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.
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.
Partycjonowanie wg użytkowników i primary key na numer transakcji albo datę zlecenia.
Później i tak do hurtowni, odpowiednie agregacje i voila.
@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.
@Ununoctium: Indeks nie musi mieścić się w całości w pamięci RAM.
Poza tym by siegnac so konkretnego rekordu nie trzeba skanowac calego indeksu.
Po prostu używam uproszczeń, nikogo chyba nie wprowadziłem w błąd?
@Ununoctium: sa ale powinno sie ich unikac tak samo jak pelnego skanu tabeli.
@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ł.
@maniac777: Jak już mamy wchodzić w technikalia to nie zawsze działa szybciej ale z reguły tak.