eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingjsp vs phpRe: jsp vs php
  • Data: 2013-05-09 21:55:04
    Temat: Re: jsp vs php
    Od: Edek <e...@g...com> szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]

    Dnia Wed, 08 May 2013 17:32:52 -0700 po głębokim namyśle M.M. rzekł:

    > W dniu środa, 8 maja 2013 23:57:50 UTC+2 użytkownik Edek napisał:
    >
    >> Generalnie potrzebujesz szybką bazę. Jak z każdym skalowaniem, można "w
    >> górę" i "w bok".
    > Jak wyglada skalowanie baz w bok? Mamy duzo komputerow. Komputery niech
    > sa sredniej jakosci, moze tylko niech maja dobre karty sieciowe i kable.
    > Nie ma zadnego super-komputera, zadnych urzadzen dedykowanych, tylko
    > dostawiamy kolejna skrzynke i podpianmy do sieci. Na tym pracuje jakas
    > baza sql, moze byc nawet jakas droga. Powiedzmy ze bylo tych skrzynek
    > 10, a po dostawieniu jest sto skrzynek. Ktore operacje dzialaja:
    > 1) wolniej,
    > 2) bez zmian,
    > 3) minimalnie szybciej 4) szybciej prawie liniowo.

    3 i pół. Plus problemy typu kto rodziela ruch - są dedykowane
    rozwiązania failover.

    >> Te pierwsze to duże szafy z szybkimi macierzami dysków (raid, bbwc na
    >> start) i rozwiązania takie jak IntentLog czy inne cache, osobno do
    >> odczytu (spory) i do zapisu (non-volatile). Stosuje się chociażby ssd
    >> do tych celów,
    >> albo zerknij na karty Fusion-IO.
    > Hmmm dyski SSD pewnie beda w zasiegu budzetu. Zastanawiam sie tylko co
    > jest lepsze:
    > 1) skalowanie w bok na zwyklych maszynkach 2) skalowanie w bok na
    > maszynach z dyskami SSD 3) optymalizacja algorytmow i struktur danych
    > Kazde z tych rozwian jest zwiazane z jakimis kosztami i niesie jakies
    > korzysci.

    Można podejść bardzo różnie, ale przede wszystkim policzyć. A żeby
    policzyć trzeba mieć doświadczenie albo fake it till you make it
    czyli zacząć od google.

    Np. nie wiem czy NAS: ZFS + na SSD: ZIL + duży L2ARC nie załatwiłby
    jedną maszyną storydżu bazy danych. Stawia się to na dowolnym sprzęcie
    z dyskami SATA, jednym/dwa ssd i ma się tyle co niezły raid -
    10Gb przepustowości co najmniej i opóźnienia niewiele większe
    niż latency sieci. To znaczy przy dużym ruchu potrzeba tylko
    ile wlezie RAMu i szybki proc. Ale to też zależy od bazy i rodzaju
    dostępów i jasne, jest jakiś limit, a widzę plany masz typu sky is
    the limit.

    Ja specjalnie mówię o rzeczach dostępnych za free (poza sprzętem).

    To byłoby skalowaniem w górę. Optymalizacja algorytmów owszem,
    ale ona nigdy nie jest oderwana od sprzętu. Chyba że jak google
    zakłada się sprzęt taki jak z półki w sklepie.

    >> Te "w bok", czyli mnóstwo kompputerów, to różne rozwiązania, gdzie
    >> wiele dzieje się w RAM.
    > Przecietny tani komp moze miec chyba 32GB ram. Kilka TB to 100
    > komputerow -
    > moze by starczylo. Jeden dobry dysk SSD kosztuje tyle co 15 komputerow -
    > moze to jest bardziej sensowna droga niz by sie wydawalo.

    Może poćwicz na amazonie, na pewno są gotowe rozwiązania nawet
    jak nie ma benchmarków.

    >> No a temat replikacji to osobna dziedzina.
    > Jakze rozna od zapisywania danych na dysku :D

    Heh. Mieliśmy takie maszynki co obsługiwały dziesiątki milionów
    transakcji na godzinę i mieliśmy: ekspertów od dysków, ekspertów
    od połączeń do dysków, ekspertów od bazy, a eksperci od replikacji
    to siedzieli od tamtych dość daleko... No ale tu to musiałbyś
    się zapożyczyć żeby kupić jeden kabelek ;)

    --
    Edek

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: