Thorsten am 12. August 2026 um 14:38 Uhr

2026-08-12T14:38:17Z

← Nächstältere Version		Version vom 12. August 2026, 14:38 Uhr
Zeile 1:		Zeile 1:
			Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).

	== Wissensspeicherung ==		== Wissensspeicherung ==

Zeile 282:		Zeile 284:
	[[Kategorie:Rust]]		[[Kategorie:Rust]]
	[[Kategorie:Datenspeicherung]]		[[Kategorie:Datenspeicherung]]
			==Hinweis==
			Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).

Thorsten: Die Seite wurde neu angelegt: „== Wissensspeicherung == Dieser Artikel beschreibt zunächst das allgemeine Konzept der Wissensspeicherung und geht anschließend auf die konkrete technische Umsetzung in Rust ein. == Allgemeines Konzept der Wissensspeicherung == Bevor man eine konkrete Technik wählt, lohnt sich der Blick auf das allgemeine Konzept: Wie wird aus rohen Daten überhaupt "Wissen", und wie wird dieses Wissen in einem System organisiert und gespeichert? === Von Daten zu W…“

2026-08-12T14:32:58Z

Die Seite wurde neu angelegt: „== Wissensspeicherung == Dieser Artikel beschreibt zunächst das allgemeine Konzept der Wissensspeicherung und geht anschließend auf die konkrete technische Umsetzung in Rust ein. == Allgemeines Konzept der Wissensspeicherung == Bevor man eine konkrete Technik wählt, lohnt sich der Blick auf das allgemeine Konzept: Wie wird aus rohen Daten überhaupt "Wissen", und wie wird dieses Wissen in einem System organisiert und gespeichert? === Von Daten zu W…“

Neue Seite

== Wissensspeicherung ==

Dieser Artikel beschreibt zunächst das allgemeine Konzept der Wissensspeicherung und geht anschließend auf die konkrete technische Umsetzung in Rust ein.

== Allgemeines Konzept der Wissensspeicherung ==

Bevor man eine konkrete Technik wählt, lohnt sich der Blick auf das allgemeine Konzept: Wie wird aus rohen Daten überhaupt "Wissen", und wie wird dieses Wissen in einem System organisiert und gespeichert?

=== Von Daten zu Wissen: die DIKW-Hierarchie ===

Ein verbreitetes Modell zur Einordnung ist die '''DIKW-Pyramide''' (Data – Information – Knowledge – Wisdom):

{| class="wikitable"
! Stufe !! Beschreibung !! Beispiel
|-
| '''Daten''' (Data) || rohe, unverarbeitete Symbole/Werte ohne Kontext || <code>23</code>
|-
| '''Information''' || Daten mit Kontext/Bedeutung || "Die Temperatur beträgt 23 °C"
|-
| '''Wissen''' (Knowledge) || Information verknüpft mit Erfahrung/Regeln, nutzbar für Entscheidungen || "Bei 23 °C sollte man nicht heizen"
|-
| '''Weisheit''' (Wisdom) || begründete Anwendung von Wissen im Kontext || "Wann sich Heizen trotzdem lohnt"
|}

Ein Wissensspeicher (Knowledge Store) zielt darauf ab, mindestens die Ebene "Wissen" abzubilden – also nicht nur Rohwerte, sondern auch deren Bedeutung, Kontext und Beziehungen untereinander.

=== Explizites vs. implizites Wissen ===

* '''Explizites Wissen''' – lässt sich klar formulieren, dokumentieren und speichern (Texte, Regeln, Datenbankeinträge, Diagramme).
* '''Implizites/Tacit Wissen''' – erfahrungsbasiertes Wissen, das schwer zu formalisieren ist (Intuition, Handlungswissen).

Wissenssysteme können nur explizites Wissen direkt speichern; implizites Wissen muss zuerst "externalisiert" werden (z. B. durch Dokumentation, Interviews, Modellierung), bevor es in ein System aufgenommen werden kann. Dieser Prozess wird oft mit dem '''SECI-Modell''' (Sozialisierung, Externalisierung, Kombination, Internalisierung) beschrieben.

