🚀 go-pugleaf

W dniu 21.04.2016 o 06:21, Borneq pisze:
> Jaka jest alternatywa dla MySQL, niedroga baza, do postawienia na
> serwerze Linux, może pod Windows do przetestowania i radząca sobie z

A PostgreSQL ?

W dniu 21.04.2016 o 06:21, Borneq pisze:
> Jaka jest alternatywa dla MySQL, niedroga baza, do postawienia na
> serwerze Linux, może pod Windows do przetestowania i radząca sobie z

A co to takiego MariaDB?

W dniu 21.04.2016 o 06:31, Borneq pisze:
> A co to takiego MariaDB?
>
Aha, https://pl.wikipedia.org/wiki/MariaDB
Pytanie, czy konieczna jest kompatybilność z MySQL czy też coś innego. 
Jak na razie nie jestem przywiązany do MySQL.

On Thursday, April 21, 2016 at 6:23:00 AM UTC+2, Borneq wrote:
> W dniu 21.04.2016 o 06:21, Borneq pisze:
> > Jaka jest alternatywa dla MySQL, niedroga baza, do postawienia na
> > serwerze Linux, może pod Windows do przetestowania i radząca sobie z
> 
> A PostgreSQL ?

Zadam pytanie odwrotnie, czemu nie PostgreSQL?
Pozdrawiam

W dniu 21.04.2016 o 06:21, Borneq pisze:
> Wprawdzie w dystrybucjach WAMP i LAMP MySQL jest darmowy, ale już dla
> zastosowań komercyjnych trzeba płacić 2 tys i więcej dolarów rocznie.
> Jaka jest alternatywa dla MySQL, niedroga baza, do postawienia na
> serwerze Linux, może pod Windows do przetestowania i radząca sobie z
> dużą ilością danych (choć ten warunek chyba niepotrzebny, bo obecnie
> raczej wszystkie bazy radzą sobie z terabajtowymi danymi, chyba poza
> takimi jak SQLite) ?

Skąd taka informacja?
Dlaczego uważasz, że używając MySQL'a w komercyjnej aplikacji
musisz za to płacić?

--
Robert

W dniu 21.04.2016 o 11:13, M.M. pisze:
>> A PostgreSQL ?
>
> Zadam pytanie odwrotnie, czemu nie PostgreSQL?
> Pozdrawiam

O PostgreSQL słyszałem że ma bardziej zaawansowane mechanizmy, ale nie 
dorównuje prędkością MySQL.

W dniu 21.04.2016 o 11:27, Robert Winkler pisze:
> Skąd taka informacja?
> Dlaczego uważasz, że używając MySQL'a w komercyjnej aplikacji
> musisz za to płacić?

https://www.mysql.com/products/

W dniu 21.04.2016 o 13:19, Borneq pisze:
> W dniu 21.04.2016 o 11:27, Robert Winkler pisze:
>> Skąd taka informacja?
>> Dlaczego uważasz, że używając MySQL'a w komercyjnej aplikacji
>> musisz za to płacić?
>
> https://www.mysql.com/products/
>

Nie o to się pytałem,
wiem że Oracle oferuje płatny support dla MySQL'a,
ale kto ci zabrania użycia MySQL Community Edition
w projekcie komercyjnym?

https://dev.mysql.com/downloads/mysql/

--
Robert

W dniu 21.04.2016 o 13:34, Robert Winkler pisze:
> Nie o to się pytałem,
> wiem że Oracle oferuje płatny support dla MySQL'a,
> ale kto ci zabrania użycia MySQL Community Edition
> w projekcie komercyjnym?
>
> https://dev.mysql.com/downloads/mysql/

To znaczy że MySQL Community Edition można użyć w projekcie komercyjnym? 
Bardzo dobrze!
Te wyższe mają jakieś większe możliwości, ale można się chyba bez nich obyć.

Pozdrawiam

W dniu 21.04.2016 o 13:18, Borneq pisze:
> W dniu 21.04.2016 o 11:13, M.M. pisze:
>>> A PostgreSQL ?
>>
>> Zadam pytanie odwrotnie, czemu nie PostgreSQL?
>> Pozdrawiam
>
> O PostgreSQL słyszałem że ma bardziej zaawansowane mechanizmy, ale nie
> dorównuje prędkością MySQL.
>
>
Poszukaj statystyk, w których zbadano jak obciążenie wpływa na 
wydajność. Możesz się zdziwić na korzyść Postgresa.
Nie jestem obiektywny, bo zawsze lubiłem Postgresa i używam go od lat,
ale nie jestem fanatykiem. Zwłaszcza do czasu, gdy wreszcie Postgres 
dorobił się sensownego count (co się prosiło od dawna) mógłbym uwierzyć 
w przewagę czy to MySQL-a czy nawet Firebirda. Ale od wersji 9.x 
Postgres ma naprawdę chyba wszystko do zaoferowania.

