Aktywne Wpisy
![WykopX](https://wykop.pl/cdn/c0834752/8392eda7e649f71041fa56213437c4b61fc8946eb840ffe684fdec86852d0b4d,q60.gif)
WykopX +333
Treść przeznaczona dla osób powyżej 18 roku życia...
![sunkillmoon](https://wykop.pl/cdn/c0834752/9c20d02c292d9843c9977fdfdb037159aaad27b4b6f9a6e83ddf03a9b557eb54,q60.jpg)
sunkillmoon +123
Wracasz sobie z rodzinką nad morzem ale możesz nie dojechać bo jakiś kretyn w Cinquecencie będzie wyprzedzał na trzeciego pod prąd na najgorszym możliwym zakręcie na DK88 ¯\(ツ)/¯
#stopcham #polskiedrogi #gliwice #zabrze #patologiazewsi
#stopcham #polskiedrogi #gliwice #zabrze #patologiazewsi
![sunkillmoon - Wracasz sobie z rodzinką nad morzem ale możesz nie dojechać bo jakiś kr...](https://wykop.pl/cdn/c3201142/10b846059d3124e5b72c6ca04f3a435eaf873276384a348bf3e51bea5bfeb9b4,w150.png?author=sunkillmoon&auth=33d8af9afeb3f8377b628d2e98f402f9)
źródło: sssss
Pobierz
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.