5c03e07ded
Simpler story (slide decks unread -> three-bullet status email), proper Claude-chat look with avatars and bubbles on both sides. Canonical trigger prompt switched to English everywhere (homepage, architecture, both adapter generators rebuilt) - V7 consistency green, all checks pass. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PDKeXvpT6tENSvyQGLV1Uq
2.7 KiB
esco_uri, esco_label, relation, onet_soc, source, confidence, qa_count, generator, generated
| esco_uri | esco_label | relation | onet_soc | source | confidence | qa_count | generator | generated |
|---|---|---|---|---|---|---|---|---|
| http://data.europa.eu/esco/skill/897b393f-e7e0-4248-a40d-d77119694e83 | distributed computing | essential | 15-1242.00 | model-knowledge | high | 0 | gemma3:27b (prompt-designed and spot-checked by Claude) | 2026-07-10 |
distributed computing — Database Administrator
As a Database Administrator, 'distributed computing' isn’t about writing distributed systems – it’s about managing them. Increasingly, databases aren't monolithic servers; they're clusters of nodes (think Oracle RAC, SQL Server Always On Availability Groups, PostgreSQL with streaming replication, or cloud-native solutions like Amazon Aurora/DynamoDB). Your daily tasks involve monitoring the health and performance of these distributed database instances, ensuring data consistency across those instances, and managing failover scenarios. This means understanding concepts like two-phase commit, consensus algorithms (even if you don't implement them!), and how network latency impacts transaction times.
Typical tools shift from single-server monitoring to cluster-aware solutions: things like Prometheus/Grafana with custom exporters for database metrics, specialized RAC/AG monitoring tools, or cloud provider dashboards. You’ll be troubleshooting replication lag, identifying slow nodes impacting overall performance, and diagnosing network issues that cause data inconsistencies. Pitfalls include assuming a single server's diagnostic approach will work on a distributed system – you need to consider the entire cluster state. Also, complex configurations can easily lead to split-brain scenarios or incorrect failover behavior if not carefully planned and tested.
Good looks like proactively identifying potential issues before they impact users. This means setting up robust alerting based on cross-node metrics (e.g., replication lag exceeding a threshold on multiple nodes), automating routine maintenance tasks across the cluster, and having well-documented disaster recovery plans that account for network partitions or node failures. It also involves understanding how your database’s distributed architecture impacts application design – advising developers on best practices for data access patterns to minimize cross-node communication.
Finally, 'distributed computing' competence extends to related technologies like caching layers (Redis, Memcached) often deployed alongside databases to improve performance and scalability. DBAs need to understand how these systems interact with the database cluster and ensure data consistency between them.
Weitere Anreicherung
Stage-2 source for future practitioner grounding: arXiv cs.SE (software-engineering preprints).