Skocz do zawartości

Hosting z Firebird'em - gdzie?


pwk

Rekomendowane odpowiedzi

https://punkt.pl/index.php?go=podstr/wirtualne/info

Tutaj cos jest. Chociaz z ta firma nie mam doswiadczenia.

Tez ich znalazlem i tez nie wiem co myslec o tej Firmie oprocz tego ze korzystanie z Firebirda jest u nich drogie.

Na razie znalazlem tylko jedna alternatywe - czeska firma pipni.pl Calkiem tania i raczej(?) ok chociaz na razie nie znam nikogo kto ma z nimi jakies doswiadczenia. Moze tu ktos taki jest?

Pawel

Odnośnik do komentarza
Udostępnij na innych stronach

powiedz proszę do czego potrzebny Ci jest hosting z Firebird-em?

Nijak nie nadaje się do webapplikacji, a typowe aplikacje desktopowe mulą.

Troche to niezgodne z tematem wątku ale jeżeli prosisz...

MySql ma swoje zalety ale wolę Firebirda. Głównie dlatego, że go dobrze trochę znam. Firebird potrafi to co mySQL i jeszcze więcej ... czyli dlaczego "...nijak nadaje się do webaplikacji" jeżeli mySQL się nadaje?.

Nie chcę tu wywoływać żadnych wojen i dyskusji "o wyższości..." ale gołym okiem widać, że mySQL jako serwer bazodanowy to szczeniak, chyba nie trzeba tu pisać dlaczego. Wiem, że przez to, że mySQL wielu rzeczy nie potrafi jest szybki, ale czy aż tak bardzo? Miałem do czynienia z bazami Firebirda po kilkadziesiąt GB do których dobijało się kilkudziesięciu, kilkuset użytkowników i wiem, że odpowiednio skomponowane zapytania do "zadbanej" bazy potrafią być jak dla mnie całkiem szybkie. Nieważne; przyjmuję, że Firebird jest wolniejszy ale nie ma to dla mnie jakiegoś zasadniczego znaczenia. Nie myśle o serwisie, który miałby obsługiwać w ciągu sekundy dzesiątki czy setki klientów. Na dodatek myśle, że część tej straty czasu odrobię sobie przerzucając część pracy na serwer SQL co dodatkowo uprości i skróci kod PHP. Np. część funkcjonalności "włożę" do triggerów czy procedur albo będę pobierać wszystkie informacje do pokazania stron jedną procedurą czy widokiem i będę miał jedno może trochę dłuższe odwołanie do serwera zamiast kilku krótszych.

pozdrawiam

Pawel

PS do poprzedniego głosu; https://www.pipni.pl/ u mnie pokazuje się dobrze.

Odnośnik do komentarza
Udostępnij na innych stronach

Troche to niezgodne z tematem wątku ale jeżeli prosisz...

MySql ma swoje zalety ale wolę Firebirda. Głównie dlatego, że go dobrze trochę znam. Firebird potrafi to co mySQL i jeszcze więcej ... czyli dlaczego "...nijak nadaje się do webaplikacji" jeżeli mySQL się nadaje?.

Heja,

FireBird z UDFami potrafi to co MySQL <=> gdy zawiera jego całą funkcjonalność.

Zauważ proszę, że MySQLu (MyISAM) nie występują tranzakcje, FK chodzą losowo, pliki/indeksy rozrzucone są po dysku. FireBird trzyma całą bazę w jednym miejscu (abstrahujemy od fizycznego rozkładu bazy danych na różne nośniki). MySQL w prostych rzeczach wydajnościowo bije FB.

Nie chcę tu wywoływać żadnych wojen i dyskusji "o wyższości..." ale gołym okiem widać, że mySQL jako serwer bazodanowy to szczeniak, chyba nie trzeba tu pisać dlaczego. Wiem, że przez to, że mySQL wielu rzeczy nie potrafi jest szybki, ale czy aż tak bardzo?

Tak - szybkością nadrabia prawie wszystko ;-)

Miałem do czynienia z bazami Firebirda po kilkadziesiąt GB do których dobijało się kilkudziesięciu, kilkuset użytkowników i wiem, że odpowiednio skomponowane zapytania do "zadbanej" bazy potrafią być jak dla mnie całkiem szybkie.

Wszystkie połączenia masz po LANie. Warto nadmienić, że do bazy jest dedykowana maszynka wieloprocesorowa, macierz dyskowa. Oraz ilość danych, z których jednocześnie korzystają użytkownicy (tych kilkuset w jednocześnie) to poniżej 1% ?

Nieważne; przyjmuję, że Firebird jest wolniejszy ale nie ma to dla mnie jakiegoś zasadniczego znaczenia. Nie myśle o serwisie, który miałby obsługiwać w ciągu sekundy dzesiątki czy setki klientów. Na dodatek myśle, że część tej straty czasu odrobię sobie przerzucając część pracy na serwer SQL co dodatkowo uprości i skróci kod PHP. Np. część funkcjonalności "włożę" do triggerów czy procedur albo będę pobierać wszystkie informacje do pokazania stron jedną procedurą czy widokiem i będę miał jedno może trochę dłuższe odwołanie do serwera zamiast kilku krótszych.