Pozdrawiam
Rony

On Thursday, April 21, 2016 at 1:18:39 PM UTC+2, Borneq wrote:
> W dniu 21.04.2016 o 11:13, M.M. pisze:
> >> A PostgreSQL ?
> >
> > Zadam pytanie odwrotnie, czemu nie PostgreSQL?
> > Pozdrawiam
> 
> O PostgreSQL słyszałem że ma bardziej zaawansowane mechanizmy, ale nie 
> dorównuje prędkością MySQL.

Nie jestem specjalistą od baz danych, ani od historii ich rozwoju, 
więc nie traktuj moich słów jako pewnik, ani nawet jako prawdę. Tak 
zupełnie luźno pisząc...

Kiedyś MySQL miał tak mało do zaoferowania że wszyscy z niego
nabijali się iż to nawet nie jest baza danych, ale był szybki. PostgreSQL z
kolei (przynajmniej) uchodził za bazę profesjonalną, a że za większą
funkcjonalność trzeba płacić, więc też uchodził za bazę wolną i pewnie
faktycznie wolniejszy był. Potem świat stanął na głowie i w MySQLu
pojawiło się wiele nowych cech, i nawet czołowi producenci 
baz danych zdecydowali się go wykupić. Ciekawe co naprawdę skłoniło
do wykupienia, trudno uwierzyć, że bali się konkurencji, ale jakiś
mały procent rynku być może tracili z powodu MySQLa. Potem znowu
świat stanął na głowie i teraz postgres uchodzi za bazę wydajną.

Czy naprawdę jest wydajny, czy nie, to pytanie bardziej trudne niż 
mogłoby się wydawać... Jak udzielić odpowiedzi na to pytanie bez
konkretnego zastosowania? 

Ja bym chciał się dowiedzieć, czemu niektóre zapytania SQL tak wolno
działają na wielu silnikach, nawet gdy wszystkie dane są w buforze
ram systemu operacyjnego lub w buforze samego silnika. Może tak
trudno jest napisać dobry optymalizator zapytań? Nie wiem.

Pozdrawiam

On 22.04.2016 00:10, M.M. wrote:
> Ja bym chciał się dowiedzieć, czemu niektóre zapytania SQL tak wolno
> działają na wielu silnikach, nawet gdy wszystkie dane są w buforze
> ram systemu operacyjnego lub w buforze samego silnika. Może tak
> trudno jest napisać dobry optymalizator zapytań? Nie wiem.

trudno jest odpowiedzieć na tak ogólnie zadane pytanie. zapytanie 
zapytaniu nierówne. najlepiej zobaczyć jaki jest plan wykonania i 
sprawdzić jak silnik zdecydował się je "rozpracować". być może długo się 
wykonują bo, ogólnie rzecz ujmując, muszą.

On Friday, April 22, 2016 at 8:48:19 AM UTC+2, geos wrote:
> On 22.04.2016 00:10, M.M. wrote:
> > Ja bym chciał się dowiedzieć, czemu niektóre zapytania SQL tak wolno
> > działają na wielu silnikach, nawet gdy wszystkie dane są w buforze
> > ram systemu operacyjnego lub w buforze samego silnika. Może tak
> > trudno jest napisać dobry optymalizator zapytań? Nie wiem.
> 
> trudno jest odpowiedzieć na tak ogólnie zadane pytanie. zapytanie 
> zapytaniu nierówne. najlepiej zobaczyć jaki jest plan wykonania i 
> sprawdzić jak silnik zdecydował się je "rozpracować". być może długo się 
> wykonują bo, ogólnie rzecz ujmując, muszą.

