Please enable JavaScript.

Coggle requires JavaScript to display documents.

Database (Cassandra (Data Modeling (No Joins (Joins on Client Side,…

- - - - Scale-out - add more nodes
      - Scale-up - add more power to node
  - - - Achieve Strong Consistency
        
        Update Quorum + Reqd Quorum
        
        Update Any + Read All
        
        Update All + Read Any
      - Split replicas between different Fault Domains
      - Keep commit log and memtable on a separate disk
      - All production deployments should use the NetworkTopologyStrategy
      - Make sure a proper time synchronization process is running such as NTP
      - Using clustering keys to sort data makes retrieval of adjacent data more efficient.
      - Performing joins on the client should be a very rare case; you really want to duplicate (denormalize) the data instead.
      - Never use Cassandra as Queue
      - It is advised to prefer sets over lists when possible.
      - the goal is to design tables that can provide the data you need with queries that touch a single partition, or failing that, the minimum possible number of partitions
    - - Write operations are always sent to all replicas, regardless of consistency level. The consistency level simply controls how many responses the coordinator waits for before responding to the client.
      - Every mutation is timestamped (including deletes)
        and a Last-Write-Wins Element-Set conflict-free
        replicated data type for each CQL row is used
      - In the event of an unexpected shutdown, Cassandra can lose up to the sync period or more if the sync is delayed (periodic sync mode).
      - The more tokens you have, the higher the probability of an outage
      - The design of the primary key is extremely important, as it will determine how much data will be stored in each partition and how that data is organized on disk, which in turn will affect how quickly Cassandra processes reads.
      - think not only how the data is written, but also in terms of how the data will be queried by downstream use cases.
      - All updates for an INSERT are applied atomically and in isolation.
      - In an UPDATE statement, all updates within the same partition key are applied atomically and in isolation.
      - You're not allowed to update the value of any column that's in the primary key.
    - - Running “nodetool drain” before stopping Cassandra will write everything in the memtables to SSTables and remove the need to sync with the commitlogs on startup.
      - A general guideline is to keep number of values per partition to below 100,000 and disk space per partition to below 100MB.
  - - - Commit Log: append-only log file persisted on hard drive
      - Memtable: in-memory data structure to buffer mutations
      - SSTable: immutable data file persisted on hard drive
  - - - Joins on Client Side
      - Denormalized tables
    - - LWT (light-weight-transactions)
      - Cascading deletes are not available
    - - It is important to keep related columns defined together in the same table.
      - A key goal is to minimize the number of partitions that must be searched in order to satisfy a given query
    - - The sort order available on queries is fixed
- - - - Strict consistency
        
        For distributed systems: R+W>N
      - Eventual consistency