[Rollines]

Mirki potrzebuje postawić bazę danych pod aplikacje.
Dane będą ustrukturyzowane, około 10-15 kolumn przy czym tylko w jednej będzie tekst użytkownika (wiec może to być cokolwiek). Miesięcznie 50-100 mln rekordów. Nie znam się zupełnie, ale musiałbym wiedzieć mniej więcej co będzie potrzebne. Pytania, co lepiej sql, no sql? Jeżeli no sql to co, żeby była w miare user friendly dla osób, które będą te dane przetwarzać. Musi być w miare szybka do querowania i updatowania.
Jeżeli to zbyt ogólny opis to co warto jeszcze zaznaczyć? Jeżeli odpowiedz to „to zależy” to w co wy byście poszli bazując na doświadczeniu. Z tego co czytam baza sql by się na to pisała, ale jak będzie gdy rekordów okaże się więcej i trzeba będzie dodać mocy.
Co myślicie Mireczki?
#sql #nosql #programista15k #python #aws

[morsik]

Pytania, co lepiej sql, no sql?

@Rollines: na to to musisz odpowiedzieć sobie sam. My Ci nie pomożemy bo każde z tych ma swoje plusy i minusy więc musisz nam podać:
- jakiego typu tam będziesz miał dane
- jak bardzo będzie Cię bolała utrata pojedynczych rekordów
- jak bardzo będzie Cię bolała utrata np. 1/3 rekordów
- czy potrzebujesz ACID na bazie

Bez tych informacji nikt z poważnym doświadczeniem nie

[morsik]

@Rollines: A tak dopowiadając jeszcze odnośnie wielkości tabeli:

100 mln/mc to *jest* sporo. Przy MySQL/PostgreSQL bez partycjonowania się nie obejdzie. Chyba że struktura będzie faktycznie prosta i będą potem proste zapytania leciały. Ale to nadal będzie sporo i jedynymi sensownymi kandydatami będą tu MS SQL Server lub Oracle. Czy da się osiągnąć to na PostgreSQL i MySQL? No da się, ale będzie to kosztować prawdopodobnie dodatkowe cudowanie po stronie aplikacji.

Ale

[wpiot]

@Rollines: A jakie technologie macie teraz w systemie?
Pytam, bo design to jedno a potem trzeba to produkcyjnie utrzymać, jakieś zarządzanie, konfigurowanie itp

Jeśli jakieś proste kolumny to poczytałbym o Cassandrze, jest wersja darmowa, jest też na wypasie płatna z wsparciem i dodatkami

[Rollines]

@morsik: dzięki za szybka reakcje.

Dane to głównie text, daty lub inty do 20 znaków max (za wyjątkiem jednej kolumny)
A rekordów niestety nie mogę stracić żadnych + ACID compliant.

[morsik]

A rekordów niestety nie mogę stracić żadnych + ACID compliant.

@Rollines: no więc opcją jest jedynie SQL.

To zostaje Ci:
- MS SQL Server za kupę hajsu - jeśli jesteś w środowisku Microsoftowym (typu C# czy .NET to pewnie to jedyna opcja dla Ciebie)
- Oracle za kupę hajsu - jeśli jesteś w środowisko Enterprise Linuksowym lub Microsoftowym
- PostgreSQL z hackami architektonicznymi; firmy ostatnio idą jednak w niego żeby odciąć

[Rollines]

@wpiot: kurde jestem laikiem, ale co masz na myśli „technologie w systemie”?

Aplikacja jest webowa napisana w pythonie

[morsik]

https://www.reddit.com/r/PostgreSQL/comments/7y65po/how_to_manage_a_table_with_50_billion_rows/

Tu wspominają o tym samym co ja - partycjonowanie.

Aczkolwiek w Postgresie jest to prostsze niż w MySQL bo Postgres może partycje robić pod spodem, a wystawiać użytkownikowi już widok z zagregowanymi partycjami.

[morsik]

Ah, no i potrzebujesz do tego dobry dysk bo wychodzi średnio 38 insertów/sekundę.

Niby nie dużo, ale jeśli nie możesz utracić ani jednego wiersza to jest to równoznaczne z robieniem synca przy każdym zapisie bo jest jednak obciażającą operacją na dysku. No i trzeba pamiętać, że to średnia arysmetyczna co znaczy, że w szczycie może być 200 czy nawet 1000 insertów/s.

W MySQL-u stosowałem hacki typu "rób synca co sekundę" - wtedy

[Rollines]

@morsik: dzięki, trochę już jestem lepiej przygotowany :)