Jest wolniejszy i to DUŻO. W przypadku obsługi wielu (kilkuset) na jednej maszynce to już katastrofa :-)

Weź pod uwagę, że na takim hostingu nie tylko Ty będziesz miał swoją webapp, co do tego, że praktycznie całą webapplikację można przerzucić na bazę danych zgodzę się - sam tak miałem, że cała moja app webowa to było jedno DUŻE zapytanie do $QLa.

Jeżeli chodzi o hosting FireBird to wrzuć w google: "firebird hosting" - pewnie coś znajdziesz :-)

Możesz zerknąć również tu: https://www.amm.net.pl/interbase.htm

OT

Opisz maszynkę (hardware) na której chodził Ci FB z nnGB bazkami danych i czy to był CS czy SS.

P. S.

Klykasz coś w Delphi? ;-) to może asp.net ? ja wdrożyłem w grudniu 2003 rozwiązanie webowe bazujące na silniku FB - chodziło znośnie z racji bardzo małego obciążenia tylko z mojej strony.

P. S. 2.

Może chciałbyś kupić domenę firebird.pl :-)

pozdr0 600

oKrupieństwo

potęga umysłu

Odnośnik do komentarza
Udostępnij na innych stronach

Wszystkie połączenia masz po LANie. Warto nadmienić, że do bazy jest dedykowana maszynka wieloprocesorowa, macierz dyskowa. Oraz ilość danych, z których jednocześnie korzystają użytkownicy (tych kilkuset w jednocześnie) to poniżej 1% ?

Maszyna jest "dobra", szczególów nie znam dokładnie ale jest tak jak piszesz, 2 albo 4 jakies xeony, 2GB, macierz. Co do ilosci wykorzystywanych danych to szacuje więcej, kilkanaście %. Serwer CS/Linux.
Jest wolniejszy i to DUŻO. W przypadku obsługi wielu (kilkuset) na jednej maszynce to już katastrofa :-)

Wszystko zgoda, FB może być wolniejszy, chociaż czy rzeczywiscie "katastrofa"? Zacząłem szukać jakiegos miarodajnego, wiarygodnego testu. Pewnie takiego nie ma, znalazłem tylko to:

https://noldor.iglu.cz/root_cz_firebird_article.pdf

Sam przyznaję, wyniki dziwne, muszę kiedys zrobic podobny test zeby sie przekonac. Nawet jezeli to sie potwierdzi to nie zaprzecza temu co napisales bo to jest sytuacja kiedy serwer odpytuje jeden klient. Co do innego testu to wyglada na to ze przynajmniej częsc stron pipni.cz chodzi na FB, tak przynamniej wynika z adnotacji w stopkach "Powered by Firebird". Chodzi to calkiem sprawnie, ich serwis wyglada na calkiem spory, obsluguja wiele serwisow a FB jest na jednej maszynie (https://new.pipni.pl/hardware.phtml).

Ale .. to nie sa zadne dowody, argumenty (chociaz jakies są ;). Zdaję sobie sprawę, że FB może nie być tak sprawny ja mySQL. Tak w ogóle, te moje przymiarki to raczej zabawa i wcale nie upieram się (za bardzo) przy FB. Ale przy tej okazji zbiorę jakies doswiadczaenia, wnioski, które mogą mi się przydać.

Przy okazji: znalazłem ciekawe zestawienie różnic FB (IB) i MySQL:

https://www.borland.com/resources/en/pdf/wh...ib_vs_MySQL.pdf

Może chciałbyś kupić domenę firebird.pl :-)

nie, nie chcę :)

pozdrawiam Pawel

Odnośnik do komentarza
Udostępnij na innych stronach

Maszyna jest "dobra", szczególów nie znam dokładnie ale jest tak jak piszesz, 2 albo 4 jakies xeony, 2GB, macierz. Co do ilosci wykorzystywanych danych to szacuje więcej, kilkanaście %. Serwer CS/Linux.

Immienniku, skoro pracowałeś z takimi bazami danych to jak możesz nie wiedzieć na jakim sprzęcie pracowały? CS w wersji na Linuxa w najnowszej wersji 1.5.3... obsługuje 4 "jakieś" xeony?

Na zdrowy chłopski rozum... masz bazę nnGB, jednocześnie korzysta z niej mmm klientów i wszystko chodzi w czasie rzeczywistym to... albo to 2gb się rozmnożyło albo znasz jakieś niezłe triki, które rad byłbym poznać ;-)

Wszystko zgoda, FB może być wolniejszy, chociaż czy rzeczywiscie "katastrofa"? Zacząłem szukać jakiegos miarodajnego, wiarygodnego testu. Pewnie takiego nie ma, znalazłem tylko to:

https://noldor.iglu.cz/root_cz_firebird_article.pdf

