Użytkownik "Tomek Kańka" <t...@t...eu.org> napisał w wiadomości
news:slrnkoemnj.4ci.tom@tv2.dom.local...
> M.M. <m...@g...com> napisał(a)
>> W dniu poniedziałek, 6 maja 2013 00:06:23 UTC+2 użytkownik Lopez napisał:
>>
>>> A w takim, �e ma juz w sobie przede wszystkim obsluge
>>> sesji i uwierzytelnianie, a takze wiele dodatkowych funkcji
>>> jak obsluga parametrow, ORM itp. ktorych chyba nikt normalny
>>> nie chce pisac od nowa:)
>>
>> Frameworki w takim PHP maja pelno bledow.
>
> Tak, w przeciwieństwie do home-made rozwiązań.
>
>> Znam kilka
>> osob ktore napisaly swojego prostego frameworka i wcale
>> nienormalne nie sa.
>
> To chyba taka php-przypadłość, że tam każdy wynajduje koło. Raz
> współpracowałem z takimi, którzy pisali "swoje" RSA - wyszło fatalnie.

To nie jest przypadlosc php - to ogolnie czesto spotykana "ambicja" u wielu
programistow.

Przyznaj sie - nigdy, zwlaszcza na poczatku drogi, nie probowales stworzyc
czegos "lepszego" od tego co jest ogolnie dostepne?

do góry

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

do góry

On 2013.05.02 13:06, M.M. wrote:

> Ale z tego co się rozglądałem, to zatrudnienie
> ludzi wprawnie posługujących się C++ za średnie wynagrodzenie jest
> praktycznie niemożliwe. W praktyce bym musiał zrobić wszystko sam, albo
> prawie sam.

To zdradź rąbka tajemnicy co to jest za projekt i jaki przewidujesz ruch
na stronie (500 requestów na sekunde?). Może ktoś z grupy zechce
współpracować.


--
Tomek

do góry

co do tego przyspieszania baz danych na plikach
to nie widze tego w jakis oczywisty sposob

przy samym czytaniu albo takim calosciowym
przetwarzaniu plik wejsciowy na plik
wyjsciowy to moze tak ale przy wyszukiwaniu
i tych insertach delete to nie wiem

