Datenbanken

Migration Ihrer Oracle- und SQL Server-Datenbanken zu Google Cloud

Wed, 08 Feb 2023 04:00:00 +0000

Bevor Cloud Computing unsere Sicht auf Datenbanken und Anwendungen veränderte, waren Oracle- und Microsoft SQL Server-Datenbanken jahrzehntelang eine wichtige Basis für die Architektur von Unternehmensanwendungen. Doch heute werden Sie angesichts der gegenwärtigen Branchentrends und der enormen Möglichkeiten, die die Cloud bietet, wahrscheinlich noch einmal genau überlegen, auf welche Technologie Sie bei der Cloud-Planung setzen.

Im Datenbankbereich gehören zu diesen Trends der Wechsel zu Open-Source-Technologien (insbesondere zu MySQL, PostgreSQL und ihren Derivaten), die Einführung nicht-relationaler Datenbanken, Multi-Cloud- und Hybrid-Cloud-Strategien sowie die Notwendigkeit, global verteilte Anwendungen, die ständig online sind, zu nutzen. Dabei kann jede Anwendung andere Cloud-Anforderungen stellen – ob es sich nun um eine schnelle Lift-and-Shift-Migration, eine umfangreiche Anwendungsmodernisierung oder um eine vollständige Transformation mit einer Cloud-First-Datenbank handelt.

Google Cloud bietet eine Reihe von verwalteten Datenbankdiensten, die Open-Source-, Drittanbieter- und Cloud-First-Datenbanken unterstützen. Anlässlich der Next 2022 haben wir fünf neue Videos veröffentlicht, die sich gezielt an Oracle- und SQL Server-Kunden richten, die sich für eine Lift-and-Shift-Migration in die Cloud interessieren oder sich ganz von Lizenzierungs- und anderen Beschränkungen befreien wollen. Wir hoffen, dass Ihnen diese Videos beim Analysieren Ihrer Möglichkeiten helfen – ob Sie nun zu einer homogenen Migration (Verwendung der bisherigen Datenbank) oder zu einer heterogenen Migration (Wechsel zu einer anderen Datenbank-Engine) tendieren.

Kommen wir nun zu den fünf Videos.

#1 Ausführung von Oracle-basierten Anwendungen in der Google Cloud

Von Jagdeep Singh & Andy Colvin

Der Wechsel in die Cloud kann sich als schwierig erweisen, wenn Ihr Unternehmen auf Anwendungen angewiesen ist, die auf einer Oracle-Datenbank laufen. Anwendungen können z. B. aus Kompatibilitäts-, Lizenzierungs- und Verwaltungsgründen von Oracle abhängig sein. Informieren Sie sich über verschiedene Lösungen von Google Cloud, darunter die „Bare Metal Solution for Oracle“, eine für Oracle-Workloads zertifizierte und optimierte Hardwarelösung, sowie Lösungen von Cloud-Partnern wie VMware und Equinix. Sie erfahren, wie Sie Legacy-Workloads auf Oracle ausführen und gleichzeitig moderne Cloud-Technologien für neuere Workloads einsetzen können.

#2 SQL Server-basierte Anwendungen in Google Cloud ausführen

Von Isabella Lubin

Microsoft SQL Server ist nach wie vor ein weit verbreitetes kommerzielles Datenbankmanagementsystem. Informieren Sie sich darüber, wie Sie SQL Server mit Cloud SQL, einem vollständig verwalteten Datenbankdienst für die Ausführung von MySQL-, PostgreSQL- und SQL Server-Workloads, zuverlässig und sicher ausführen können. Einige der größten Unternehmen der Welt setzen auf Cloud SQL. Mehr als 90 % der 100 größten Google Cloud-Kunden nutzen Cloud SQL. Wir zeigen Ihnen, wie Sie die richtige Datenbank-Instanz auswählen, Ihre Datenbank migrieren, mit Standard-SQL-Server-Tools arbeiten und wie Sie Ihre Datenbank überwachen und auf dem neuesten Stand halten.

#3 Auswahl einer PostgreSQL-Datenbank in der Google Cloud

Von Mohsin Imam

PostgreSQL ist eine branchenführende relationale Datenbank, die für ihre freizügige Open-Source-Lizenzierung, ihre umfangreiche Funktionalität, ihren nachweislich erfolgreichen Einsatz in Unternehmen und eine starke Gemeinschaft von Entwickler*innen und zahlreiche Tools geschätzt wird. Google Cloud bietet drei vollständig verwaltete Datenbanken für PostgreSQL-Nutzer: Cloud SQL, ein intuitiver, vollständig verwalteter Datenbankdienst für Open-Source-PostgreSQL, AlloyDB, ein PostgreSQL-kompatibler Datenbankdienst für Anwendungen, die ein besonders hohes Maß an Skalierbarkeit, Verfügbarkeit und Leistung benötigen, und Cloud Spanner, eine Cloud-First-Datenbank mit unbegrenzter globaler Skalierung, 99,999 % Verfügbarkeit und einer PostgreSQL-Schnittstelle. Sie erfahren, welche Lösung die richtige für Ihre Anwendung ist, wie Sie Ihre Datenbank in die Cloud migrieren und wie die ersten Schritte dafür aussehen.

#4 Wie Sie Ihre Anwendungen mit Google Cloud-Datenbanken migrieren und modernisieren

Von Sandeep Brahmarouthu

Die Migration Ihrer Anwendungen und Datenbanken in die Cloud ist nicht immer ganz einfach. Während einfache Workloads vielleicht nur eine einfache Lift-and-Shift-Migration der Datenbank erfordern, können individuelle Unternehmensanwendungen von umfassenderen Modernisierungs- und Transformationsmaßnahmen profitieren. In diesem Video informieren wir Sie über die verwalteten Datenbankdienste von Google Cloud, unseren Ansatz für eine schrittweise Modernisierung, das Framework und die Programme, die wir für die Datenbankmigration anbieten, und darüber, wie wir Ihnen mit einer unverbindlichen Bewertung den Einstieg erleichtern können.

#5 Erste Schritte mit dem Database Migration Service

Von Shachar Guz & Inna Weiner

Angesichts der steigenden Kosten für die Wartung von Legacy-Datenbanken wird die Migration Ihrer Datenbanken zur Cloud immer attraktiver. Google Cloud kann Ihnen dabei helfen – ob es sich nun um eine einfache Lift-and-Shift-Migration, eine Datenbankmodernisierung auf eine moderne, Open-Source-basierte Alternative oder eine vollständige Transformation von Anwendungen handelt. Sie erfahren, wie der Database Migration Service die Migration mit einer serverlosen, sicheren Plattform, die native Replikationsfunktionen für hochpräzise und zuverlässige Migrationen nutzt, vereinfacht. Es wird gezeigt, wie eine Datenbankmigration weniger komplex, weniger zeitaufwendig und auch risikoärmer sein kann – und wie Sie Ihre Migration in den meisten Fällen in weniger als einer Stunde in die Wege leiten können.

Wir freuen uns auf die Zusammenarbeit mit Ihnen

Welchen Weg Sie bei der Migration zur Cloud auch einschlagen – Sie werden schnell erkennen, dass Google Cloud-Datenbanken skalierbar, zuverlässig, sicher und offen sind. Wir freuen uns darauf, ein neues Zuhause für Ihre Oracle- und SQL Server-basierten Anwendungen zu schaffen.

Beginnen Sie Ihre Cloud-Reise mit einer kostenlosen Testversion von Cloud SQL oder Spanner und gehen Sie anschließend mit dem Database Migration Program den nächsten Schritt zur Google Cloud.

Migrieren von Datenbanken nach Google Cloud VMware Engine (GCVE)

Wed, 12 Oct 2022 03:00:00 +0000

Dieser Beitrag behandelt einige Prozesse und Tools, die häufig für die Migration lokaler Datenbanken, oft auf VMware, nach Google Cloud VMware (GCVE) verwendet werden. Viele Kunden wählen diesen Lift-and-Shift-Ansatz als ersten Schritt, um Datenbanken rasch nach Google Cloud zu migrieren, bevor sie mit der Aktualisierung und Modernisierung der Datenbank beginnen.

Google Cloud VMware Engine

GCVE ist ein vollständig managed Service, mit dem Sie eine VMware-Umgebung in Google Cloud betreiben können. Die Lösung umfasst vSphere, vCenter, vSAN, NSX-T und die entsprechenden Tools. GCVE ermöglicht den Betrieb von VMware-Umgebungen an einer Vielzahl von Google Cloud-Standorten nativ auf dedizierter Google Cloud Bare Metal-Infrastruktur. GCVE stellt alle Funktionen bereit, die für eine effiziente und sichere Nutzung von VMware benötigt werden. Jeder Cluster besteht aus mindestens drei Nodes und sorgt mit vSphere High Availability für Hochverfügbarkeit der betriebenen VMs. Weitere Informationen zu vSphere HA finden Sie unter folgendem Link: Arbeitsweise von vSphere HA.

Zu beachten ist:

Eine GCVE Private Cloud = 1 vCenter + 1 NSX-T Manager + 1 HCX Manager
GCVE unterstützt keine überlappenden CIDR-Bereiche in vSphere- oder
HCX-Verwaltungsnetzwerken.
Ein Cluster muss aus mindestens drei Nodes bestehen.

Verbinden von lokaler VMware mit Google Cloud VMware Engine

Weitere Informationen zum Verbinden mit GCVE finden Sie im Whitepaper „Privates Cloud-Netzwerk für Google Cloud VMware Engine”.

Tools für die Datenbankmigration

Es gibt mehrere Tools für die Migration von Servern nach GCVE, von denen die drei folgenden besonders häufig genutzt werden:

VMware HCX

VMware HCX dient zur Migration von VMs aus Ihrer lokalen VMware-Umgebung in die Google Cloud VMware Engine. Dabei muss der HCX Connector OVA sowohl lokal als auch in der privaten Cloud heruntergeladen, installiert, bereitgestellt und konfiguriert werden. Die HCX Connector-Instanzen werden den lokalen vCenter-Instanzen 1:1 zugeordnet. Wenn also zehn vCenter Instanzen vorhanden sind, muss für jedes vCenter ein Connector installiert werden.

Weitere Informationen zum Migrieren von VMs aus Ihrer lokalen Umgebung in Ihre Private Cloud mit VMware HCX finden Sie hier.

Ein Hinweis zur Migration von Windows-Clustern: Die Migration von SQL Server Failover (FCI)- und anderen Windows-Clustern kann durch die Netzwerkkonnektivität, erforderliche IP-Änderungen und gemeinsam genutzte Speicherkomponenten erschwert werden. In diesen Fällen ist es oft sinnvoll, nicht das Cluster selbst zu migrieren, sondern in GCVE eine neue VM mit der benötigten Konfiguration zu erstellen und dann die Daten zu verschieben.

Datenbank-Replatforming

Manchmal lassen sich virtuelle Server nicht von der lokalen Umgebung nach GCVE migrieren, sei es weil das System zu komplex oder das Migrationstool nicht kompatibel ist. In diesem Fall empfiehlt es sich, in GCVE VM-Vorlagen zu erstellen, die das Betriebssystem, die Datenbank, die Überwachungssoftware, die erforderlichen Softwarekonfigurationen und Werkzeuge sowie Hilfsprogramme wie den Actifio Datenbank-Connector enthalten. Auf Basis dieser Vorlagen werden dann VMs als Migrationsziele für die Datenbank-Arbeitslasten bereitgestellt. Der weitere Ablauf der Migration ist von der zu Grunde liegenden Plattform und dem verfügbaren Migrationsfenster abhängig.

In dieser Tabelle sind die gängigen Datenbank-Replatforming-Strategien für die einzelnen Plattformen aufgeführt:

Bei Legacy-Datenbankplattformen wie Oracle 8i und 9i können die Datenbanken möglicherweise mit dem Stromasys Charon-Emulator auf GCVE ausgeführt werden.

Im Anschluss an die Migration der Datenbanken nach GCVE kann die Datensicherung mit Actifio konfiguriert und vSphere Replication für die Datenbankreplikation (DR) eingerichtet werden. Einen Überblick über die unterstützten Betriebssysteme und Datenbanken finden Sie in der Actifio Go Support Matrix. Wenn die zu migrierende Datenbank von Actifio nicht direkt unterstützt wird, können Sie sie mit einem datenbankspezifischen Backup-Tool (RMAN, mysqldump, pg_dump usw.) auf einem angehängten Volume sichern und dann mit Actifio in regelmäßigen Abständen ein Snapshot des Volumes mit den Sicherungskopien erstellen.

Wenn der Host überregionale Notfallwiederherstellung erfordert, wird im nächsten Schritt häufig vSphere Replication so konfiguriert, dass VMs der primären Region in die DR-Regionen repliziert werden. VMware Site Recovery Manager unterstützt die Automatisierung der Replikation und Wiederherstellung von VMs, ist aber nicht erforderlich. Mit Site Recovery Manager ist Skipterstellung und Automatisierung per VMware PowerCLI möglich.

Nach einem ersten Snapshot werden weitere Snapshots in den gemäß RPO erforderlichen Intervallen geplant. Bei einem geplanten Failover in eine DR-Region müssen wegen des Subnetzwechsels erforderliche IP-Adressänderungen und DNS-Aktualisierungen berücksichtigt werden. Je nach Datenbank ist es unter Umständen notwendig, bestimmte Datenbank-Konfigurationsdateien wie tnsnames.ora und listener.ora zu aktualisieren und an die neue Host-IP-Adresse anzupassen. Wenn sich Personen per DNS CNAME mit Ihrer Datenbank verbinden, muss auch der CNAME-Eintrag aktualisiert werden.

Beachten Sie, dass vSphere Replication nicht alle Datenbanken unterstützt. Ob Ihre Datenbank unterstützt wird, können Sie mit der VMware 3rd Party Solution Interoperability Matrix feststellen. Wenn dies nicht der Fall ist, können Sie auf eine datenbankspezifische Funktion wie Replikation, Protokollversand, Always-On Availability Groups usw. zurückgreifen.

Die nächsten Schritte: Modernisierung und Hybride GCE/GCVE-Umgebungen