Nie, przepraszam, nie podejmuję rękawicy, ponieważ to wymaga za
dużo pracy :) Żeby porządnie pogadać, to bym musiał się ze 2-3 dni 
przygotować. Bym musiał zbudować zapytanie które tak mocno obciąża, 
bazę, upewnić się że dane baza buforuje w RAM, bym musiał zrobić 
różne konfiguracje bazy, pomierzyć czasy... Potem bym musiał napisać 
program w C++ i porównać wydajność bazy z wydajnością tego programu, czyli z
wydajnością niemal teoretyczną. Sorry, nie mam na to czasu.

Mogę tylko tak ogólnie rzucić temat, że czasami w C++ działało u mnie
10tys razy szybciej i nie wiedziałem dlaczego.

Pozdrawiam

On 22.04.2016 17:40, M.M. wrote:
> Mogę tylko tak ogólnie rzucić temat, że czasami w C++ działało u mnie
> 10tys razy szybciej i nie wiedziałem dlaczego.

ok, ale pewnie nie zapewniało izolacji, obsługi transakcji, mechanizmu 
parsowania, wielowątkowości, obsługę rollbacku, userów, triggerów, 
procedur do logowania itepe itede... stosunkowo łatwo zaimplementować 
algorytm w c++ używany np. w złączeniach typu NESTED LOOPS albo HASH 
JOIN, ale już wszystko scalić do kupy i nazwać bazą danych to już tak 
nie zbyt łatwo.

On Friday, April 22, 2016 at 6:13:37 PM UTC+2, geos wrote:
> On 22.04.2016 17:40, M.M. wrote:
> > Mogę tylko tak ogólnie rzucić temat, że czasami w C++ działało u mnie
> > 10tys razy szybciej i nie wiedziałem dlaczego.
> 
> ok, ale pewnie nie zapewniało izolacji, obsługi transakcji, mechanizmu 
> parsowania, wielowątkowości, obsługę rollbacku, userów, triggerów, 
> procedur do logowania itepe itede... stosunkowo łatwo zaimplementować 
> algorytm w c++ używany np. w złączeniach typu NESTED LOOPS albo HASH 
> JOIN, ale już wszystko scalić do kupy i nazwać bazą danych to już tak 
> nie zbyt łatwo.

Ściśle, to tak, masz rację, nie obsługiwało tego wszystkiego co 
piszesz. Jednak aplikacja na tym działała i działa nadal. Po prostu
te mechanizmy o których piszesz zostały zrealizowane inaczej. Np.
tylko jeden wątek dostaje prawo do zapisu, więc wątki odczytujące
(innymi słowy, wątki wykonujące selecta) nie muszą się martwić
niczym innym - dlatego tak szybko działają.

Pozdrawiam

