Baza danych do trzymania logów użytkownik

Szukam bazy danych, która sprawdzi się w trzymaniu logów użytkowników. Logi trzymane byłyby maksymalnie przez kilka dni.

• Jaki jest oczekiwany wolumen danych (kb, mb, gb, tb)?
• Jakie są oczekiwane czasy zapisu / odpowiedzi?
• Jakie są oczekiwane standardy co do integralności danych? (pełne ACID itd.)
• Jakie licencje wchodzą w grę? (MIT, płatne oprogramowanie itd.)

Patryk27 napisał(a):

• Jaki jest oczekiwany wolumen danych (kb, mb, gb, tb)?
• Jakie są oczekiwane czasy zapisu / odpowiedzi?
• Jakie są oczekiwane standardy co do integralności danych? (pełne ACID itd.)
• Jakie licencje wchodzą w grę? (MIT, płatne oprogramowanie itd.)

mb
czas zapisu nie ma większego znaczenia, ale odpowiedź nie powinna zająć więcej niż sekunde
brak
Wszystkie, które pozwalają na komercyjne użycie tak jak MIT

@Patryk27: jeszcze uzupełniając Twoje pytania - czy to ma być trzymane lokalnie, czy na jakimś serwerze? Jeśli zapis ma być zdalny to w grę wchodzą jedynie "prawdziwe" silniki typu Postgres czy MySQL. Jeśli tylko lokalnie, na maszynie, na której aplikacja działa, to można się zastanowić nad SQLite (aczkolwiek, jak słusznie zauważyłeś, mamy zbyt mało danych, żeby doradzić coś bardziej sensownie).

Ponieważ padły pytania ilościowe, czy inżynieryjne, nie będę ich powtarzał.
Pomedytuję nad słowami podstawowymi.

**Log **to coś, co przyjmuje wpisy planowane, ale nade wszystko nieplanowane (pierdyknie jakiś wyjątek), z konieczności wpis o strukturze bardziej free-form.
**Baza **za to przyjmuje dane przewidziane i zaplanowane, a nawet aktywnie się sprzeciwia nieplanowanym danym (walidacja przed/przy wpisie).
Jakie potrzeby selekcji danych masz @vonewa913 w tej swojej idei?
Nade wszystko myślisz "baza" czy "log" ?
Co NAPRAWDĘ w tych wpisach będzie?

Narzędzia do logowania też przechodzą rozwój (i nie mówię o kobyłach cloudowych), np zdolność analizy aktualnych danych (bez czekania na logrotate). Kilka ciekawych projektów wypączkowało z otoczenia slf4j
Do pytań @cerrato i @Patryk27 bym dodał o kuloodporności, czy w ostatniej chwili przed śmiercią ma dać jeszcze wpis itd...

AnyKtokolwiek napisał(a):

Ponieważ padły pytania ilościowe, czy inżynieryjne, nie będę ich powtarzał.
Pomedytuję nad słowami podstawowymi.

**Log **to coś, co przyjmuje wpisy planowane, ale nade wszystko nieplanowane (pierdyknie jakiś wyjątek), z konieczności wpis o strukturze bardziej free-form.
**Baza **za to przyjmuje dane przewidziane i zaplanowane, a nawet aktywnie się sprzeciwia nieplanowanym danym (walidacja przed/przy wpisie).
Jakie potrzeby selekcji danych masz @vonewa913 w tej swojej idei?
Nade wszystko myślisz "baza" czy "log" ?
Co NAPRAWDĘ w tych wpisach będzie?

Narzędzia do logowania też przechodzą rozwój (i nie mówię o kobyłach cloudowych), np zdolność analizy aktualnych danych (bez czekania na logrotate). Kilka ciekawych projektów wypączkowało z otoczenia slf4j
Do pytań @cerrato i @Patryk27 bym dodał o kuloodporności, czy w ostatniej chwili przed śmiercią ma dać jeszcze wpis itd...

Te informacje nie są bardzo ważne, więc nawet jak cos zginie nic strasznie złego się nie stanie. Zadaniem będzie po prostu zbieranie informacji o tym co zrobił użytkownik o danej godzinie i pożniej wyświetlenie mu tego.

Jeśli chcesz relacyjną bazę danych do tego to oczywiście polecam PostgreSQLa (o ile ilość danych jest mniejsza niż 1TB). Ale do trzymania logów są dedykowane nierelacyjne bazy jak Graylog czy Logstash