Pan John Kołalsky napisał:

>> Dostałem kiedyś dane zorganizowane w ten sposób, że tekstowe informacje
>> były w kilkudziesięciu tysiącach małych plików pogrupowanych w kilka
>> poziomów katalogów. Pierwsze co zrobiłem, to potraktowałem to wszystko
>> wzmiankowanym programem TAR (co się wkłada: TApe-ARchiver, czyli program
>> do zamiany struktry dysku na liniową reprezentację taśmy magnetycznej).
>> Teksty nie zmieniły swojej formy, każdy został tylko poprzedzony jednym
>> wierszem zawierającym dane o pliku i katalogu. I już dało się w tej kupie
>> wszystko wyszukiwać w mgnieniu oka, zamiast czekać kilkadziesiąt sekund
>> nim system operacyjny rozprawi się ze strukturą danych na dysku.
>
> To Ty chcesz to wszystko przeglądać a nie szukać. Zupełnie inny problem.

Potrzebowałem szukać. Szukać konkretnych słów, czy ogólniej łańcuchów
znaków. Ten problem został świetnie rozwiązany w opisany wyżej sposób.

> Do szukania jest indeks. System plików może indeksować pliki tak samo
> jak baza danych, że będzie odpowiadał na zapytanie dotyczące zawartości.

Ten indeks, to przede wszystkim trzeba (trzeba?) najpierw stworzyć. Gdybym
był jakimś za przeproszeniem koderem od baz danych, to też bym tak gadał
-- "panie, to trzeba najpierw zorganizować w bazę, projekt zrobić, zespół
stworzyć, kierownika powołać, dać trzy miesiące czasu itd". Ale to *JA*
potrzebowałem w tych danych *szukać*. I zrobiłem to w sposób optymalny --
innymi metodami nie dało się tego zrealizować ani szybciej, ani taniej.

> Np w katalogu "janek" mogą być wszystkie sms'y Janka a w katalogu
> "2013-07-07" dzisiejsze sms'y. Zapytanie systemu indeksującego dane
> będzie statystycznie wielokrotnie szybsze od ich przeglądnięcia.

Statystycznie, to może będzie szybsze, ale praktycznie dla mnie to nie
do przyjęcia. Trzymam wszystkie SMS-y w jednym pliku i nie mam problemu
ze znalezieniem wszystkich "od Janka" albo z "1 marca" (no dobra, niech
będzie, że maile a nie SMS-y).

--
Jarek

do góry

Użytkownik "Krzysztof Halasa" <k...@p...waw.pl> napisał w wiadomości
news:m37gh28iht.fsf@intrepid.localdomain...
> "J.F." <j...@p...onet.pl> writes:
>
>> Rekompresja to spore obciazenie, prosciej byloby nagrywac lak leci.
>
> Trzeba porównać przepustowość rekompresora oraz dysków.

Takowoż. Zdarzało mi się już, ze starymi ATA (nie SATA!) dyskami, mieć
przepływność danych powyżej 150-200MB/s, bo dane były mocno skomprespowane,
a maszyna dośc mocna. W czasie, gdy dysk robił "seek", maszyna
dekompresowała dane z poprzedniego odczytu i szło, jak jasny gwint. Bo
oczywiście, nie zawsze jest tak fajnie, wiemy, że zależy to np. od struktury
danych. Przy zapisie - porcja danych, błysk kompresja i zapisanie
niewielkiej już porcji fizycznych danych na dysku. Może więc zajść (i
zachodzi, choć nie zawsze - stwierdzone empirycznie) zjawisko, że praca z
danymi gdy używamy kompresji, jest szybsza. Wada - proces (de)kompresji dość
mocno obciąża procesor - bo to nie tylko sama (de)kompresja, ale i reszta
algorytmów z tym związanych. Taki koszt przezroczystości - to nie ciurkający
sobie bez zobowiązań w tle RAR, czy ZIP, któremu można opuścić priorytet,
gdyby zanadto obciążał system.

