Jak duże tabele są spotykane w bazach danych?

Cześć wszystkim,
Napisałem dla siebie - do moich małych potrzeb prostą bazę danych tzn program serwerowy tcp/ip.
Działa stabilnie jest wielowątkowy sprawdzony na 20 klientów na raz ,nie zawiesza się a jeśli wystąpi bład to po 5 sek tworzy nowy wątek nasłuchujący.
Niestety jestem amatorem i moje algorytmy szyfrowania danych tabel oraz wysyłanych streamów (zwłaszcza szyfrowania wysyłki całych zapisanych tabel jako tabel a nie plików- gdybym wysyłał streamem cały plik wtedy problemu z szybkością by nie było).
I teraz moje pytanie jak jest to rozwiązane w profesjonalnych bazach? Operacje na tstringlist w postaci kodowania takiej tabeli do streama zajmuje znacznie więcej czasu niż ten sam sposób kodowania samego strumienia podczas tworzenia tabeli na dysku jako plik.
Mam dwa pytania:

1. jak duże tabele spotykacie najczęściej? - do jakich dostosować mój serwer żeby go z czasem ulepszać?
2. Czy - jeśli program kliencki zażyczy sobie wysyłki całej tabeli to czy wysyłać ją w formie Pliku szyfrowanego? Czy najpierw serwer odczytać ma tabele odszyfrowując ją do tstringlist a następnie zaszyfrować do wysyłki listy streamem ? Ten drugi sposób jest bardzo powolny.

Obecnie wygląda to wg sposobu 2, i stabilnie działa dla tabel 1000x1000 elementów - wysyłka internetowa danych to około 3 sek. Natomiast większe tabele potrzebują bardzo dużo czasu i zdarza się że przy ich przepisywaniu do memorystream że jest to ekstremalnie długie co zawiesza przesył. W ogóle nie ma to miejsca przy wysyłaniu bezpośrednio z pliku z pominięciem tstringlist.

Oczywiście istnieje opcja wycofania się z przesyłu takich dużych tabel, jednak w przyszłości być może część moich programów powinna mieć możliwość działania offline jeśli tabele bez danych wrażliwych będą potrzebne. Wtedy programy klienckie będą sprawdzać aktualność tabel w ich katalogach i aktualizować jeśli pojawi się nowa wersja tabeli bo zostanie przez kogoś zaktualizowana o wpisy itd.

Pozdrawiam i proszę o pobłażliwość.
Piszę dla siebie małe programy i do mojego miejsca pracy. Nikt z Was nawet nie pochyliłby się nad rozwiązaniem naszych problemów bo skala i komplikacja jest nieopłacalna dla Was.
Krzysztof

Napisz co to za problem biznesowy jest. Po pierwsze poza tabelami słownikowymi nigdy nie przesylam calych tabel na klienta za jednym razem -od tego jest stronicowanie. I co oznacza rozmiar 1000×1000 elementów. Jakich elementów? Czym one są jaki mają rozmiar.

Wielkość tabeli nie ma znaczenia !
Opisz trochę technicznej, bo na razie to zero konkretów , co wysyłasz, skąd dokąd i dlaczego

W treści pojawia sie tstringlist , czy to jest Delphi albo C++ Builder ?

