Pan J.F. napisał:

>> Ekonomiki zero -- ta uwaga odnosi się do całej organizacji przedsięwzięcia.
>> Trzeba za każdym razem utworzyć plik, a wcześniej wymyślić mu nazwę.
>> Organizacja wyszukiwania też nie jest prosta -- trzeba czytać kartalogi
>> żeby dostać nazwy plików, które mogą (choć nie muszą) być skojarzone
>> z metadanymi dotyczącymi SMS. Ale żeby poszukać coś w *treści* SMS-ów,
>> to już trzeba po kolei otwierać każdy plik i zaglądać mu do wnętrza.
>> Po prostu horror.
>
> de facto to samo co w bazie banych - dane sa gdzies na dysku, a do
> tego mamy dane organizacyjne :-)
> Tyle tylko ze baza danych dostowana do typowych operacji, a system
> plikow zazwyczaj nie :-)

Jeśli typową operacją będzie żądanie agenta CBŚ "dawać mi tu wszystkie
SMS-y wysłane z numeru N", to taka organizacja systemu, gdzie każdy
numer ma swój plik (np. w dwupoziomowych katalogach po 1000 sztuk, jak
to bywa w rozmaitych systemach cache), może być dobrze dostosowana.
Jeśli do tego agenci CBA będą chcieli żeby im dawać treść SMS-ów wsłanych
*do* abonenta X, to już gorzej. Ale wtedy najprościej jest od razu tworzyć
drugą bazę na osobnym "wielkim serwerze" pod nazwą "SMS-y odebrane".
Jak zorganizoważ bazę, by dało się odpytywać bazę na podstawie *treści*
SMS-ów, to już zmartwienie tych wszystkich prismów, a nie operatora.

Dla niewielkich zbiorów danych (powiedzmy milion SMS) i niezbyt dużej
częstości zapytań (niech będzie, że tysiące na dobę) zwykły plik może
wciąż być optymalnym rozwiązaniem.

>>> Jakby przyszło co do czego, to bym pomyślał nad sensownym zebraniem tego
>>> do kupy.
>> 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.
>
> Co tylko zle swiadczy o systemie operacyjnym :-)

Nie tak bardzo źle. On nie po to był zrobiony, by co chwile przekopywać
się przez sto tysięcy plików i natychmiast o tym zapominać. Od takich
rzeczy są systemy bazodanowe.

> P.S. FAT ma jedna wade - nie da sie seek w dlugim pliku szybko zrobic,
> trzeba przez wszystkie wpisy w fat przeleciec. Fat co prawda moze byc
> w pamieci, a system moze jakies skroty trzymac - ale unix ma to jednak
> lepiej przemyslane. Tylko w nim odczyt katalogu trwa dziwnie dlugo :-)

Żeby tylko jedną wadę. Ale to nie był FAT (z tego co pamiętam).

--
Jarek

do góry

Dnia 06 Jul 2013 23:14:20 GMT, Jarosław Sokołowski napisał(a):
> Pan Tomasz Wójtowicz napisał:
>> Mało tego. Kodek głosowy GSM z trudem uzyskuje kompresję 1:5, bo musi
>> pracować na małych porcjach danych, ale na centrali mogą z powodzeniem
>> pakować rozmowę kodekiem VQF 1:18, co oznacza, że minuta rozmowy zajmie
>> jakieś 53 kilobajty.

Rekompresja to spore obciazenie, prosciej byloby nagrywac lak leci.
A i tak kodek ma ~15kb/s, wiec wyjdzie powiedzmy 120kB/min

>> Jeśli polscy abonenci dziennie wydzwaniają np. 10
>> milionów minut no to 530 GB to nie jest dużo, jeśli chodzi o dane głosowe

10 mln to ma jeden operator klientow, a raczej 15.
Ilosc minut rosnie, wiec raczej bym spodziewal kilku minut dziennie.

