пропозиції роботи
konto usunięte
Temat: Kiedy NoSQL?
Prosto wytłumaczone różnice między SQL-em a NoSQL-em w kontekście MongoDB:http://public.dhe.ibm.com/software/dw/demos/jmongodb/i...
- 1
- 2
http://public.dhe.ibm.com/software/dw/demos/jmongodb/i...
Tomasz Zadora programuję
Temat: Kiedy NoSQL?
Często to nie jest tak, że albo SQL albo NoSQL tylko SQL + NoSQL.W ogóle idealny byłby silnik bazy danych oferujący *jednocześnie* obydwa modele przechowywania i dostępu do danych - czyli możemy sobie w jednej bazie danych stworzyć tradycyjne tabele z transakcjami ACID i tabele/kolekcje/whatever schemaless, z dostępem NoSQL i bez ACID.Tomasz Zadora edytował(a) ten post dnia 21.06.11 o godzinie 18:14
konto usunięte
Temat: Kiedy NoSQL?
Tomasz Zadora:
Często to nie jest tak, że albo SQL albo NoSQL tylko SQL + NoSQL.
W ogóle idealny byłby silnik bazy danych oferujący *jednocześnie* obydwa modele przechowywania i dostępu do danych - czyli możemy sobie w jednej bazie danych stworzyć tradycyjne tabele z transakcjami ACID i tabele/kolekcje/whatever schemaless, z dostępem NoSQL i bez ACID.
W Netezzie mamy możliwość korzystania z klasycznych tabel i implementacji Hadoopa
Temat: Kiedy NoSQL?
Tomasz Zadora:
Często to nie jest tak, że albo SQL albo NoSQL tylko SQL + NoSQL.
W ogóle idealny byłby silnik bazy danych oferujący *jednocześnie* obydwa modele przechowywania i dostępu do danych - czyli możemy sobie w jednej bazie danych stworzyć tradycyjne tabele z transakcjami ACID i tabele/kolekcje/whatever schemaless, z dostępem NoSQL i bez ACID.
Jest coś takiego: MySql z handlersocket. Ale to jest jeszcze w powijakach
konto usunięte
Temat: Kiedy NoSQL?
Tomasz Zadora:
Często to nie jest tak, że albo SQL albo NoSQL tylko SQL + NoSQL.
W ogóle idealny byłby silnik bazy danych oferujący *jednocześnie* obydwa modele przechowywania i dostępu do danych - czyli możemy sobie w jednej bazie danych stworzyć tradycyjne tabele z transakcjami ACID i tabele/kolekcje/whatever schemaless, z dostępem NoSQL i bez ACID.
Moim zdaniem troszku sobie zaprzeczasz, ponieważ prawdziwa zaleta nosql jest ich liniowe skalowanie na X węzłów, sama taka architektura zmusza Cie już do synchronizacja danych po wszystkich węzłach, czyli doprowadzenia do stanu kiedy baza nie jest konsystetna ( wezel a,b,c ma stan rekordu przed aktualizacja a wezel d,e,f po aktualizacji ) czyli złamania ACID'a. Takie zjawisko nazywa sie Eventual consistency. Tak więc średnio da się coś takiego zrobić. Owszem, zaraz ktoś powie, to zalokujmy rekordy w węzłach do czytania na czas synchronizacji - tak okej, ale w tedy tracimy na availabillity (cAp ) które charakteryzuje nasze Nosql.
Zgodzę się z TOba ze sql + nosql, ale raczej jest to balansowanie w tym kierunku w którym chcemy podążać w zależności od wymagań projektu.
Z tego co się orientuje to VoltDB ( to jest baza czysto relacyjna ) oferuje ogromną wydajność i skalowalność poziomą w funkcji liniowej, przy zachowaniu zasad ACID ( jak przystało na bazę relacyjną :) )
Na ich stronie są podane wyniki porównujące ( wydajność ) z popularnymi NoSql'ami jak Cassandra.
Tomasz Zadora programuję
Temat: Kiedy NoSQL?
Nie zaprzeczam sobie "troszku". Nie potrafisz wyobrazić sobie sytuacji kiedy dla jakiejś części danych potrzebujesz systemu transakcyjnego ? Podpowiedź: spójrz np. na systemy bankowe, tam większość operacji na danych opiera się na transakcjach, bo nie można sobie pozwolić na brak spójności danych.
konto usunięte
Temat: Kiedy NoSQL?
Wybór modelu BD zależy od projektu i złożoności systemu.Należy pamiętać jednak, że "noSQL" nie oznacza całkowitej rezygnacji z rozwiązań SQL-owych, zatem skrót ten należy rozumieć jako "Not Only SQL", które ma wspierać proste modele danych. Dlatego też relacyjność nie istnieje tutaj w samej bazie danych, a może zostać emulowana w kodzie programu, choć nie zawsze jest to konieczne. Sprawia to, że rozwiązanie noSQL staje się bardziej elastyczne i niezależne od schematów niż rozwiązanie SQL-owe.
Jedną z bardziej charakterystycznych dla noSQL cech jest rezygnacja z ACID na rzecz BASE ogromnej ilości danych.
Generalizując odpowiedź na pytanie w temacie można powiedzieć, że noSQL jest lepszy do obsługi wielkiej ilości danych o nieskomplikowanej strukturze (nieliczna ilość typów danych), natomiast rozwiązanie SQL będzie lepsze do obsługi wielkiej ilości danych o skomplikowanej strukturze (liczna ilość typów danych).
konto usunięte
Temat: Kiedy NoSQL?
Tomasz Zadora:
Nie zaprzeczam sobie "troszku". Nie potrafisz wyobrazić sobie sytuacji kiedy dla jakiejś części danych potrzebujesz systemu transakcyjnego ? Podpowiedź: spójrz np. na systemy bankowe, tam większość operacji na danych opiera się na transakcjach, bo nie można sobie pozwolić na brak spójności danych.
Tak się składa ze aktualnie pracuje przy systemach transakcyjnych, wiec doskonale wiem o czym mówisz.
W takim układzie wyjaśnij mi jak rozumiesz system transakcyjny, bo może od tego trzeba zacząć.
Zważ że żaden system bazodanowy nie działa w systemie dla części danych tak a dla części danych siak. Może to determinować operacja jaką chcemy wykonać.
PS: wracając do systemy bankowego. Czyli widzisz model gdzie łączysz Informixa z powiedzmy MongoDB ? - bo tak rozumiem Twoja wypowiedź.Łukasz Grabowski edytował(a) ten post dnia 23.06.11 o godzinie 19:13
Tomasz Zadora programuję
Temat: Kiedy NoSQL?
Właśnie jeżeli chodzi o tą emulację... przykładowo jest system informatyczny / serwis www gdzie większość danych "mamy" w "modelu" NoSQL a część to np. transakcje (np. doładowanie konta) i jakiś abstrakcyjny stan kont.W takiej sytuacji zamiast budować różnego rodzaju emulacje, wygodniej jest zastosować stare, dobre sprawdzone ACID.
Jeszcze wracając do tego co pisał Łukasz - transakcje ACID też mogą być rozproszone bez straty specyfikacji ACID, np.:
http://blogs.oracle.com/MySQL/entry/scaling_web_databa...
"Unlike other distributed databases, users do not lose the ability to perform JOIN operations or sacrifice ACID-guarantees."
konto usunięte
Temat: Kiedy NoSQL?
Tomasz Zadora:
Często to nie jest tak, że albo SQL albo NoSQL tylko SQL + NoSQL.
W ogóle idealny byłby silnik bazy danych oferujący *jednocześnie* obydwa modele przechowywania i dostępu do danych - czyli możemy sobie w jednej bazie danych stworzyć tradycyjne tabele z transakcjami ACID i tabele/kolekcje/whatever schemaless, z dostępem NoSQL i bez ACID.
zaprzeczanie tyczyło się tej wypowiedzi ...
O realizowanie zasad ACID i BASE.
PS: tak wiem co to są transakcje XA, ale nie masz tutaj możliwości odczytu jaki daje Ci Nosql. (czyli taki jaki widziałeś w swoim modelu w 2 poście)Łukasz Grabowski edytował(a) ten post dnia 23.06.11 o godzinie 19:17
Tomasz Zadora programuję
Temat: Kiedy NoSQL?
Transakcja - zbiór operacji na bazie danych który spełnia warunki ACID: http://en.wikipedia.org/wiki/ACIDOczywiście możesz sobie wyobrazić innego rodzaju transakcje, ale ja mam na myśli właśnie takie.Tomasz Zadora edytował(a) ten post dnia 23.06.11 o godzinie 19:21
Piotr
D.
Tester
Oprogramowania
Temat: Kiedy NoSQL?
Mam wrażenie, że coraz więcej projektów - na początek open source - idzie w kierunku hybrydy. Jest rozwój mechanizmu relacyjnego, a oprócz tego bezpośredni dostęp do storage-engine'u. Z czasem przejmą to pewnie bazy komercyjne (chociaż kiedyś w jakiejś ulotce Oracle'a widział coś o "support for unstructured data".Poza tym, Oracle też poszedł w odwrotną stronę - BerkleyDB dostało wielowątkowe API zgodne z SQLite...
Tomasz Zadora programuję
Temat: Kiedy NoSQL?
Łukasz Grabowski:[...]
zaprzeczanie tyczyło się tej wypowiedzi ...
Nadal nie wykazałeś w jaki sposób sobie zaprzeczam. Co więcej, jak już wyżej koledzy napisali - są próby integracji obydwu rozwiązań w jednym silniku.
konto usunięte
Temat: Kiedy NoSQL?
Tomasz Zadora:
Transakcja - zbiór operacji na bazie danych który spełnia warunki ACID: http://en.wikipedia.org/wiki/ACID
nie jest to prawda : )
Transakcja to jest ciąg operacji których atomowy efekt końcowy determinuje końcowy stan transakcji. Czyli "być albo nie być".
ACID - jest zbiór warunków jakie musi spełniać system relacyjny aby można było nadać mu miano transakcyjnego i takowe operacje w nim realizować.
Oczywiście możesz sobie wyobrazić innego rodzaju transakcje, ale ja mam na myśli właśnie takie.Łukasz Grabowski edytował(a) ten post dnia 23.06.11 o godzinie 19:36
konto usunięte
Temat: Kiedy NoSQL?
Tomasz Zadora:
Łukasz Grabowski:[...]zaprzeczanie tyczyło się tej wypowiedzi ...
Nadal nie wykazałeś w jaki sposób sobie zaprzeczam. Co więcej, jak już wyżej koledzy napisali - są próby integracji obydwu rozwiązań w jednym silniku.
Zaprzeczasz sobie w tym ze chcesz przeprowadzać transakcje w bazie danych opartej o odczyty Nosql baz typu CP ( CAP theory )Łukasz Grabowski edytował(a) ten post dnia 23.06.11 o godzinie 19:33
Tomasz Zadora programuję
Temat: Kiedy NoSQL?
Przecież Ci napisałem, o jakie transakcje *mi* chodzi.W chwyty semantyczno-erystyczne bawić się nie będę, jeszcze jedna taka wypowiedź z Twojej strony i będziesz przeze mnie ignorowany :)
Tomasz Zadora programuję
Temat: Kiedy NoSQL?
Łukasz Grabowski:[...]
Zaprzeczasz sobie w tym ze chcesz mieć transakcyjny odczyt w bazie danych opartej o odczyty Nosql baz typu CP ( CAP theory )
Tylko, że ja nie chce odczytywać ani przeprowadzać transakcji na tych tabelach/kolekcjach które działają w "modelu" NoSQL.
Ja chce mieć w jednym silniku dwa różne typy tabel, w pewnym sensie jest to już obecne w MySQL: tabele typu MyISAM (nietransakcyjne) i tabele typu InnoDB.
konto usunięte
Temat: Kiedy NoSQL?
No i własnie tutaj jest cała zabawa...ale osobiście sugerowałbym zastosowaniem 2 systemów, transakcyjnego i jakiegoś Couch'a albo Mongo . ;)Łukasz Grabowski edytował(a) ten post dnia 23.06.11 o godzinie 19:51
Tomasz Zadora programuję
Temat: Kiedy NoSQL?
"I tu się moim zdaniem mylisz :)" <- nieaktualne bo sprytnie zmieniłeś post-aPonieważ o ile połączenia (klucze obce) pomiędzy tabelami transakcyjnymi powinny być spójne o tyle połączenia *Z* tabeli nietransakcyjnej *DO* tabeli transakcyjnej (ale nie w drugą stronę) spójne już nie muszą być.
Dlatego tak małą porcję danych jak konto uzytkownika (id, login, hasło, stan konta) mogę sobie trzymać w tabeli transakcyjnej a gigabajty danych z tym kontem połączone (zdjęcia, dokumenty, whatever) - mogą spokojnie być rozproszone w jakiejś chmurze/nosql-u.
Teraz zrozumiał ?Tomasz Zadora edytował(a) ten post dnia 23.06.11 o godzinie 19:54
konto usunięte
Temat: Kiedy NoSQL?
Tomasz Zadora:nie chodzi o klucze, tylko w momencie kiedy chcesz w transakcji dodac cos do tabelki myisam to ona jest zalokowana na czas transakcji.
I tu się moim zdaniem mylisz :)
Ponieważ o ile połączenia (klucze obce) pomiędzy tabelami transakcyjnymi powinny być spójne o tyle połączenia *Z* tabeli nietransakcyjnej *DO* tabeli transakcyjnej (ale nie w drugą stronę) spójne już nie muszą być.
a co do kluczy obcych, jak masz constrainta założonego to on wymaga aby rekord był ...w myisam nie masz kluczy obcych ....
i nie spotkałem się aby było coś takiego jak contraint który do tej tabelki może być a do tej nie ...
chyba ze za klucz główne uważasz wpis w tabelce który ma być równy innemu wpisowi w innej ( bez fizycznego dodawania kluczy ? )
Dlatego tak małą porcję danych jak konto uzytkownika (id, login, hasło, stan konta) mogę sobie trzymać w tabeli transakcyjnej a gigabajty danych z tym kontem połączone (zdjęcia, dokumenty, whatever) - mogą spokojnie być rozproszone w jakiejś chmurze/nosql-u.
Teraz zrozumiał ?
Ja doskonale rozumiem to co chcesz zrealizować,ale jest to naprawdę ciężkie bez realizacji obsługi operacji w oparciu o dodatkowa warstwę.
Uważam że możemy zakończyć tutaj naszą rozmowę, ponieważ zeszła na technicze rozmowy o mysql ...
Uważam też że Twoje potrzeby wydajnościowo/transakcyjne zrealizuje VoltDb - jest cholernie szybka i wydajna ;>Łukasz Grabowski edytował(a) ten post dnia 23.06.11 o godzinie 20:08
- 1
- 2
Podobne tematy
Następna dyskusja:
