Konstrukcja bazy danych Opcje

[evenementrf]

Witam wszystkich.
Niedawno otrzymałem do napisania aplikacje, a raczej mam zaprojektować bazę danych, która będzie magazynowała dane z plików txt. Przerosło mnie to zadanie gdyż nigdy nie zajmowałem się aż tak ogromną ilością danych. Ale po kolei....
Dane wyglądają następująco:
tabela demoraficzna z pacjentami, każdy pacjent ma przydzielone badania, moga to być badania robione w odstępach czasowych np co ok 5 min, pojedyńcze badanie zwraca plik txt, który ma np 10 kolumn i 20 000 wierszy, są to liczby int badz double. Ja ten plik (a konkretnie dane z tego pliku) mam uploadować do bazy, po to żeby mozna było podglądac na szybko wyniki danego pacjenta.

Szczerze to nie mam pomysłu jak to ugryźć, bo dla 10 pacjentów tych danych może być kilka milionów. Uproszczeniem jest to że każde badanie (rodzaj badania) zwraca określona liczbę kolumn.
Wiadomo jak w każdej bazie chodzi mi o optymalizacje. No bo jeżeli do każdego badania będę tworzył dynamicznie nową tabelę to baza będzie puchła i myślę, że wyszukiwanie wyników badania jakiegoś pacjenta może trwać bardzo długo.

Dziękuję za każdą podpowiedz!

[grzes999]

Jeżeli wiesz jakie badania są możliwe i jakie będziesz miał wyniki to możesz dla każdego badania stworzyć osobną tabelę.
I wtedy dajesz coś takiego.

Pacjent

id | imie | nazwisko | ... |

Zlecone badanie

id_zleconego | id_pacjenta | id_badania

Badanie_X

id | jakaś kolumna | jakaś kolumna

To taki mój pomysł trochę wymyślany na szybko; ale może ci coś podpowie (IMG:style_emoticons/default/wink.gif)

Ten post edytował grzes999 17.04.2012, 10:22:43

[alegorn]

poszukaj informacji o nosql'owych bazach danych. niektore sa projektowane pod ogromne ilosci danych.

wydaje mi sie ze relacyjne bazy danych nie sa odpowiednim narzedziem do przechowywania tych informacji.
j.

[bpskiba]

A co powiecie na pomysł, aby pliki *.txt przechowywać na dysku, a w bazie danych jedynie adres do pliku i jego nazwę.
Można stworzyć na dysku katalog którego nazwa będzie taka, jak id_pacjenta, a w nim katalogi o nazwach takich, jak id_badania zawierające pliki *.txt

Oczywiście można tą strukturę na dysku budować dla każdego roku, wtedy będzie ona łatwa do konserwacji i archiwizowania

Gdy ktoś zechce sprawdzić jakie badania i kiedy były wykonywane u danego pacjenta dostanie odpowiedź z bazy danych. Sprawdzenie wyników będzie wymagało zaczytania pliku z dysku. Z uwagi na ilość informacji zapewne po jednym na stronę

Zaczytywanie plików *.txt i walidowanie do bazy w pola double uważam za zły pomysł z uwagi na możliwość pomyłki. Do tego kilka wątków niżej jest mój post z kwestią zaokrąglania (IMG:style_emoticons/default/Rkingsmiley.png)
Znacznie bezpieczniej jest wyświetlić plik bez ingerencji.

Piotrek

Ten post edytował bpskiba 17.04.2012, 18:22:09

[evenementrf]

NOSQL - ciekawe, jednam mam już wytyczne, serwer stoi na mysql więc nie mam zbyt wielkiego pola do popisu... ;/

a mam pytanie czy jeżeli będę tworzył do każdego badania dla pacjenta nową tabelę, baza urośnie do kilkudziesięciu tysiecy tabel (oczywiście zakładam że indeksy mi w tym pomoga) to czy wyszukiwanie będzie w miarę szybkie? bo wyczytałem że MYSQL nie ma ogranicznenia, ograniczeniem jest tylko przestrzeń dyskowa.

Pomysł z plikami *.txt ciekawy, jednak dane mają siedziec w bazie, pozatym mają być szyfrowane więc pliki odpadają.

[alegorn]

nie zakładaj ze nie masz wpływu na wybór rozwiązań.
jeśli przedstawisz odpowiednie argumenty - możesz postawić na swoim. w końcu to ty odpowiadasz za wykonanie projektu, to ty będziesz odpowiadał jeśli zabrniesz w ślepą uliczkę bez wyjścia.

w razie czego, ja bym się zabezpieczył dokumentem stwierdzającym, ze nie masz wpływu na wybór technologii, i nie odpowiadasz za jej ograniczenia.
z doświadczenia wiem, ze większości PM brak odwagi przed podpisaniem takiego dokumentu.

***

kilkadziesiąt tyś tabel..... osz... pomysł, czym np. będziesz chciał otworzyć do wglądu taka bazę danych... masakra. moim zdaniem, jest to zły pomysł. złe podejście, złe rozwiązanie, ja bym się tego nie podejmował, jeżeli nie miałbym innego wyjścia - zmieniłbym prace. pomyśl sobie ile czasu serwer będzie się podnosił... (musi zaczytać meta dane odnośnie każdej z tabel, brrr...)