wogole nie znam sie na stronkach
- to czytanie z dysku tak spowalnia?
skryptowe kody strony? wolne lacze?
(mi sie zawsze wydawalo ze glownie wolne
lącze

asynchroniczne czytanie plikow ladnie
dziala (nie obciaza procesora) i ciekawbylbym
czy daloby sie to zrobic tak by np
asynchronicznie czytac 10 plikow rownolegle

inna rzecz czy sa systemy plikow ktore
obsluguja inserty delety, bez przepisywania
tresli plikow i dlaczego wspolczesne kompiane systemy bodajrze tego nie obslugują

do góry

W dniu poniedziałek, 6 maja 2013 11:31:32 UTC+2 użytkownik Tomasz Sowa napisał:
> On 2013.05.02 13:06, M.M. wrote:
>
>
>
> > Ale z tego co si� rozgl�da�em, to zatrudnienie
>
> > ludzi wprawnie pos�uguj�cych si� C++ za �rednie wynagrodzenie jest
>
> > praktycznie niemo�liwe. W praktyce bym musia� zrobi� wszystko sam, albo
>
> > prawie sam.
>
>
>
> To zdrad� r�bka tajemnicy co to jest za projekt i jaki przewidujesz ruch
>
> na stronie (500 request�w na sekunde?). Mo�e kto� z grupy zechce
>
> wsp�pracowa�.
>

500 requestow na sekunde to chyba bardzo
duzo, nie? jakie stronki maj atak duzy
ruch?

do góry

W dniu poniedziałek, 6 maja 2013 08:33:21 UTC+2 użytkownik R.e.m.e.K napisał:

> A co z fragmentacja dysku?
Z tego co słyszałem, problem fragmentacji dysku na dobrych systemach
plików nie występuje przy spełnieniu prostego warunku: dysk nie może
być zapełniony, musi na nim być zawsze pewien zapas wolnego miejsca.


> Co Ci da to, ze dane beda "obok" siebie w pliku
Nie chodzi o to co da, ale co zlikwiduje. Zlikwiduje zbędne naprowadzania
głowicy. Będzie odczyt sekwencyjny zamiast random.


> skoro beda na dwoch koncach dysku?
O ile się nie mylę, na dobrych systemach plików tak się dzieje bardzo rzadko.


> Pomijajac juz taki detal, ze nie ma zadnego mechanizmu ukladania
> danych w tabelach wg swoich widzimisie.
Skoro znasz tak dobrze silniki bazodanowe, to wierzę, że takiego mechanizmu
żaden silnik nie oferuje. Ja je znam bardzo pobieżnie... umiem założyć
tabelę, indeksy, zrobić zapytanie, ewentualnie umiem dodać jakiś triger.
Myślałem że może są jakieś zaawansowane optymalizatory.


> Tym zarzadza serwer i nie masz do tego dostepu. Nie istnieje takie
> pojecie jak kolejnosc ulozenia danych w pliku bazy danych.
Kilka dni temu też tak powiedziałem, kumpel na to mi odrzekł: znasz góra
10% możliwości dwóch baz, lepiej się upewnij. Rozumiem że Ty znasz
bazy danych w 100% i mogę na tej informacji polegać?


> Z pewnoscia moge zaryzykowac stwierdzenie, ze chocbys stanal na glowie nie
> jestes w stanie zrobic nic wydajniejszego niz wspolczesne silniki DB.
Nie mogę, a jakimś dziwnym trafem kilka razy w swoim życiu zrobiłem. Kilka
ostatnich programów które napisałem działają setki razy szybciej na plikach
csv niż na bazach postgres i sqlite. Działają dlatego szybciej, że w jednym
plik csv mam dokładnie to, co z bazy muszę wyciągać skomplikowanym zapytaniem.

Zrób eksperyment. Załóż bazę która zawiera 5-7 tabel dużych tabel. Połącz
wszystkie tabele jakimiś relacjami. Napisz zapytanie do wyciągania danych.
Zmierz czas zapytania. Potem zapisz wyniki zapytania w pliku, w postaci
liniowych rekordów. Ostatecznie zmierz czas odczytania tego pliku ( w
jakimś dobrym języku, może Java, albo C++). Zobacz jakie będą różnice w
czasie.

No ale ja nie znam perfekcyjnie wszystkich możliwości jakie oferują bazy...
może na bazach też da się uzyskać taki efekt... może coś robię źle...
Nie wiem, ja raczej pytałem w tym poście o radę.


> Powiem wiecej, wydaje mi sie, ze trwonisz czas na nieistotnych rzeczach,
> bazy danych dzialaja z setkami milionow rekordow, ze zlaczeniami i innymi
> "utrudnieniami" i daja rade.
Dają radę, tak jak mogą. Masz setki milionów rekordów. Wśród nich masz tysiąc
rozrzuconych losowo przeznaczonych do wyciągnięcia. Jeśli rekordy nie są w
cache, to:
1) jeśli nie są zaindeksowane - trzeba przejrzeć setki milionów, aby znaleźć
ten tysiac;
2) jeśli są zaineksowane - w pesymistycznym przypadku trzeba naprowadzić
tysiąc razy głowicę + jeszcze trochę naprowadzeń na odczyt indeksów.

A gdy ten tysiąc rekordów leży w liniowym pliku, albo są w pamięci
RAM, bo programista napisał specjalistyczny algorytm cache, to dane
są w ułamku sekundy natychmiast.

> Na 90% zrobisz w swoim sofcie wiecej waskich gardel niz to, ktore
> dostaniesz od serwera SQL.
Nigdy nie twierdziłem że wyręczanie serwera SQL to łatwe zadanie i
pierwsza wersja wyrzeźbiona ręcznie będzie na pewno szybsza. Każdy
proces optymalizacji jest trudny i daje wiele możliwości na pogorszenie.


> Oczywiscie serwerowi tez
> mozesz pomoc lub podlozyc noge projektujac dobra lub zla strukture tabel.
No właśnie pytałem czy bazy danych oferują coś do układania potrzebnych
danych obok siebie :)