> Też sobie o tym samym od razu pomyślałem. Przy takim upakowaniu jednemu
> operatorowi do przechowania wszystkich rozmów jeden dysk wystarczy gdzieś
> na miesiąc.

Sa juz 16GB ? W moich obliczeniach trzeba ich znacznie wiecej ... ale
to nie sa jakies niewyobrazalne ilosci. W razie potrzeby by sie dalo.
Klopot wiekszy chyba z transmisja danych, gdyby mialo splywac w jedno
miejsce - ale przeciez mozna regionalne serwery miec.

> Ale i bez takich zabiegów pryzma z nośników gromadzących
> nasze gadulstwo nie wygląda jak egipska piramida.

Wiecej gadac i filmy sensacyjne opowiadac, to moze im sie odechce
podsluchiwac. No i PGP wlaczyc :-)

J.

do góry

W dniu 2013-07-07 10:42, Big Jack pisze:
> W wiadomości
> news://news-archive.icm.edu.pl/kra664$hrn$1@node2.ne
ws.atman.pl
> *Tomasz Wójtowicz* napisał(-a):
>
>> Poza tym, jeśli chodzi o treści SMS-ów, to najczęściej są pisane w
>> jakimś ludzkim języku, więc przy zastosowaniu kompresji może wyjść
>> mniej niż 100 bajtów na SMS.
>
> To ja pozwolę sobie przypomnieć, że HDD mają jednostki alokacji i czy
> SMS będzie miał 1 bajt, 100, czy 1024, to na HDD zajmie nie mniej niż ta
> 1 jednostka alokacji.
>
>
Bzdura.

do góry

Użytkownik "Jarosław Sokołowski" <j...@l...waw.pl> napisał w wiadomości
news:slrnktinb7.g0j.jaros@falcon.lasek.waw.pl...
> 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.

No, mniej-więcej właśnie coś takiego miałem na myśli. A co do konkretnego
przypadku - to chodziło mi po prostu o to, aby "oprogramować" go tak, by
wszelkie działania były szybsze/łatwiejsze/razem wzięte/itd. Tylko, że
niestety, nie mam daru wymyślania takich rzeczy naprzód, czyli zaistnieje
przypadek, potrzeba, dopiero wtedy rozkminiam to pod kątem użytych sposobów
i środków. W każdym razie - robiłem też takie zbiórki, gdy danych było dużo,
drobno, jak znalazło, sprawdzałem w którym kawałku siedzi i tam już
cyzelowałem. Czyli bardzo podobnie do tego, co piszesz.

--
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:

> Jeśli typową operacją będzie żądanie agenta CBŚ "dawać mi tu wszystkie
> SMS-y wysłane z numeru N", to taka organizacja systemu, gdzie każdy
> numer ma swój plik (np. w dwupoziomowych katalogach po 1000 sztuk, jak
> to bywa w rozmaitych systemach cache), może być dobrze dostosowana.

Raczej wątpie. Przede wszystkim musi to być dostosowane do obciążenia,
jedyny sensowny pod tym względem system to zapisywanie SMSów itp. jeden
po drugim liniowo, bez żadnego dodatkowego systemu plików. Inaczej dyski
nie wyrobią się z seekami, albo będzie to dużo większe niż trzeba.
Owszem, do tego potrzebne są indeksy, ale te będą o rząd wielkości
mniejsze.
Kompresja może być zastosowana wtedy, gdy zapis skompresowany jest szybszy.

> Jeśli do tego agenci CBA będą chcieli żeby im dawać treść SMS-ów wsłanych
> *do* abonenta X, to już gorzej.

Trzeba tworzyć podwójne indeksy, minimalna różnica.

> Jak zorganizoważ bazę, by dało się odpytywać bazę na podstawie *treści*
> SMS-ów, to już zmartwienie tych wszystkich prismów, a nie operatora.

Nie widzę problemu, przeszukiwanie liniowe nadaje się do tego dobrze,
ew. można to poindeksować np. słownikiem itp. (a la Google).