=== Formen der Wissensrepräsentation ===

Damit Wissen maschinell gespeichert und verarbeitet werden kann, muss es in eine Repräsentationsform gebracht werden:

{| class="wikitable"
! Repräsentationsform !! Prinzip !! Typische Systeme
|-
| Unstrukturierter Text || freier Text, Volltextsuche || Wikis, Dokumentenablagen, CMS
|-
| Strukturierte Datensätze || feste Felder/Schema || relationale Datenbanken, Tabellen
|-
| Schlüssel-Wert-Paare || einfache Zuordnung Key → Wert || Key-Value-Stores, Caches
|-
| Graphen/Netze || Entitäten + Beziehungen || Knowledge Graphs, Ontologien (RDF, OWL)
|-
| Regeln/Logik || Wenn-Dann-Regeln, Fakten || Expertensysteme, regelbasierte Systeme
|-
| Vektoren/Embeddings || semantische Nähe im Vektorraum || Vektordatenbanken, KI-/RAG-Systeme
|}

In der Praxis kombinieren viele Systeme mehrere Formen, z. B. ein Wiki (Text) mit Kategorien und Verlinkungen (graphartige Struktur) und einer Volltextsuche (Index).

=== Aufbau eines Wissenssystems (Knowledge System) ===

Ein typisches Wissenssystem durchläuft folgenden Lebenszyklus:

# '''Erfassen''' (Capture) – Wissen aus Quellen (Personen, Dokumenten, Messwerten) aufnehmen
# '''Strukturieren''' (Organize) – Kategorisieren, Verschlagworten, in ein Schema/Modell bringen
# '''Speichern''' (Store) – dauerhafte Ablage in Datei, Datenbank oder Graph
# '''Abrufen''' (Retrieve) – Suche, Abfragen, Navigation, Vernetzung mit anderem Wissen
# '''Pflegen/Aktualisieren''' (Maintain) – Widersprüche auflösen, veraltetes Wissen korrigieren oder entfernen
# '''Weitergeben''' (Share) – Zugriff für andere Personen/Systeme ermöglichen

Klassische Beispiele für Wissenssysteme sind Wikis (wie dieses hier), Knowledge Bases im Support-Kontext, Ontologien/Knowledge Graphs (z. B. Wikidata), Dokumentenmanagementsysteme sowie – im technischen Umfeld – Programme, die Wissen in Datenstrukturen abbilden und mittels der im Folgenden beschriebenen Techniken persistieren.

=== Bezug zur technischen Umsetzung ===

Die im nächsten Abschnitt beschriebenen Rust-Techniken (Structs, serde, Dateien, Key-Value-Stores, Datenbanken) sind die '''technische Speicherschicht''' für die oben genannte Stufe "Speichern". Welche Repräsentationsform (Tabelle, Key-Value, Graph, Text) gewählt wird, bestimmt dabei maßgeblich, welche Rust-Bibliothek/Datenbank sinnvoll ist:

* Strukturierte Datensätze mit Beziehungen → relationale Datenbank (rusqlite, sqlx, diesel)
* Einfache Schlüssel-Wert-Zuordnungen → Key-Value-Store (sled, redb)
* Einzelne Dokumente/Konfiguration → Datei + serde (JSON/TOML/YAML)
* Vernetztes Wissen (Graph) → Graphdatenbank-Anbindung oder eigene Graphstruktur mit Adjazenzlisten

== Wissensspeicherung in Rust ==

Dieser Abschnitt beschreibt die gängigen Methoden, um Daten ("Wissen") in Rust-Programmen dauerhaft zu speichern und wieder zu laden – von einfachen Dateien bis zu vollwertigen Datenbanken.

=== Überblick ===

In Rust gibt es keine "eingebaute" Persistenzschicht wie in manchen anderen Sprachen. Stattdessen kombiniert man:

# eine '''Datenstruktur''' im Speicher (<code>struct</code>, <code>enum</code>, <code>HashMap</code>, …)
# eine '''Serialisierungsbibliothek''', die diese Struktur in ein Speicherformat umwandelt (meist [https://serde.rs serde])
# ein '''Speicherziel''': Datei, Key-Value-Store oder relationale/eingebettete Datenbank