Pozdrawiam

do góry

W dniu poniedziałek, 6 maja 2013 20:29:24 UTC+2 użytkownik firr kenobi napisał:

> 500 requestow na sekunde to chyba bardzo
> duzo, nie? jakie stronki maj atak duzy
> ruch?

Sporo, zwlaszcza jak sie wezmie pod uwage fakt, ze jedno zapytanie
SQL trwa 2-10sekund :D

Pozdrawiam

do góry

Dnia Mon, 6 May 2013 12:55:09 -0700 (PDT), M.M. napisał(a):

>> A co z fragmentacja dysku?
> Z tego co słyszałem, problem fragmentacji dysku na dobrych systemach
> plików nie występuje przy spełnieniu prostego warunku: dysk nie może
> być zapełniony, musi na nim być zawsze pewien zapas wolnego miejsca.

A jaki system plikow tak dziala? Pytam z ciekawosci, bo o ile mi wiadomo
linuksowy Ext4 sie fragmentuje, NTFS wiadomo ze tak, jablkowy HFS takze.
Jaki nie?

>> Co Ci da to, ze dane beda "obok" siebie w pliku
> Nie chodzi o to co da, ale co zlikwiduje. Zlikwiduje zbędne naprowadzania
> głowicy. Będzie odczyt sekwencyjny zamiast random.

No tak, przy zalozeniu, ze fragmentacja dysku nie istnieje.

>> skoro beda na dwoch koncach dysku?
> O ile się nie mylę, na dobrych systemach plików tak się dzieje bardzo rzadko.

Podaj nazwy tych dobrych systemow plikow.

>> Pomijajac juz taki detal, ze nie ma zadnego mechanizmu ukladania
>> danych w tabelach wg swoich widzimisie.
> Skoro znasz tak dobrze silniki bazodanowe, to wierzę, że takiego mechanizmu
> żaden silnik nie oferuje. Ja je znam bardzo pobieżnie... umiem założyć
> tabelę, indeksy, zrobić zapytanie, ewentualnie umiem dodać jakiś triger.

Ogolna zasada budowy plikow bazy danych jest taka, ze plik jest zbudowany ze
stron, kazda taka strona ma okreslony rozmiar i jest alokowana w chwili, gdy
poprzednia strona sie "skonczy". Juz sam fakt korzystania ze stron i ich
dynamicznego przydzialu powoduje, ze beda one rozrzucone po dysku. Nie sadze
by jakikolwiek system plikow gwarantowal, ze konkretnemu plikowi bazy danych
da ciagly obszar dysku. Nawet gdyby tak bylo, to np. dane tabeli A moglby
byc w stronach 2, 10, 23, 65, 127, etc. Czyli i tak nie po kolei.

Tu masz o MS SQLu troche od kuchni. W innych serwerach jest podobnie.

http://edu.pjwstk.edu.pl/wyklady/szb/scb/wyklad15/w1
5.htm

> Myślałem że może są jakieś zaawansowane optymalizatory.

Optymalizatory sa, ale nie alokacji danych na dysku a zapytan, tworzace plan
zapytania z uwzglednieniem indeksow (lub nawet tworzeniem ich w locie w
razie potrzeby, jak umie czynic to MS SQL) i "inteligentnych" zlaczen.

>> Tym zarzadza serwer i nie masz do tego dostepu. Nie istnieje takie
>> pojecie jak kolejnosc ulozenia danych w pliku bazy danych.
> Kilka dni temu też tak powiedziałem, kumpel na to mi odrzekł: znasz góra
> 10% możliwości dwóch baz, lepiej się upewnij. Rozumiem że Ty znasz
> bazy danych w 100% i mogę na tej informacji polegać?

Nie mozesz oczywiscie, nikt nie jest omnibusem, ale przynajmniej masz
material do weryfikacji i przemyslen :-)

>> Z pewnoscia moge zaryzykowac stwierdzenie, ze chocbys stanal na glowie nie
>> jestes w stanie zrobic nic wydajniejszego niz wspolczesne silniki DB.
> Nie mogę, a jakimś dziwnym trafem kilka razy w swoim życiu zrobiłem. Kilka
> ostatnich programów które napisałem działają setki razy szybciej na plikach
> csv niż na bazach postgres i sqlite. Działają dlatego szybciej, że w jednym
> plik csv mam dokładnie to, co z bazy muszę wyciągać skomplikowanym zapytaniem.