Sam przyznaję, wyniki dziwne, muszę kiedys zrobic podobny test zeby sie przekonac. Nawet jezeli to sie potwierdzi to nie zaprzecza temu co napisales bo to jest sytuacja kiedy serwer odpytuje jeden klient. Co do innego testu to wyglada na to ze przynajmniej częsc stron pipni.cz chodzi na FB, tak przynamniej wynika z adnotacji w stopkach "Powered by Firebird". Chodzi to calkiem sprawnie, ich serwis wyglada na calkiem spory, obsluguja wiele serwisow a FB jest na jednej maszynie (https://new.pipni.pl/hardware.phtml).

Nie chodzi o to, że FB jest "wolniejszy", w wielu przypadkach będzie nieporównywalnie szybszy.

Chodzi o praktyczne zastosowanie silnika, który nie został stworzony w celu supportowania 100 i więcej baz na jednej maszynce.

Bardzo ciekawe są porównania InterBase w wersji 7.5 i MS SQL Servera - polecam ;-)

Ale .. to nie sa zadne dowody, argumenty (chociaz jakies są :unsure:. Zdaję sobie sprawę, że FB może nie być tak sprawny ja mySQL. Tak w ogóle, te moje przymiarki to raczej zabawa i wcale nie upieram się (za bardzo) przy FB. Ale przy tej okazji zbiorę jakies doswiadczaenia, wnioski, które mogą mi się przydać.

Z autopsji powiem Ci, że jeżeli masz na szybko wdrożyć jakieś rozwiązanie dostępne przez dla klientów zza wody pracujących na makach (czyli najlepsze rozwiązanie to webapp) i wiesz, że ta aplikacja będzie odpalana powiedzmy 100x na dobę to nawet nie myśl o zmianie silnika... zrób replikację, pare skryptów w PHP i wynik będzie zadawalający.

Przy okazji: znalazłem ciekawe zestawienie różnic FB (IB) i MySQL:

https://www.borland.com/resources/en/pdf/wh...ib_vs_MySQL.pdf

Nie ukrywam, że jestem sympatykiem Borlanda ;-) (m. in. organizuję Zlot Programistów Delphi 2005 w Krakowie, na który serdecznie zapraszam) ale przeczytałem wiele ich porównań i... okazuje się, że mają rację... pod warunkiem, że mamy identyczne środowiska do testów.

P. S.

Dlaczego nie stosuje się FB w środowiskach webapp powinieneś wiedzieć na przykładzie odpalonych wielu instancji na jednym hoście.

pozdr0 600

oKrupieństwo

potęga umysłu

Odnośnik do komentarza
Udostępnij na innych stronach

Immienniku, skoro pracowałeś z takimi bazami danych to jak możesz nie wiedzieć na jakim sprzęcie pracowały? CS w wersji na Linuxa w najnowszej wersji 1.5.3... obsługuje 4 "jakieś" xeony?
Nie mam bezpośredniego kontaktu z nimi, tym bardziej że serwery fizycznie sa w zupełnie innym miejscu. Kiedyś coś się uruchomiło, teraz się kręci i rośnie a zajmują się tym inni. Ale żeby nie kręcić dowiem się dokładniej jakie tam są warunki, obciążenie i napiszę do Ciebie.
Na zdrowy chłopski rozum... masz bazę nnGB, jednocześnie korzysta z niej mmm klientów i wszystko chodzi w czasie rzeczywistym to... albo to 2gb się rozmnożyło albo znasz jakieś niezłe triki, które rad byłbym poznać ;-)
Dowiem się. Ale ... na mój chłopski rozum.... nie bardzo rozumiem co ma wersja CS do ilości procesorów? Ja zapamiętałem to tak, że na każdą sesję użytkownika tworzony jest oddzielny proces i to system operacyjny decyduje na który procesor czy rdzeń ją skierować. Bo "affinity" ma chyba znaczenie tylko dla SS? Co do pamięci; każda sesja w CS to ok 2MB + cache (il. stron x page_size) to daje na sesję załóżmy 8MB. Sam serwer FB/CS zużywa niewiele, jakis Lock Manager i jąkąś pamięć na "sorting", powiedzmy razem z syst. operacyjnym da to 150MB. Czyli np na 2GB powinno zostać miejsce dla ok 200 sesji. Ale to tylko chłopska teoria. Zaintrygowałes mnie, z "takimi" sytuacjami nie mam do czynienia codziennie, po prostu zapamiętałem kiedyś, że to jest możliwe nie wnikając, nie sprawdzając do końca konfiguracji. Sprawdzę to i później napiszę.

pozdrawiam Paweł

Odnośnik do komentarza
Udostępnij na innych stronach

  • 2 lata później...
  • 1 rok później...

Zarchiwizowany

Ten temat przebywa obecnie w archiwum. Dodawanie nowych odpowiedzi zostało zablokowane.

  • Ostatnio przeglądający   0 użytkowników

    • Brak zarejestrowanych użytkowników przeglądających tę stronę.
×
×
  • Dodaj nową pozycję...

Powiadomienie o plikach cookie

Umieściliśmy na Twoim urządzeniu pliki cookie, aby pomóc Ci usprawnić przeglądanie strony. Możesz dostosować ustawienia plików cookie, w przeciwnym wypadku zakładamy, że wyrażasz na to zgodę. Warunki użytkowania Polityka prywatności