Misiek08

Redis można właśnie wziąć w przyszłości pod cache informacji gdzie jest plik. Stosowałem to przy małej ilości plików, ale dużym ruchu i 70 storage'ach. Sprawdziło się. Po prostu kluczem był plik_{ID}, a wartością były sprzecinkowane serwery, na których dany plik był (ew. jeden serwer jak nie było dupa).

Moim skromnym zdaniem MongoDB jest prostsze do wprowadzenia i pisania na samym początku. Konfiguracja też banalna wg tutoriala. Ja polecam od siebie MongoDB.

Migracja z czegokolwiek na cokolwiek przy hostingu plików zawsze (tak, zawsze) zmieści się w 12-24h. Nie ma takiej możliwości, żeby baza metadanych (nawet jeśli to będą sumy w 3 algo, długość, kodeki, rozmiar i typ) była tak duża, żeby migracja była niemożliwa lub trwa bardzo długo. @pedro84 - ja. Zawsze na to patrzę. Dlaczego? Wyobraź sobie, że storage wstawiam w chmurę a'la S3, ale kupuję od firmy samą powierzchnię i transfer, a do tego ustawiam 10 instancji. Teraz te instancje mogą mnie kosztować 220zł/mies jak wezmę malutkie z np. 0.5-1GB RAMu albo 600-800zł jak wezmę 2+GB RAMu. Tylko tutaj patrzę. Nie jestem też (mam nadzieję, że to się zmieni ) bogaczem, więc nawet w takim miejscu szukam oszczędności.

To zależy jak bardzo szastasz RAMem. Cassandra, na 4 node'ach już swoje weźmie (sama VMka Javy potrafi wziąć 90-150MB RAMu). Java fajna, bo mało awaryjna, sama Cassandra też. Jednak ja bym dalej stawiał na jakieś Mongo i to będzie działać.

Kup sobie kilka VPSów w OVH lub np. w Tiktalik CPU-Hoga. Kilka VPSów w OVH to dużo łącza i zasoby dla Ciebie. Nie ma rewelacji z prędkością, ale działa. Podaj budżet to podpowiem inne ciekawe rozwiązania

MongoDB, Aerospike, CouchDB to takie dosc popularne. Aerospike to bardziej jak masz duzo RAMu i SSD i ogromny ruch. Niektorzy "szalency" nawet na Redisie trzymaja. Mozesz zaczac na MySQL, ale pisz wszystko tak, zeby przelaczenie systemu na inna baze nie wymuszalo pisania wszystkiego od nowa. Rozbij na klasy i providery, ale tez nie rob 50 klas do podawania pliku Mysle, ze pojdziesz taka sciezka MySQL>MongoDB, a potem jak bedzie czas na kolejny krok to zrobisz juz testy paru rozwiazan i to bedzie najlepsze.

Myślisz dobrze. Jeżeli czegokolwiek nie będziesz rozumiał pytaj, jeżeli chcesz współpracować przy Twoim projekcie odezwij się na PW lub creating.www@gmail.com - dogadamy się Konta FTP możesz mieć u siebie ładowane z bazy. Wiele serwerów, np. proftpd ma moduł MySQL, dzięki czemu utworzenie konta FTP może się zakończyć na stworzenie folderu na dysku i wpisaniu 1 rekordu do bazy. Dodatkowo takie serwery jak proftpd mogą wykonywać akcje po wrzuceniu pliku, więc możesz w takim momencie uploadować automatycznie plik do e24files, czy innej takiej usługi oraz wpisywać jego metadane do bazy. Wszystko pełen automat. Raczej gotowca pod to nie ma, ale z wykorzystaniem odpowiedniego serwera FTP możesz to napisać w dosłownie kilkudziesięciu linijkach (+ oczywiście kod kont, itd., ale sama logika systemu plików to te parę linijek). Proftpd, vsftpd, czy jeszcze pare innych. Ja dałem przykład, który u mnie działał Następna kwestia: Jeżeli naprawdę myślisz o ogromnych ilościach plików to od razu użyj jakiejś bazy typu NoSQL, bo nie potrzebujesz relacji, a MySQL wymusi już po paru miesiącach popularności pewne ruchy, optymalizacje i inne takie. Jest mnóstwo rozwiązań, które dadzą Ci zapomnieć przynajmniej o tej części systemu na dłuuuugi czas. Nie ma też nic złego w trzymaniu danych o plikach w 1 bazie, a np. dane o użytkownikach, płatnościach i innych rzeczach w (My|Postgre)SQL.

Baza się nie usunęła, bo dałeś [ i ] nie wiadomo po co. Daj DROP DATABASE dbispconfig;

Pewnie Ci nie zapasuje, ale MyDevil.net ma ciekawą ofertę. Wszystkie główne technologie, w których tworzy się webaplikacje (bez ASP.NET - nie róbmy sobie żartów z webmasterki). Jedynie co, to miejsce jest podzielone pomiędzy kilka serwerów, ale w sumie za 150zł/mies da się mieć 50GB miejsca (a nawet 100GB).

Oktawave nie umrze z dnia na dzień, a jak na razie usługi mają najwyższej jakości. Zenbox też nie wynosi się stamtąd, bo się boją, tylko chcą się rozszerzyć, a w Oktawave coś im strasznie przeszkadza. Nikt oprócz nich na razie nie ucieka. Prędkości na instancjach szybkie, na OCS nie testowałem produkcyjnie, ale tak z testów na pojedynczych plikach było ok.

Skąd link do tego macie? Na stronie nie widziałem tej oferty.

Często są to Opetrony, 3Ghz na rdzeń. Jeżeli połowa tych stron to prosty php bez danych lub nawet html to nie ma sensu brać Classic 2. Jeżeli masz wśród tej 10 ze 3-5 wordpressów, które mają np. po 1000 UV dziennie to też Classic 1 spokojnie da radę.

Classic 1!!!! Na Classic 2 jestem w stanie utrzymać 1000-1500 ludzi online na forum MyBB, więc pod wizytówki Classic 1!

Napisałem mail, priv to nie najlepsze miejsce, bo zajrzeć może zbyt wiele osób.

https://www.google.pl/search?q=22Gbps+in+3+hours => 29.7TB, czyli te 30TB za 3 godziny wyszło dobrze 1. Amazon jest drogi. Tutaj temat zazwyczaj się kończy, ale miałem już klienta, który zarabiał krocie na transmisji, więc nie patrzył na kwoty. Cloudfront powinien dać radę dla takiej przepustowości. Cena za 2x3h (o ile nigdzie nie popełniłem błędu) ok. 15 000zł za 60TB ruchu, do tego jeszcze licencja na Wowzę, bo jeżeli z niej chcemy korzystać to potrzebujemy. 2. Transfer na EC2 jest w podobnej cenie, więc 15.000zł + koszty maszyn, które się zamkną w 100-150zł, więc to można pominąć. 3. Załóżmy, że średnio będzie 20 000 ludzi, bo jeżeli zakładamy maksimum na 25 tys. to 20 będzie średnio. W takim momencie liczymy po prostu 20 tys. * bitrate, czyli 20000*0.85Mbps = 17000Mbps ~ 17Gbps. Potem transfer przeliczy nam już ładnie wujek G: https://www.google.pl/search?q=17Gbps+*+3+hours 22.95TB za 3h. 4. Ja osobiście (o ile miałbym kilka dni na przygotowanie infrastruktury pod taki event) liczę sobię za event coś w stylu "opłata administracyjna" + zależy jak się dogadamy, ale najczęściej po prostu koszt transferu. Dzięki temu każdy jest zadowolony, bo ja nie rzucam kosmicznych kwot jak Amazon (36gr/GB w pierwszych 10TB ruchu) tylko czasami nawet 8x taniej przy mniejszych eventach. Teraz ja zapytam: treść legalna?

Chcę!

Ja trochę od tematu - czy koniecznie potrzebujesz tego silnika i obudowy bazy? Używasz transakcji? Może NoSQL jakiś lub np. zamiast MySQL, Percona?

NFS nie, bo to umrze przy 3-4 serwerach jakimś ruchu. Apache to też nie tędy droga. MySQL na początek, potem jakaś percona. A co do subdomen to reverseproxy będzie kumulować ruch w 1 punkcie i cały plan rozkładania ruchu pada na pysk. Musisz blogi rozkładać i trzymać dane lokalnie, balancer napisać ładnie samemu i rzucać np. CNAME'y lub w inny sposób rozłożyć ruch na serwery. Subdomeny to albo własny DNS (nie RP) albo API CF.

Podaj adres strony, poradzimy coś na to.

Zintegrowany procek? Chętnie to wezmę!

Ja zawsze stawiam dynamic i zależnie od stron(y) ustawiam nie tak jak wzór każe, tylko tak jak ja uważam. Np. zdarza mi się, że ustawiam max na 40, min na 3 i spawnuje 5. Dlaczego? Np. hostuję stronę, która niestety ze względu na autoryzację wymaga PHP i jest zawalana ruchem tylko na czas wydawania aktualizacji. W normalnym trybie jest max. 10req/min, ale przy aktualizacjach zdarza się do 150req/s.

@Archi - z tym APC jesteś pewien? Jak testowałem to miałem wrażenie, że APC dzieli wszystko, więc jak ktoś w APC przechowa np. statystyki, które chciałby mieć tylko dla siebie, to druga strona może mu je "ukraść". Przy hostowaniu tylko własnych stron jest fajnie, ale wtedy i tak trzeba pamiętać, żeby jakieś namespace'y zrobić.

JW Player obsługuje to co potrzebujesz

Ja zrobiłem to tak, że w nginx-lua mam napisany jak pod-serwer podający HLS i tam liczę na żywo połączenia. Całość jest bardziej skompilkowana niż z tego opisu się wydaje, ale to też nie jest niemożliwość.

@up - "Mózg roz......y" Tak to wygląda, że niby administrator odpowiedzialny nie jest, ale jak przychodzi co do czego - jest, bo przecież stworzył stronę, gdzie można oglądać filmy i myślał, że tylko króliczka będą wszyscy wrzucać.