Nachdem Sie Datenbanken und Anwendungen nach GCVE migriert haben, können Sie neue Workstreams zur Anwendungs- und Datenbank-Modernisierung einleiten. So könnten Sie beispielsweise in einem nachfolgenden Modernisierungsprojekt eine Anwendung so umgestalten, dass sie teils in GCE oder GKE und teils in GCVE läuft. Auch eine hybride GCE/GCVE-Betriebsumgebung wäre möglich, in der eine Anwendung nach GCE migriert wird und die dazugehörige Datenbank in GCVE verbleibt.

Weitere Informationen zu GCVE-Netzwerken, Konnektivitätsoptionen und gängigen Anwendungsfällen finden Sie im Beitrag ‚Privates Cloud-Netzwerk für Google Cloud VMware Engine‘ unter Private Cloud zu lokaler Umgebung, Private Cloud zu VPC und Privater Google-Zugriff.

Zusammenfassung

Die Lift-and-Shift-Migration ist eine beliebte Strategie für die Migration lokaler Datenbanken auf VMware VMs nach GCVE. Nach Abschluss des ersten Migrationsschritts können Unternehmen ihre Anwendungen und Datenbanken mit GCVE und nativen Google-Diensten nach und nach entsprechend ihren Geschäftsanforderungen transformieren.

Neuigkeiten bei Googles offener und intelligenter Daten-Cloud

Thu, 22 Sep 2022 16:00:00 +0000

Wir haben das Privileg, täglich mit höchst innovativen Kunden weltweit zusammenzuarbeiten. Viele von ihnen entschieden sich für Google Cloud, weil wir über fundiertes Fachwissen in den Bereichen Datenanalyse und KI verfügen. Bei der Zusammenarbeit haben wir festgestellt, dass viele der führenden Datenunternehmen ähnliche Prioritäten haben: Datenbarrieren und -komplexität abbauen, neue Anwendungsfälle erschließen und mehr Menschen mit mehr Wirkung erreichen.

Diese disruptiven Unternehmen treiben die Dateninnovation mit einer Daten-Cloud voran, die ihre Mitarbeiter*innen befähigt, Daten aller Art, jeglichen Umfangs und aus jeder Quelle schnell zu bearbeiten – ohne Kapazitätsgrenzen. Diese Daten-Cloud bietet Bewegungsfreiheit, die Nutzer*innen wechseln ihre Workloads mühelos zwischen SQL und Spark, Business Intelligence und Machine Learning. Und für all das muss nur wenig Infrastruktur eingerichtet werden. Außerdem bildet diese Daten-Cloud das Fundament eines Ökosystems zur Schaffung von Datenprodukten, mit denen Mitarbeiter*innen, Kunden und Partner informierte Entscheidungen auf einer breiten Grundlage treffen können.

Am 11. Oktober, auf der Google Cloud Next ‘22, werden wir eine ganze Reihe neuer Funktionen vorstellen, die für diese Vision und ihre Weiterentwicklung stehen. Sollten Sie sich noch nicht für den Data Cloud-Track bei der Google Next angemeldet haben, sichern Sie sich am besten noch heute einen Platz!

Doch weil passionierte Datenfachleute nur ungern warten, möchten wir schon vor der Next eine Vorschau auf die jüngsten Daten-Cloud-Innovationen bieten.

Data Sharing ohne Barrieren, Erkenntnisse in Echtzeit, offene Ökosysteme

Gewöhnlich sind nicht alle Daten, die Sie benötigen, an einer Stelle versammelt, sondern liegen in einer Vielzahl von Quellen und Formaten vor. Nach Jahrzehnten von digitalem Datenaustausch kann die Datenbewegung bei einem traditionellen Austausch sehr aufwendig sein. Sicherheits- und Compliance-Fragen kommen erschwerend hinzu.

Deshalb haben wir uns entschieden, den nun verfügbaren Analytics Hub zu entwickeln – eine Data-Sharing-Plattform für Teams und Organisationen, die den Datenaustausch intern und extern sicher und zuverlässiger gestalten möchten.

Diese Innovation gewährleistet nicht nur, dass große Datensätze global analysebereit zusammengestellt und geteilt werden können, sondern erschließt auch Datensätze, die nur Google bereitstellen kann, z. B. die Google Search Trends oder den Data Commons Knowledge Graph.

Analytics Hub bietet ein erstklassiges Nutzungserlebnis innerhalb von BigQuery: Testen Sie den Hub jetzt im Rahmen der BigQuery-Nutzung kostenlos, ohne Angabe von Kreditkartendaten.

Daten schnell in Ihre Analyseumgebung zu bringen geht aber auch ohne Analytics Hub. Eine kürzlich neu eingeführte Option erlaubt es, Daten in Echtzeit für BigQuery zu extrahieren, zu laden und zu transformieren: das Pub/Sub-Abonnement „BigQuery Subscription“. Diese ELT-Innovation vereinfacht das Streamen von einzuspeisenden Workloads, sie lässt sich leichter implementieren und bietet auch wirtschaftliche Vorteile, denn Sie müssen keine neue Rechenleistung bereitstellen, um Daten zu bewegen, und für die Stream-Einspeisung in BigQuery auch nichts mehr zahlen.

Was aber, wenn Ihre Daten nun in verschiedenen Lakes, Warehouses, Clouds und Dateiformaten stecken? Mit der Zahl der Nutzer*innen vermehren sich auch die Anwendungsfälle und lassen eine herkömmlich aufgebaute Infrastruktur zur Datenbewegung schnell an die Grenzen ihrer Skalierbarkeit stoßen, wodurch hohe Kosten und Risiken entstehen können.

Wir haben deshalb die neue Speicher-Engine BigLake eingeführt, die den innovativen BigQuery-Speicher auf offene Dateiformate ausdehnt, die in öffentlichen Cloud-Objektspeichern residieren. Mit BigLake können Kunden sichere Data Lakes auf der Grundlage offener Dateiformate aufbauen. Und da die Lösung konsistente, granulare Sicherheitskontrollfunktionen für Google Cloud- und Open-Source-Query Engines bietet, muss das Sicherheitssystem nur an einer zentralen Stelle konfiguriert werden, um überall wirksam zu sein.

Kunden wie die Deutsche Bank, Synapse LLC und Wizard haben die Preview-Version von BigLake bereits im Einsatz. Die allgemeine Verfügbarkeit von BigLake gibt Ihnen Gelegenheit, zu erproben, wie Sie Ihr eigenes Daten-Ökosystem aufbauen können.

Freie Wege in der Datenverarbeitung

Wenn sich Ökosysteme auf Datenarten, -größen, -typen und -formate aller Art ausdehnen, werden Organisationen oft in der Innovation ausgebremst, denn die Mitarbeiter*innen müssen, je nach Workload, ständig zwischen unterschiedlichen Schnittstellen wechseln.

Das gilt insbesondere für den Bereich Machine Learning, wo die ML-Schnittstelle häufig eine andere als die für Geschäftsanalysen ist. Nach unseren Erfahrungen kommen BigQuery ML Kunden auf ihren Innovationspfaden jedoch sehr viel schneller voran – weil die Machine Learning-Fähigkeiten integraler Bestandteil von BigQuery sind, während sie bei anderen Lösungen lediglich aufgesetzt werden.

Dieselbe Philosophie wenden wir nun beim Data-Logging an, indem wir einen Loganalyse-Dienst in Cloud Logging anbieten. Dieses derzeit noch im Preview-Status befindliche neue Feature bietet seinen Anwender*innen profunde Einblicke in ihre BigQuery-Logging-Daten. Über die Cloud Logging-Gebühren hinaus fallen keine weiteren Kosten für die Loganalyse an, die zudem von den bald allgemein verfügbaren BigQuery-Features zur Loganalyse profitieren wird: Suchindizes, ein JSON-Dateityp und die Storage Write API.

Kunden, die ihre eigenen maschinengenerierten Daten von Servern, Sensoren und anderen Geräten speichern, untersuchen und analysieren, können damit auf dieselben BigQuery-Features zurückgreifen und haben es so bei der Abfrage der Logs leicht. Sie verwenden einfach die standardmäßige BigQuery-SQL, um operative Log-Daten zu analysieren, genauso wie bei ihren anderen Geschäftsdaten.

Doch das war noch längst nicht alles. Wir freuen uns darauf, Sie am 11. Oktober auf der Google Next ’22 zu begrüßen und Ihnen weitere Details zu den Daten-Cloud-Lösungen der nächsten Generation zu verraten. Suchen Sie die Ihrer Rolle und Ihren Interessen entsprechenden Beiträge unter den Top-Sessions der Next für Datenentwicklung, Datenwissenschaft und Datenanalyse aus – oder erstellen und teilen Sie Ihre eigenen Playlists.

Kommen Sie zur Next ’22 und hören Sie aus erster Hand, wie Boeing, Twitter, CNA Insurance, Telus, L’Oreal, Wayfair und andere Top-Unternehmen datengestützte Erkenntnisse in Erfolge umsetzen – mit der Daten-Cloud von Google.

Wie Bayer Crop Science mit BigQuery und geobeam die Bodengesundheit verbessert

Mon, 12 Sep 2022 03:00:00 +0000

Bayer Crop Science analysiert mit Google Cloud mehrere Milliarden Hektar Land, um die Bodenbeschaffenheit der Anbauflächen für unsere Nutzpflanzen zu analysieren. Ein Großteil dieser wichtigen Arbeit basiert auf Daten von US-Behörden wie dem geologischen Forschungsinstitut USGS, dem Amt für Meteorologie und Ozeanografie NOAA und dem nationale Wetterdienst NWS, die umfangreiche Messungen der Erdoberfläche und der Atmosphäre vornehmen. Diese Messergebnisse stehen der Öffentlichkeit zur freien Verfügung, müssen aber ausgewertet werden, um daraus Informationen und Erkenntnisse zu gewinnen.

Für den Abruf sowie die Speicherung, Analyse und Visualisierung dieser raumbezogenen Daten setzen die Datenwissenschaftler*innen von Bayer auf die Dienste von Google Cloud. Das können auch Sie: In diesem Beitrag erfahren Sie, wie sich mit Google Cloud-Diensten wie BigQuery und Dataflow selbst große Mengen an Erdbeobachtungsdaten mühelos analysieren lassen.

Daten zusammenführen

Werfen wir zunächst einen Blick auf einige der verfügbaren Datensätze. Für dieses Projekt war das Bayer-Team vor allem an einem speziellen Datensatz aus dem globalen Bodendatenbestand der ISRIC-Stiftung interessiert. Das International Soil Reference and Information Centre erstellt eine weltweite Bodenqualitätskarte und misst dafür den pH-Wert, den Gehalt an organischen Substanzen, den Stickstoffgehalt und andere chemische Eigenschaften der Böden. Diese Messdaten werden in Rasterdateien kodiert – große Bilder aus verschiedenfarbigen Pixeln, die jeweils den an einem bestimmten Punkt auf der Erdoberfläche gemessenen Wert darstellen. Sie enthalten mehrere Schichten von Rastern, die Daten aus den einzelnen Tabellen einer Datenbank abbilden. Raster sind ideal, um durch Punktmessungen erzeugte Gitterdaten zu speichern und werden häufig für die Bereitstellung von Erdbeobachtungsdatensätzen genutzt. Die räumliche Beziehung zwischen einzelnen Bereichen, Segmenten und Schichten eines Rasters ist dabei allerdings nicht leicht zu erkennen.

Daten zu Erkenntnissen verarbeiten

Deshalb wandelt Bayer die Rasterdaten mit Dataflow und geobeam in Vektordaten um, die eine Visualisierung ermöglichen. Um aus den Datenpunkten Bilder zu erzeugen, werden die Rastersegmente in Polygone konvertiert, in das von BigQuery verwendete WGS 84-Koordinatensystem reprojiziert und zu h3-Indizes verarbeitet. Vor allem die Polygonisierung ist ein sehr komplexer Vorgang, dessen Schwierigkeit mit der Größe der Datei exponentiell zunimmt. Dataflow teilt deshalb umfangreiche Rasterdateien in kleinere Blöcke auf, die dann massiv parallel verarbeitet werden. Auf diese Weise lassen sich beliebige Datenmengen wesentlich schneller konvertieren, als es auf einem einzelnen Rechner mit herkömmlichen GIS-Tools möglich wäre – und das im Handumdrehen, mit minimalem Programmieraufwand. Die Rasterdaten werden polygonisiert, reprojiziert und vollständig umgewandelt und dann von Dataflow als Vektordaten direkt in BigQuery-Tabellen geschrieben.

Mithilfe von BigQuery GIS und den durch geobeam berechneten h3-Indizes verbindet Bayer die in BigQuery geladenen Daten über mehrere Tabellen hinweg zu einer Gesamtansicht der verschiedenen Bodenschichten. Damit können die kombinierten Daten ausgewertet, alle Schichten gleichzeitig mit BigQuery GeoViz abgebildet und mit Machine-Learning-Modellen nach Mustern untersucht werden, die für das menschliche Auge nicht erkennbar sind.

Screenshot der Bodenanalyse von Bayer in GeoViz

Geodaten in der Praxis

Bayer nutzt die Bodengitterdaten, um die Bodeneigenschaften in den Anbaugebieten seiner Kunden zu analysieren und die Entwicklung und den Vertrieb seiner Produkte besser auf die örtlichen Bedingungen abzustimmen. Auch bei der Analyse der Bodeneigenschaften auf den Feldern seines internen Testnetzwerks kommt diese Technologie zum Einsatz, um globale Muster bei den Umweltbedingungen zu erkennen und historische Entwicklungen abzubilden.

Es ist wenig überraschend, dass die Nutzung der Erkenntnisse aus Geodaten zum Anbau von Nutzpflanzen für Bayer Crop Science ein entscheidender Durchbruch ist. Dieselben Strategien und Tools können aber auch in vielen anderen Branchen und Unternehmen eingesetzt werden.