Nie no.. oczywiscie. Ale nie o to mi chodzilo. Chodzilo mi o zrobienia
enginu analogicznego do RDBMS, czyli takich "plikow CSV" i ich obslugi, ze
mozesz dodawac miliony nowych wpisow w dowolnej kolejnosci do dowolnych
plikow, laczyc podczas wyszukiwania dane z roznych plikow po jakims
kluczu/kluczach, wyszukiwanie pozwalaloby zakladac warunki wybierajace tylko
niektore wpisy z plikow (zlozona klauzula WHERE na kilku plikach).
Bo jesli mowa o stalej (read only) strukturze danych, ktora jest ulozona w
kolejnosci odczytu i odczyty sa sekwencyjne (np. 500 rekordow od setnego) to
oczywiscie tak, mogles to napisac bez wiekszego trudu.

> Zrób eksperyment. Załóż bazę która zawiera 5-7 tabel dużych tabel. Połącz
> wszystkie tabele jakimiś relacjami. Napisz zapytanie do wyciągania danych.
> Zmierz czas zapytania. Potem zapisz wyniki zapytania w pliku, w postaci
> liniowych rekordów. Ostatecznie zmierz czas odczytania tego pliku ( w
> jakimś dobrym języku, może Java, albo C++). Zobacz jakie będą różnice w
> czasie.

Ale czekaj... co znaczy "Potem zapisz wyniki zapytania w pliku, w postaci
liniowych rekordów. Ostatecznie zmierz czas odczytania tego pliku"? Czyli
RDBMS odwali cala robote z szukaniem, a potem mam mierzyc wczytanie pliku
textowego z wynikami i to porownywac z baza?? Cos mi tu nie halo.

>> Powiem wiecej, wydaje mi sie, ze trwonisz czas na nieistotnych rzeczach,
>> bazy danych dzialaja z setkami milionow rekordow, ze zlaczeniami i innymi
>> "utrudnieniami" i daja rade.
> Dają radę, tak jak mogą. Masz setki milionów rekordów. Wśród nich masz tysiąc
> rozrzuconych losowo przeznaczonych do wyciągnięcia. Jeśli rekordy nie są w
> cache, to:
> 1) jeśli nie są zaindeksowane - trzeba przejrzeć setki milionów, aby znaleźć
> ten tysiac;

Lub pozwolic serwerowi zrobic indeks.

> 2) jeśli są zaineksowane - w pesymistycznym przypadku trzeba naprowadzić
> tysiąc razy głowicę + jeszcze trochę naprowadzeń na odczyt indeksów.

Lub w sprzyjajacych warunkach (zalezy od rodzaju danych) odczytac dane
bezposrednio z indeksu (to tez "w locie i po cichu" potrafia dobre RDBMS).

> A gdy ten tysiąc rekordów leży w liniowym pliku, albo są w pamięci
> RAM, bo programista napisał specjalistyczny algorytm cache, to dane
> są w ułamku sekundy natychmiast.

Heh, myslisz, ze serwery SQL nie trzymaja ile sie da w ramie? To jeden z
fundamentow wydajnosci. Nawet cale bazy potrafia trzymac jak maja odpowiedni
sprzet (czyt. kupe ramu).

>> Na 90% zrobisz w swoim sofcie wiecej waskich gardel niz to, ktore
>> dostaniesz od serwera SQL.
> Nigdy nie twierdziłem że wyręczanie serwera SQL to łatwe zadanie i
> pierwsza wersja wyrzeźbiona ręcznie będzie na pewno szybsza. Każdy
> proces optymalizacji jest trudny i daje wiele możliwości na pogorszenie.

Zycze Ci oczywiscie sukcesow, ale imho skupiasz energie w zlym miejscu. Lub
moze inaczej, warto sie tym zajmowac wtedy, gdy wszystko inne bedzie
stuningowane na maksa.

