Aktywne Wpisy
Szinako +303
Hamas przeprowadził terrorystyczny atak, w którym zabił kilkuset Izraelczyków. Dlatego właśnie teraz Izrael w ramach zemsty bombarduje strefę Gazy i wymorduje kilkanaście tysięcy Palestyńczyków w tym dzieci. Z tym że to już nie jest terroryzm i zbrodnie wojenne tylko coś innego, to metafizyka xD. Odcięcie dwóch milionów ludzi od wody, prądu i dostaw żywności to też ciekawa sprawa. Dziwnym trafem media zachodnie coś są cicho na ten temat. Widocznie wujek z ameryki
LuckyStrike +40
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.
W mojej ocenie wprowadziles tu:
Wyszukiwanie po indeksie dziala o wiele rzedow wielkosci wydajniej bez wzgledu na to czy zmiesci sie on w RAM czy nie.
Obrazowo:
@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.