Problem biznesowy to np bardzo specyficzny grafik pracy z wystawianiem faktur zliczaniem godzin automatycznym przydzielaniu miejsca pracy w danym dniu dla obecnych z wzięciem pod uwagę umiejętności(grupy specjalistów itd) i preferencji. W tym określenie wielu innych preferencji dynamicznie zmieniających się w ustawieniach dostępnych dla admina na oddziale szpitalnym wraz z równomiernym w długim okresie obliczaniem kto ile gdzie i jak randomizację nieco zmieniać wg tych danych- program ma to robić sam. Jedynie zasady - ustawienia byłyby ustawialne w wielu profilach.
Prowadzenie na wybranych maszynach kart zleceń (bardzo specyficzne dla oddziałów intensywnej terapii więc niekomercyjne i zapomnij że szpital za to zapłaci w Polsce :( ). W tym samym programie dynamiczne kierowanie antybiotykoterapią i sugerowanie na podstawie wielu składowych wprowadzanych w kliencie danych opisujących sytuację chorego. Wszystko ustawialne dynamicznie przez osobę z uprawnieniami do kierowania antybiotykoterapią w szpitalu.
Na ten moment tabele będą małe stosunkowo , dane zapisywane w komórkach ansistring zawsze.
Napisanie takiego programu wymaga żeby zrobił to anestezjolog bo inaczej nie weźmie się prawidłowo pod uwagę wielu specyficzności. Albo anestezjolog i programista i to siedząc koło siebie bo inaczej program będzie kiepsko się sprawdzal i nie będzie wykorzystywany.
Taki mam plan. Idzie to wolno bo przerwałem pracę nad tym jakiś czas temu, miały przyjść rozwiązania … niestety to co przyszło załamanie przeżyliśmy haha.
Chcę sobie ułatwić pracę i skupić się głównie nad antybiotykami bo antybiotykooporność bakterii zabija coraz więcej ludzi a z antybiotykoterapii chyba nowe podspecjalizacje powstaną…

1. aplikacja działa lokalnie (ew. po VPNie) czy globalnie?
2. klienci są windowsowi czy mobilni
3. w czym piszesz? Delphi / Lazarus / coś innego?
4. jeśli lokalnie na windowsie to dlaczego nie łączysz się bezpośrednio do bazy z klienta?
5. czy próbujesz wymyślić własny protokół komunikacji zamiast użyć np. REST czy SOAP (wiem stare i niemodne) lub ew. ClientDataSet z Delphi
6. czy Ty próbujesz przepychać CAŁE SPAKOWANE DATASETY zamiast odpytać serwer o interesujące dane i tyle?

taki przykład obecnie wystepujących komend(przepraszam za styl kodowania :():

if com='#delete_base:' then list.Add(delete_base(s)); {#delete_base:baza}
if com='#list_bases:' then bases_list(list);     {#list_bases}
if com='#read_base:' then base_read(s,list);    {#read_base:baza}
if com='#base_date:' then base_date(s,list);    {#base_date:baza}
if com='#create_row:' then create_row(list,s); {#create_row:baza}
if com='#delete_row:' then delete_row(list,s); {#delete_row:baza,row  - row - unikalny numer wiersza}
if com='#create_col:' then create_col(list,s); {#create_col:baza}
if com='#delete_col:' then delete_col(list,s); {#delete_col:baza,col - unikalny numer kolumny}
if com='#insert_value:' then insert_value(list,s); {#insert_value:baza,col,row,value - unikalny numer kolumny}
if com='#read_value:' then read_value(list,s); {#read_value:baza,col,row}
if com='#read_row:' then read_row(list,s); {#read_row:baza,row}
if com='#read_col:' then read_col(list,s); {#read_row:baza,col}
if com='#mkdir:' then make_dir(list,s); {#mkdir:path} {podaj sciezke do folderu w katalogu bases, jesli go nie ma zostanie utworzony}
if com='#rmdir:' then delete_dir(list,s);{#rmdir:}
if com='#is_equal:' then  is_equal(list,s);{#is_equal:base,col,row,value}//  zwraca true albo false
if com='#list_dirs:' then list_dirs(list,s); {zwraca wszystkie katalogi w katalogu bases}
if com='#list_files:' then list_files(list,s); {zwraca wszystkie pliki w katalogu bases}
if com='#check_row:' then check_row(list,s); {#read_row:baza,col}
if com='#check_col:' then check_col(list,s); {#read_row:baza,row}
if com='#recive_file:' then recive_file(list,s,asocket); {s=#recive_file:baza,x,y,file_path - sciezka na kliencie}
if com='#send_file:' then    

W moim wszechświecie tak słabym nie pozwala się pisać "produkcyjnych" programów dla medycyny

Czyli na ten moment jedno rozwiązanie jest- nie praktykuje się przesyłania dużych tabel danych.

Pozostaje pytanie jakie duże tabele zwykle spotykacie ( ile column na ile wierszy) średnio tak….
Czy warto mi pracować nad przyspieszeniem dla super dużych tabel. Czy zostawić już temat i robić klienta użytecznego a nie testery.

Trochę się pogubiłem w tym co chcesz zrobić jak tabele w katalogach to już całkiem nie wiem o co caman. Chyba podchodzisz do tego bardzo źle. Zacznij od bazy relacyjnej, to co opisujesz to nie jest jakiś wielki problem, kwestia jak jest bardziej jak to merytorcznie wyglada.

Pisząc klient mam na myśli program który sami wykorzystać chcemy z kolegami w pracy.

Merytorycznie program serwerowy kolejkuje zapytania - wpisy dokonuje wg kolejności i robi je tylko dla pojedynczych komórek dlatego każdy użytkownik - klient nie skasuje jednoczesnego wpisu innej osoby. Gdy trwa zapis do tabeli inne wątki jednoczasowe mają zakaz zapsiu i czekają. Zapis jest zawsze poprzedzony odczytem (świeżej wersji tabeli z dysku) i cały proces (odczyt- operacje- zapis) traktowany jest jako zapis. W większości przypadków wymagane jest zapisywanie pojedynczych komórek. Omija to nadpisywanie sobie nawzajem całej tabeli albo ginięcia wpisów.
Zwykłe czytania komórek i odczyty wykonywane są bez kolejkowania (tzn poza czasem zapisu).
Baza jako taka jest zbiorem katalogów dla różnych klientów(różne programy o różnych zastosowaniach mają dostęp do właściwego dla siebie katalogu ja go ustalam pisząc klienta).
W każdym z katalogów np dla programu z antybiotykami są podkatalogi z plikami i tabelami w zależności jak program kliencki je nakaże stworzyć serwerowi.
Tabele w pierwszym wierszu mają podane ilości kolumn i wierszy z jakich się składają, klient ma możliwość odczytać datę utworzenia/modyfikacji pliku, dzięki czemu może odczytując tylko jedną komórkę wiedzieć czy należy zaktualizować wyświetlane dane (bo ktoś z pozostałych użytkowników je zaktualizował).
Raz na jakiś czas ustalony przez admina- klienta serwer wykonuje backup całego właściwego katalogu na osobnym dysku tworząc kilka kopii , każda z nieco innego czasu wg harmonogramu. Oraz na życzenie klienta serwer przywróci z zapasowego dysku daną kopię backupu. Tego jeszcze nie ma ale to będzie prosta procedura do napisania.

Ja maluczki jestem, nie znam się, więc powiem, co myślę, choć pewnie źle myślę.
Przychodzi kolega do działu "bazy danych" gdzie ludzie piszą głównie o SQLu, czasem jakichś Mongach, Redisach, z rzadka o Accessie.
Kolega pisze, że ma jakiś projekt z kategorii mocno branżowych, wymyślił do tego architekturę opartą o swój serwer, jakąś strukturę katalogów z plikami tabel wewnątrz. Jak wspomniałem, nie znam się, więc nie wiem, o czym tu mowa.

Ale zasadnicze pytanie brzmi, jak duże tabele są spotykane w bazach danych?
Ja bym powiedział, że bardzo duże, choć sam z takimi do czynienia nie miałem. Największa tabela, jakiej osobiście "dotykam", waży aktualnie około 50GB przechowując przy tym ~110M rekordów. Podejrzewam, że koledzy z forum pracują z tabelami większymi o rząd wielkości.
Ale bladego pojęcia nie mam, jakie to ma znaczenie dla Twojego projektu - to Ty piszesz swojego "potworka", więc Ty wiesz najlepiej, jakiej ilości danych się spodziewać powinieneś

S4t napisał(a):

Trochę się pogubiłem w tym co chcesz zrobić jak tabele w katalogach to już całkiem nie wiem o co caman. Chyba podchodzisz do tego bardzo źle. Zacznij od bazy relacyjnej, to co opisujesz to nie jest jakiś wielki problem, kwestia jak jest bardziej jak to merytorcznie wyglada.

Powiem mniej delikatnie: to jakieś mrzonki ...

małe tylko tabele max do 1000x1000.zresztą największa jaką do moich zastosowań teraz widzę to 200x200. Pozostałe będą dzielone no na lata w swoich katalogach, każda 12x31 komórek. . — Windowbee 20 minut temu

To słownictwo świadczy jak dalece nie kontaktujesz z branżą

Windowbee napisał(a):

Niestety jestem amatorem i moje algorytmy szyfrowania danych tabel

Nie wymyślaj samodzielnie szyfrowania, skorzystaj z gotowych rozwiązań, 3DES, AES.

Bardzo trudno wymyśleć własne szyfrowanie bezpieczne, to trochę jak nagroda nobla do zdobycia, jak wymyślisz algorytm co będzie konkurował z tymi co są na rynku.

NIE ODPOWIADAJ W KOMENTARZACH!!!! Ciężko to czytać a jeszcze ciężej odpowiadać

@Windowbee, szczerze mówiąc zgroza mnie ogarnęła jak widzę, że amatorsko i jak rozumiem - jednoosobowo - napisany program jest wykorzystywany w leczeniu pacjentów.
Kwestie dostępu danych i bezpieczeństwa na razie pomińmy, ale co z testami? Ktoś to poza twórcą weryfikuje? Jak zapewniana jest jakość developmentu i sprawdzanie czy spełnia on założenia (o ile są jakieś)?
Kolejna sprawa to kwestia odpowiedzialności - jeśli program ma wpływ na leczenie pacjentów, to twórca jest jednoosobowo odpowiedzialny w razie jakiegoś "fakapu". Nie polecam takiej opcji.

Co do tabel, przyjąłeś jakieś dziwaczne rozwiązanie, które nie ma nic wspólnego z typowymi bazami relacyjnymi. Szczerze mówiąc nic nie zrozumiałem z twoich opisów działania tych "tabel" (a raczej chyba tablic /array/ czy też macierzy, sądząc po ich dynamicznym rozmiarze).

Tabela w typowej bazie danych ma stałą liczbę nazwanych kolumn, które identyfikują wartości zapisane w danej kolumnie, a ponadto każda kolumna ma określony typ danych (liczba, data, tekst itp.).
Poza szczególnymi przypadkami czy też modyfikacjami programu tabela nie zmienia liczby kolumn wraz z przyrostem danych. Dodajemy tylko nowe wiersze (rekordy), czyli każdy z nich ma tę samą strukturę.

Tabela (a inaczej mówiąc - relacja) przechowuje dane powiązane ze sobą relacjami, dajmy na to: Adresy, Osoby, Role osób, Przydział do Ról, Badania, Wyniki Badań itp.
Poszczególne tabele można wiązać ze sobą, zapewniając spójność danych i tworząc pewne zasady logiczne (np. osoba może mieć wiele adresów, ale dany adres może być przypisany tylko jednej osobie). Więcej nie będę rozwijał tematu, bo to nie wykład o relacyjnych bazach danych.

Mam przeczucie, że większość problemów byś rozwiązał stosując jakąś prostą bazę danych np. MySQL/MariaDB (albo bardziej zaawansowaną PostgreSQL) czy też SQLite jako składnicę danych. Wtedy taka baza zapewnia ci mechanizmy pilnowania spójności, wielodostępu, uwierzytelniania, autoryzacji (ograniczanie dostępu do elementów bazy), szyfrowania (* sprawdzić czy dana baza to wspiera), tworzenia i odtwarzania kopii zapasowych itd.

A dane z niej pobierasz tylko te co potrzebujesz zamiast przesyłania całych zbiorów danych ("tabel") - użytkownik za pomocą interfejsu aplikacji wysyła żądanie o przesłanie danych z konkretnych tabel (zwykle wielu na raz), dla rekordów spełniających zadane kryteria (np. data badania = 2023-11-03, pacjent=Kowalski Jan).

robertos7778 napisał(a):

@Windowbee, szczerze mówiąc zgroza mnie ogarnęła jak widzę, że amatorsko i jak rozumiem - jednoosobowo - napisany program jest wykorzystywany w leczeniu pacjentów.

Jej no nie o to mi chodziło żeby straszyć :) zupełnie nie! Ale niestety przez moje braki w słownictwie i wyrażaniu siebie w sposób Wam bliski czyli fachowy to mimo że wiem ,że to co zrobiłem działa stabilnie i wystarcza do bieżących moich potrzeb to nie mogę Wam w tak krótkich komentarzach odpowiadać na wszelkie zarzuty.

Jeśli chodzi o wpływ na leczenie pacjentów to ma to taki obecnie ,że braki pewnych ułatwień informatycznych przerzucają część naszego czasu w papiery i prymitywne metody przeszukiwania danych- książki, tabelki itd (jeśli chodzi o antybiotyki).

Program doboru empirycznego antybiotyków w odniesieniu do konkretnych sytuacji klinicznej i stwierdzonych oporności w szpitalu/ oddziale , biorący pod uwagę niewydolności narządowe i sugerujący podanie takich a takich antybiotyków nie zwalnia nikogo z myślenia!

Algorytm zaimplementuję w kliencie taki jaki wykorzystujemy my - nasze mózgi podczas doboru obecnie. Tabele i relacje między nimi będzie segregować właśnie klient znacznie upraszczając przeszukiwania ,że tak powiem „wspólnych mianowników” a wyniki wyrzuci argumentując ścieżkę jak do tego doszedł na wykresach i w zbiorach wizualnie.
Nikt z moich kolegów bezkrytycznie nie zastosuje antybiotyku przeciwskazanego bo też są specjalistami i delikatnie mówiąc coś nie będzie grało. Poza tym program będzie się składał z 8 tabel (takich jak opisałem- wiersze plus kolumny) zarówno wiersz jak i kolumna ma unikalny znacznik. Wiem gdzie w takiej tabeli umieszczać takie a takie dane i wiem jak odczytywać relacje pomiędzy nimi (mimo że tych 8 tabel jest rozłącznych fizycznie). Jeśli wiem jak dane będą ustrukturyzowane to nie będzie błędu w algorytmie i będziemy go testowali najpierw. Zaoszczędzi to wertowania pewnych podręczników , indeksu leków - jak dawkować w takiej a takiej niewydolności. Program podpowie wiele rzeczy i wyświetli dane na podstawie których algorytm znalazł relacje pasujące do zapytań. Wyniki przedstawi w taki sposób żeby 70 letnia lekarka jak i rezydent mógł zrozumieć i się odnieść. W tym programie kwestie bezpieczeństwa wyglądają tak jak dane do niego wprowadzone. Jak to z jakich się korzysta. Z informacji z pudelka nikt nie leczy. Algorytm rozbudowywać będę ja i osoba zajmująca się antybiotykoterapią (już w większości jest gotowy w naszych głowach od dawna)w szpitalu plus rezydenci będą uzupełniać online tabele w domu albo na dyżurach.
Moje tabele można rozbudowywać nie wpłynie to negatywnie na algorytm. Ani kasowanie wiersza ani kolumny.
Bezpieczeństwo logowania jest drugorzędne. Bo tylko uprawnieni będą mieli możliwość wglądu edycyjnego do tabel. Choć widzieć je będą wszyscy.

To jest tylko jedna część zadań jakie program ma wykonywać.

[robertos7778]

A dane z niej pobierasz tylko te co potrzebujesz zamiast przesyłania całych zbiorów danych ("tabel") - użytkownik za pomocą interfejsu aplikacji wysyła żądanie o przesłanie danych z konkretnych tabel (zwykle wielu na raz), dla rekordów spełniających zadane kryteria (np. data badania = 2023-11-03, pacjent=Kowalski Jan).

Tak, rozumiem to i zaimplementuję taką funkcję jeszcze. Część tabel musi się pobierać aby zapewnić działanie offline klienta. Gdy ktoś dokona zmiany w tabeli na serwerze to klient sobie ją zaciągnie automatycznie. Stąd było takie pytanie. Zależy od specyfiki danego programu klienckiego.

Dość mgliście opisałeś problem.
Wydaje mi się że próbujesz wymyśleć na nowo koło.
Użyj relacyjnej bazy danych, która rozwiąże wiele problemów, które sam musiałeś oprogramować (wielodostęp, integralność danych) .
Ps. Tabela z 1000 kolumnami to jakiś koszmarek

grzegorz_so napisał(a):

.

Ps. Tabela z 1000 kolumnami to jakiś koszmarek

na razie największa to 100 antybiotyków na 100 gatunków bakterii, mniej więcej… reszta tabel w tym programie będzie mniejsza. Tabele muszą się multistanowiskowo edytować i aktualizować na każdym stanowisku. Przy czym zmieniać je będzie tylko serwer na wniosek klientów.

Teraz już rozumiem, o co Ci chodzi z tymi tabelami. Masz na myśli tabelki w formacie, do jakiego przyzwyczajeni jesteśmy w książkach - w osi poziomej lista antybiotyków, w osi pionowej lista bakterii, a na przecięciu informacje o działaniu danego antybiotyku na daną bakterię, co przy stu bakteriach i stu lekach daje maksymalnie 10 000 komórek z opisywanymi cechami (nie wiem, czy zakładasz, że niektóre będą puste
W relacyjnych bazach danych byłoby to rozwiązane tak, że miałbyś tabelę z kilkoma kolumnami i maksymalnie dziesięcioma tysiącami wierszy, gdzie jeden wiersz opisywałby jedną komórkę z "Twojej tabeli".
Przykładowy zestaw kolumn w takim układzie:

1. identyfikator bakterii
2. identyfikator antybiotyku
3. jedna, lub kilka(naście/dziesiąt) kolumn opisujących cechy połączenia leku z mikrobem
4. wersja (data aktualizacji na serwerze).

Przy takim układzie możesz trzymać wszystko na każdym kliencie, a synchronizacja polega na odpytaniu serwera o wszystkie (ale tylko te) rekordy, które mają datę aktualizacji większą od największej daty aktualizacji spotkanej w bazie klienta.

Tak mniej więcej o takie rozwiązanie. Pusta komórka zawierać będzie 0 albo null zresztą algorytm obsłuży to. Takich tabel będzie kilka. Ale małe. Muszą być edytowalne na kliencie ale zmiany wprowadzone przez serwer. Edycja dla odp. poziomu dostępu.