MongoDB vs RDBMS DBA Pflichten

Was sind die Unterschiede zwischen den täglichen Aufgaben eines Mongo DBA im Vergleich zu einem RDBMS DBA?

Einige Websites behaupten beispielsweise, dass ein MongoDB-DBA keine Datenmodellierung oder das Entwerfen der Datenbank durchführen müsste, wie dies von einem Entwickler oder Anwendungsdesigner durchgeführt würde.

Dies würde bedeuten, dass einige Aufgaben für MongoDB-Administrationen nicht mehr ausgeführt werden müssen, was früher von den RDBMS-Datenbankadministratoren ausgeführt wurde.

Welche anderen Aufgaben wären erforderlich, die normalerweise nicht im Zeitplan eines RDBMS-Datenbankadministrators enthalten sind? Und auch die Aufgabe, die die RDBMS-Datenbankadministratoren früher ausgeführt haben, aber nicht mehr im Zeitplan von MongoDB-Datenbankadministratoren enthalten sind?

Ich bin neu in der MongoDB-Administration, daher versuche ich, diese Aufgabe zu identifizieren, damit ich nicht den Fehler begehen kann, Dinge in meiner täglichen Aufgabe zu tun, die nicht benötigt werden, oder etwas vermisse, das ich brauche.

Können mir erfahrene MongoDB-Datenbankadministratoren helfen, damit ich bei meiner Arbeit keine dummen Fehler mache?

Ich bin seit 3 ​​Jahren im NoSQL-Bereich.
Als MongoDB-DBA müssen Sie eng mit den Entwicklungs- und Ops-Teams zusammenarbeiten. Im Folgenden finden Sie die Dinge, die Sie als MongoDB-DBA als tägliche Aufgaben erledigen müssen. Die Rolle kann grob in drei Teile unterteilt werden:

1. Verwaltung:

   • Neue Bereitstellungen (manuell / automatisiert)
   • Bereitstellungsdesign Ihrer Datenbanksysteme
   • Überwachung
   • Backups & Wiederherstellung
   • Sicherheit
   • Best Practices für DB Health

2. Entwicklung:

   • Sie müssen Code / Skripte schreiben, die regelmäßig / einmal auf Ihren Daten ausgeführt werden. Dies kann erforderlich sein, um Berichte und Analysen zu erstellen.
   • Debuggen von Application-DB-Problemen mit Entwicklungsteams
   • Verfügbarkeit, Skalierbarkeit und Sicherheit von der App-Seite aus implementieren
   • Abfragen der Datenbank zu Staging und Produktion bei Bedarf
   • Indizierungsstrategien vorschlagen und umsetzen
   • Sie sind am Datenbankdesign und an der Modellierung beteiligt

3. Leistungsoptimierung:

   • Dies erfordert eine kontinuierliche Messung der Leistung Ihrer Datenbank mithilfe von Tools
   • Erstellen Sie Indizes oder Shard-Datenbanken basierend auf den Anforderungen
   • Melden Sie die Datenbankleistung dem Entwicklerteam

DBA ist ein kleines Akronym, aber eine große Rolle. Zu verschiedenen Zeiten habe ich einen DBA gesehen, der sich um mich kümmert

• Lager
• Netzwerk
• VMs
• Knoten berechnen
• Installation und Konfiguration der oben genannten
• Backups und Testwiederherstellungen
• DR-Strategie
• Integrität von Unternehmensdaten
• ETL
• Datensicherheit
• Datenmodellierung, Normalisierung und Datenbankdesign
• Datenebenenprogrammierung
• Leistungsoptimierung
• betriebliche Verfügbarkeit
• Reproduzieren
• Failover
• Support auf Abruf

.. und andere außerdem. Ich kann nichts davon verschwinden sehen, nur weil Oracle / SQL Server / PostgreSQL durch MongoDB / Cassandra / CouchDB ersetzt wird.

"Oh", aber Sie sagen, "es gibt kein Schema. Ich muss diese Modellierungs- und Design-Sache nicht machen."

"Du bist getäuscht", würde ich antworten. Wenn das System beispielsweise für die Auftragsabwicklung vorgesehen ist (und nicht für die Auftragsabwicklung und Schokoladenkuchenrezepte sowie für die Katalogisierung von Selfies usw.) und The Business Bestellungen durch eine 7-stellige ganzzahlige Bestellnummer unterscheidet und jede Bestellung aus einer oder mehreren Bestellpositionen besteht (mit jeweils einem Produkt), dann haben Sie ein Schema. Nur weil es in der Anwendungsschicht und nicht im DBMS erzwungen wird, verschwindet es nicht. Und jemandSchreiben Sie diese Regeln besser auf, bestätigen Sie sie mit den Benutzern, teilen Sie sie dem Testteam mit, bringen Sie neu eingestellten Mitarbeitern bei, was sie sind, und bringen Sie sie in die Endbenutzerdokumentation ein, um sicherzustellen, dass alte Daten weiterhin verfügbar sind von der gerade geänderten Anwendung gelesen. Nur weil die Regeln nur im Anwendungscode und nicht im Anwendungscode und im DBMS-Skript geändert werden können, ist nichts davon weniger wichtig.

Für meine zwei Cent, glaube ich nicht, dass diese Klasse von Software trotz ihrer vielen, vielen Vorteile jede bedeutende Aufgabe beseitigt, die traditionell von einem DBA in der RDBMS-Welt erledigt wird. Es kann sie auf Personen mit anderen Berufsbezeichnungen umverteilen, und die Aufgaben können einfacher auszuführen oder weniger aufdringlich für den SDLC sein.

Beim Hinzufügen von Aufgaben besteht das Problem, die Kompatibilität mit alten Daten aufrechtzuerhalten, die gemäß einem früheren Verständnis der Geschäftsregeln geschrieben wurden. Ein RDBMS hätte dieses Problem nicht, da es zu jedem Zeitpunkt nur ein akzeptables Schema gibt.