Die Wahl hängt davon ab, wie groß die Datenmenge ist, ob nebenläufiger Zugriff nötig ist und ob Abfragen (Queries) oder nur einfaches Laden/Speichern gebraucht werden.

=== 1. Daten im Arbeitsspeicher modellieren ===

Der erste Schritt ist immer, das "Wissen" als Rust-Typen zu modellieren:

<pre>
struct Notiz {
id: u32,
titel: String,
inhalt: String,
tags: Vec<String>,
}
</pre>

Solche Structs sind die Grundlage für alle folgenden Speichermethoden.

=== 2. Serialisierung mit serde ===

Die Standardlösung in Rust ist die Crate '''serde''' ("SERialize/DEserialize") zusammen mit einem Format wie <code>serde_json</code>, <code>serde_yaml</code>, <code>toml</code> oder <code>bincode</code>.

'''Cargo.toml:'''
<pre>
[dependencies]
serde = { version = "1", features = ["derive"] }
serde_json = "1"
</pre>

'''Struct annotieren:'''
<pre>
#[derive(serde::Serialize, serde::Deserialize)]
struct Notiz {
id: u32,
titel: String,
inhalt: String,
}
</pre>

'''Speichern (Serialisieren) in eine Datei:'''
<pre>
use std::fs;

fn speichern(notiz: &Notiz) -> std::io::Result<()> {
let json = serde_json::to_string_pretty(notiz).unwrap();
fs::write("notiz.json", json)
}
</pre>

'''Laden (Deserialisieren):'''
<pre>
fn laden() -> std::io::Result<Notiz> {
let text = fs::read_to_string("notiz.json")?;
let notiz: Notiz = serde_json::from_str(&text).unwrap();
Ok(notiz)
}
</pre>

==== Gängige Formate mit serde ====

{| class="wikitable"
! Format !! Crate !! Vorteil !! Einsatz
|-
| JSON || <code>serde_json</code> || menschenlesbar, weit verbreitet || Konfiguration, APIs, Austauschformate
|-
| TOML || <code>toml</code> || sehr gut lesbar, für Configs gedacht || Konfigurationsdateien
|-
| YAML || <code>serde_yaml</code> || kompakt, lesbar || Konfiguration
|-
| Bincode || <code>bincode</code> || binär, sehr schnell, kompakt || interne Persistenz, Caches
|-
| MessagePack || <code>rmp-serde</code> || binär, kompakt, sprachübergreifend || Netzwerk, Interop
|-
| CSV || <code>csv</code> (+ serde) || tabellarisch || Tabellen, Datenexport
|}

=== 3. Reine Datei-I/O ohne serde ===

Für sehr einfache Fälle genügt <code>std::fs</code> direkt, z. B. um Text- oder Binärdaten zu schreiben:

<pre>
use std::fs::File;
use std::io::Write;

fn schreiben() -> std::io::Result<()> {
let mut datei = File::create("wissen.txt")?;
datei.write_all(b"Wichtige Information")?;
Ok(())
}
</pre>

Für strukturierte Binärdaten kann <code>std::io::Read</code>/<code>Write</code> zusammen mit Byte-Konvertierungen (<code>to_le_bytes</code>, <code>from_le_bytes</code>) genutzt werden – das ist aber meist unnötig, da <code>bincode</code> diese Arbeit übernimmt.

=== 4. Eingebettete Key-Value-Datenbanken ===

Wenn Daten häufig aktualisiert werden und nicht die ganze Datei neu geschrieben werden soll, eignen sich eingebettete Datenbanken:

* '''sled''' – reine Rust-Implementierung, transaktional, sehr einfache API
* '''rocksdb''' (Bindings zu Facebooks RocksDB) – sehr performant, C++-Unterbau
* '''redb''' – reine Rust-Implementierung, ACID, embedded

Beispiel mit '''sled''':
<pre>
let db = sled::open("meine_datenbank")?;
db.insert(b"schluessel", b"wert")?;
let wert = db.get(b"schluessel")?;
db.flush()?;
</pre>

