Marek Urbański

Marek Urbański Pasjonat - pierwszy
program napisany w
1987 roku

Temat: Duża baza - prośba o poradę

Mam pytanie i może ktoś pokusi się o odpowiedź ;)

Jaką bazę wybrać (nie wykluczam nawet plików w bashu bo spotkałem się też z taką opcją i była bardzo wydajna) do zbierania rekordów i późniejszej ich analizy, zakładając że:

- miesięcznie będzie to (2 wariany) 50 lub 100 mln danych
- sam rowek danych będzie miał 5 kolumn
- datetime, varchar(100), int(10), varchar(10), varchar(50)
- co miesiąc będzie nowy zestaw danych (ew. tabela)
- oczywiście chodzi o szybkość zapisu i odczytu
- nie mam worka złota na serwery kasetowe i Oracla ;)
- do dyspozycji załóżmy mam 8 vCPU, dyski hdd i 16GB RAM

Jakieś pomysły ?

konto usunięte

Temat: Duża baza - prośba o poradę

A czas dostępu do danych i ew. operacje na nich...?
Np. za moich czasów (początek tego wieku) program zwany "Demond Planer" bazował na silniku ACCESS i danych w plikach testowych... A możliwości...?
No cóż, to nie (tylko) silnik decyduje. Są powiązania, indeksy procedury składowane...
Twoje informacje są dość enigmatyczne. Do samego przechowywania takiej ilości danych wystarczą pliki txt lub csv. Ale co potem? I to powinno decydować o wyborze. Może FIREBIRD. Pracuję obecnie na 2.5 i już może dużo.... (przynajmniej do tego co pamiętam z ORACLE(9)). Ale są już nowsze wersje...
A może ACCESS wystarczy? Jeżeli każdy miesiąc będzie w odrębnej tabeli... (z twojego opisu nie wynika co będzie kryło się pod enigmatycznym varchar(100) a już int(10) wzbudza u mnie nie zdrowe emocje. :)Ten post został edytowany przez Autora dnia 03.03.18 o godzinie 00:51
Marek Urbański

Marek Urbański Pasjonat - pierwszy
program napisany w
1987 roku

Temat: Duża baza - prośba o poradę

Hmm, no sam nie wiem.
Kiedyś robiłem jakieś migracje z Accesa i mam wrażenie że przy takiej ilości danych on sobie z tym nie poradzi.
Z założenia 100 mln to jest jeden miesiąc - zastanawiałem się nad przerobienim kodu tak żeby dzielić tabele na mniejsze ilości ale mało schludnie mi to wygląda.
Pracowałem na Postgresie swego czasu dość mocno - radził sobie z dużymi bazami lepiej niż MySQL i MSSQL.
Pracowałem też w jednej firmie (dawno temu) i już wtedy mieli tyle danych że żadne bazy nie wyrabiały i obrabiali to w bashu - podobno robili wczesniej testy (jak ja tam zacząłem pracować to już to działało) i bash/c/c++ najlepiej wypadał (doda że jedna paczka liczyła się koło tygodnia !!!)

Mi zależy na prostych selectach (index na polach datetime i int), Co do typów danych to pewnie by można je zminimalizować ale założenie jest takie jakie jest. Teraz jest to MySQL a tam nie ma znaczenia czy jest to INT(8) czy INT(10).
Przepisywanie na C++/bash średnio mi się uśmiecha. Oczywiście jeśli chodzi o zapis to pół biedy, ale potem wyciąganie tych danych to już więcej roboty. No ale jak będzie trzeba to to zrobię.
Zagneżdzenie katalogów (typu postfix) nieźle sobie z tym radzi, no ale sporo pracy żeby to przpisać razem z historycznymi danymi)
Dlatego pytam o jakieś inne rozwiązania i bez urazy ale jakoś ACCESa w tym nie widzę ;)
Może z innej strony to ogarnąć - jakieś widoki, tabele buforujące typu memory ?
Może jakiś Rabbit do tego albo Erlang ?
Każdy pomysł i sugestia mile widziana :)
Krzysztof Wojtal