Google hat sich dem Ziel verschrieben, das Wissen der Welt zu organisieren und es allgemein zugänglich und nutzbringend einsetzbar zu machen. Wir freuen uns, mit Kunden wie Bayer Crop Science zusammenzuarbeiten, die ihre Daten für die Entwicklung von Produkten einsetzen, die sowohl ihren Kunden als auch der Umwelt zugutekommen.

Wenn auch Sie daran interessiert sind, innovative Geodatenanwendungen für Ihr Unternehmen zu entwickeln, werfen Sie einen Blick in unsere Referenz zu den raumbezogenen Funktionen von Google Cloud. Mit BigQuery und geobeam finden Sie alle dazu nötigen Anwendungen in der Google Cloud-Konsole.

Sieben Cloud Spanner-Mythen

Mon, 22 Aug 2022 04:00:00 +0000

Einführung in Cloud Spanner

Cloud Spanner ist eine unternehmenstaugliche, global verteilte und extern konsistente Datenbank mit unbegrenzter Skalierung und 99,999 % Verfügbarkeit. Sie erfordert keine Wartungsfenster, bietet eine vertraute PostgreSQL-Schnittstelle und verbindet die Vorteile relationaler Datenbanken mit der unübertroffenen Skalierbarkeit und Verfügbarkeit nicht-relationaler Datenbanken.

Spanner bietet Unternehmen, die ihre Software-Ausstattung modernisieren und vereinfachen möchten, neue Möglichkeiten, um ihre Vorstellung und Nutzung von Datenbanken für die Entwicklung neuer Anwendungen und Kundenerlebnisse zu transformieren.

Es ist nicht einfach, die richtige Datenbank für Ihre Workloads auszuwählen. Der Markt bietet unzählige Optionen, die sich in Sachen Onboarding und Betrieb teilweise deutlich unterscheiden. Das Google Cloud-Team möchte Ihnen gerne dabei helfen, sich in diesem großen Angebot zurechtzufinden: In diesem Blogbeitrag möchten wir sieben Missverständnisse aufklären, die im Zusammenhang mit Spanner besonders oft aufkommen, damit Sie eine faktenbasierte Entscheidung treffen können.

Mythos Nr. 1: Der Einsatz von Spanner ist nur bei massiven Workloads sinnvoll

Es ist in der Tat so, dass Spanner für die weltweit verfügbaren Google-Produkte wie YouTube, Drive und Gmail eingesetzt wird und viele groß angelegte Transformationen – unter anderem bei Uber, Niantic und Sharechat – möglich gemacht hat. Richtig ist auch, dass Spanner zu Spitzenzeiten mehr als eine Milliarde Abfragen pro Sekunde verarbeitet.

Dennoch schätzen auch viele Kunden mit kleineren Workloads – also weniger Transaktionen und geringerer Speichergröße – die Verfügbarkeit und Skalierbarkeit von Spanner. So laufen beispielsweise auch die kleineren Workloads von Google Password Manager auf Spanner. Kunden wie diese entscheiden sich für Spanner, weil sie sich keine Ausfallzeiten leisten können, beim Betrieb ihrer Anwendungen auf Hochverfügbarkeit angewiesen sind und verlässliche Skalierbarkeit für ihr künftiges Wachstum benötigen.

Unbegrenzte Skalierbarkeit mit höchster Verfügbarkeit ist in vielen Branchen, wie der Gaming Industrie und dem Einzelhandel, entscheidend – wenn etwa ein Spiel nach der Veröffentlichung über Nacht zum Verkaufsschlager wird oder ein Einzelhändler am Black Friday oder Cyber Monday plötzlich einen besonders hohen Ansturm bewältigen muss.

Ganz gleich, wie groß die Workloads sind: Jedes Unternehmen, das auf dem Weg in die Cloud ist, legt Wert auf Skalierbarkeit und Verfügbarkeit und möchte den Arbeits- und Kostenaufwand für Patches, Upgrades und andere Wartungsarbeiten verringern.

Mythos Nr. 2: Spanner ist zu teuer

Anstatt bei der Beurteilung einer Datenbank nur auf den Listenpreis zu schauen, sollten Sie die Gesamtbetriebskosten und den Gebrauchswert, den sie bietet, mit in Betracht ziehen. Spanner bietet einen erheblichen Mehrwert in entscheidenden Punkten wie Verfügbarkeit, Preis-Leistungs-Verhältnis und verringerte Betriebskosten.

Verfügbarkeit: Spanner überzeugt mit hoher Verfügbarkeit und Zuverlässigkeit durch synchrone Replikation von Daten. Was die Notfallwiederherstellung betrifft, bietet Spanner 0-RPO und 0-RTO für zonale Ausfälle regionaler Instanzen und regionale Ausfälle überregionaler Instanzen. Das bedeutet weniger Ausfallzeiten und mehr Umsatz.

Preis-Leistungsverhältnis: Mit Blick auf das Preis-Leistungs-Verhältnis ist Spanner die ideale Lösung für anspruchsvolle und leistungskritische Anwendungen, denn großartige Kundenerlebnisse erfordern konsistent optimale Latenzzeiten.

Verringerte Betriebskosten: Bei Spanner profitieren Kunden von Upgrades und Schemaänderungen ohne Ausfallzeiten und ohne Wartungsfenster. Dank automatischer Fragmentierung ist, anders als bei herkömmlichen Datenbanken, keine aufwändige Skalierung nötig. Das bedeutet weniger Verwaltungsaufwand und damit mehr Zeit für Innovationen.

Sicherheit & Compliance: Spanner verschlüsselt Daten bereits standardmäßig bei der Übertragung über seine Client-Bibliotheken und bei der Speicherung mit von Google verwalteten Schlüsseln. CMEK-Unterstützung für Spanner sorgt dafür, dass Sie jetzt die volle Kontrolle über die Schlüssel haben. Zudem bietet Spanner Unterstützung für VPC Service Controls und kann dank Compliance-Zertifizierungen und der nötigen Genehmigungen für Workloads verwendet werden, die ISO 27001, 27017, 27018, PCI DSS, SOC1|2|3, HIPAA und FedRAMP erfordern.

Bei Spanner haben Sie die Gewissheit, dass die Sicherheit, Verfügbarkeit und Zuverlässigkeit Ihrer Daten nicht beeinträchtigt werden.

Profi-Tipp: Nutzen Sie den Auto-Scaler, um Ihre Spanner-Instanzen richtig zu dimensionieren, und TTL, um die Speicherdatenmenge zu reduzieren.

Mythos Nr. 3: Sie müssen Skalierung, Konsistenz und Latenzzeit gegeneinander abwägen

Tatsächlich lässt sich Spanner je nach Anwendungsfall und Konfiguration der Instanz so nutzen, dass Sie keine Kompromisse bezüglich Konsistenz, Latenz und Skalierung schließen müssen.

Um Datenkonsistenz zu gewährleisten, verwendet Spanner ein synchrones, Paxos-basiertes Replikationsschema, bei dem die Replikate jede Schreibanforderung bestätigen. Ein Schreibvorgang wird nur dann ausgeführt, wenn die Mehrzahl der Replikate (z. B. 2 von 3) als sogenanntes Quorum zustimmen. Bei regionalen Instanzen befinden sich die Replikate in der Region. Deshalb sind die Schreibvorgänge schneller als bei überregionalen Instanzen, deren Replikate auf mehrere Regionen verteilt sind. Im letzteren Fall kann die mehrheitliche Genehmigung von Schreibvorgängen mehr Zeit in Anspruch nehmen und die Latenz geringfügig erhöhen. Dennoch werden auch Spanner-Multiregionen geografisch sorgfältig konfiguriert, so dass die Replikate stets schnell genug kommunizieren können und die Schreiblatenzen annehmbar bleiben.

Lesevorgänge werden als Strong Read (standardmäßig) oder als Stale Read ausgeführt. Ein Strong Read ist ein Lesevorgang, bei dem garantiert alle bis zum aktuellen Zeitpunkt übertragenen Daten erfasst werden. Ein Stale Read hingegen erfasst den Datenstand eines länger zurückliegenden Zeitpunkts. Bei einem Strong Read garantiert das Replikat, das die Daten bereitstellt, dass alle bis zum Beginn des Lesevorgangs übertragenen Daten angezeigt werden. Hierfür muss sich dieses Replikat unter Umständen beim Leader-Replikat rückversichern, dass es über die neuesten Daten verfügt. Im Falle einer überregionalen Instanz, bei der die Daten nicht von einem Leader-Replikat bereitgestellt werden, kann die Leselatenz deshalb etwas höher ausfallen als bei der Bereitstellung aus einer Leader-Region. Ein Stale Read liefert Daten, die zu einem Zeitpunkt in der Vergangenheit übertragen wurden, und kann daher mit sehr geringer Latenz vom nächstgelegenen Replikat bereitgestellt werden, das über den Datenbestand zum angeforderten Zeitpunkt verfügt. Für latenzkritische Anwendungen können Stale Reads mit einem empfohlenen Stale-Read-Wert von 15 Sekunden sinnvoll sein.

Mythos Nr. 4: Spanner spricht kein PostgreSQL

Tatsächlich ist Spanner sehr flexibel und kann nicht nur in einem SQL-Dialekt, der auf dem ANSI 2011-Standard basiert, sondern auch über eine für Leistung und Komfort optimierte REST oder gRPC API-Schnittstelle mit der Datenbank kommunizieren. Darüber hinaus haben wir kürzlich eine PostgreSQL-Schnittstelle für Entwicklungsteams eingeführt, die lieber auf der ihnen vertrauten Oberfläche der weit verbreiteten Umgebung arbeiten. Die PostgreSQL-Schnittstelle stellt ein umfangreiches Subset des PostgreSQL Open Source SQL-Dialekts mit der gängigen Abfragesyntax sowie wichtigen Funktionen und Operatoren bereit. Sie unterstützt alle grundlegenden Open Source PostgreSQL-Datentypen, DDL-Syntax und Informationsschema-Ansichten. So können Sie die mächtige relationale Semantik von Spanner auch in Ihrer vertrauten PostgreSQL-Umgebung nutzen.

Weitere Informationen zu unserer PostgreSQL-Schnittstelle finden Sie hier.

Mythos Nr. 5: Beobachtbarkeitsdaten können nur in der Spanner Console abgerufen werden

Die Client-Bibliotheken von Spanner unterstützen OpenCensus Tracing und Metriken, die Einblick in die Client-Interna bieten und die Fehlersuche in der Produktion erleichtern. Client-seitige Traces und Metriken enthalten sitzungs- und transaktionsbezogene Informationen.

Außerdem unterstützt Spanner den OpenTelemetery-Empfänger, sodass Sie Metriken aus Cloud Spanner-Systemtabellen mühelos verarbeiten, visualisieren und in das Application Monitoring (APM)-Tool exportieren können. Das kann entweder eine Open-Source-Kombination aus einer Zeitreihen-Datenbank und einem Grafana-Dashboard oder aber ein kommerzielles Angebot wie Splunk, Datadog, Dynatrace, NewRelic oder AppDynamics sein. Zudem haben wir Grafana-Referenzdashboards veröffentlicht, sodass Sie die häufigsten Anfragen von Nutzerinnen und Nutzern wie „Warum ist meine Tail-Latenz so hoch?“ oder „Warum sehe ich trotz unveränderter Workload eine CPU-Spitze?“ sofort bearbeiten können. Dieser Docker-Dienst ist ein Beispiel dafür, wie der Cloud Spanner-Empfänger mit dem Prometheus-Exporter und Grafana-Dashboards zusammenarbeiten kann.

Wir setzen auch weiterhin auf offene Standards und die Integration mit unserem Partnernetzwerk. Außerdem entwickeln wir die von Google Console bereitgestellte Beobachtbarkeit weiter, um Kunden unabhängig von ihrem Standort das bestmögliche Erlebnis zu bieten.

Mythos Nr. 6: Spanner eignet sich nur für globale Workloads, die Kopien in mehreren Regionen voraussetzen

Tatsächlich bietet Spanner neben einer Reihe von überregionalen Instanzkonfigurationen in jeder GCP-Region auch eine regionale Konfiguration. Jeder regionale Knoten wird in drei Zonen innerhalb der Region repliziert, ein überregionaler Knoten mindestens fünfmal in verschiedenen Regionen. Eine regionale Konfiguration bietet eine Four-Nines-Verfügbarkeit und Schutz vor zonalen Ausfällen.

Eine überregionale Instanzkonfiguration ist in der Regel angezeigt, wenn Ihre Anwendung Workloads an mehreren geografischen Standorten umfasst oder Ihr Unternehmen eine Verfügbarkeit von 99,999 % und Schutz vor regionalen Ausfällen benötigt. Mehr dazu erfahren Sie hier.

Mythos Nr. 7: Spanner-Schemaänderungen erfordern teure Sperren

Die Wahrheit ist, dass Spanner auf Tabellenebene überhaupt keine Sperren hat. Seine Architektur ermöglicht Spanner, mehrere gleichzeitige Schema- und Datenversionen zu erkennen und zu verwalten. Das erlaubt qualifizierte Ad-hoc- und Online-Schemaänderungen ganz ohne Ausfallzeiten, zusätzliche Tools, Migrationspipelines oder komplexe Rollback-/Backup-Pläne. Nach dem Start einer Schemaaktualisierung können Sie ohne Unterbrechung weiter in der Datenbank schreiben und lesen, während Spanner das Update-Backfill verarbeitet – ganz gleich, ob Ihre Tabelle zehn Zeilen oder zehn Milliarden Datensätze umfasst.

Dieser Mechanismus kann auch für die Wiederherstellung zu einem bestimmten Zeitpunkt und für Snapshot-Abfragen verwendet werden, um sowohl das Schema als auch den Zustand der Daten mit einer bestimmten Abfragebedingung und einem bis zu sieben Tage zurückliegenden Zeitstempel zu regenerieren.

Nun kennen Sie die Wahrheit über Cloud Spanner und können direkt einsteigen – besuchen Sie unsere Website.

Globale Multiplayer-Spiele entwickeln – mit Cloud Spanner

Mon, 13 Jun 2022 04:00:00 +0000