Kombiniert man <code>sled</code> mit <code>serde</code>/<code>bincode</code>, lassen sich ganze Structs unter einem Schlüssel speichern:
<pre>
let bytes = bincode::serialize(&notiz).unwrap();
db.insert(notiz.id.to_be_bytes(), bytes)?;
</pre>

=== 5. Relationale Datenbanken ===

Für komplexes "Wissen" mit Beziehungen, Abfragen und mehreren Nutzern bieten sich klassische SQL-Datenbanken an.

==== SQLite (lokal, dateibasiert) ====

Crate: <code>rusqlite</code>
<pre>
let conn = rusqlite::Connection::open("wissen.db")?;
conn.execute(
"CREATE TABLE IF NOT EXISTS notiz (
id INTEGER PRIMARY KEY,
titel TEXT NOT NULL,
inhalt TEXT NOT NULL
)",
[],
)?;
conn.execute(
"INSERT INTO notiz (titel, inhalt) VALUES (?1, ?2)",
rusqlite::params!["Titel", "Inhalt"],
)?;
</pre>

==== sqlx (async, mehrere Datenbanken) ====

<code>sqlx</code> unterstützt PostgreSQL, MySQL und SQLite mit asynchronem Zugriff und prüft SQL-Abfragen teils schon zur Kompilierzeit:
<pre>
let pool = sqlx::SqlitePool::connect("sqlite://wissen.db").await?;
sqlx::query("INSERT INTO notiz (titel, inhalt) VALUES (?, ?)")
.bind("Titel")
.bind("Inhalt")
.execute(&pool)
.await?;
</pre>

==== diesel (ORM) ====

<code>diesel</code> ist ein vollwertiges, synchrones ORM mit Migrationstooling und typsicheren Query-Buildern – geeignet für größere Anwendungen mit stabilem Schema.

=== 6. Auswahlkriterien ===

{| class="wikitable"
! Anforderung !! Empfehlung
|-
| Einfache Konfiguration || TOML-Datei + serde
|-
| Ein einzelnes Objekt/Dokument || JSON-Datei + serde_json
|-
| Viele kleine Schreibzugriffe, kein SQL nötig || sled / redb (Key-Value)
|-
| Abfragen, Beziehungen, mehrere Tabellen || SQLite via rusqlite/sqlx, ggf. diesel
|-
| Netzwerk-Datenbank, mehrere Clients || PostgreSQL/MySQL via sqlx oder diesel
|-
| Maximale Geschwindigkeit, keine Lesbarkeit nötig || bincode + Datei oder Key-Value-Store
|}

=== 7. Fehlerbehandlung ===

Alle I/O- und Datenbankoperationen in Rust liefern <code>Result</code> zurück. Für Anwendungen empfiehlt sich eine zentrale Fehlerbehandlung, z. B. mit den Crates '''thiserror''' (für eigene Fehlertypen) oder '''anyhow''' (für einfache Fehlerweitergabe):

<pre>
fn laden() -> anyhow::Result<Notiz> {
let text = std::fs::read_to_string("notiz.json")?;
let notiz = serde_json::from_str(&text)?;
Ok(notiz)
}
</pre>

=== 8. Zusammenfassung ===

* Datenstrukturen mit <code>struct</code>/<code>enum</code> modellieren.
* Mit '''serde''' in ein passendes Format serialisieren (JSON/TOML/YAML für Lesbarkeit, bincode für Performance).
* Für einfache Fälle reichen Dateien (<code>std::fs</code>).
* Für häufige Änderungen: eingebettete Key-Value-Stores wie '''sled''' oder '''redb'''.
* Für komplexe Abfragen und Beziehungen: relationale Datenbanken über '''rusqlite''', '''sqlx''' oder '''diesel'''.
* Fehlerbehandlung zentral mit '''anyhow'''/'''thiserror''' organisieren.

[[Kategorie:Rust]]
[[Kategorie:Datenspeicherung]]

Speicherung - Versionsgeschichte

Thorsten am 12. August 2026 um 14:38 Uhr