Czy z ciekawości (jak i dla przyszłych pokoleń googlujacych ten temat) napisałbyś jakby to wyglądało, gdyby nie było transakcji i ACID nie byłby wymogiem?

[zibizz1]

@morsik: co to za takie swietne bazy co traca po kilka rekordow, lub 1/3 LOL

[wpiot]

@Rollines: Może inaczej. Chodzi mi o to czy masz w zasięgu kogoś z kompetencjami bazodanowymi i co ten człowiek potrafi. Dałeś taga aws - jeśli to będzie cloudowa apka, to AWS ma kilka różnych usług i może nie warto próbować instalować, konfigurować i uczyć się administracji samemu?

[morsik]

@zibizz1:
Przypadek z 1/3: każda NoSQL którą ktoś źle skonfigurował i zrobił shardy które nie mają replik ( ͡° ͜ʖ ͡°)

Przypadek z pojedynczymi: każda która nie syncuje danych przy zapisie tylko chwilę później. Przy niektórych trzeba w aplikacji wymuszać sync danych.

[zibizz1]

@morsik: a no to nie ma sensu wybierać bo każda gwarantuje możliwość utraty 100% danych.
Przypadek: brak slave/repliki

[morsik]

@zibizz1: no cóż, fakty są takie że gościu nie bardzo ma pojęcie co robi skoro pyta o takie rzeczy, a w NoSQLowych jednak znacznie łatwiej zgubić sobie dane gdy się nie wie co robi (czyt. jest defaultowa konfiguracja).

Nie wiem czemu jesteś taki czepliwy.

[Rollines]

@wpiot: będzie od tego człowiek, po prostu musiałem przynajmniej mniej więcej wiedzieć w co iść. Teraz już będę widział o co pytać takiego człowieka.

[aseeon_]

@morsik: jak na takie fajne odpowiedzi pisać takie bzdury o PostgreSQL to straszny dyshonor.

Nawet goły PostgreSQL z dobrą konfigurajcą na mocnym sprzęcie przyjmie na klatę taką ilość danych.

A jak komuś się nie chce po prostu skonfigurować odpowiednio postgresql i zakupić odpowiednio mocny serwer to problem w zależności od rodzaju danych został rozwiązany już wielokrotnie, Citus, Timescale, Greenplum, Amazon RDS for PostgreSQL, Cloud SQL for PostgreSQL - take your pick.

[morsik]

@aseeon_: czekałem aż ktoś się przyczepi do mojej wypowiedzi o Postgresie i nie zawiodłem się - szczególnie, że Ty odpowiedziałeś ( ͡° ͜ʖ ͡°)

A tak serio, bazy danych to nie jest mój konik, ale z racji pracy chcąc czy nie chcąc muszę ich dotykać i jakąś-tam wiedzę z nich mam. Z naciskiem na "jakąś-tam" ( ͡° ͜ʖ ͡°). Optymalizować ich za bardzo

[morsik]

@aseeon_: ale tak w sumie to czytam swoje wypowiedzi i nie widzę nigdzie jakiegoś szkalowania.

Napisałeś:

Nawet goły PostgreSQL z dobrą konfigurajcą na mocnym sprzęcie przyjmie na klatę taką ilość danych.

A ja napisałem:

myślę ze warto przetestować i o nim pomyśleć ale bez testów wydajnościowych się nie obejdzie (czyli hajs na specjalistów od optymalizacji Postgresa + hajs na zapewne poprawienie architektury Twojej aplikacji

oraz:

Ah, no i potrzebujesz do tego

[aseeon_]

jedynymi sensownymi kandydatami będą tu MS SQL Server lub Oracle

@morsik: O tak napisałeś, proszę spojrzeć. To jest ta nieprawda. A szkalowania faktycznie nie ma, no trudno :D

[morsik]

@aseeon_: no niech Ci będzie! Wygrałeś (✌ ﾟ ∀ ﾟ)☞