Die Entwicklung moderner Videospiele dauert oft einige Jahre und erfordert viel Kapital. Beeinflusst wird die Entwicklungszeit von der unterliegenden Plattform sowie der Größe, der Art und dem Umfang des Spiels. Gamer erwarten oftmals vom ersten Tag an eine globale Multiplayer-Erfahrung. Deshalb hängt der Erfolg eines Spiels davon ab, wie gut es sich innerhalb der ersten Wochen für eine Community von Millionen Nutzer*innen skalieren lässt. Stabilität und eine hohe Verfügbarkeit sind hierbei die Grundvoraussetzungen, um auf die Nachfrage und das Wachstum zu reagieren. Treten in den ersten Tagen nach der Veröffentlichung Probleme auf, kann das fatale Folgen haben, denn Gamer verzeihen eine schlechte Spielerfahrung generell nur selten und die anfängliche Vorfreude kann schnell verfliegen. Mit anderen Worten: Das Momentum ist entscheidend.

Ist Cloud Spanner komplexen Architekturen gewachsen?

Online-Spiele benötigen viel Speicherplatz: Spielerfolge, Statistiken, Ranglisten und viele weitere Daten müssen in großem Maßstab gesichert werden. Je mehr Spieler*innen einsteigen, desto schneller nimmt das Datenvolumen zu. Die wichtigsten Voraussetzungen für eine unterliegende Datenbank sind deshalb Skalierbarkeit und eine hohe Verfügbarkeit.

Gaming-Backends benötigen meist sowohl eine NoSQL als auch relationale Datenbank, um adäquat skalieren zu können und die Datenkonsistenz aufrechtzuerhalten. Die in Google Cloud zur Verfügung stehenden Firestore- und Bigtable-Optionen können je nach Anforderung, sei es „Mobile First“ oder eine plattformübergreifende Unterstützung, für NoSQL genutzt werden. Im Bereich der relationalen Datenbanken führt kein Weg an Cloud Spanner vorbei – ein Produkt, das sowohl im Hinblick auf die Skalierbarkeit als auch auf die globale Konsistenz der SQL-Schnittstellen entscheidende Stärken besitzt.

Spanner ist unsere verteilte, global skalierbare SQL-Datenbank, die auf dem Prinzip der Entkopplung von Rechen- und Speicherleistung basiert. So können Ressourcen zur Berechnung unabhängig von den Speicherressourcen skaliert werden. Der Vorteil: horizontale Skalierbarkeit und somit bessere Leistung (in Operationen pro Sekunde) bei Schreib- und Lesevorgängen ohne Ausfälle. Das macht Spanner zur idealen Lösung für unkalkulierbare Workloads, auch aus dem Online-Gaming-Sektor.

Ungeplante Systemausfälle sind die größte Gefahr für den langfristigen Erfolg von Online-Spielen. Deshalb wünschen sich Gaming-Unternehmen hochverfügbare Dienste, um unvorhergesehene Ausfälle zu vermeiden. Spanner bietet eine Verfügbarkeit von 99,999 % für multiregionale Anwendungsfälle sowie eine transparente, synchrone Replikation für regionale und multiregionale Konfigurationen. Global verteilte Replikat-Shards sorgen für eine verkürzte Latenz, da sie von einer lokalen Kopie aus arbeiten.

Spanner unterstützt ANSI SQL und Schemata, die nicht denormalisiert werden müssen, und ermöglicht dementsprechend online DML (Data Manipulation Language) Operationen auf Ihrer Spieledatenbank. ANSI SQL kann zudem die Lernkurve von Entwickler*innen und Datenbankadministrator*innen verkürzen. Auch die Objektrelationale Abbildung (OMR) wird unterstützt und die Entwicklungszeit reduziert.

Damit Gaming-Unternehmen leichter Ihre Compliance-Vorgaben erfüllen können, ist Spanner gemäß PCI, SoC und FedRAMP zertifiziert. Über VPC Service Controls generierte Audit-Logs registrieren nicht nur die Aktivitäten der Administrator*innen, sondern auch die der Nutzer*innen (DML, DDL und sogar Queries).

Einführung von Spanner

Die Einführung von Spanner folgt einem klar vorgegebenen Ablauf. Mit den in der Grafik gezeigten Schritten gelingt Ihnen diese möglichst reibungslos. Im Unterschied zu herkömmlichen relationalen Datenbanken ist Spanner ist eine verteilte Datenbank, die relationale Sprachen unterstützt. Um Fehler und zusätzliche Optimierungsschleifen zu vermeiden, sollten Ihre Entwicklungs- und Administratorteams im Entwicklungszyklus so früh wie möglich mit der Evaluierung von Spanner beginnen.

Haben sie sich einmal damit vertraut gemacht, können bestehende relationale Datenbankschemata und relevante Abfragen dank der Unterstützung von ANSI SQL und Schemata in nur wenigen Schritten konvertiert werden. Einige unserer Gaming-Kunden haben die Umrüstung innerhalb von nur zwei bis drei Wochen absolviert. Zahlreiche Tools wie Harbourbridge, ein Open-Source-Evaluierungs- und Migrationstool, sorgen für eine zuverlässige und einfache heterogene Migration.

Wie auch bei anderen Datenbanken müssen bei Spanner Performance-Optimierungen und Belastungstests vorgenommen werden, um die Anforderungen hinsichtlich Datenrate und Latenz zu erfüllen. Die von Spanner bereitgestellten Tools zur Introspektion liefern wertvolle Erkenntnisse, die die Optimierung erleichtern. Dank der intuitiven, visualisierten Ausführungspläne gelingt es auch Entwickler*innen ohne umfassende Datenbankkenntnisse, lang laufende Abfragen zu optimieren. Das Vorwärmen der Datenbank vor dem Spielstart sorgt für eine optimale Verteilung und Datenrate.

Niantic Labs hat auf Google Cloud ein global skalierbares Spiel für Millionen von Nutzer*innen entwickelt: Pokémon Go. Ihre Erfahrungen bei der Skalierung mit Google Kubernetes Engine (GKE) und Spanner haben sie mit uns geteilt und beschrieben, wie BigQuery, Dataflow und Pub/Sub zur Datenanalyse genutzt werden können.

Mit mehr als 200 Millionen Nutzer*innen in über 190 Ländern weltweit ist Vimeo ein wichtiger Akteur auf dem wachsenden Video-/Saas-Markt. In nachfolgenden Video zeigen sie, wie sie Cloud Spanner für ihre Plattform nutzen und weshalb sie sich für Google Cloud entschieden haben:

Sie möchten mehr über unser global skalierbares Gaming-Backend in Google Cloud, die Vorteile von Spanner und die Unterschiede zu herkömmlichen relationalen Datenbanken erfahren? Dann lesen Sie unser Whitepaper „Develop Global Multiplayer Games using Cloud Spanner“.

Chefkoch bringt mit Texterkennung handschriftliche Rezepte in die Cloud

Mon, 06 Dec 2021 09:00:00 +0000

Hinweis der Redaktion: Chefkoch.de serviert Familienrezepte auf einer Technologieplattform des 21. Jahrhunderts. Google liefert dazu eine skalierbare, innovative Lösung auf Basis seiner Google Cloud-Dienste.

Von Sonntagsbraten bis Weihnachtsplätzchen – in vielen Familien gibt es hochgeschätzte Rezepte, die von Generation zu Generation weitergegeben werden. Häufig ist dieser kulinarische Nachlass aber bloß handschriftlich oder gedruckt auf Papier festgehalten. Chefkoch.de wollte seinen Nutzerinnen und Nutzern die Möglichkeit bieten, diese wertvollen Rezepte schnell und einfach zu analysieren und zu digitalisieren. Google Cloud-Funktionen für erweiterte Analysen und Machine Learning (ML) sollten dazu beitragen, dass diese Rezepte in digitaler Form unkompliziert geteilt und angesehen werden können.

Im Vorfeld hatte Chefkoch zunächst umfassende weltweite Marktforschung betrieben, um herauszufinden, welche neuen Funktionalitätsmerkmale für die Weiterentwicklung der Website am wichtigsten wären. Das Unternehmen identifizierte branchenspezifische Best Practices, analysierte verschiedene Geschäftsmodelle und die neuesten Trends in der Lebensmitteltechnologie. Danach untersuchte das Team, wer die Chefkoch-Website aus welchen Gründen verwendet. All diese Daten gingen in ein Kano-Modell ein, das verschiedene Funktionalitätsmerkmale in der Reihenfolge ihrer wahrscheinlichsten Relevanz priorisierte.

An der Spitze der so entstandenen Liste stand das personalisierbare Kochbuch, in dem die Chefkoch-Nutzer*innen ihre liebsten Rezepte speichern, sortieren und verwalten können. Zukünftig sollten sie hier jedes beliebige Rezept speichern können – auch solche, die bisher nur auf Papier vorhanden waren. „Die Herausforderung bestand darin, den Text – ob handschriftlich oder gedruckt – zu extrahieren und dann den Titel, die Zutatenliste und die Hinweise für die Zubereitung voneinander zu trennen“, erklärt Tim Adler, CTO von Chefkoch.

APIs lesen Rezepte

Das Team von Chefkoch testete verschiedene Tools zum Importieren von Texten. Im Mai 2021 fiel dann die Entscheidung, die ML-Dienste von Google Cloud sowie Google Cloud Functions zu nutzen. Letztere bieten skalierbare Functions as a Service (FaaS) mit einer Reihe von APIs, die es ermöglichen, Code ohne Serververwaltung auszuführen.

„Wir haben alle Softwareanbieter für die Erkennung von gescannten handschriftlichen Texten unter die Lupe genommen“, erzählt Adler weiter. „Das Angebot von Google überzeugte uns. Nicht nur weil die APIs einfach zu verwenden und gut dokumentiert sind, sondern auch wegen der überzeugenden Konzeptdemonstration, bei dem das Google Team unsere eigenen Testdaten verwendete.“

Das Team von Chefkoch beschloss, für die neue Lösung zum Lesen von Rezepten die Vision- und Natural Language-Dienste von Google Cloud zu nutzen. Diese funktionieren geräteübergreifend und lassen sich kostengünstig skalieren. Wie im Diagramm oben zu sehen, nutzt das Tool die optische Zeichenerkennung (OCR) der Cloud Vision API. Diese ist für das Erkennen von Texten in deutscher und englischer Sprache optimiert und ermöglicht das Extrahieren handschriftlicher oder gedruckter Vorlagen. Anschließend setzt die Lösung die Modelle 1 und 2 der AutoML Natural Language-Entitätsextraktion sowie die Cloud Natural Language API ein, um die verschiedenen Bereiche eines Rezepts zu identifizieren und voneinander zu trennen. Die so entstandene Darstellung eines Rezepts am Bildschirm sehen Sie unten.

Chefkoch und Google arbeiteten eng zusammen, um die Lösung zu optimieren. Zu Beginn erstellte das Team von Google eine Demo, um den Projektbeteiligten von Chefkoch zu erklären, wie die einzelnen Komponenten ineinandergreifen – etwa, wie ein Dataset strukturiert sein muss, um nach dem Modelltraining die gewünschten Ergebnisse weiter zu verbessern. Sie stellten eine lauffähige Demoversion einer voll funktionierenden API vor, die das Bild eines handschriftlichen oder gedruckten Rezepts verarbeitet und ein digitales Dokument ausgibt, in dem die verschiedenen Teile des Rezepts sauber extrahiert und voneinander getrennt sind.

Die neue Möglichkeit zum Digitalisieren von Offlinerezepten testet Chefkoch derzeit im Kochbuch. „Wir arbeiten daran, die Produktlösung zu verbessern, zu erweitern und produktionsreif zu machen“, erklärt dazu Adler.

Am Rezept feilen

Die Ergebnisse erster Tests sind ermutigend – das OCR-Feature erhält fast ausschließlich Bestnoten von den Nutzer*innen. Aufgrund des Feedbacks hat das Chefkoch Team bereits kleinere Änderungen am Training des Modells vorgenommen, um es besser an die Anforderungen der Zielgruppe anzupassen. Das Tool mit dem inoffiziellen Namen Handwritten Recipe Parser kann nun kontextabhängig Rechtschreibfehler erkennen, beispielsweise wenn in einem Rezept „Bären“ statt „Beeren“ steht.

Analog-zu-Digital-Angebot

Es gibt Pläne, den Handwritten Recipe Parser noch um weitere Funktionen zu ergänzen. Aktuell entwickeln die Mitarbeiter*innen von Chefkoch eine Funktion für das manuelle Bereitstellen von Rezepten. Auf diese Weise können Nutzer*innen eigene Rezeptbilder hochladen und den Titel, die Zutatenliste und die Zubereitungshinweise selbst hinzufügen. Auch für das Hinzufügen von Texten und handschriftlichen Notizen zu bestehenden Chefkoch-Rezepten ist in Planung.

Weitere Informationen zu Cloud AutoML und zur Vision API finden Sie auf unserer Website.

Bare-Metal-Lösung: aktuelle Regionen, Server und Zertifizierungen

Thu, 09 Sep 2021 17:00:00 +0000

Im Jahr 2021 bleibt vieles ungewiss. Sie können sich jedoch darauf verlassen, dass Google Cloud zu seinen Unternehmenskunden steht ebenso wie zu seiner Position als führender Anbieter einer offenen Cloud. Teil dieses Engagements für eine offene Cloud ist die Unterstützung verschiedenster Workloads sowie unserer Unternehmenskunden an ihrem Standort. Das alles bietet die Bare-Metal-Lösung, unsere Lösung zum Ausführen von Oracle-Datenbank-Workloads in Google Cloud.

Wir entwickeln die Bare-Metal-Lösung kontinuierlich weiter, um die Anforderungen unserer Kunden zu erfüllen. Hierzu möchten wir Ihnen den aktuellen Stand präsentieren:

Die Bare-Metal-Lösung ist seit diesem Jahr auch in Montreal und Iowa, unserer zehnten und elften Region, verfügbar.
Wir bieten zusätzlich einen neueren, kleineren 8-Kern-Server an.
Unsere Lösung unterstützt nun auch die Sicherheits- und Compliance-Standards PCI DSS und HIPAA.

