BDT

Pro:

• Kleine Daten

• Gut wenn selten Updates

• Eventuell consistency ist akzeptabel

• Fast read

• Gut bei OLAP

Con:

• Verschachtelung

• Unnesten von zb. Arrays

• Update Annomalien

• Schlecht bei OLTP

• Redundanz

Pro:

• Gut bei OLTP

• Flüchtige Daten (Keine Update Annomalien)

• Strong Consistency (ist nötig!)

• Muss nicht immer ganzes Dokument fetchen (kein JOIN = weniger Daten)

• Fast Writes

Con:

• JOINs teuer

• Langsam bei OLAP (JOIN)

• 
  

Up:

• Vertical

• Transparent

• Limitiert

Out:

• Horizontal

• High scalability

• Benötigt Load balancing

Pro:

• Insert/Update einfach

Con:

• Evtl unnötige Daten lesen

• Schlechter zu komprimieren (ca. 1:3)

Pro:

• Komprimierung (1:10 bis 1:30)

• Nur relevante Daten lesen

• Gut für OLAP

Con:

• Insert/Update braucht multi-access

• Read teurer bei ganzen records

Unterschied zwischen einem Software model (OOP) und dem DB model

• Unterschied object to tabel

• Hash-Maps

• B-Trees

Nested Maps

Columns Families müssen vordefiniert sein

Column kann any sein

Mehrere Versionen pro Zelle durch Timestamp möglich

Adjecency List

Bestandteile:

• Vertex (V): Nodes (Entities)

• Edge (E): Relationships (Kante)

• Properties: Attributes and Meta Data: (key, value) pairs

Übersetzt von Application über SQL zu spezifischer DB

• Standartsierung

Single kann 1 DB gleichzeitig

Multi kann mehrere gleichzeitig

=> Komplexität steigt, Konsistent muss sichergestellt werden

1. Offer only particular subset of features für ALLE Stores (intersection)

2. Particular subset of features für particular Store

3. Missing features selbst implementieren in Mapper => Performance leidet

2 und 3 können kombiniert werden

1. Map

2. (Shuffel)

3. Reduce

Einsatz: zB: ETL Prozess

platform for analyzing large data sets

PigLatin: A Data Processing Language

Pig Infrastructure: An Evaluator for PigLatin programs

Pig compiles Pig Latin into physical plans

=> Ausführung über Hadoop

1. Hive

2. Pure Hadoop SQL Engines

3. Format-agonstic SQL Engines

4. RDBMS with Hadoop access

SQL -> MapReduce für HDFS und HBase

Tabellen in Hive Metastore

Nutzt Serializer-Deserializer => Schema-on-Read

Pro: Scalable, fault tolerant, stable, easy to use

Con: Batch-oriented, slow, no transactions

Support for many data formats

Write: Daten per ETL in Relationales DBMS laden => Dann SQL darauf

Read: Daten in Hadoop laden => Dann Schema auf die Daten mappen und per SQL abfragen

Verteilte + parallele SQL Engine

Nutzt Hive Metadaten

Sitzt auf Hadoop

Kein MapReduce

Nur HDFS als Storage

Pro: Schneller als Hive, Low Latency, Pipeline + Caching, Scaleable

Con: No transactions

Verteiltes in-Memory Computing Framework

RDD (Resilient Distributed Datasets)

Not restricted to Hive meta data

Consumes a lot of memory

No transactions

Unterstützt nicht nur HDFS als Storage

Sondern auch: Hive und NoSQL

Integriere Hadoop in RDBMS

Erweitere externe Tabellen

Data processing in RBDMS or Hadoop

Con: Teuer

Data-lake

• RDBMS primary

• HDFS for big data

• Mixed analytical and transactional load

FW = Schema Creation

RV = Schema Overview, Data Exploration

Advanced RV = Schema Version Extraction

SW = Darwin

Single:

• Add

• Rename

• Delete

Multi:

• Copy (denormalization)

• Move (refactoring)

Eager Migration:

• Neues Schema => Alle Entities migrieren

Lazy Migration:

• Migrate on Request

Lazy

Eager

Incremental:

• Ist meist Eager

• Pro: Composition von Operationen möglich

• Con: Migriert unnötige Daten

Predictive:

• Forecast, which entities are accessed in the future

• Migrate these

• Con: Ggf. migration, wenn falscher Forecast

zb: Statt: copy und dann delete original => move

• Consistency

• Availability

• Partition Tolerance

PACELC

If Partition{

Availability OR Consistency

}else{

Latency OR Consistency

}

• Strong

• Weak

• Eventuall (Abwandlung von Weak)

  • System wird irgendwann konsistent

• Causal

• Read-your-writes

• Session consistency

• Monotonic reads

• Monotonic writes

• Art von Eventual Consistency

• Read = wenn Process D(k) gesehen, nie mehr älter als k

• Write = Serialize the writes of the same process

Basically available (Immer up)

Soft-state (State kann sich ändern => zb Stale)

Eventually consistent (Wird irgendwann konsistent)

atomicity, consistency, isolation, and durability

• Hash

• Range

• Entity-Group

Aufteilen von Daten über Scaled Out Data

Pro: Gleichmäßig verteilt

Con: No data locality

Range:

Pro: Range Scans und Sorting

Con: Repatitionierung und Balancing benötigt

Entity-Group:

Pro: Ermöglicht ACID Transactions

Con: Partitionierung nicht einfach änderbar

Kreis von Nodes und Keys

Daten gehen an nächste Node und übernächste für Replica

Erster Eintrag: succ(k+1)

Danach: succ(k+2^(i-1))

succ=Auflösen zu nächster Node

Synchron (Eager)

Akzeptiert weitere Writes, aber ACK erst wenn propagiert

Pro: Konsistent

Contra: Commit Protocol benötigt (Roundtrip time)

Async (Lazy)

Sofort ACK

Pro: Fast writes, keine Koodinierung nötig

Con: Daten evtl. Stale (inkonsistent / weak consistent)

W+R > N

Bei multi-master auch: W+W > N

Read optimized

Write optimized

R=W= (N/2) + 1

Static vs Dynamic:

• Für jedes Item dynamisch, anstatt N

Unweighted vs Weighted

Zero, One/Two/Three, Quorum, All

Read: Ohne Zero!

Hinted Handoff

Notiz an nearest alive Node, wenn eine Ausfällt. System kann weiterarbeiten.

Write has not propagated to all Nodes

Read-Repair

Anti-Entropy

1. System erkennt out-of-sync

2. Markieren der Nodes mit Read Repair flag

3. Sync Stale Nodes with newest Versions

• Maste-Slave

• Multi-Master (Quorum Consesus)

Vektor-Clocks

• Local Secondary Indexing

• Global Secondary Indexing

Scan Queries (Sharding)

ACID Transactions (Replication)

Joins (Techniques, Query Processing)

Filter Queries (Query Processing)

Data/Write Scalability (Sharding)

Read Scalability (Replication)

Write Throughtput (Storage Management)

Durability (Storage Management)

Read Latency (Query Processing)