--
Pod żadnym pozorem nie zezwalam na wysyłanie mi jakichkolwiek reklam,
ogłoszeń, mailingów, itd., ani nawet zapytań o możliwość ich wysyłki.
Nie przyjmuję ŻADNYCH tłumaczeń, że mój adres e-mail jest ogólnodostępny
i nie został ukryty. Wszelkie próby takich wysyłek potraktuję jako stalking.

do góry

Jarosław Sokołowski <j...@l...waw.pl> writes:

> Nie jestem zachwycony pracą naszych służb specjalnych, ale jeśli barierą
> w żądaniu dostępu do naszych SMS-ów są "seeki dyskowe", to jest z tym
> gorzej niż sie spodziewałem.

Problem byłby przede wszystkim z zapisem.

>> Trzeba tworzyć podwójne indeksy, minimalna różnica.
>
> Między tworzeniem pojedynczych i podwójnych, faktycznie minimalna.
> Ale między tworzeniem i nietworzeniem -- znacząca. Więć warto
> przynajmniej się zastanowić, czy zawsze warto i trzeba tworzyć.

Tu wydaje się to naturalne. No chyba że tylko chcemy przeszukiwać to
liniowo po czasie wysłania, wtedy nie ma takiej potrzeby. Bazy danych,
postaci normalne itd.

> Czyli żeby zgromadzić 'fsystkie tsy' SMS-y na dysku peceta muszę tworzyć
> 'optymalne rozwiązania' z niezwykłym fs? W takim razie mamy różne definicje
> optymalności -- jest jakaś granica, powyżej której indeksowane bazy danych
> mają sens. Poniżej tej granicy ujawniają się głownie wady złożonych
> systemów, a zalet nie widać. Nie upieram się, że tą granicą jest akurat
> wspomniany milion.

Nie twierdzę, że każde inne rozwiązanie jest złe, ale nie są one
optymalne. Przypominam że mówiliśmy o rozwiązaniu optymalnym.

Projektowanie rozwiązań, które nadają się dla naszej skali, i które będą
za małe w skali dwukrotnie większej, gdy stworzenie (R&D, bez sprzętu
itp.) rozwiązania pozwalającego na pracę w skali 1000 x większej
kosztuje tyle samo, jest raczej mało sensowne.
--
Krzysztof Hałasa

do góry

Jarosław Sokołowski <j...@l...waw.pl> writes:

> Mnie w tym wszystkim najbardziej przerażają pokłady nailwności pomieszanej
> z zakłamaniem. W różne rzeczy mogę uwierzeć, ale nie w to, że terroryzmem
> zajmują się jakieś niegramotne żule

Jednak tak najczęściej jest. Mnie to nie zaskakuje - każda osoba, która
nie jest opóźniona w rozwoju, powinna chyba rozumieć, że to jest bez sensu.
--
Krzysztof Hałasa

do góry

Anerys napisał:

> Może więc zajść (i zachodzi, choć nie zawsze - stwierdzone empirycznie)
> zjawisko, że praca z danymi gdy używamy kompresji, jest szybsza.

Tak było, wypisz wymaluj, z programem PKlite pod DOS-em. To był ten
program, co pakował exeki -- po spakowaniu działały tak samo, tylko
plik był mniejszy i rozkompresowywał się dopiero w pamięci komputera
po załadowaniu z dysku. No i z reguły uruchamiał się szybciej -- bo
procesory były wtedy już dość żwawe, za to transmisje dyskowe wolne.

--
Jarek

do góry

Pan Krzysztof Halasa napisał:

>> Nie jestem zachwycony pracą naszych służb specjalnych, ale jeśli
>> barierą w żądaniu dostępu do naszych SMS-ów są "seeki dyskowe",
>> to jest z tym gorzej niż sie spodziewałem.
>
> Problem byłby przede wszystkim z zapisem.

Nie jestem w stanie tego dokładnie ocenić. Znalazłem informację, że
w Polsce wysyła się rocznie 56 miliardów SMS-ów (myślałem, że mniej).
To daje średnią półtora tysiąca na sekundę. W porywach oczywiście
więcej (jakiś Nowy Rok), ale operatorów jest czterech i logowanie też
mogą mieć jakoś rozproszone. W każdym razie nawet te kilka tysięcy
dostępów do różnych plików w ciągu sekundy nie wydaje się czymś aż
tak bardzo problematycznym.

