[Kiro]

Po miesiącu uzywania w pracy riaka stwierdzam ze takie rozproszone bazy danych master-master są jak kobiety:

Ja: zapisz to

Baza: ok

Ja: udało sie?

Baza: chyba tak

J: chyba?

B: no jeszcze nie wiem, ale chyba tak... czekam na info od reszty...

....

J: daj mi to co zapisałem

B: yy...

J: ?

B: no bo ktoś zapisał coś z takim samym kluczem na innym node i nie wiem którą wersję mam ci dać... masz wszystkie, wybierz sobie dobrą i zapisz jeszcze raz :))))

I spróbuj tu człowieku zapewnić unikalność :( #programowanie #bazydanych

[scriptkitty]

@Kiro: Unikalność zapewniasz w ten sposób, że klucz musi być unikalny. Do tego możesz użyć wersji, żeby sprawdzić czy coś było już przedtem zapisane czy nie (razem z mechanizmem vector clock).

[Kiro]

@scriptkitty: No jakby tak o tym pomyśleć to to wygląda pięknie i prosto. Ale dla case gdzie linkuje do nowego obiektu z domyślnym kluczem, nowy obiekt z kluczem który musi być unikalny, waląc w różne node z wielu różnych instancji aplikacji? Zapis przechodzi super, a później w 50 miejscach w appce mogę dostać conflict error. I teraz próbuj rozwiązać konflikty nie wieszając systemu. Jeśli dobrze pamiętam, vector clock w niczym

[scriptkitty]

@Kiro: Bazy nosql nie nadają się do wszystkiego, jeśli nie macie jakiejś super dużej skali, to pewnie postgres spisałby się lepiej.

[Kiro]

@scriptkitty: No właśnie sęk w tym że mamy - bezpieczeństwo i dostępność danych są tu tak samo ważne jak tranzakcyjność i spójność, a między tymi cechami trzeba wybierać. I niestety wybór padł na pierwsze kosztem drugiego...

[m.....q]

@Kiro: A nei da sie tam ustawic offsetu na kazdym masterze? Node1 przyznaje ID 1,2,...10,21,22...29,30,41,42 etc a Node2 kolejno 11,12,13...19,20,31,32... etc. I w ten sposob nie masz konflikow?

[Kiro]

@msq: Hm, nie, ale nie wiem jak to by miało pomóc (pomijam fakt że klucz jest z zwenętrznego źródła, nie automatyczny). Jeśli zapiszę 2 rekordy z takim samym kluczem w tym samym czasie, na różnych węzłach to tak czy siak: a) chcę wiedzieć który jest poprawny (zwykle pierwszy), b) chcę wiedzieć to przy zapisie żeby móc ew. zwrócić błąd . To niestety nie jest możliwe przy rozproszonym systemie.

[m.....q]

@Kiro: No to jak ID pochodzi z zewnatrz to kontroluj to na zewnatrz. W RDBMS to najczesciej kontroluje baza i mozesz sobie to tak zdefiniowac na wszystkich nodach ze sie nigdy nei powtorzy. Tak to dziala w MySQL, podobnie to dziala w sekwencjach na nodach Oracle RAC.

Jesli to takie kluczowe a klucze nei musza isc dokladnie po kolei moga byc tam dziury, to moze warto na oddzielnej maszynie postawic

[Kiro]

@msq: Zewnętrzne źródło == niezależne ode mnie. Przykładowo dane od użytkownika które mogą zostać wysłane z różnych miejsc w tym samym czasie i zapisane równocześnie na 2 różnych nodach, bo w żadnym przypadku nie będę miał informacji czy w innym miejscu właśnie coś takiego się nie zapisuje..

[m.....q]

@Kiro: No wlasnie dlatego pisze ze dobrze by bylo miec jedno miejsce wydajace takie tickety ktore zapewni Ci ich unikalnosc. W przeciwnym razie masz duzy problem i moim zdaniem nie ma innego sposobu na jego wyeliminowanie. Jesli masz jakikolwiek klusterowy system skladowania danych gdzie jest mozliwosc duplikowania kluczy w sytuacji kiedy nie bardzo sie tego spodziewasz lub tez postrzegasz to jako blad - to gdzies jest problem i to chyba

[Kiro]

@msq: No to jest główna (jedyna) używana baza, niestety, mimo że to by dużo rozwiązało, nie mogę mieć jednego miejsca do walenia w bazę, ostatecznie będzie wiele instancji aplikacji na paru serwerach. Może nie koniecznie błąd - po prostu, jak wcześniej wspominałem, w naszym przypadku postawiono na bezpieczeństwo i wydajność, a pozostałe kwestie takie jak właśnie unikalność są do rozwiązania przez nas :) A problemem jest to że potrzebujemy i

[m.....q]

@Kiro: Ok, a masz jakikolwiek wplyw na to jak klucze sa generowane? I czy sa to klucze numeryczne?

[Kiro]

@msq: Adresy e-mail podawane przez użytkowników. Jest kilka rzadkich przypadków kiedy request może walnąć 2 razy w tym samym czasie w różne miejsca i stworzyć obiekt z tym samym kluczem i nie mam na to wpływu.

[m.....q]

@Kiro: To masz problem. Jesli nie masz na to wplywu i nie mozesz wymusic unikalnosci na poziomie bazy to nie mam pojecia jak chcesz / mozesz to rozwiazac. Ale jak cos wykminisz - daj znac, bom ciekaw.

We wszystkich tego rodzaju przypadkach konczylo sie na przewartosciowaniu zalozen, bo okazywalo sie ze lacznie tworza warunki nei do spelnienia.

Jak

[Kiro]

@msq: Wiem, dlatego się musiałem aż wyżalić :) Osobiście (chociaż jeszcze młody jestem) uważam że tego typu bazy nadają się raczej do cache, zbierania logów i jakichś danych, niż jako jedyna baza w funkcjonalnej aplikacji. Wymyślić już nic nie wymyślę, skończy się na tym że większość przypadków będzie obsługiwana w rl time, a te kilka bardzo rzadkich których się nie da będą musiały się rozwiązać jakoś w tle.