Auch in diesem Jahr setzen wir weiter auf die Dynamik der Bare-Metal-Lösung von Google Cloud, mit der Unternehmen Oracle-Datenbanken mit äußerst niedriger Latenz in Google Cloud ausführen können. Ein Beispiel dafür stellen wir in unserem Blogbeitrag dar. Hier erfahren Sie, wie StubHub die Bare-Metal-Lösung nutzt, um seine Abhängigkeit von Oracle zu reduzieren, die Gesamtkosten zu senken und die Leistung zu verbessern.

Derzeitige Regionen

Letztes Jahr stellten wir die Bare-Metal-Lösung vor und boten sie zunächst in fünf Regionen an. Im Laufe des Jahres machten wir sie in vier weiteren Regionen verfügbar. Mit der Bereitstellung der Bare-Metal-Lösung in Montreal und Iowa bauen wir unsere Präsenz in Nordamerika weiter aus und bringen unsere Lösung nun auch nach Kanada, um unseren Unternehmenskunden eine lokale Verfügbarkeit zu bieten. Wir werden die Bare-Metal-Lösung in diesem Jahr weiterhin in einer ganzen Reihe neuer Regionen herausbringen (und sogar in Dual-Regionen anbieten, genauer gesagt in Regionen mit zwei separaten Zonen). Wir wissen, dass unsere Kunden lokale Optionen benötigen. Wenden Sie sich also bitte an unsere Google Cloud-Expertinnen und Experten, wenn Sie sich für die Bare-Metal-Lösung interessieren, damit wir Ihnen möglichst bald ein Angebot machen können. Die folgende Karte zeigt die elf Regionen, in denen die Bare-Metal-Lösung derzeit verfügbar ist:

Ein kleinerer Server, mit dem Sie bei Lizenz- und Hardwarekosten sparen

Damit Sie die Größe Ihrer Cloud-Workloads anpassen und Kosten reduzieren können, bieten wir Ihnen neben den bewährten Optionen einen neuen, kleineren 8-Kern-Server in all unseren Regionen. Durch diesen neuen 8-Kern-Server, der unsere hervorragenden Computing-, Speicher- und Netzwerkoptionen nutzt, beansprucht eine Migration zur Bare-Metal-Lösung weniger Hardware und kann somit die Lizenzkosten für Oracle reduzieren, die oft von der Anzahl der Kerne abhängen. Im Folgenden finden Sie unser vollständiges Angebot für Bare-Metal-Server, die in all unseren Regionen zur Verfügung stehen:

PCI DSS und HIPAA zur Unterstützung Ihrer Workloads

Die Bare-Metal-Lösung kann unsere Unternehmenskunden außerdem bei der Einhaltung von PCI DSS und HIPAA unterstützen. Mit Unterstützung für PCI DSS können unsere Einzelhandelspartner die Kreditkartendaten ihrer Kundinnen und Kunden nutzen und ihre Workloads gemäß den Payment Card Industry Data Security Standards (PCI DSS) ausführen. Unterstützung für HIPAA bedeutet auch, dass unsere Partner aus dem Gesundheitswesen gemäß den Anforderungen des Health Insurance Portability and Accountability Act (HIPAA) die Gesundheitsdaten ihrer Kundinnen und Kunden auf unseren Systemen verarbeiten können. Da wir in neue Regionen expandieren und daran arbeiten, auf bestimmte Branchen besser einzugehen, können Sie davon ausgehen, dass noch weitere regionale und branchenbezogene Zertifizierungen hinzukommen werden.

Wie Songkick seine Infrastruktur mit Memorystore vereinheitlicht

Fri, 04 Jun 2021 10:00:00 +0000

Wir von Songkick, als Teil der Warner Music Group, bieten unseren Nutzer:innen eine Suchfunktion für Konzerte und darüber hinaus eine Livemusik-Plattform, um Musikfans an Live-Events teilhaben zu lassen. Jährlich ermöglichen wir über 175 Millionen Musikfans aus aller Welt, ihren Lieblingskünstler:innen zu folgen, nach Konzerten und Livestreams zu suchen sowie auf sichere Weise über mobile Apps und online über eine Website Tickets zu buchen.

Wir beschäftigen in London etwa 15 Entwickler:innen in vier Teams. Meine Aufgabe ist es, diese Teams bei ihren technischen Entscheidungen und bei der Entwicklung von Lösungen zu unterstützen. Nach der Migration zu Google Cloud waren wir auf der Suche nach einer komplett verwalteten Caching-Lösung. Diese sollte sich nahtlos in die anderen von uns geschätzten Google-Tools einbinden lassen und unseren Entwickler:innen die Möglichkeit geben, innovative Produkte zu erstellen, die unsere Kund:innen begeistern. Memorystore, der skalierbare, sichere und hochverfügbare Speicherdienst von Google für Redis, war hierfür die richtige Lösung.

Mehr Zeit für Innovation dank des komplett verwalteten Memorystore-Dienstes

Unsere ursprüngliche Caching-Infrastruktur basierte ausschließlich auf lokalem Memcached, eine für uns damals einfach anwendbare Lösung. Schließlich haben wir auf Redis umgestellt, da wir dessen fortgeschrittene Features wie Wörterbücher und Zählerfunktionen nutzen wollten. In unserer dienstorientierten Architektur waren beide Open-Source-Datenspeicher im Einsatz. Wir hatten zwei Redis-Cluster: einen für nichtflüchtige Daten und einen anderen als einfache Caching-Ebene zwischen unserer Front-End-Anwendung und unseren Diensten.

Bei unseren Diskussionen über die Nutzung von Google Cloud wurde deutlich, dass die gleichzeitige Anwendung von zwei Caching-Technologien (Memcached und Redis) keinen echten Vorteil bietet. Wir haben uns dann ausschließlich für Redis entscheiden, da damit alle unsere Anwendungsfälle abgedeckt werden und wir so kein Know-how für zwei Datenbanken benötigen. Uns ist bewusst, dass Redis in der Anwendung und Verwaltung komplexer sein kann. Das ist für uns aber kein großes Problem, denn der von uns genutzte Memorystore wird komplett von Google Cloud verwaltet. Da durch Memorystore komplexe Redis-Aufgaben automatisiert werden, beispielsweise die Aktivierung von Hochverfügbarkeit, Failover, Patching und Monitoring, steht uns nun mehr Zeit für die Entwicklung innovativer Funktionen und Produkte zur Verfügung.

So fallen z. B. die Stunden weg, in denen wir bisher beschädigte Redis-Cluster und Netzwerkprobleme beheben mussten. Unser Team hat viel Erfahrung in der Entwicklung, aber weniger in der Verwaltung der Infrastruktur. Die Probleme mit Redis wurden deshalb für unser Team zum Störfaktor und kosteten Zeit. Darüber hinaus besteht bei einem selbstverwalteten Tool immer die Gefahr, dass es zu Ausfallzeiten für die Nutzer:innen kommt. Memorystore stellt dagegen eine sichere, komplett verwaltete Option dar, die kostengünstig ist und eine Lösung dieser Probleme bietet. Damit lassen sich die Vorteile von Redis ohne aufwendige Verwaltung nutzen. Die Entscheidung dafür fiel uns deshalb nicht schwer.

Wie wir Memorystore nutzen

Wenden wir uns nun einigen unserer Anwendungsfälle für Memorystore zu. Es gibt zwei Caching-Ebenen bei Memorystore: Die Front-End-Anwendung führt ein Caching der Ergebnisse von API-Aufrufen für unsere Dienste durch, andere Dienste erledigen das Caching der Datenbankergebnisse. In der Regel besteht unser Caching-Schlüssel für die Front-End-Dienste aus der URL und allen primitiven Werten, die übergeben werden. Anhand der URL und der Abfrageparameter prüft die Front-End-Anwendung, ob bereits Daten vorhanden sind oder ob sie mit dem Dienst Kontakt aufnehmen muss.

Einige unserer Dienste enthalten sogar eine eigene Caching-Ebene, die zuerst mit Redis kommuniziert und dann gegebenenfalls unsere Geschäftslogik abruft und eine Verbindung zu den Datenbanken herstellt. Dieses Caching sitzt vor dem Dienst und arbeitet nach den gleichen Regeln wie das Front-End-Caching.

Außerdem nutzen wir Fastly als Caching-Ebene vor unseren Front-Ends. Auf Seitenebene wird damit gegebenenfalls die gesamte Seite umfassend in Fastly zwischengespeichert, z. B. wenn eine Seite eine Bestenliste der Top-Künstler:innen auf der Plattform enthält.

Memorystore wird dann für Inhalte auf der Ebene der Benutzer:innen verwendet, etwa wenn eine Veranstaltungsseite Informationen über die Künstlerin oder den Künstler und/oder die Veranstaltung sowie Empfehlungen für Künstler:innen abruft. Falls der Fastly-Cache auf der Unterseite der Künstlerin oder des Künstlers abgelaufen ist, wird er an die Front-End-Anwendung übergeben, die dann die verschiedenen Dienste kontaktiert, um alle angeforderten Informationen auf der Seite zur Verfügung zu stellen. In diesem Fall können drei verschiedene Datenelemente in unserem Redis-Cache enthalten sein. Die Unterseiten der Künstler:innen enthalten außerdem Komponenten, die nicht in Fastly zwischengespeichert werden. Deshalb greifen wir sehr viel mehr auf Redis zurück.

Die Gültigkeitsdauer (Time-to-live, TTL) unseres Redis-Cache ist in der Regel recht kurz. Manchmal sind Einträge nur für 10 Minuten verfügbar. Bei sehr statischen Daten können diese dagegen für einige Stunden in Redis zwischengespeichert sein. Wir bestimmen für jedes Datenelement einen sinnvollen Caching-Zeitraum und legen dann auf dieser Grundlage die Gültigkeitsdauer fest. Angenommen, eine bestimmte Künstlerin oder ein bestimmter Künstler wird 100.000-mal am Tag aufgerufen. Schon ein 10-minütiger Cache hat dann einen großen Einfluss darauf, wie viele Aufrufe täglich an unseren Dienst übergeben werden müssen.

Für einen solchen Anwendungsfall haben wir einen hochverfügbaren Memorystore-Cluster von ca. 4 GB Arbeitsspeicher eingerichtet und nutzen eine Richtlinie zur Cache-Entleerung von allkeys-lru (zuletzt verwendete Schlüssel). Für diesen Cluster erhalten wir im Moment etwa 400 Anfragen pro Sekunde zu Spitzenzeiten. Dies ist das durchschnittliche tägliche Anfragevolumen, das unter bestimmten Bedingungen aber noch sehr viel höher ausfallen kann.

In unserer alten Infrastruktur hatten wir zwei verschiedene Redis-Cluster. Der erste Cluster entsprach dem gerade beschriebenen. Der zweite Cluster war ein nichtflüchtiger Redis-Cluster. Im Zuge der Migration zu Google Cloud haben wir dann beschlossen, Redis möglichst optimal zu nutzen. Dafür haben wir die vier oder fünf Features vereinfacht und neu konzipiert, die den nichtflüchtigen Redis-Speicher verwenden, entweder mithilfe von Cloud SQL for MySQL oder mit BigQuery. Manchmal nutzen wir Redis auch zum Aggregieren von Daten. In Google Cloud können wir dafür jetzt einfach BigQuery verwenden und haben so sehr viel bessere Analysemöglichkeiten als beim Aggregieren mit Redis.

Wir verwenden Memorystore auch für einen verteilten wechselseitigen Ausschluss. Bei bestimmten Aktionen in unserem System sollen einige Vorgänge nicht gleichzeitig ausgeführt werden. Dies gilt beispielsweise für die Migration von Daten für eine spezielle Veranstaltung, bei der zwei Administrator:innen zur gleichen Zeit versuchen, dieselbe Aufgabe durchzuführen. Wenn diese Datenmigration gleichzeitig ausgeführt wird, kann es zu Fehlern in unserem System kommen. Deshalb nutzen wir in solchen Fällen Redis als Sperre in Form eines wechselseitigen Ausschlusses zwischen verschiedenen Prozessen, um zu gewährleisten, dass sie nacheinander und nicht gleichzeitig ausgeführt werden.

Problemlose Zusammenarbeit von Memorystore und Redis

Seit der Migration sind keine Probleme mit Redis aufgetreten. Außerdem schätzen wir die Monitoring-Funktionen, die mit Memorystore einsatzfertig zur Verfügung stehen. Nach der Bereitstellung eines neuen Features können wir im Handumdrehen feststellen, ob es sofort Daten an den Cache übergibt oder ob die Trefferquote sehr niedrig ist. Letzteres weist darauf hin, dass die Implementierung fehlerhaft ist.

Ein weiterer Vorteil besteht darin, dass die Schnittstelle von Memorystore genau wie die von Redis funktioniert. Wir nutzen das herkömmliche Redis in einem Docker-Container in unseren Entwicklungsumgebungen. Wenn wir es dann lokal ausführen, können wir sofort feststellen, ob der Caching-Code exakt wie beabsichtigt funktioniert.

Wir arbeiten mit einer Produktions- und mit einer Staging-Umgebung. Beide Umgebungen werden als Virtual Private Clouds mit einem jeweils eigenen Memorystore-Cluster ausgeführt. Wir verwenden außerdem Unittests, die keinen direkten Einfluss auf die Redis-Nutzung haben, und Integrationstests, die sowohl mit lokalem MySQL in Docker als auch mit einem Redis-Speicher in Docker kommunizieren. Außerdem führen wir Akzeptanztests aus. Das sind Tests zur Browserautomatisierung in der Staging-Umgebung, die mit Cloud SQL und Memorystore kommunizieren.

Planung weiterer Schritte mit Memorystore

Für potenzielle zukünftige Anwendungsfälle von Memorystore werden wir ziemlich sicher unsere Infrastruktur mit Pub/Sub ergänzen. Außerdem werden wir Redis zum Deduplizieren von Nachrichten aus Pub/Sub nutzen, etwa damit eine E-Mail nicht kurz nacheinander mehrmals gesendet wird. Wir freuen uns auch schon auf die komplett verwalteten Pub/Sub-Dienste. Aktuell arbeiten wir mit RabbitMQ, für das aber zu oft ein Debugging notwendig ist. Wir haben Pub/Sub bereits probeweise für denselben Anwendungsfall genutzt. Da dies hervorragend funktioniert hat, lag auch dafür die Entscheidung auf der Hand.