> Dla niewielkich zbiorów danych (powiedzmy milion SMS) i niezbyt dużej
> częstości zapytań (niech będzie, że tysiące na dobę) zwykły plik może
> wciąż być optymalnym rozwiązaniem.

Zwykłe pliki w zwykłym systemie plików na pewno nie są optymalnym
rozwiązaniem. Niezwykłe pliki w niezwykłym fs? Oczywiście, przecież taki
liniowy zapis z indeksami to też jest system plików.

> Nie tak bardzo źle. On nie po to był zrobiony, by co chwile przekopywać
> się przez sto tysięcy plików i natychmiast o tym zapominać. Od takich
> rzeczy są systemy bazodanowe.

BTW system plików to także jest baza danych, tylko zwykle nieco inaczej
zoptymalizowana.
--
Krzysztof Hałasa

do góry

Pan J.F. napisał:

>> Też sobie o tym samym od razu pomyślałem. Przy takim upakowaniu
>> jednemu operatorowi do przechowania wszystkich rozmów jeden dysk
>> wystarczy gdzieś na miesiąc.
>
> Sa juz 16GB ?

Chyba nie, ale za to operatorów mamy czterech.

> W moich obliczeniach trzeba ich znacznie wiecej ...

To co przedstawiłem, to raczej zgrubne szacunki a nie obliczenia. Dyski
zwykle działaja w jakiejś macierzy, więc powinny starczyć na kwartał.

>> Ale i bez takich zabiegów pryzma z nośników gromadzących nasze
>> gadulstwo nie wygląda jak egipska piramida.
>
> Wiecej gadac i filmy sensacyjne opowiadac, to moze im sie odechce
> podsluchiwac. No i PGP wlaczyc :-)

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 -- więc jeśli zechcą się naradzić tak,
by nikt ich nie podsłuchiwał, to tak właśnie zrobią. Przy dzisiejszych
możliwościach technicznych trzeba to przyjąć za pewnik. I mamy teraz tego
nieszczęsnego młodziana Snowdena, który nagle przejrzał na oczy, czego mu
kumple nie mogą darować. A z drugiej strony całe zastępy snowmanów, co to
nie mają skrupułów, by doić bez opoamiętania publiczną kasę, chociaż dobrze
wiedzą (niektórzy przynajmniej), że pożytku z tego nie ma i nigdy nie będzie.

Jarek

--
-- Ma się wiedzieć, pani Müllerowo. Jakby pani chciała zastrzelić arcyksięcia
albo pana cesarza, toby się pani na pewno z kimś naradziła. Co głowa, to rozum.
Ten doradzi to, tamten owo i w ten sposób zbożne dzieło się powiedzie, jak
o tym śpiewamy w naszym hymnie państwowym.

do góry

Użytkownik "Jarosław Sokołowski" <j...@l...waw.pl>

>
>> Jakby przyszło co do czego, to bym pomyślał nad sensownym zebraniem tego
>> do kupy.
>
> 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. 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. 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.

do góry

Pan J.F. napisał:

>> A archwizacja polega na tym, że aby coś znaleźć, archiwsta musi odstawić
>> kubek z herbatą, założyć kapcie, zejść do archiwum i zacząć szukać. Długo
>> szukać.
>
> Od dawna wymyslono na to roboty zmienajace tasmy, potem czytniki plyt
> ze zmieniarkami, potem znow zmieniarki do tasm ... i co najwyzej
> sprowadza sie to do dluzszego czekania.

Ja byłem zawsze zauroczony genialnością organizacji systemu TRICKLE,
który działał w systemie BITNET. Młodszym trzeba wyjaśnić, że służyło
to zaopatrywaniu się w pliki, gdy nie było jeszcze sciągania z WWW,
ani nawet z FTP (bo BITNET to też nie był Internet). Serwerów TRICKLE
na świecie było kilka, a najgłówniejszy w bazie rakietowej White Sands,
w bunkrze z ośmiometrowym betonowym stropem -- stamtąd można było
ściągnąć program do drukarki albo GIF ze zdjęciem zielonej żabki.