>> Oczywiscie serwerowi tez
>> mozesz pomoc lub podlozyc noge projektujac dobra lub zla strukture tabel.
> No właśnie pytałem czy bazy danych oferują coś do układania potrzebnych
> danych obok siebie :)

Chodzilo mi tu o dobra, przemyslana strukture tabel i indeksow. Do
zarzadzania plikami serwer uzywa inzynierow swojego producenta ;-)

--
pozdro
R.e.m.e.K

do góry

On 2013-05-06, R.e.m.e.K <g...@d...null> wrote:
> Dnia Mon, 6 May 2013 12:55:09 -0700 (PDT), M.M. napisał(a):
>
>>> A co z fragmentacja dysku?
>> Z tego co słyszałem, problem fragmentacji dysku na dobrych systemach
>> plików nie występuje przy spełnieniu prostego warunku: dysk nie może
>> być zapełniony, musi na nim być zawsze pewien zapas wolnego miejsca.
>
> A jaki system plikow tak dziala? Pytam z ciekawosci, bo o ile mi wiadomo
> linuksowy Ext4 sie fragmentuje, NTFS wiadomo ze tak, jablkowy HFS takze.
> Jaki nie?

XFS choćby.

>>> Pomijajac juz taki detal, ze nie ma zadnego mechanizmu ukladania
>>> danych w tabelach wg swoich widzimisie.
>> Skoro znasz tak dobrze silniki bazodanowe, to wierzę, że takiego mechanizmu
>> żaden silnik nie oferuje. Ja je znam bardzo pobieżnie... umiem założyć
>> tabelę, indeksy, zrobić zapytanie, ewentualnie umiem dodać jakiś triger.
>
> Ogolna zasada budowy plikow bazy danych jest taka, ze plik jest zbudowany ze
> stron, kazda taka strona ma okreslony rozmiar i jest alokowana w chwili, gdy
> poprzednia strona sie "skonczy". Juz sam fakt korzystania ze stron i ich
> dynamicznego przydzialu powoduje, ze beda one rozrzucone po dysku.

Dlatego pliki baz danych nie przyrastają po jednym bajcie, tylko po
kilkaset mega i więcej. Albo alternatywnie baza wymaga ręcznego dodania
nowego miejsca (np. pliku) do składowania danych -- wtedy się dodaje
miejsce w ilości rzędu gigabajtów.

> Nie sadze
> by jakikolwiek system plikow gwarantowal, ze konkretnemu plikowi bazy danych
> da ciagly obszar dysku. Nawet gdyby tak bylo, to np. dane tabeli A moglby
> byc w stronach 2, 10, 23, 65, 127, etc. Czyli i tak nie po kolei.

To już silnik bazodanowy powinien optymalizować.

Swoją drogą, zupełnie nie rozumiem po co rozważać ułożenie plików na
dysku w kontekście webaplikacji. To jak martwić się o kolejność
wykonania instrukcji maszynowych dla kodu napisanego w Prologu czy innym
Haskellu. Ani widać wpływ drugiego na pierwsze, ani da się go w ogóle
mierzyć...

--
Secunia non olet.
Stanislaw Klekot

do góry

Dnia Mon, 6 May 2013 21:39:36 +0000 (UTC), Stachu 'Dozzie' K. napisał(a):

>> A jaki system plikow tak dziala? Pytam z ciekawosci, bo o ile mi wiadomo
>> linuksowy Ext4 sie fragmentuje, NTFS wiadomo ze tak, jablkowy HFS takze.
>> Jaki nie?
>
> XFS choćby.

Dzieki za info, poczytam.

> Swoją drogą, zupełnie nie rozumiem po co rozważać ułożenie plików na
> dysku w kontekście webaplikacji. To jak martwić się o kolejność
> wykonania instrukcji maszynowych dla kodu napisanego w Prologu czy innym
> Haskellu. Ani widać wpływ drugiego na pierwsze, ani da się go w ogóle
> mierzyć...

O! To wlasnie mysl przewodnia mojego rozwleklego posta, obu nawet. Tez nie
wiem po co to roztrzasac i szukac dziury w calym.

--
pozdro
R.e.m.e.K

do góry