Krzysztof Wojtal Specjalista ds
systemu ERP, PL/SQL,
Crystal rep., Power
B...

Temat: Duża baza - prośba o poradę

Cześć,

Nie myślałeś o bazie Firebird (jest to darmowa baza). Parę lat temu miałem styczność z tymi bazami i całkiem nieźle sobie radziła z danymi. Co prawda, ja tylko wyciągałem z nich dane do raportów i analiz i dość szybko sobie z tym radziły. Jak się dobrze zdefiniuje indeksy to całkiem nieźle to śmiga i nie obciąży Ci budżetu.
Nie wiem jak jest teraz, ale na wersji 2.5 nie było zabezpieczenia na poziomie samej bazy danych. Wystarczyło przenieść bazę na swoją maszynę, gdzie znałeś hasło na usera SYSDBA i mogłeś przeglądać całą zawartość.

Pozdrawiam
Krzysiek.
Marcin Mackiewicz

Marcin Mackiewicz Programista JAVA, RS
Adware Polska

Temat: Duża baza - prośba o poradę

Przy takiej ilości danych zakładam, że pola tekstowe zawierają powtarzające się wartości.
Czy tam są dane osobowe i się nie powtarzają?

Wykorzystaj zagadnienia z hurtowni danych.

Dodaj słowniki i buduj je na etapie importu..
Ogólnie praca na liczbach jest dużo szybsza niż praca na tekstach a na pewno będziesz miał where varchar(100) like '%%'. Zrobienie słowników skróci te dane:

fakty: datetime, varchar
zamień np na
fakty: datetime, id_varchar
slownik1: id, varchar(100)
gdzie fakty.id_varchar => slownik1.id.
Teraz jak ktoś poprosi o dane zawierające treść "kozioł" to wystarczy
WITH sl AS (
SELECT id FROM slownik1 WHERE varchar ilike '%kozioł%'
)
SELECT * FROM fakty JOIN sl ON sl.id = fakty.id_varchar
co zadziała dużo szybciej niż
SELECT * FROM fakty WHERE varchar ilike '%kozioł%'
Z tabeli faktów zrób klaster ale wykorzystaj do tego mechanizm klastrowania wbudowany w engine bazy danych. Jak porobisz sobie kilka, kilkanaście niezależnych tabel to będziesz miał problem jeżeli zakres danych obejmie więcej niż jedną tabelę.

Na słownikach gdzie masz dane tekstowe załóż index na tekstach.

Na pewno na każdym engine bazy danych będzie działało dużo szybciej nie z tradycyjną tabelką.

ps. SQL PostgresSQL 9.x

konto usunięte

Temat: Duża baza - prośba o poradę

Pytanie jak będzie wyglądać dostęp do danych. Czy transakcyjność / ACID są potrzebne?
Ja bym zaatakował Kafką, do tego Kafka-streams, albo Apache Spark.

Jeżeli nie, bo coś tam. Pierwsze co - w rok danych będzie na tyle dużo, że ogarnięcie ich będzie dużym problemem. Zanim do tego dojdzie - trzeba zaprojektować partycjonowanie, tak, żeby potem kasować / przenosić / kompresować - to co jest wymagane, a nie dłubać w całym worze. PostgreSQL ma fajne indeksy - RBIN.

Może da się to wypchnąć do chmury? Skalowanie samego rozwiązania to jedno, ale testowanie hipotez, albo zmiana struktury wymagająca dużej mocy? AWS ma redshifta - interfejs jak postgresql, ale pod spodem baza kolumnowa, z danymi zebranymi w paczki.... No, ale to trzeba wiedzieć co i jak się chce. No i przy takich ilościach danych nikt nie używa Aurory, albo RDSa tylko się obskakuje całe rozwiązanie samemu. W ten sposób to działa. I tu jest kolejny wniosek - jest spora szansa, że i tak będzie potrzebny jakiś DBA.

Następna dyskusja:

PostgreSQL i duża baza danych




Wyślij zaproszenie do