🚀 go-pugleaf

W dniu poniedziałek, 6 maja 2013 01:02:51 UTC+2 użytkownik M.M. napisał:
> W dniu poniedziałek, 6 maja 2013 00:39:18 UTC+2 użytkownik firr kenobi napisał:
> 
> > W dniu niedziela, 5 maja 2013 22:06:51 UTC+2 użytkownik M.M. napisał:
> 
> > > glowicy na dysku, ale nie wiem czy wiekszosc to 95%, czy moze 60%. Jesli
> 
> 
> 
> > dyski maja cache w ram - i kiedys 
> 
> > pisalem jak to ladnie dziala, np
> 
> > pierwsza kompilacja blisko 10 s
> 
> > a kolejna 1 s, innym razem o tym
> 
> > ze dostep z cache jest niewiele
> 
> > wolniejszy niz memcopy ) wydaje sie
> 
> > wiec ze to cache powinno dzialac
> 
> > zwlaszcza ze wspolczesne kompy maja
> 
> > sporo ramu - czyzby nie dzialalo ?
> 
> 
> 
> Dziala i to na tyle dobrze, ze przyspieszenie widac golym okiem. 
> 
> 
> 
> Problem w tym, ze danych moze byc 100 razy wiecej niz pamieci
> 
> RAM w jednym kompie. W takim przypadku "statystyczny bufor" 
> 
> raz zadziala dobrze, drugi raz zle. Zwykle algorytm buforujacy
> 
> musi byc dostosowany do aplikacji.
> 
> 
> 
> Teraz z innej beczki:
> 
> Odczyt z dysku jest szybki, naprowadzania glowicy
> 
> wolne. Na dysku lezy duza tabela, zawiera recepty pacjentow. Recepty
> 
> moga byc porozrzucane losowo. Gdy chce recepty Xa, to naprowadzam
> 
> glowice nad kazdy rekord z recepta i odczytuje. Gdy chce recepty
> 
> Ya, to robie to samo. Mozna wiec zmienic kolejnosc recept, tak aby
> 
> obok siebie lezaly recepty tego samego pacjenta. Ale gdy bede
> 
> chcial recepty z 5-maja, to napotkam ten sam problem, w innej 
> 
> postaci. Indeksy rozwiazuja problem przeszukiwania calej tabeli, ale
> 
> nie rozwiazuja problemu gdy rekordy sa losowo porozrzucane.
> 
> 
> 
> Czy w bazach danych (w systemach operacyjnych?) sa standardowo 
> 
> implementowane jakies rozwiazania tego problemu? Gdybym mial 
> 
> recznie cos takiego rozwiazywac, to chyba bym zrobil dwie kopie
> 
> tabeli, w jednej bym posortowal po nazwiskach, w drugiej po dacie.
> 
> 
> 
> Oczywiscie wplata sie w to wszystko koszmarny problem, a mianowicie
> 
> spowolnienie operacji usuwania i edycji pola po ktorym tabele zostaly
> 
> posortowane. Wiec moze optymalnym rozwiazaniem jest zrodlo danych na
> 
> XML czy CSV a nie na tabelach rekordow? Z pliku CSV mozna latwo 
> 
> usunac recepte, mozna recepte przeniesc z jednego pliku do drugiego.
> 
> 
> 
> Hmmm jakis czas temu byla dyskusja o rozwiazaniach NO-SQL, ale to
> 
> o czym teraz napisalem, to chyba rozwizanie NO-TABLES? :D
> 

cholera jasna, Znowu fatalnie sie czuje 
(nie wiem nawet czy to nie nawrot boreliozy
bo znowu 3dni temu lazilem po jakichs 
krzakach, znowu pogryzlo mnie chyba jakies 
robactwo i znowu czuje masakryczny prąd galwaniczny w stawach - przerabane, ufam
jednak ze chyba az takiego pecha nie mam
bo sa to nieziemskie kłopoty)
 

co do tych baz/plikow to sluszna uwaga,
sa to jednak kwestie dot szczegolw 
implementacji i poprawnego uzywania
baz danych i systemu plikow a ja nie
mam duzej wiedzy na ten temat

dysk+system plikow to jest w sumie rodzaj 
bazy danych ale raczej nie oferuje on
wyszukiwania (*) - nie oferuje on tez 
wlasnie
wspomnianych insertów i deletów (a moglby
bo przeciez klastry tworza linked liste
ale zdaje sie jest zle napisany i tego nie
obsluguje)

tak ze np wstawianie i deletowanie 
takich recept ani na dysku ani w bazie
chyba nie moze byc szybkie

(*) i jak na dany moment nie jestem 
pewien czy powinien za to obsluge insertowania i deltowania do srodku plikow 
powinien obslugiwac raczej na pewno