Memorystore ist nur eine der Daten-Cloud-Lösungen von Google, die wir täglich nutzen. Dazu kommen noch Cloud SQL, BigQuery und Dataflow für ETL-Pipelines, Data-Warehouse-Prozesse und unsere Analyseprodukte. Damit aggregieren wir für Künstler:innen relevante Daten, führen diese nach MySQL zurück und stellen sie anschließend in unseren Produkten für Künstler:innen bereit. Wenn wir dann Pub/Sub einsetzen, nutzen wir im Prinzip jede Option des Google Cloud-Datenbanktyps. Das zeigt auch, wie zufrieden wir mit den Tools von Google Cloud sind.

Weitere Informationen zu unseren Musikdiensten und -produkten finden Sie auf der Songkick-Website. Möchten Sie mehr über Memorystore erfahren? Informieren Sie sich über Best Practices zur Leistungsoptimierung für Memorystore for Redis in unserem Blogartikel.

Große Pläne: warum sich Ricardo für Bigtable als Ergänzung zu BigQuery entschied

Mon, 12 Apr 2021 17:00:00 +0000

Mit über 3,7 Millionen Mitgliedern ist Ricardo der größte Online-Marktplatz der Schweiz. 2019 haben wir unsere lokalen Arbeitslasten erfolgreich zu Google Cloud migriert – ein Schritt, mit dem auch die Herausforderungen einiger neuer Anwendungsfälle auf uns zukamen. Da unser lokales Rechenzentrum bereits nicht mehr verfügbar war, standen wir bei der Suche einer Lösung für diese Anwendungsfälle unter Zeitdruck. Unser Schwerpunkt lag dabei in erster Linie auf der Verarbeitung von Datenstreams. Die von uns gewählte Lösung umfasst sowohl Cloud Bigtable als auch Dataflow von Google Cloud. Im Folgenden werfen wir einen Blick darauf, warum wir uns für diese Lösung entschieden und wie wir sie umgesetzt haben. Außerdem betrachten wir zukünftige Anwendungsfälle in unserer Roadmap.

Die Herausforderungen im Detail

Für Analysen hatten wir ursprünglich das Microsoft SQL Data Warehouse verwendet und uns dann für einen Wechsel zu BigQuery entschieden, dem Enterprise Data Warehouse von Google Cloud. Das zog auch die Verlagerung all unserer Workloads dorthin nach sich. Für die Importe und Batch-Loads von Kafka in BigQuery setzten wir Apache Beam ein.

Wir wollten unseren internen Teams die Möglichkeit geben, über unser Informationsportal Aufgaben zur Betrugserkennung durchzuführen. Auf diese Weise können unsere Kundinnen und Kunden besser vor betrügerischen Warenangeboten und Personen geschützt werden, die gestohlene Identitäten verwenden.

Außerdem mussten sich unsere Entwicklerinnen und Entwickler zügig mit der Frage befassen, wie wir unsere beiden Hauptdatenstreams zusammenführen können, da diese bisher in getrennten Systemen gespeichert waren. Der eine ist für Artikel, also im Wesentlichen für die Verkaufsangebote auf unserer Plattform. Der andere ist für Assets, die verschiedene Beschreibungen zu den Artikeln enthalten. Zunächst haben wir die Datenstreams in BigQuery eingefügt und dann einen JOIN durchgeführt. Eine der Herausforderungen liegt darin, dass Ricardo schon ziemlich lange besteht. So kann es vorkommen, dass ein Artikel seit 2006 nicht mehr gespeichert wurde oder neu gelistet wird, wodurch eventuell Daten im Asset-Stream fehlen.

Ein Problem, mehrere Lösungswege

Bei der Suche nach Lösungen für unsere Problematik mit den Datenstreams stieß ich auf einen Beitrag im Google Cloud Blog mit einer Anleitung für gängige Anwendungsmuster in Dataflow (dem einheitlichen Stream- und Batch-Verarbeitungsdienst von Google Cloud) und einem Abschnitt zu großen Suchtabellen im Streamingmodus. Zusätzlich zu unserem Artikel-Stream verfügen wir über eine etwa 400 GB große Suchtabelle mit Assets. Wir mussten aber auch in der Lage sein, das entsprechende Asset für einen Artikel nachzuschlagen. Laut Anleitung könnte ein spaltenorientiertes System diese Art von Abfrage in Millisekunden beantworten. Außerdem ließe es sich in einer Dataflow-Pipeline für Suchabfragen und zum Aktualisieren der Tabelle verwenden.

Wir hatten demnach zwei Optionen, um den Anwendungsfall zu lösen. Einen Versuch starteten wir mit einem Prototyp auf Basis von Apache Cassandra, der quelloffenen spaltenorientierten NoSQL-Datenbank. Hierbei sollte von BigQuery aus mit Apache Beam gestreamt werden, um Verlaufsdaten vorab zu laden.

Wir erstellten einen neuen Cassandra-Cluster auf Google Kubernetes Engine (GKE) und verwendeten dabei den von Datastax als Open Source veröffentlichten CASS Operator. Anschließend bauten wir eine Indexstruktur auf, optimierten das Ganze, führten einige Benchmarks durch und stellten erfreut fest, dass alles funktionierte. Damit besaßen wir nun also einen funktionsfähigen Cassandra-Cluster – die Pipeline nahm Assets und Artikel auf, und die Assets wurden aus dem Cassandra-Speicher abgerufen, wo sie auch gespeichert waren.

Was aber war mit den alltäglichen Aufgaben und Herausforderungen des Betriebs? Unser Data-Intelligence-Team (DI) beispielsweise muss völlig autark sein. Wir sind ein kleines Unternehmen. Daher müssen wir schnell handeln und möchten kein System aufbauen, das schon bald wieder veraltet ist.

Die verwalteten Dienste von BigQuery nutzten wir bereits und waren auch sehr zufrieden mit ihnen. Es war daher naheliegend, den vollständig verwalteten, spaltenorientierten NoSQL-Datenbankdienst Bigtable mit niedriger Latenz zu nutzen.

13-prozentige Netto-Kostenersparnis mit Bigtable

Was die laufenden Kosten betrifft, konnte Cassandra mit Bigtable jedoch nicht ganz mithalten. Wir stellten fest, dass Cassandra für die Verfügbarkeitsgarantien drei Knoten benötigt. Mit Bigtable hingegen konnten wir eine fehlertolerante Datenpipeline beziehungsweise Apache Beam-Pipeline einsetzen, die auf Apache Flink läuft. Selbst bei geringer Verfügbarkeit bestand Fehlertoleranz, sodass wir keine drei Knoten betreiben mussten. Für die Aufnahme der Verlaufsdaten aus BigQuery in die Suchtabelle in Bigtable verwendeten wir 18 Knoten. Nach der Übertragung konnten wir diese dann problemlos auf einen oder zwei Knoten herunterskalieren, da jeder von ihnen bis zu 10.000 Zeilen pro Sekunde einlesen kann. Bigtable kümmert sich im Hintergrund um Verfügbarkeit und Stabilität und kann daher sogar mit nur einem Knoten eine garantierte Leistung bieten.

Diese Tatsache hat ganz deutlich werden lassen, dass die Bigtable-Lösung nicht nur einfacher zu verwalten ist als Cassandra, sondern auch kostengünstiger. Wenn wir als kleines Team die laufenden Schulungskosten, die Ausfallzeiten und den für die Cassandra-on-GKE-Lösung erforderlichen technischen Support einkalkulieren, war es schon allein deshalb naheliegender, für den Anfang 1 TB in einer Bigtable-Instanz statt in der Cassandra-on-GKE-Lösung zu verwenden, für die ein dreifacher E2-Knoten-Cluster erforderlich ist - auch wenn die einzelnen Knoten mit einer 8-CPU-VM ziemlich klein sind. Bigtable war die einfachere, schnellere und kostengünstigere Lösung. Durch die Verlagerung solcher Suchabfragen auf Bigtable konnten wir letztendlich 13 % der BigQuery-Kosten einsparen. (Bitte beachten Sie, dass es sich hierbei um Nettoeinsparungen handelt – die zusätzlichen Kosten für den Betrieb von Bigtable sind also bereits eingerechnet).

Nachdem diese neue Lösung erst einmal angelaufen war, verlagerten wir eine weitere Arbeitslast zu Bigtable: die Einbindung von Daten aus Zendesk-Tickets für unser Serviceteam. Wir haben Informationen von Kundinnen und Kunden in Bigtable verfügbar gemacht und die Produktschlüsselsuche mit den Zendesk-Daten verknüpft, damit den betreuenden Mitarbeiter:innen die Informationen unserer Kund:innen sofort angezeigt werden konnten.

Vorteile der nahtlosen Einbindung von Google Cloud-Tools

Für ein kleines Unternehmen wie wir es sind, hat der Aufbau einer leicht zugänglichen Dateninfrastruktur eine hohe Priorität. Für uns ist Bigtable unser Speicher, in dem verarbeitete Daten für unsere Dienste zur Verwendung bereitstehen. Die Einbindung der Dienste in Bigtable, BigQuery und Dataflow macht es für uns so einfach, diese Daten verfügbar zu halten.

Ein weiterer Grund, der für die Google Cloud Platform spricht, ist aus unserer Sicht das Tempo, mit dem wir Anpassungen an Dataflow und BigQuery vornehmen können. Als ich zum Beispiel eines Morgens über ein laufendes Projekt nachdachte, wurde mir klar, dass wir die Artikel-ID hätten umkehren sollen. Sie sollte besser in umgekehrter Reihenfolge gespeichert werden, um ein Heißlaufen zu verhindern. Dafür konnten wir mühelos und schnell auf 20 Bigtable-Knoten und 50 Dataflow-Worker hochskalieren. Die Batch-Jobs lasen die Daten aus BigQuery aus und schrieben sie mit Bigtable in das neu erstellte Schema. Das Ganze hat gerade einmal 25 Minuten gedauert. Vor dem Umstieg auf Bigtable hätte uns eine solche Anpassung mehrere Tage gekostet.

Key Visualizer von Bigtable eröffnet neue Möglichkeiten

Die Idee zum Umkehren der Artikel-ID kam mir beim Nachdenken über den Key Visualizer von Bigtable, der im Vergleich zu unserem vorherigen Setup sehr übersichtlich gestaltet und einfach zu bedienen ist. Die Einbindung ist absolut nahtlos und einfach zu erklären.

Wir verwenden SSD-Knoten und müssen uns bei der Konfiguration nur um die Anzahl der Knoten kümmern und darum, ob wir eine Replikation wollen oder nicht. Das ist so einfach wie den Lautstärkeregler an einer Stereoanlage zu drehen – und eine Sache, die mich wirklich beeindruckt hat. Die Skalierung nach oben und unten geht enorm schnell. Mit Dataflow gehen keine Daten verloren, es muss nichts vorgewärmt werden, wir erstellen einfach einen Zeitplan und verteilen die Ressourcen während des Betriebs. So eine einfache Skalierung haben wir noch nie erlebt.

Mögliche zukünftige Anwendungsfälle für Bigtable

Was zukünftige Anwendungsfälle betrifft, arbeiten wir an einem Projekt zur besseren Betrugserkennung mit Machine Learning (ML), das wir später zu Bigtable migrieren möchten. Derzeit haben wir einen Prozess, der über Airflow einmal pro Stunde den Python-basierten Cloud Composer auslöst. Dieser nimmt die Daten der letzten Stunde aus BigQuery und geht sie durch. Dabei wird der Python-Container mit dem ML-Modell ausgeführt, das geladen wird und die Daten als Eingabe verwendet. Wenn der Algorithmus einen Artikel mit hundertprozentiger Sicherheit als betrügerisch einstuft, wird das Produkt gesperrt. Um die Sperrung wieder aufzuheben, ist eine manuelle Anfrage des Serviceteams erforderlich. Wenn der Algorithmus nicht ganz sicher ist, landet der Artikel im Posteingang der Abteilung und wird markiert, sodass das Team ihn überprüfen kann.

Was derzeit im Prozess fehlt, ist eine automatisierte Feedbackschleife, eine Lernanpassung, wenn das Serviceteam antwortet: „Das ist kein Betrug.“ Wir könnten zwar etwas Passendes für diese Aktion programmieren, aber wir benötigen eine schnellere Lösung. Es wäre sinnvoller, dies direkt über die Pipeline aus Bigtable in die Lernmodelle zu übertragen.

In Zukunft würden wir auch gerne die Dataflow-Pipeline für alle wichtigen Themen gleichzeitig in BigQuery und Bigtable schreiben lassen. Dann könnten wir diese Art von Anwendungsfällen direkt aus Bigtable statt aus BigQuery heraus bearbeiten und so annähernd in Echtzeit reagieren.

Dank der 13-prozentigen Einsparungen bei den BigQuery-Kosten und der nahtlosen Einbindung aller verwalteten Google Cloud-Dienste, wie Bigtable, ist unser kleines (aber tatkräftiges) DI-Team von den lästigen Aufgaben befreit, die auf unserer Datenplattform anfallen. Wir können diese Zeit in die Lösungsentwicklung für zukünftige Anwendungsfälle und weitere Projekte investieren.

Wenn Sie mehr über uns erfahren möchten, sehen Sie sich unsere Angebote auf Ricardo.ch an oder finden Sie weitere Informationen über den cloudnativen Schlüssel-Werte-Speicher Bigtable auf der Google Cloud-Website.

Google stellt die Weichen für eine moderne Cloud

Tue, 02 Feb 2021 17:30:00 +0000