Wysyłało się mail z żądaniem konkretnego pliku do najbliższego serwera,
a ten, jeśli tylko mógł, wysyłał natychmiast serie maili z UUEnkodowanymi
fragmentami potrzebnego pliku. Natychmiast, czyli gdzieś tak w kwadrans
lub dwa. Jeśli nie mógł, bo nie miał, to rozpytał inne serwery, czy ktoś
ostatnio o taki plik nie prosił i czy nie mają go w pamięci podręcznej.

Jeśli się taki znalazł, to on wysyłał. Poniewż to przysługa sąsiedzka,
więc niekoniecznie od razu. Ale w ciągu doby zwykle się wyrabiał.
Dopiero gdy i to nie wyszło, wtedy zapotrzebowanie szło do White Sands.
A tam raz na tydzień jakiś robot zakładał na przewijak taśmę z plikami
trickle i po kolei, bez szarpania w te i nazad, czytał pliki i rozsyłał
je tam, gdzie zgłoszono zgłoszono chęć ich otrzymania. Więc była gwarancja,
że dłużej niż tydzień na mail nie będzie trzeba czekać.

Jarek

PS
Zmieniarkę do płyt też pamiętam. Ale to już w Internecie. Nie wiem, czy
to nie u was we Wrocławiu mieli jeden czytnik CD, a za to aż trzy płyty
z cenną zawartością. Więc było ogłoszone wszem i wobec, że w poniedziałki
i czwartki wkłada się tam płytę z darmowymi fontami Type1, we wtorki
i piątki jakieś oprogramowanie, a w środy i soboty coś jeszcze innego.

do góry

Pan Krzysztof Halasa napisał:

>> Jeśli typową operacją będzie żądanie agenta CBŚ "dawać mi tu wszystkie
>> SMS-y wysłane z numeru N", to taka organizacja systemu, gdzie każdy
>> numer ma swój plik (np. w dwupoziomowych katalogach po 1000 sztuk, jak
>> to bywa w rozmaitych systemach cache), może być dobrze dostosowana.
>
> Raczej wątpie. Przede wszystkim musi to być dostosowane do obciążenia,
> jedyny sensowny pod tym względem system to zapisywanie SMSów itp. jeden
> po drugim liniowo, bez żadnego dodatkowego systemu plików.

W najbardziej ogólnym przypadku, to jest prawda. Pochwałę liniowego
zapisu już wygłosiłem, więc teraz po prostu się z tym zgodzę. Ale jeśli
można już w trakcie zbierania danych można wytworzyć odpowiednią ich
strukturę, dostosowaną do *jedynego* sposobu korzystania z nich, to
czemu tego nie zrobić? Zaznaczam, że nie nawet szacowałem wielkości
ruchu. Być może w polskich sieciach jest o zbyt duży, ale w jakiejś
maltańskiej czy nawet łotewskiej będzie już ok.

> Inaczej dyski nie wyrobią się z seekami,

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.

>> Jeśli do tego agenci CBA będą chcieli żeby im dawać treść SMS-ów
>> wsłanych *do* abonenta X, to już gorzej.
>
> 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ć.

>> Dla niewielkich zbiorów danych (powiedzmy milion SMS) i niezbyt dużej
>> częstości zapytań (niech będzie, że tysiące na dobę) zwykły plik może
>> wciąż być optymalnym rozwiązaniem.
>
> Zwykłe pliki w zwykłym systemie plików na pewno nie są optymalnym
> rozwiązaniem. Niezwykłe pliki w niezwykłym fs? Oczywiście, przecież
> taki liniowy zapis z indeksami to też jest system plików.

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.

--
Jarek

do góry

"J.F." <j...@p...onet.pl> writes:

> Rekompresja to spore obciazenie, prosciej byloby nagrywac lak leci.

Trzeba porównać przepustowość rekompresora oraz dysków.
--
Krzysztof Hałasa

do góry