-
Data: 2013-07-07 17:58:29
Temat: Re: Czy operator przechowuje treść smsów ?
Od: Jarosław Sokołowski <j...@l...waw.pl> szukaj wiadomości tego autora
[ pokaż wszystkie nagłówki ]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
Następne wpisy z tego wątku
- 07.07.13 18:03 Krzysztof Halasa
- 07.07.13 18:13 Jarosław Sokołowski
- 07.07.13 18:19 Anerys
- 07.07.13 18:25 Krzysztof Halasa
- 07.07.13 18:30 Krzysztof Halasa
- 07.07.13 18:33 Jarosław Sokołowski
- 07.07.13 19:20 Jarosław Sokołowski
- 07.07.13 19:20 J.F.
- 07.07.13 19:20 Jarosław Sokołowski
- 07.07.13 19:26 Jarosław Sokołowski
- 07.07.13 19:43 J.F.
- 07.07.13 20:15 Jarosław Sokołowski
- 07.07.13 20:21 Jarosław Sokołowski
- 07.07.13 21:16 John Kołalsky
- 07.07.13 21:25 J.F.
Najnowsze wątki z tej grupy
- "betamaxy" i inne voip-y dzisiaj
- Hackowanie SS7
- nowe spamerstwo ?
- Przychodzące impulsy telefon nie dzwoni
- Re: Zgody...
- Jak tanio dzwonic do Wielkiej Brytani?
- Chess
- Vitruvian Man - parts 7-11a
- Czas umierać.
- [ot] aplikacja - ameryk. nr. telef + dzwonienie za free do stanow i kanady
- Vectra 'Plan domowy bez limitu'
- Re: Ponownie: Android i zarządzanie książką telefoniczną z komputera
- Re: Ponownie: androSRAJ i zarządzanie książką teleSRAną z bitMłyna
- Re: Ponownie: Android i zarządzanie książką telefoniczną z komputera
- Android, export/import książki telefonicznej
Najnowsze wątki
- 2024-11-24 Aby WKOOOORWIĆ ekofaszystów ;-)
- 2024-11-22 OC - podwyżka
- 2024-11-22 wyszedł z domu bez buta
- 2024-11-22 Bieda hud.
- 2024-11-24 DS1813-10 się psuje
- 2024-11-23 Białystok => Inżynier bezpieczeństwa aplikacji <=
- 2024-11-23 Szczecin => QA Engineer <=
- 2024-11-23 Warszawa => SEO Specialist (15-20h tygodniowo) <=
- 2024-11-22 Warszawa => Kierownik Działu Spedycji Międzynarodowej <=
- 2024-11-22 Warszawa => Senior Account Manager <=
- 2024-11-22 Warszawa => Key Account Manager <=
- 2024-11-22 Warszawa => DevOps Specialist <=
- 2024-11-22 Kraków => IT Expert (Network Systems area) <=
- 2024-11-22 Warszawa => Infrastructure Automation Engineer <=
- 2024-11-22 Warszawa => Presales / Inżynier Wsparcia Technicznego IT <=