z relacyjnych baz danych - oracle? mssql (IMG:style_emoticons/default/questionmark.gif) być może...

przeprowadź konsultacje z jakimś administratorem (zwłaszcza tym który będzie obsługiwał ten projekt), myślę ze kilka ciekawych spraw usłyszysz od niego, ciekaw jestem jego szacunku co do wymagań sprzętowych, i kosztów jakie za zakup i utrzymanie zapłacicie.

najzwyczajniej w świecie.
relacyjne bazy danych nie są projektowane do tego. i nie ma możliwości by ci to dobrze działało.
ty być może potrzebujesz hurtowni danych, nosql, ale na pewno nie mysql.

j.

[evenementrf]

Czytałem o data warehouse, kolega też mi o tym opowiadał ale też nie wiem jak to ugryźć, a mam zbyt małe doświadczenie...

też mi wybili z głowy pomysł dynamicznego tworzenia tabel, ale za to mam inny pomysł, wszystkie znaki z tych plików nie przekraczają nawet połowy LONGTEXT, tylko jak sprawnie urywać wiersze, ale myślę, że i z tym jakoś sobie poradze, najwyżej wszystko będę troktował jako tekst... a nie każdą daną osobno;]

[alegorn]

jasne, da sie. ale raczej zapomnij o sprawnym i szybkim dzialaniu tej bazy
choc jesli wesprzesz sie np sphinxem - jakos to zadziala.

wygeneruj sobie symylacje ilosci danych, tak by uzyskac tabele wielkosci kilkuset milionow rekordow.
sprawdz czy podstawowe operacje jakie bedziesz chcial przeprowadzac na tej bazie - beda mialy akceptowalne czasy reakcji.


j.

[bpskiba]

NOSQL - ciekawe, jednam mam już wytyczne, serwer stoi na mysql więc nie mam zbyt wielkiego pola do popisu... ;/

a mam pytanie czy jeżeli będę tworzył do każdego badania dla pacjenta nową tabelę, baza urośnie do kilkudziesięciu tysiecy tabel (oczywiście zakładam że indeksy mi w tym pomoga) to czy wyszukiwanie będzie w miarę szybkie? bo wyczytałem że MYSQL nie ma ogranicznenia, ograniczeniem jest tylko przestrzeń dyskowa.

Pomysł z plikami *.txt ciekawy, jednak dane mają siedziec w bazie, pozatym mają być szyfrowane więc pliki odpadają.

Gdyby jedynym problemem było szyfrowanie problem byłby banalny. Plik można zaszyfrować dowolnym algorytmem z losowym kluczem,a klucz ten (inny dla każdego pliku) przechowywać w bazie danych.
Jeżeli natomiast podtrzymana zostanie konieczność przechowywania danych w tabelach mysql widzę tu jedyną możliwość:
Zastosowanie dwóch serwerów mysql (na dwóch osobnych fizycznych maszynach) Pierwszy do obsługi danych pacjentów, całej aplikacji, uwierzytelniania itd, a drugi przechowywania wyników badań. Pierwszy serwer nie będzie problemem. Dodatkowo należy tu zapisać wskaźniki do szybkiego odnalezienia rekordu na serwerze 2

Dla określenia struktury bazy serwera nr2 trzeba będzie odpowiedzieć na kilka pytań. 90% zapytań o wyniki będzie dotyczyć ostatnich badań(ostatni dzień, ostatni tydzień). Należy określić ten czas i te dane trzymać blisko (może w osobnej bazie, a może nawet na serwerze nr 1)
Serwer 2 powinien przechowywać dane w osobnych bazach dla jakiegoś czasu (rok, rok_miesiąc, rok_tydzień)
Najstarsze dane należy przechowywać w tabeli archive
Mechanizmem pomocnym może być tutaj również partycjonowanie tabel

[adamec]

ale czy ciebie chodzi o zaprojektowanie bazy danych poprzez stworznie odpowiednich tabel ? czy poprostu szukasz odpowiedniego silnika bazy danych ? bo projekt tabel podał ci już grzes999

[evenementrf]

ale czy ciebie chodzi o zaprojektowanie bazy danych poprzez stworznie odpowiednich tabel ? czy poprostu szukasz odpowiedniego silnika bazy danych ? bo projekt tabel podał ci już grzes999

szukam jakiegoś sensownego projektu/pomysłu/układu tabel w bazie, aby szybkość wyszukiwania jednak była na możliwym poziomie, to co napisał grzes999 nie jest moim zdaniem dobrym pomysłem, gdyż przy założeniu że jedno badanie zwraca z czujnika tablice o 10 kolumnach i 10 tyś - 20 tyś wierszy powoduje, że po 100 próbkach badania na tym pacjencie, mamy już tabele mającą 2 miliony wierszy..... razy X pacjentów, razy X badań... nie wiem czy to będzie działało sprawnie...

alegorn dzieki za pomysł, nie wiedziałem o tym, na pewno wykorzystam... narazie biorę sie za robote