Mostra notizie nelle discussioni
  • Avatar
    ☺
    Scritto da
    il 2009-11-26 09:27:00.0 alle 2009-11-26 09:27:00.0
    Trollate totali: 2005
    NOSQL Patterns
    http://horicky.blogspot.com/2009/11/nosql-patterns...

    Lo metto qua, che se trovo tempo più tardi lo leggo.

    --FdT Social Bookmarking
    • Avatar
      Scritto da
      Non Autenticato
      il 2009-11-26 13:48:00.0 alle 2009-11-26 13:48:00.0
      Re: NOSQL Patterns
      - Scritto da: pentothal
      > http://horicky.blogspot.com/2009/11/nosql-patterns
      >
      > Lo metto qua, che se trovo tempo più tardi lo
      > leggo.
      >
      > --FdT Social Bookmarking

      Modello: spazzatura.
      Caratteristiche: pensi di aumentare la disponibilità ma in realtà stai sicuramente buttando la consistenza. Il teorema CAP (teorema... parolone...) va bene solo per cose tipo Google dove se un nodo fornisce informazioni inconsistenti una tantum non è un grosso problema (la prossima richiesta darà quasi certamente informazioni consistenti). Per il resto è solo una bomba ad orologeria. Speriamo lo usino in molti così ci sarà sempre lavoro per noiartri.
    • Avatar
      Scritto da
      Non Autenticato
      il 2009-11-26 13:54:00.0 alle 2009-11-26 13:54:00.0
      Re: NOSQL Patterns
      - Scritto da: pentothal
      > http://horicky.blogspot.com/2009/11/nosql-patterns
      >
      > Lo metto qua, che se trovo tempo più tardi lo
      > leggo.
      >
      > --FdT Social Bookmarking

      btw, già questa è una minchiata astronomica: "because the CAP theorem proves that you cannot get Consistency, Availability and Partitioning"

      Certo che si può avere, basta che
      - le relazioni siano frammentate e ridondate su più dbms
      - il dbms garantisca la consistenza con un protocollo opportuno (2 phase commit ad esempio)
      - il dbms garantisca la ricostruzione della relazione originale

      Quello che non si può avere insieme alle proprietà CAP sono solo delle prestazioni decenti.
      • Avatar
        ☺
        Scritto da
        avvelentani
        Cubicolario
        il 2009-11-26 17:40:00.0 alle 2009-11-26 17:40:00.0
        Trollate totali: 18184
        Re: NOSQL Patterns
        - Scritto da:
        > - Scritto da: pentothal
        > >
        > http://horicky.blogspot.com/2009/11/nosql-patterns
        > >
        > > Lo metto qua, che se trovo tempo più tardi lo
        > > leggo.
        > >
        > > --FdT Social Bookmarking
        >
        > btw, già questa è una minchiata astronomica:
        > "because the CAP theorem proves that you cannot
        > get Consistency, Availability and
        > Partitioning"
        >
        > Certo che si può avere, basta che
        > - le relazioni siano frammentate e ridondate su
        > più
        > dbms
        > - il dbms garantisca la consistenza con un
        > protocollo opportuno (2 phase commit ad
        > esempio)
        > - il dbms garantisca la ricostruzione della
        > relazione
        > originale
        >
        > Quello che non si può avere insieme alle
        > proprietà CAP sono solo delle prestazioni
        > decenti.

        Guarda che il teorema cap e` un teorema dimostrato e succede anche se replichi ogni oggetto su ogni nodo, il problema e`: cosa fai se una parte del sistema non riesce a comunicare con un'altra parte?
        puoi fare due cose:

        a) la query fallisce, hai C ma non A

        b) assumi che la parte del sistema che non risponde sia morta e ottieni A a discapito di C (perche' quella parte potrebbe essere solo temporaneamente irraggiungibile)

        se non vuoi sacrificare C o A devi eliminare la possibilita` che si creino partizioni mettendo i nodi piu` vicini possibile e usando timeout abbastanza elevati per essere sicuro che se qualcosa non risponde e` perche' e` *veramente* morto.
        questa soluzione e` un problema di suo visto che piu` i nodi sono vicini piu` e` probabile che cadano tutti assieme e mentre stai aspettando per i tuoi lunghi timeout devi accumulare il lavoro da qualche parte e quando finalmente puoi procedere il carico in eccesso (potenzialmente decine di volte piu` grande del normale) tipicamente causera` altri problemi di scalabilita` nel sistema.

        e` un tradeoff inevitabile la soluzione giusta va scelta caso per caso, ad esempio questa:

        http://guysblogspot.blogspot.com/2008/09/cap-solut...

        ha letture potenzialmente inconsistenti e scritture potenzialmente indisponibili.
        Gli rdbms risolvono in favore della consistenza a scapito di una (o entrambe) le altre proprieta` e tutti li usano semplicemente perche' fino a qualche anno fa erano praticamente l'unica cosa disponibile a meno di riscrivere tutto da zero.
        I think happiness is love
        - Vladimir Putin
<softv>

Pagina generata in 66 millisecondi

Utenti attivi: 8 nell'ultimo minuto, 25 negli ultimi cinque minuti, 63 negli ultimi 15 minuti