>>> Trzeba tworzyć podwójne indeksy, minimalna różnica.
>>
>> Między tworzeniem pojedynczych i podwójnych, faktycznie minimalna.
>> Ale między tworzeniem i nietworzeniem -- znacząca. Więć warto
>> przynajmniej się zastanowić, czy zawsze warto i trzeba tworzyć.
>
> Tu wydaje się to naturalne. No chyba że tylko chcemy przeszukiwać to
> liniowo po czasie wysłania, wtedy nie ma takiej potrzeby. Bazy danych,
> postaci normalne itd.

Nawet biorąc tygodniowy ruch od wszystkich operatorów, czyli miliard
SMS-ów, albo inaczej 100-200 GB danych, nie jest to jakiś dramat żeby
to zwyczajnie przegrepować w poszukiwaniu numeru. Ale nie gromadzi się
w jednym miejscu wszyskich SMS-ów od wszystkich do wszystkich (chyba
że na jakiejś pryzmie), więc i tak trzeba wstępnie określić miejsce
poszukiwań. Pożądnie indeksowana baza oczywiście będzie pomocą, ale
bez tego też się da. To nie ta skala, co Google i WWW.

>> Czyli żeby zgromadzić 'fsystkie tsy' SMS-y na dysku peceta muszę
>> tworzyć 'optymalne rozwiązania' z niezwykłym fs? W takim razie mamy
>> różne definicje optymalności -- jest jakaś granica, powyżej której
>> indeksowane bazy danych mają sens. Poniżej tej granicy ujawniają
>> się głownie wady złożonych systemów, a zalet nie widać. Nie upieram
>> się, że tą granicą jest akurat wspomniany milion.
>
> Nie twierdzę, że każde inne rozwiązanie jest złe, ale nie są one
> optymalne. Przypominam że mówiliśmy o rozwiązaniu optymalnym.

Na tym własnie polega różnica w naszych podejściach. Bo ja twierdzę,
że stosowanie bazy danych do obróbki stu SMS-ów, to rozwiązanie złe
i nieoptymalne.

--
Jarek

do góry

Dnia Sun, 07 Jul 2013 18:30:07 +0200, Krzysztof Halasa napisał(a):
> Jarosław Sokołowski <j...@l...waw.pl> writes:
>> Mnie w tym wszystkim najbardziej przerażają pokłady nailwności pomieszanej
>> z zakłamaniem. W różne rzeczy mogę uwierzeć, ale nie w to, że terroryzmem
>> zajmują się jakieś niegramotne żule
>
> Jednak tak najczęściej jest. Mnie to nie zaskakuje - każda osoba, która
> nie jest opóźniona w rozwoju, powinna chyba rozumieć, że to jest bez sensu.

Dlaczego ? Po doborze celow i srodkow to ma sens, w Hiszpanii sie
udalo.

Tak czy inaczej, nawet inteligentni moga miec problem przy ambitnej
inwigilacji. Zaczac od kompilacji linuxa i sprawdzania zrodel ?
ale co z telefonem - uzywac starej Nokii ?

J.

do góry

Pan Krzysztof Halasa napisał:

>> Mnie w tym wszystkim najbardziej przerażają pokłady nailwności pomieszanej
>> z zakłamaniem. W różne rzeczy mogę uwierzeć, ale nie w to, że terroryzmem
>> zajmują się jakieś niegramotne żule
>
> Jednak tak najczęściej jest. Mnie to nie zaskakuje - każda osoba, która
> nie jest opóźniona w rozwoju, powinna chyba rozumieć, że to jest bez sensu.

Gdyby tak było *najczęściej*, to by świadczyło jak najgorzej o ludziach,
którzy mają temu zapobiegać. Bo zamachy się zdarzają, bomby wybuchaja
i ludzie giną. No i jakże to tak -- wydać tyle pieniędzy, zorganizować
tak wspaniały sprzęt i dać się przechytrzyć byle żulowi?

Jarek