Google Cloud ist ein führender Anbieter in der Welt der Daten. In den letzten Jahren haben wir erstaunliche Fortschritte erzielt und können so unsere Kundinnen und Kunden bei der Modernisierung ihrer Unternehmensdatenbanken und Analysefunktionen noch besser unterstützen. Unsere Datenplattform ist einer der ausschlaggebenden Gründe, warum die größten Unternehmen der Welt wie The Home Depot, HSBC und UPS ihre geschäftskritischen Anwendungen in Google Cloud ausführen. Auch in der Analysten-Community konnten wir neue Impulse sehen. Gartner, Forrester und IDC haben uns in ihren Analystenberichten als einen der führenden Anbieter in den Bereichen Datenanalysen, Datenbanken und KI eingestuft. Unternehmen vertrauen auf unsere vollständig verwalteten Datenbank- und Analysedienste für die digitale Transformation in einer hochvernetzten und ständig aktiven Welt, in der Arbeitslasten zunehmend in die Cloud migriert werden.

Google wurde mit dem Ziel gegründet, die Informationen dieser Welt zu organisieren und für jedermann zugänglich und nützlich zu machen. Um diese Vision zu verwirklichen, verarbeiten und analysieren wir die weltweit größten Datensätze in einer der übersichtlichsten und zuverlässigsten Cloud-Infrastrukturen. Wir haben dieses Fachwissen genutzt, um unseren Kund:innen eine auf Unternehmen zugeschnittene neue Art von Cloud zu bieten, die einfach, intelligent und offen ist. Die integrierten Automatisierungsfunktionen sorgen für optimale Geschäftsabläufe in datenorientierten Unternehmen und erlauben diesen, Ihr nächstes Projekt einfach und ohne Umstände zu entwickeln.

Sehen wir uns fünf Gründe an, die uns zu einer Führungsposition auf dem Cloud-Markt verholfen haben:

1. Führende Marktforschungsunternehmen sind sich einig, dass sich die Datenbank- und Analyseoptionen von Google Cloud für datenorientierte Unternehmen jeglicher Größe eignen. Unsere Unternehmenskunden verarbeiten und analysieren Petabyte von Daten auf einer der weltweit fortschrittlichsten und skalierbarsten Datenplattformen. Unabhängig von ihrer Größe und ihrem digitalen Reifegrad sind diese Unternehmen in der Lage, nahtlos zu wachsen – von kleinen Prototypen bis hin zu weltweitem Erfolg. Die einmalige Kombination einer relationalen operativen Datenbank mit nicht relationaler Skalierung macht Cloud Spanner zum Vorreiter in der relationalen Welt. Cloud Bigtable ist auf Anwendungen mit hohem Durchsatz und niedriger Latenz ausgerichtet und unterstützt bis zu mehrere Millionen Abfragen pro Sekunde. Google Cloud bietet branchenführende Zuverlässigkeit über Regionen hinweg, sodass Sie Ihre geschäftskritischen Anwendungen jederzeit schnell und mühelos einrichten können. Google bietet SLAs mit besonders hohen Verfügbarkeiten. Für Spanner kann ein SLA von bis zu 99,999 % Verfügbarkeit abgeschlossen werden, und für BigQuery seit Kurzem ein SLA von 99,99 %. Externe Marktforschungsunternehmen haben Google Cloud mehrfach als führenden Anbieter im Hinblick auf skalierbares Hochleistungs-Datenmanagement für Analysen eingestuft. Um all dies anbieten zu können, werden solide Sicherheits- und Governance-Kontrollen benötigt, mit deren Hilfe die Daten unserer Kundinnen und Kunden geschützt werden. Die bei uns gespeicherten Daten werden standardmäßig verschlüsselt, und für die Identitäts- und Zugriffsverwaltung bei all unseren Lösungen nutzen wir Cloud Identity and Access Management (Cloud IAM).

2. Google Cloud unterhält weltweit und branchenübergreifend eine der am schnellsten wachsenden Clouds. Wir verzeichnen Wachstum in allen Kundensegmenten und Branchen. BigQuery gilt allgemein als marktführende Lösung für Analysen und Data-Warehousing-Prozesse. Mit der Multi-Cloud-fähigen Plattform Looker und ihrer universellen semantischen Ebene können Unternehmen schnell Informationen aus Daten gewinnen. Unsere Datenbankdienste Spanner und Cloud SQL unterstützen geschäftskritische Anwendungen und setzen neue Maßstäbe hinsichtlich Skalierbarkeit, Verfügbarkeit und Leistung. Laut einer aktuellen Studie von SlashData ist Cloud Firestore von allen Cloud-Datenbanken auf dem Markt sogar die bevorzugte Dokumentendatenbank unter Entwicklerinnen und Entwicklern. Auch Cloud SQL hat im letzten Jahr an Beliebtheit gewonnen und zählt nun zu den Google Cloud-Diensten mit dem schnellsten Wachstum. Mit der Einführung von Database Migration Service ist es für Unternehmen nun noch einfacher, von ihrer lokalen Infrastruktur oder anderen Clouds zu Cloud SQL zu migrieren, ohne ihre Geschäftsabläufe zu unterbrechen. Unsere Führungsposition im Datensektor hat maßgeblich dazu beigetragen, dass Unternehmen wie HSBC, Major League Baseball, Mayo Clinic und ShareChat zur Ausführung ihrer datengestützten Anwendungen auf Google vertrauen. Und dies ist auch der Grund, weshalb IDC unsere Datenplattform im MarketSpace-Bericht „APeJ Cloud Data Analytics Platform 2020“ als eine der führenden einstuft.

3. Datenbanken und Analysen von Google Cloud gründen auf einer offenen Philosophie, zu der Open-Source-Software und -Datenbanken, offene APIs, offene Datenformate und ein umfassendes Partnernetzwerk gehören. Unsere Kunden und Kundinnen können aus einer breiten Palette von operativen und analytischen Engines, Open-Source-Tools und ML-Diensten (Machine Learning) auswählen. Cloud SQL ist ein verwalteter Dienst für die weltweit gängigsten Open-Source-Datenbanken MySQL und PostgreSQL, über den die neuesten Errungenschaften der Community sowie Verfügbarkeit, Sicherheit und Leistung auf Großkunden-Niveau verfügbar sind. Offene APIs vereinfachen die Migration und Portabilität sowie den Datenzugriff über Ihre bevorzugten Tools. Außerdem sorgt unsere offene Plattform für sofort verfügbare Interoperabilität zwischen einer Vielzahl von Diensten zum Aufnehmen, Speichern, Verarbeiten und Analysieren von Daten – darunter Apache Spark, Presto usw. Und dank unseres breit gefächerten Partnernetzwerks und der vielfältigen Einbindungsoptionen in unsere wichtigsten Google-Dienste (z. B. Google Analytics) können Sie die von Ihrem Team bevorzugten Datenquellen und -technologien schnell und nahtlos einbinden. Der Erfolg unserer Unternehmenskunden und Partnerunternehmen ist uns wichtig. Unsere offene und partnerfreundliche Plattform ermöglicht unseren Nutzerinnen und Nutzern die Skalierung ihrer Daten- und Analyseanforderungen, während Partner wie Elastic, Confluent und MongoDB auf diesem Wege umfassendere Lösungen anbieten und ihre Cloud-Dienste so besser vermarkten können.

4. Mit Google können Unternehmen ihre größten datenbezogenen Herausforderungen mit vorkonfigurierten horizontalen und vertikalen Analyselösungen meistern, in denen marktführende KI-Technologie eingebettet ist. Mit kostengünstigen, von Partnerunternehmen unterstützten Paketlösungen können Sie sowohl die Abläufe im Service für Kundinnen und Kunden und die Dokumentenverarbeitung verbessern als auch zielgerichtete Branchenlösungen für das Gesundheitswesen, den Einzelhandel, Fertigung und Industrie, Finanzdienstleistungen, Medien und Unterhaltung bieten. Unternehmen, die ihr Geschäft auf neue Kanäle ausweiten und Echtzeiterlebnisse bieten möchten, können mit Firestore die Entwicklung von mobilen Anwendungen, Webanwendungen und IoT-Anwendungen beschleunigen. Mit Firestore können Entwicklungsteams im Handumdrehen zuverlässige Echtzeit-Anwendungen erstellen und entsprechend den Anforderungen moderner Organisationen skalieren. Unternehmen können auch ihre eigenen Analyselösungen entwickeln, um Daten abzufragen. Mit BigQuery ML, Dataproc Hub, Connected Sheets und Data QnA können alle Mitglieder einer Organisation – von geschäftlichen Nutzer:innen bis hin zu Data Scientists – mühelos Informationen aus Daten gewinnen. „Mit Connected Sheets übertragen wir Daten nicht einfach nur in Tabellen; vielmehr leben diese Daten in der jeweiligen Datenbank“, so Peter Van Nieuwerburgh, Global Change Manager bei PwC. „Dieses einfache Analysieren und Visualisieren von Daten ist äußerst nützlich.“

5. Wir sind der einzige Hyperscale-Cloud-Anbieter mit einer Multi-Cloud-Vision. Dank des Multi-Cloud-Modells von Google Cloud können Kundinnen und Kunden ihre Daten jederzeit und überall nutzen. Sie können ihre Anwendungen überall erstellen oder modernisieren und neue Anwendungsfeatures schneller bereitstellen, um in diesem sich rasch verändernden Umfeld erfolgreich zu sein. Laut Branchenanalysten ist Google Cloud der erste Hyperscale-Cloud-Anbieter, der sein Multi-Cloud-Versprechen erfüllt. Google Cloud bietet dank offener Standards Raum für Innovation und sorgt dafür, dass Nutzer:innen den richtigen Cloud-Anbieter bzw. die richtige Cloud-Umgebung für jede ihrer Arbeitslasten auswählen und nicht mehr von einem einzigen IT-Anbieter abhängig sind. Kundinnen und Kunden können Anwendungen überall ausführen und die Verwaltung und den Support von Google Cloud nutzen. Entwicklungsteams haben somit die Möglichkeit, neue Features schnell zu erstellen und in jeder beliebigen Umgebung im Handumdrehen bereitzustellen, auch lokal. Mit Lösungen wie Anthos können Nutzer:innen Container verwenden, um Cloud-Angebote in einer Hybridumgebung auszuführen. Diese Architektur kann auch in einer Multi-Cloud-Umgebung ausgeführt werden und wird derzeit auf AWS ausgeführt. Mit Dataproc in Kubernetes können Unternehmen containerisierte Spark-ML- und Datenverarbeitungsjobs erstellen, die überall bereitgestellt werden können. Mit BigQuery Omni können Sie außerdem Daten auf AWS mit Standard-SQL analysieren, ohne die vertraute BigQuery-Oberfläche zu verlassen.

Das ist erst der Anfang

Wo es um Daten geht, ist Google ein führender Anbieter. Unsere Systeme, unsere Dienste und unser Fachwissen beruhen auf der gleichen Dateninfrastruktur, die wir für Google-Produkte wie Google Suche, Maps, Ads und YouTube entwickelt haben, und die Milliarden Menschen verwenden. Wir haben dieses Fachwissen genutzt, um allen datenorientierten Unternehmen eine neue Art von Cloud mit vollständig verwalteten Automatisierungen zu bieten, die für optimale Geschäftsabläufe sorgt und das einfache Erstellen neuer Features ermöglicht. Wir werden uns auch in Zukunft dafür einsetzen, dass unsere Kundinnen und Kunden weniger Zeit für die Verwaltung aufwenden müssen und mehr Zeit für die Entwicklung von Innovationen bekommen. In diesem Sinne bieten wir Ihnen eine Daten-Cloud, in der Daten und Analysen entsprechend den Anforderungen Ihres Unternehmens vollständig in Multi-Cloud- und Hybridumgebungen eingebunden sind.

Bleiben Sie auf dem Laufenden und nutzen Sie noch heute unser kostenloses Testangebot.

^{Gartner, Magic Quadrant for Cloud Database Management Systems, 23. November 2020, Donald Feinberg, Adam Ronthal, Merv Adrian, Henry Cook, Rick Greenwald}

^{Gartner unterstützt keine Anbieter, Produkte oder Dienstleistungen, die in diesen Veröffentlichungen aufgeführt werden, und rät Nutzer:innen von Technologien in keiner Weise dazu, nur Anbieter mit hohen Bewertungen oder bestimmten Bezeichnungen auszuwählen. Die Marktforschungspublikationen von Gartner enthalten ausschließlich Auffassungen des Marktforschungsinstituts Gartner und sollten nicht als gegebene Tatsachen ausgelegt werden. Gartner lehnt jegliche Gewährleistungen, ob ausdrücklich oder implizit, in Bezug auf diese Marktforschungsarbeit ab, einschließlich aller Gewährleistungen hinsichtlich der Gebrauchstauglichkeit oder der Eignung für einen bestimmten Zweck.}

Gartner stuft Google in seinem Magic Quadrant 2020 für Datenbankmanagementsysteme als einen führenden Anbieter ein

Wed, 27 Jan 2021 17:30:00 +0000

Google wurde im ersten Gartner Magic Quadrant für Datenbankmanagementsysteme (DBMS) 2020 als einer der führenden Anbieter eingestuft. Wir bei Google Cloud fühlen uns geehrt und glauben, dass wir diese Anerkennung aufgrund unserer Vision und Strategie für Datenanalysen und Datenbanken erhalten haben. Unsere Kunden, die sich über alle Branchen und Regionen immer häufiger für Google Cloud als ihre Datenplattform entscheiden, geben uns recht.

Gartner hat Google im Magic Quadrant auf der Achse für Unternehmen mit umfassender Vision als eins von drei führenden Unternehmen positioniert. Wir erfüllen unsere Versprechen hinsichtlich Multi-Cloud und Hybrid-Cloud und können mittlerweile einen vielfältigen Kundenstamm in den verschiedensten Regionen und Branchen vorweisen. Wir setzen einen neuen Standard für flexible Preisgestaltung, bieten starke Funktionen für Financial Governance und können auf Partnerschaften in vielen Bereichen vertrauen. Wir lassen unsere Vision Realität werden und sind stolz darauf, mit BigQuery Omni der erste Hyperscale-Anbieter mit einem Multi-Cloud Data Warehouse im Portfolio zu sein. Darüber hinaus bieten wir mit Rabatten für zugesicherte Nutzung über alle Cloud SQL Engines hinweg das flexibelste Preismodell der Branche. Mit Data QnA erhalten Unternehmen sofort umfassende Informationen über ihren gesamten Geschäftsbetrieb. Cloud Spanner schließlich sorgt für eine höhere Zuverlässigkeit und mehr Benutzerfreundlichkeit bei der Entwicklung. Und das sind nur einige der zahlreichen Vorteile.