W dniu 21.04.2016 o 06:21, Borneq pisze:
> serwerze Linux, może pod Windows do przetestowania i radząca sobie z
> dużą ilością danych (choć ten warunek chyba niepotrzebny, bo obecnie

A jaka baza danych pod Linuxem poradzi sobie z ogromną ilością zapytań. 
Wielu klientów będzie jednocześnie pytało o zawartość bazy.

W dniu 2016-04-23 o 06:31, Borneq pisze:
> W dniu 21.04.2016 o 06:21, Borneq pisze:
>> serwerze Linux, może pod Windows do przetestowania i radząca sobie z
>> dużą ilością danych (choć ten warunek chyba niepotrzebny, bo obecnie
>
> A jaka baza danych pod Linuxem poradzi sobie z ogromną ilością zapytań.
> Wielu klientów będzie jednocześnie pytało o zawartość bazy.
>
A co to jest "ogromna ilość zapytań" i "wielu klientów" ?

-- 
Pozdrawiam,
Leszek Kubrak

W dniu 23.04.2016 o 07:52, Lesiok pisze:
>> A jaka baza danych pod Linuxem poradzi sobie z ogromną ilością zapytań.
>> Wielu klientów będzie jednocześnie pytało o zawartość bazy.
>>
> A co to jest "ogromna ilość zapytań" i "wielu klientów" ?

A może NoSQL?

W dniu sobota, 23 kwietnia 2016 06:31:49 UTC+2 użytkownik Borneq napisał:
> W dniu 21.04.2016 o 06:21, Borneq pisze:
> > serwerze Linux, może pod Windows do przetestowania i radząca sobie z
> > dużą ilością danych (choć ten warunek chyba niepotrzebny, bo obecnie
> 
> A jaka baza danych pod Linuxem poradzi sobie z ogromną ilością zapytań. 
> Wielu klientów będzie jednocześnie pytało o zawartość bazy.

 MSSQL w wersji 2016 jest dla Windows i dla Linuxa, a ta baza raczej sobie radzi z dużym obciążeniem i duża ilością danych

On Saturday, April 23, 2016 at 6:31:49 AM UTC+2, Borneq wrote:
> W dniu 21.04.2016 o 06:21, Borneq pisze:
> > serwerze Linux, może pod Windows do przetestowania i radząca sobie z
> > dużą ilością danych (choć ten warunek chyba niepotrzebny, bo obecnie
> 
> A jaka baza danych pod Linuxem poradzi sobie z ogromną ilością zapytań. 
> Wielu klientów będzie jednocześnie pytało o zawartość bazy.

Zapytanie wykonywane przez połączenie TCP a nawet UDP ma pewną,
jak ja to nazywam, bezwładność. Jeśli używasz (jeśli baza nie daje 
alternatywy dla TCP, UDP), to sprawdź: ile na sekundę, od ilu 
klientów, można przesłać po jednym bajcie w tą i z powrotem. 
Wyjdzie Ci górne oszacowanie 'ogromnej ilości zapytań' dla dowolnej
bazy na tychże połączeniach.

Jeśli wyjdzie Ci za mało, to musisz najpierw zastanowić się nad
innym sposobem komunikacji.

Pozdrawiam

W dniu 2016-04-23 o 09:33, Borneq pisze:
> W dniu 23.04.2016 o 07:52, Lesiok pisze:
>>> A jaka baza danych pod Linuxem poradzi sobie z ogromną ilością zapytań.
>>> Wielu klientów będzie jednocześnie pytało o zawartość bazy.
>>>
>> A co to jest "ogromna ilość zapytań" i "wielu klientów" ?
>
> A może NoSQL?
A może odpowiedz na pytanie?

-- 
wloochacz

W dniu 23.04.2016 o 14:46, wloochacz pisze:
>>> A co to jest "ogromna ilość zapytań" i "wielu klientów" ?
>>
>> A może NoSQL?
> A może odpowiedz na pytanie?

Trudno oszacować, na razie w fazie pomysłów, ale jakby to był serwis 
dostępny publicznie przez www, to naprawdę wiele osób jednocześnie 
dawało by zapytania.

W dniu 2016-04-23 o 15:39, Borneq pisze:
> W dniu 23.04.2016 o 14:46, wloochacz pisze:
>>>> A co to jest "ogromna ilość zapytań" i "wielu klientów" ?
>>>
>>> A może NoSQL?
>> A może odpowiedz na pytanie?
>
> Trudno oszacować, na razie w fazie pomysłów, ale jakby to był serwis
> dostępny publicznie przez www, to naprawdę wiele osób jednocześnie
> dawało by zapytania.
>
>
Żeby wybrać rozsądnie technologię do zrealizowania projektu MUSISZ to 
jakoś oszacować.

-- 
Pozdrawiam,
Leszek Kubrak

On Saturday, April 23, 2016 at 3:39:14 PM UTC+2, Borneq wrote:
> W dniu 23.04.2016 o 14:46, wloochacz pisze:
> >>> A co to jest "ogromna ilość zapytań" i "wielu klientów" ?
> >>
> >> A może NoSQL?
> > A może odpowiedz na pytanie?
> 
> Trudno oszacować, na razie w fazie pomysłów, ale jakby to był serwis 
> dostępny publicznie przez www, to naprawdę wiele osób jednocześnie 
> dawało by zapytania.

Wszyscy do tego samego komputera?

Pozdrawiam

W dniu 23.04.2016 o 18:51, M.M. pisze:
> Wszyscy do tego samego komputera?

No właśnie, to ograniczenie, chyba żeby zrobić to w jakiś inny sposób, 
ale nie wiem jak.

On Saturday, April 23, 2016 at 7:54:18 PM UTC+2, Borneq wrote:
> W dniu 23.04.2016 o 18:51, M.M. pisze:
> > Wszyscy do tego samego komputera?
> 
> No właśnie, to ograniczenie, chyba żeby zrobić to w jakiś inny sposób, 
> ale nie wiem jak.

Jeśli ta ogromna ilość zapytań, to w ogromnej części zapytania odczytujące, to
może warto zainteresować się replikacją - dużo baz wspomaga replikację. 
Natomiast jeśli masz dużo zapisów, to ja też nie wiem jakie ogólne(!)
rozwiązanie zaproponować. 

Pozdrawiam