--
-- On się miał zamachnąć na mnie a ja na niego. Po co daleko szukać?
On przodownik i ja przodownik. To tak uradziliśmy. A ja już wcześniej
zamachnąłem się na władzę ludową. Kiełbikiem.

do góry

Pan J.F. napisał:

>>> Mnie w tym wszystkim najbardziej przerażają pokłady nailwności
>>> pomieszanej z zakłamaniem. W różne rzeczy mogę uwierzeć, ale
>>> nie w to, że terroryzmem zajmują się jakieś niegramotne żule
>>
>> Jednak tak najczęściej jest. Mnie to nie zaskakuje - każda osoba,
>> która nie jest opóźniona w rozwoju, powinna chyba rozumieć, że to
>> jest bez sensu.
>
> Dlaczego ? Po doborze celow i srodkow to ma sens, w Hiszpanii sie
> udalo.
>
> Tak czy inaczej, nawet inteligentni moga miec problem przy ambitnej
> inwigilacji. Zaczac od kompilacji linuxa i sprawdzania zrodel ?
> ale co z telefonem - uzywac starej Nokii ?

To pierwsze, to może jeszcze da się jakoś zrealizować, ale używać starej
Nokii?! Nie może być, któż byłby skłonny do takich poświęceń i wyrzeczeń!

--
Jarek (to może ja już pójdę sprawdzać i kompilować te źródła)

do góry

Dnia 07 Jul 2013 17:20:07 GMT, Jarosław Sokołowski napisał(a):
> Nie jestem w stanie tego dokładnie ocenić. Znalazłem informację, że
> w Polsce wysyła się rocznie 56 miliardów SMS-ów (myślałem, że mniej).
> To daje średnią półtora tysiąca na sekundę.

~100/mc/klienta.
Mozliwe ze ktos nadrabia srednia ... ale nalezy tez doliczyc wszystko
co dostajemy. Konkursy, informacje, hasla z banku ...

>To daje średnią półtora tysiąca na sekundę. W porywach oczywiście
>więcej (jakiś Nowy Rok), ale operatorów jest czterech i logowanie też
>mogą mieć jakoś rozproszone.

Wszystkie przechodza przez Centrum SMS, nie wiem czy tam jest jakies
zwielokrotnienie, ale najwyrazniej wystarczaja. Fakt ze kazdy operator
ma swoje.

> W każdym razie nawet te kilka tysięcy
> dostępów do różnych plików w ciągu sekundy nie wydaje się czymś aż
> tak bardzo problematycznym.

A to akurat moze byc problem, bo zobacz jak szybko dziala np
wyszukiwanie pliku, albo kasowanie ... straszny jest narzut systemu.

Usiluje wlasnie skasowac pliki na zdalnym komputerze - kilka sekund na
plik ...

> Nawet biorąc tygodniowy ruch od wszystkich operatorów, czyli miliard
> SMS-ów, albo inaczej 100-200 GB danych, nie jest to jakiś dramat żeby
> to zwyczajnie przegrepować w poszukiwaniu numeru. Ale nie gromadzi się
> w jednym miejscu wszyskich SMS-ów od wszystkich do wszystkich (chyba
> że na jakiejś pryzmie), więc i tak trzeba wstępnie określić miejsce
> poszukiwań. Pożądnie indeksowana baza oczywiście będzie pomocą, ale
> bez tego też się da. To nie ta skala, co Google i WWW.

I tak jak pisalem - oni zapisuja informacje o SMS, o rozmowach, o
logowaniach do BTS - a to podobna ilosc danych. I robia to.

>> Nie twierdzę, że każde inne rozwiązanie jest złe, ale nie są one
>> optymalne. Przypominam że mówiliśmy o rozwiązaniu optymalnym.
>
> Na tym własnie polega różnica w naszych podejściach. Bo ja twierdzę,
> że stosowanie bazy danych do obróbki stu SMS-ów, to rozwiązanie złe
> i nieoptymalne.

Zalezy do czego i jak chcesz obrabiac - teraz latwiej o narzedzia do
sql niz do setki plikow :-)

J.

do góry