[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-deep-evm-26-sharding-vs-partitionierung-massive-tabellen":3},{"article":4,"author":59},{"id":5,"category_id":6,"title":7,"slug":8,"excerpt":9,"content_md":10,"content_html":11,"locale":12,"author_id":13,"published":14,"published_at":15,"meta_title":16,"meta_description":17,"focus_keyword":18,"og_image":19,"canonical_url":19,"robots_meta":20,"created_at":15,"updated_at":15,"tags":21,"category_name":24,"related_articles":39},"d7000000-0000-0000-0000-000000000126","a0000000-0000-0000-0000-000000000075","Deep EVM #26: Sharding vs. Partitionierung — Architektur fuer massive Tabellen","deep-evm-26-sharding-vs-partitionierung-massive-tabellen","Datenbank-Sharding und Partitionierungsstrategien fuer horizontale Skalierung vergleichen. Consistent Hashing, Cross-Shard-Abfragen, Resharding und wann welchen Ansatz waehlen.","## Partitionierung vs. Sharding: Was ist der Unterschied?\n\nBeide teilen Daten in kleinere Stuecke, arbeiten aber auf unterschiedlichen Ebenen:\n\n- **Partitionierung:** Teilt eine Tabelle auf demselben Datenbankserver\n- **Sharding:** Verteilt Daten auf mehrere Server\n\nPartitionierung skaliert vertikal (mehr CPU\u002FRAM), Sharding skaliert horizontal (mehr Server).\n\n## Wann Partitionierung reicht\n\n- Tabelle \u003C 1 Milliarde Zeilen\n- Einzelner Server hat genug CPU\u002FRAM\n- Abfragen betreffen typischerweise einen Bereich (z.B. letzte 24 Stunden)\n- VACUUM wird durch kleinere Partitionen schneller\n\n## Wann Sharding notwendig wird\n\n- Tabelle > 1 Milliarde Zeilen\n- Schreiblast uebersteigt die Kapazitaet eines einzelnen Servers\n- Geographische Verteilung erforderlich\n- Leselast erfordert Parallelisierung ueber Server\n\n## Consistent Hashing\n\nBeim Sharding muessen Sie entscheiden, welche Daten auf welchem Shard landen. Consistent Hashing minimiert die Datenbewegung beim Hinzufuegen neuer Shards:\n\n```rust\nuse std::collections::BTreeMap;\nuse sha2::{Sha256, Digest};\n\nstruct ConsistentHashRing {\n    ring: BTreeMap\u003Cu64, ShardId>,\n    virtual_nodes: usize,\n}\n\nimpl ConsistentHashRing {\n    fn get_shard(&self, key: &[u8]) -> ShardId {\n        let hash = self.hash(key);\n        \u002F\u002F Finde den naechsten Knoten im Ring\n        self.ring.range(hash..)\n            .next()\n            .or_else(|| self.ring.iter().next())\n            .map(|(_, shard)| *shard)\n            .unwrap()\n    }\n}\n```\n\n## Cross-Shard-Abfragen\n\nDas groesste Problem beim Sharding: Abfragen, die Daten von mehreren Shards benoetigen.\n\nStrategien:\n1. **Scatter-Gather:** Abfrage an alle Shards senden, Ergebnisse zusammenfuehren\n2. **Shard-Key-Design:** So waehlen, dass haeufige Abfragen nur einen Shard treffen\n3. **Denormalisierung:** Haeufig abgefragte Daten auf allen Shards replizieren\n\n## Resharding\n\nWenn Sie neue Shards hinzufuegen muessen:\n\n1. Neue Shards bereitstellen\n2. Hash-Ring aktualisieren\n3. Daten von alten zu neuen Shards migrieren (im Hintergrund)\n4. Dual-Write waehrend der Migration\n5. Alte Daten nach Abschluss bereinigen\n\n## Fazit\n\nPartitionierung und Sharding sind komplementaere Strategien. Beginnen Sie mit Partitionierung — sie ist einfacher und oft ausreichend. Wechseln Sie zu Sharding, wenn ein einzelner Server nicht mehr ausreicht. Der Schluessel: Waehlen Sie Ihren Shard-Key sorgfaeltig, denn er bestimmt die Leistung aller zukuenftigen Abfragen.","\u003Ch2 id=\"partitionierung-vs-sharding-was-ist-der-unterschied\">Partitionierung vs. Sharding: Was ist der Unterschied?\u003C\u002Fh2>\n\u003Cp>Beide teilen Daten in kleinere Stuecke, arbeiten aber auf unterschiedlichen Ebenen:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Partitionierung:\u003C\u002Fstrong> Teilt eine Tabelle auf demselben Datenbankserver\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Sharding:\u003C\u002Fstrong> Verteilt Daten auf mehrere Server\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Partitionierung skaliert vertikal (mehr CPU\u002FRAM), Sharding skaliert horizontal (mehr Server).\u003C\u002Fp>\n\u003Ch2 id=\"wann-partitionierung-reicht\">Wann Partitionierung reicht\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>Tabelle < 1 Milliarde Zeilen\u003C\u002Fli>\n\u003Cli>Einzelner Server hat genug CPU\u002FRAM\u003C\u002Fli>\n\u003Cli>Abfragen betreffen typischerweise einen Bereich (z.B. letzte 24 Stunden)\u003C\u002Fli>\n\u003Cli>VACUUM wird durch kleinere Partitionen schneller\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"wann-sharding-notwendig-wird\">Wann Sharding notwendig wird\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>Tabelle > 1 Milliarde Zeilen\u003C\u002Fli>\n\u003Cli>Schreiblast uebersteigt die Kapazitaet eines einzelnen Servers\u003C\u002Fli>\n\u003Cli>Geographische Verteilung erforderlich\u003C\u002Fli>\n\u003Cli>Leselast erfordert Parallelisierung ueber Server\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"consistent-hashing\">Consistent Hashing\u003C\u002Fh2>\n\u003Cp>Beim Sharding muessen Sie entscheiden, welche Daten auf welchem Shard landen. Consistent Hashing minimiert die Datenbewegung beim Hinzufuegen neuer Shards:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-rust\">use std::collections::BTreeMap;\nuse sha2::{Sha256, Digest};\n\nstruct ConsistentHashRing {\n    ring: BTreeMap<u64, ShardId>,\n    virtual_nodes: usize,\n}\n\nimpl ConsistentHashRing {\n    fn get_shard(&self, key: &[u8]) -> ShardId {\n        let hash = self.hash(key);\n        \u002F\u002F Finde den naechsten Knoten im Ring\n        self.ring.range(hash..)\n            .next()\n            .or_else(|| self.ring.iter().next())\n            .map(|(_, shard)| *shard)\n            .unwrap()\n    }\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"cross-shard-abfragen\">Cross-Shard-Abfragen\u003C\u002Fh2>\n\u003Cp>Das groesste Problem beim Sharding: Abfragen, die Daten von mehreren Shards benoetigen.\u003C\u002Fp>\n\u003Cp>Strategien:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>Scatter-Gather:\u003C\u002Fstrong> Abfrage an alle Shards senden, Ergebnisse zusammenfuehren\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Shard-Key-Design:\u003C\u002Fstrong> So waehlen, dass haeufige Abfragen nur einen Shard treffen\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Denormalisierung:\u003C\u002Fstrong> Haeufig abgefragte Daten auf allen Shards replizieren\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch2 id=\"resharding\">Resharding\u003C\u002Fh2>\n\u003Cp>Wenn Sie neue Shards hinzufuegen muessen:\u003C\u002Fp>\n\u003Col>\n\u003Cli>Neue Shards bereitstellen\u003C\u002Fli>\n\u003Cli>Hash-Ring aktualisieren\u003C\u002Fli>\n\u003Cli>Daten von alten zu neuen Shards migrieren (im Hintergrund)\u003C\u002Fli>\n\u003Cli>Dual-Write waehrend der Migration\u003C\u002Fli>\n\u003Cli>Alte Daten nach Abschluss bereinigen\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch2 id=\"fazit\">Fazit\u003C\u002Fh2>\n\u003Cp>Partitionierung und Sharding sind komplementaere Strategien. Beginnen Sie mit Partitionierung — sie ist einfacher und oft ausreichend. Wechseln Sie zu Sharding, wenn ein einzelner Server nicht mehr ausreicht. Der Schluessel: Waehlen Sie Ihren Shard-Key sorgfaeltig, denn er bestimmt die Leistung aller zukuenftigen Abfragen.\u003C\u002Fp>\n","de","b0000000-0000-0000-0000-000000000001",true,"2026-03-28T10:44:30.389872Z","Sharding vs. Partitionierung — Architektur fuer massive Tabellen","Datenbank-Sharding und Partitionierung fuer horizontale Skalierung vergleichen. Consistent Hashing, Cross-Shard-Abfragen, Resharding und PostgreSQL-native Partitionierung.","Datenbank-Sharding vs. Partitionierung",null,"index, follow",[22,27,31,35],{"id":23,"name":24,"slug":25,"created_at":26},"c0000000-0000-0000-0000-000000000012","DevOps","devops","2026-03-28T10:44:21.513630Z",{"id":28,"name":29,"slug":30,"created_at":26},"c0000000-0000-0000-0000-000000000022","Performance","performance",{"id":32,"name":33,"slug":34,"created_at":26},"c0000000-0000-0000-0000-000000000005","PostgreSQL","postgresql",{"id":36,"name":37,"slug":38,"created_at":26},"c0000000-0000-0000-0000-000000000001","Rust","rust",[40,47,53],{"id":41,"title":42,"slug":43,"excerpt":44,"locale":12,"category_name":45,"published_at":46},"d0000000-0000-0000-0000-000000000680","Warum Bali 2026 zum Impact-Tech-Hub Südostasiens wird","warum-bali-2026-impact-tech-hub-suedostasiens","Bali rangiert auf Platz 16 unter den Startup-Ökosystemen Südostasiens. Mit einer wachsenden Konzentration von Web3-Entwicklern, AI-Nachhaltigkeits-Startups und Eco-Travel-Tech-Unternehmen formt die Insel ihre Nische als Impact-Tech-Hauptstadt der Region.","Ingenieurwesen","2026-03-28T10:44:49.720230Z",{"id":48,"title":49,"slug":50,"excerpt":51,"locale":12,"category_name":45,"published_at":52},"d0000000-0000-0000-0000-000000000679","ASEAN-Datenschutz-Flickenteppich: Compliance-Checkliste für Entwickler","asean-datenschutz-flickenteppich-compliance-checkliste-entwickler","Sieben ASEAN-Länder verfügen mittlerweile über umfassende Datenschutzgesetze mit unterschiedlichen Einwilligungsmodellen, Lokalisierungsanforderungen und Sanktionsstrukturen. Eine praktische Compliance-Checkliste für Entwickler.","2026-03-28T10:44:49.715484Z",{"id":54,"title":55,"slug":56,"excerpt":57,"locale":12,"category_name":45,"published_at":58},"d0000000-0000-0000-0000-000000000678","Indonesias 29-Milliarden-Dollar-Digitaltransformation: Chancen für Softwareunternehmen","indonesias-29-milliarden-dollar-digitaltransformation-chancen-softwareunternehmen","Indonesias IT-Dienstleistungsmarkt wird voraussichtlich 2026 29,03 Milliarden Dollar erreichen, gegenüber 24,37 Milliarden im Jahr 2025. Cloud-Infrastruktur, AI, E-Commerce und Rechenzentren treiben das schnellste Wachstum in Südostasien.","2026-03-28T10:44:49.697275Z",{"id":13,"name":60,"slug":61,"bio":62,"photo_url":19,"linkedin":19,"role":63,"created_at":64,"updated_at":64},"Open Soft Team","open-soft-team","The engineering team at Open Soft, building premium software solutions from Bali, Indonesia.","Engineering Team","2026-03-28T08:31:22.226811Z"]