Heutzutage sollte es selbstverständlich sein, dass Unternehmen auf ein umfassendes Portfolio an Datenanalyse- und Datenbankdiensten zurückgreifen, sofern sie ihre Daten optimal nutzen möchten. Hierbei ist es nicht sinnvoll, Anwendungsfälle für Analysen und operative Nutzung getrennt voneinander zu betrachten. Die Märkte für Datenbankmanagementsysteme für operative Nutzung und Analyse sind näher zusammengewachsen, und somit ist es nur folgerichtig, wenn Gartner seine Bewertungen in einem einzelnen DBMS Magic Quadrant zusammenfasst. Dieser Magic Quadrant enthält nun Anbieter und Produkte, die beide Arten von Anwendungsfällen unterstützen. Wir waren schon in den beiden vorherigen Magic Quadrants unter den führenden Anbietern und begrüßen dieses neue Vorgehen sehr, da es die Art und Weise widerspiegelt, wie unsere Unternehmenskunden unsere Dienste einkaufen, implementieren und nutzen.

Fokus auf Innovationen beim Kunden statt Infrastruktur

Unternehmen wie Procter & Gamble, Vodafone und Sharechat setzen auf die vollständig verwaltete Datenplattform von Google Cloud, um ihre Produkte schneller zu erstellen und zu skalieren sowie gleichzeitig das digitale Kundenerlebnis zu verbessern.

„Wir geben immer unser Bestes, um unseren Kund:innen eine erstklassige Erfahrung zu ermöglichen – ob bei Produkten aus dem Bereich der Gesundheit, der Schönheitspflege oder in anderen Bereichen“, so Vittorio Cretella, CIO, Procter & Gamble. „Als ein führender Anbieter bei Analysen und KI ist Google Cloud für uns ein strategischer Partner, mit dem wir unseren Verbraucher:innen sicher und transparent ausgezeichnete Produkte und Dienste mit echtem Nutzen bieten können.“

Wir fühlen uns geehrt, im Gartner Magic Quadrant 2020 für Cloud-Datenbankmanagementsysteme (DBMS) unter den führenden Anbietern aufgeführt zu sein, und freuen uns darauf, Sie auf Ihrem Weg durch die digitale Transformation als Partner für fortlaufende Innovationen zu unterstützen.

Laden Sie den vollständigen Bericht 2020 Gartner Magic Quadrant for Cloud Database Management Systems herunter.

Starten Sie jetzt kostenlos mit Google Cloud.

^{Gartner, Magic Quadrant for Cloud Database Management Systems, 23. November 2020, Donald Feinberg, Adam Ronthal, Merv Adrian, Henry Cook, Rick Greenwald}

^{Diese Grafik wurde von Gartner, Inc. im Rahmen eines umfangreicheren Marktforschungsberichts veröffentlicht und sollte im Kontext des gesamten Dokuments gesehen werden. Die Veröffentlichung von Gartner erhalten Sie auf Anfrage bei Google Cloud.}

^{Gartner unterstützt keine Anbieter, Produkte oder Dienstleistungen, die in diesen Veröffentlichungen aufgeführt werden, und rät Nutzern von Technologien in keiner Weise dazu, nur Anbieter mit hohen Bewertungen oder bestimmten Bezeichnungen auszuwählen. Die Marktforschungspublikationen von Gartner enthalten ausschließlich Auffassungen des Marktforschungsinstituts Gartner und sollten nicht als gegebene Tatsachen ausgelegt werden. Gartner lehnt jegliche Gewährleistung, ob ausdrücklich oder implizit, in Bezug auf diese Marktforschungsergebnisse ab, einschließlich aller Gewährleistungen hinsichtlich der Gebrauchstauglichkeit oder der Eignung für einen bestimmten Zweck.}

Microsoft SQL Server-Arbeitslasten zu Google Cloud migrieren

Mon, 24 Feb 2020 18:04:00 +0000

Die Arbeitslasten von Unternehmensdatenbanken bilden das Rückgrat vieler Anwendungen und Systeme. Auch die garantierte Verfügbarkeit ist bei der Wahl eines Cloud-Anbieters entscheidend. Viele Unternehmen haben ihre geschäftskritischen Anwendungen auf Microsoft SQL Server 2008 aufgebaut und es ist üblich, weiterhin ältere Versionen von SQL Server zu nutzen, während sie ihre lokale Umgebung Schritt für Schritt modernisieren. Laut Business Insider verwenden 60 % der Nutzer*innen von Microsoft noch immer SQL Server 2008, der seit Juli 2019 nicht mehr verfügbar ist. Dies ist für viele eine Möglichkeit, ihre SQL Server 2008-Instanzen auf neueren Technologien mit weniger Administrationsaufwand zu hosten.

Ab sofort ist Cloud SQL for SQL Server generell weltweit verfügbar. Mit Cloud SQL können Sie Ihre SQL Server-Arbeitslasten ausführen und ein Service Level Agreement (SLA) mit einer Verfügbarkeit von 99,95 % garantieren, was den anderen Datenbank-Engines von Cloud SQL entspricht. Cloud SQL for SQL Server ist vollständig verwaltet und mit SQL Server 2017 kompatibel. Nun können Sie Ihre geschäftskritischen SQL Server-Arbeitslasten aus der Produktion in die Google Cloud migrieren und sich auf die Stabilität und Zuverlässigkeit des Dienstes verlassen.

Wir wissen von Unternehmen, wie wichtig es für die Erreichung ihrer Ziele im Hinblick auf die Modernisierung der Infrastruktur und die Multi-Cloud-Strategie ist, zu Cloud SQL for SQL Server migrieren zu können. Lokale Anwendungen wie HR-, Finanz- und Gehaltsabrechnungssysteme laufen häufig nur mit diesen veralteten Datenbanken. Kunden sprechen oft von der Herausforderung, die Kompatibilität mit diesen bestehenden Systemen und Datensätzen aufrechtzuerhalten und gleichzeitig die Bereitstellung zu optimieren und den Aufwand auf einen Bruchteil zu reduzieren. Durch die Migration dieser Instanzen zu Cloud SQL for SQL Server können Kosten und Wartungszeiten reduziert sowie die Effizienz und Geschwindigkeit gesteigert werden.

Erste Schritte bei der Migration von SQL Server 2008

Die Migration von Microsoft SQL Server 2008 zu Cloud SQL for SQL Server erfolgt in fünf einfachen Schritten. Ausführliche Informationen finden Sie im vollständigen Migrationsleitfaden unter: Daten zwischen SQL Server 2008 und Cloud SQL for SQL Server mithilfe von Sicherungsdateien migrieren.

1. Erstellen Sie eine Cloud SQL for SQL Server-Instanz

code_block: <ListValue: [StructValue([('code', 'gcloud beta sql instances create target \\\r\n --database-version=SQLSERVER_2017_ENTERPRISE \\\r\n --cpu=2 \\\r\n --memory=5GB \\\r\n --root-password=sqlserver12@ \\\r\n --zone us-central1-f'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f73875298b0>)])]>

2. Erstellen Sie nun einen Cloud Storage-Bucket

code_block: <ListValue: [StructValue([('code', 'gsutil mb -b off -l US "gs://bucket-name"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f73875297f0>)])]>

3. Sichern Sie Ihre Microsoft SQL Server 2008-Datenbank

code_block: <ListValue: [StructValue([('code', 'osql -E -Q "BACKUP DATABASE db-name TO DISK=\'c:\\backup\\db-name.bak\'"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f7387220fd0>)])]>

4. Importieren Sie die Datenbank in Cloud SQL for SQL Server

code_block: <ListValue: [StructValue([('code', 'gcloud beta sql import bak target \\\r\n gs://bucket-namedb-name.bak \\\r\n --database db-name'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f7387220b80>)])]>

5. Validieren Sie die importierten Daten

code_block: <ListValue: [StructValue([('code', '/opt/mssql-tools/bin/sqlcmd -U sqlserver -S 127.0.0.1 -Q "query-string"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f7387220f40>)])]>

Wenn Sie mit neueren Versionen von SQL Server arbeiten, lesen Sie sich diesen Migrationsleitfaden durch: Daten mithilfe von Sicherungsdateien zwischen SQL Server 2017 und Cloud SQL for SQL Server migrieren.

Seit der Einführung von Cloud SQL for SQL Server haben wir dank Ihrer Rückmeldungen die Leistung und die Langlebigkeit des Dienstes verbessert. Wir möchten unser hohes Tempo bei Innovationen und der Einführung neuer Funktionen beibehalten, um die Anforderungen unserer Kunden zu erfüllen und auf ihr Feedback einzugehen. Cloud SQL for SQL Server hat sich als Schlüsselkomponente bei der Migration bestehender Unternehmensanwendungen und -infrastrukturen bewährt.

Wir arbeiten weiterhin an der raschen Optimierung von Cloud SQL for SQL Server, um all Ihre Anforderungen an Cloud-Datenbanken zu erfüllen. Seien Sie gespannt auf künftige Funktionen, die Sie bei der Integration von Active Directory, Online-Migrationen und weiteren Optionen für Replikate und Maschinentypen unterstützen können.

Wie Google Cloud Ihnen helfen kann

Sichern Sie sich ein Guthaben von 300 $, um Cloud SQL und generell Google Cloud zu testen. Dabei können Sie mit kostengünstigen Mikroinstanzen zum Testen und für die Entwicklung anfangen. Wenn Sie soweit sind, erweitern Sie die Instanzen, um leistungsintensive Anwendungen zu bedienen. Wir wünschen Ihnen viel Spaß beim Erkunden von Google Cloud und Cloud SQL for SQL Server.

Datenbanken

Migration Ihrer Oracle- und SQL Server-Datenbanken zu Google Cloud

#1 Ausführung von Oracle-basierten Anwendungen in der Google Cloud

#2 SQL Server-basierte Anwendungen in Google Cloud ausführen

#3 Auswahl einer PostgreSQL-Datenbank in der Google Cloud

#4 Wie Sie Ihre Anwendungen mit Google Cloud-Datenbanken migrieren und modernisieren

#5 Erste Schritte mit dem Database Migration Service

Wir freuen uns auf die Zusammenarbeit mit Ihnen

Aktuelles auf dem Google Cloud Blog

Migrieren von Datenbanken nach Google Cloud VMware Engine (GCVE)

Google Cloud VMware Engine

Tools für die Datenbankmigration

Datenbank-Replatforming

Die nächsten Schritte: Modernisierung und Hybride GCE/GCVE-Umgebungen

Zusammenfassung

Aktuelles auf dem Google Cloud Blog

Neuigkeiten bei Googles offener und intelligenter Daten-Cloud

Data Sharing ohne Barrieren, Erkenntnisse in Echtzeit, offene Ökosysteme

Freie Wege in der Datenverarbeitung

Melden Sie sich für die Google Cloud Next an

Wie Bayer Crop Science mit BigQuery und geobeam die Bodengesundheit verbessert

Daten zusammenführen

Daten zu Erkenntnissen verarbeiten

Geodaten in der Praxis

Aktuelles auf dem Google Cloud Blog

Sieben Cloud Spanner-Mythen

Einführung in Cloud Spanner

Mythos Nr. 1: Der Einsatz von Spanner ist nur bei massiven Workloads sinnvoll

Mythos Nr. 2: Spanner ist zu teuer

Mythos Nr. 3: Sie müssen Skalierung, Konsistenz und Latenzzeit gegeneinander abwägen

Mythos Nr. 4: Spanner spricht kein PostgreSQL

Mythos Nr. 5: Beobachtbarkeitsdaten können nur in der Spanner Console abgerufen werden

Mythos Nr. 6: Spanner eignet sich nur für globale Workloads, die Kopien in mehreren Regionen voraussetzen

Mythos Nr. 7: Spanner-Schemaänderungen erfordern teure Sperren

Aktuelles auf dem Google Cloud Blog

Globale Multiplayer-Spiele entwickeln – mit Cloud Spanner

Ist Cloud Spanner komplexen Architekturen gewachsen?

Einführung von Spanner

Aktuelles auf dem Google Cloud Blog

Chefkoch bringt mit Texterkennung handschriftliche Rezepte in die Cloud

APIs lesen Rezepte

Am Rezept feilen

Analog-zu-Digital-Angebot

Aktuelles auf dem Google Cloud Blog I Ausgabe 5

Bare-Metal-Lösung: aktuelle Regionen, Server und Zertifizierungen

Ein Beitrag von Google Cloud zu mehr Vertrauen und Transparenz in Europa

Derzeitige Regionen

Ein kleinerer Server, mit dem Sie bei Lizenz- und Hardwarekosten sparen

PCI DSS und HIPAA zur Unterstützung Ihrer Workloads

Wie Songkick seine Infrastruktur mit Memorystore vereinheitlicht

Mehr Zeit für Innovation dank des komplett verwalteten Memorystore-Dienstes

Wie wir Memorystore nutzen

Problemlose Zusammenarbeit von Memorystore und Redis

Planung weiterer Schritte mit Memorystore

So nutzen führende Unternehmen API-Analysen für bessere Entscheidungen

Große Pläne: warum sich Ricardo für Bigtable als Ergänzung zu BigQuery entschied

Online-Shopping wird dank Recommendations AI persönlicher

Google stellt die Weichen für eine moderne Cloud

Google im Magic Quadrant von Gartner unter den führenden Anbietern für Cloud-Infrastruktur- und Plattformdienste

Gartner stuft Google in seinem Magic Quadrant 2020 für Datenbankmanagementsysteme als einen führenden Anbieter ein

Google Cloud Next 2020: Beschleunigung der digitalen Transformation in der Cloud

Microsoft SQL Server-Arbeitslasten zu Google Cloud migrieren

Erste Schritte bei der Migration von SQL Server 2008