credativ® Inside Archiv - Page 3 of 3 - credativ®

In November 1999, 20 years ago, credativ GmbH was founded in Germany, and thus laid the first foundation for the current credativ group.

At that time, Dr. Michael Meskes and Jörg Folz started the business operations in the Technology Centre of Jülich, Germany. Our mission has always been to not only work to live, but also to live to work, because we love the work we do. Our aim is to support widespread use of open source software and to ensure independence from software vendors.

Furthermore, it is very important for us to support and remain active in open source communities. Since 1999 we have continuously taken part in PostgreSQL and Debian events, and supported them financially with sponsorships. Additionally, the development of the Linux operating system has also been a dear and important project of ours. Therefore, we have been a member of the Linux Foundation for over 10 years.

In 2006 we opened our Open Source Support Center. Here, for the first time, our customers had the opportunity to get the support for their entire Open Source infrastructure with just one contract. Since then we have expanded and included different locations into a globally operating Open Source Support Center.

Thanks to our healthy and steady growth, credativ grew to over 35 employees at its worldwide locations by our 10th anniversary.

Since then, the founding of credativ international GmbH in 2013 marked another milestone in credativ’s history, as the focus shifted from a local to a global market. We were also able to expand into different countries such as the USA and India.

We have grown now to over 80 employees, with 20 years of company history. credativ is now one of the leading providers of services and support for open source software in enterprise use. We thank our customers, business partners, and employees for their time together.

This Artikel was originally written by Philip Haas.

Expansion of Open Source Support Center & PostgreSQL® Competence Center in USA

credativ Group, Maryland, 01/29/2019

credativ group, a leading provider of Open Source solutions and support in both Europe and Asia, announces a strategic expansion into the American market as part of a deal acquiring significant assets of OmniTI Computer Consulting (OmniTI), a highly aligned Maryland technical services firm. The new combined entity forms the basis for the establishment of an enlarged Open Source Support Center and PostgreSQL® Competence Center in a new US headquarters based in Columbia, Maryland.

OmniTI, founded in 1997, has built a client list that reads like a who’s who in tech, including Wikipedia, Google, Microsoft, Gilt, Etsy, and many others. In the process, they developed or contributed to the development of hundreds of Open Source projects, built the OmniOS illumos distribution, and ran the world-renowned Surge conference series. “credativ’s client-first approach and alignment on Open Source makes it a comfortable fit and seamless transition for OmniTI’s staff and customers. After 22 years of business, I’m delighted by this new direction.” says Theo Schlossnagle, Founder of OmniTI, who is leaving the company to concentrate on other activities.

The newly formed US branch of the credativ family has appointed Robert Treat as its CEO. Working in close cooperation with credativ international GmbH, led by Dr. Michael Meskes, Treat will take over further expansion of activities in the USA. A noted Open Source contributor, author, and international speaker, Treat served as both COO and CEO during his time with OmniTI.

Together with the European Open Source Support Center of credativ GmbH, the credativ group will expand its service network for numerous international customers who are currently mainly supported from Europe. Thus the credativ group can extend its unique position as the sole provider of Open Source Support Centers and offer comprehensive support with guaranteed service level agreements for a multitude of open source projects used in today’s business environments.

Robert Treat says “Open Source is at the heart of today’s biggest business disruptors; DevOps and the Cloud. At OmniTI we helped hundreds of companies navigate through these changes over the last 10 years. Now, as part of credativ, we have an even larger pool of experts to choose from to help people master all the necessary aspects of modern technology, including scalability, observability, deployment, automation, and more; all based on the power and flexibility of Open Source.”

Additionally, the US team will now offer a PostgreSQL® Competence Center that ensures the use of the free open source DBMS PostgreSQL® in mission critical applications and supports the entire life cycle of a PostgreSQL® database environment.

In addition, by expanding its existing service and support structure, credativ is one of a very few providers of PostgreSQL® support with a truly global footprint. Dr. Michael Meskes says: “We see to it that the community version of PostgreSQL® can be used as an extremely powerful alternative to the well-known commercial, proprietary databases in the enterprise environment. Apart from the very moderate costs for support, there is no need anymore for further costs for subscriptions or licenses.”

About credativ international GmbH

Founded in 1999, credativ is an independent consulting and services company offering comprehensive services and technical support for the implementation and operation of Open Source software in business applications.

Our Open Source Support Center™ provides the necessary reliability to make use of the numerous advantages of free software for your organization. Offering support around the clock, 365 days a year, our Open Source Support Center™ contains service locations in Germany, India, the Netherlands, Spain, and the United States, providing global premium support for a wide range of Open Source projects that play a fundamental role and are of utmost importance in the IT infrastructures of many companies today.

Moreover, we are advocates for the principles of free software and actively support the development of Open Source software. Most of our consultants are actively involved in numerous Open Source projects, including Debian, PostgreSQL®, Icinga, and many others, and many have been recognized as leading experts in their respective domains.

PostgreSQL® 9.3 ist da! Die neue Hauptversion bringt viele Verbesserungen und neue Funktionen. Dieser Artikel stellt einige der interssanten Neuerungen vor.

Verbessertes Locking mit Fremdschlüsseln

Fremdschlüssel sind unabdingbar für die referentielle Integrität der Daten. Allerdings brachten diese bis einschließlich PostgreSQL® 9.2 auch unter bestimmten Bedingungen Lockingprobleme bei UPDATE auf Spalten mit Fremdschlüsseln mit sich. Vor allem bei überlappenden Aktualisierungen mehrerer Transaktionen über einen Fremdschlüssel kann es sogar zu Deadlocks kommen. Das folgende Beispiel ist in PostgreSQL® 9.2 problematisch, exemplarisch an diesem einfachen Datenmodell demonstriert:

CREATE TABLE parent(id integer, value text);
ALTER TABLE parent ADD PRIMARY KEY(id);
CREATE TABLE child(id integer, parent_id integer REFERENCES parent(id), value text);
INSERT INTO parent VALUES(1, 'bob');
INSERT INTO parent VALUES(2, 'andrea');

 

Zwei Transaktionen, jeweils Session 1 und Session 2 genannt, werden zeitgleich in der Datenbank gestartet:

Session 1

BEGIN;
INSERT INTO child VALUES(1, 1, 'abcdef');
UPDATE parent SET value = 'thomas' WHERE id = 1;

 

Session 2

BEGIN;
INSERT INTO child VALUES(2, 1, 'ghijkl');
UPDATE parent SET value = 'thomas' WHERE id = 1;

 

Session 1 und Session 2 führen beide den INSERT erfolgreich aus, der UPDATE blockiert jedoch in Session 1, da der INSERT in Session 2 einen sogenannten SHARE LOCK auf das Tupel mit dem Fremdschlüssel hält. Dieser steht in Konflikt mit der Sperre, die der UPDATE auf den Fremdschlüssel haben möchte. Nun versucht Session 2 seinerseits seinen UPDATE abzusetzen, dies erzeugt jedoch wiederum einen Konflikt mit dem UPDATE aus Session 1; Ein Deadlock ist entstanden und wird automatisch in PostgreSQL® 9.2 aufgelöst. In diesem Fall wird jedoch die Transaktion in Session 2 abgebrochen:

ERROR:  deadlock detected
DETAIL:  Process 88059 waits for ExclusiveLock on tuple (0,1) of relation 1144033 of database 1029038; blocked by process 88031.
Process 88031 waits for ShareLock on transaction 791327; blocked by process 88059.

 

In PostgreSQL® 9.3 gibt es jetzt ein deutlich verfeinertes Locking bei Aktualisierungen auf Zeilen und Tabellen mit Fremdschlüsseln, die das angeführte Problem entschärfen. Hierbei werden Tupel, die kein gezieltes UPDATE auf einen Fremdschlüssel darstellen (d.h. der Wert eines Fremdschlüssels wird nicht verändert), mit einem schwächeren Lock (FOR NO KEY UPDATE) gesperrt. Für das einfache Prüfen eines Fremdschlüssels verwendet PostgreSQL® des weiteren den neuen FOR KEY SHARE Lock, der hiermit nicht in Konflikt steht. Dies verhindert im gezeigten Beispiel einen Deadlock, der UPDATE in Session 1 wird zunächst ausgeführt, der in Konflikt stehende UPDATE in Session 2 muss warten, bis Session 1 erfolgreich die Transaktion bestätigt oder zurückrollt.

Parallel pg_dump

pg_dump besitzt mit der neuen Kommandozeilenoption -j die Möglichkeit, parallel Tabellen und deren Daten zu sichern. Diese Funktion kann einen Dump sehr großer Datenbanken erheblich beschleunigen, da Tabellen gleichzeitig gesichert werden können. Dies funktioniert nur mit dem Directory Ausgabeformat (-Fd) von pg_dump. Mittels pg_restore können diese Dumps dann ebenfalls mit mehreren Restoreprozessen gleichzeitig wiederhergestellt werden.

Updatable Foreign Data Wrapper und postgres_fdw

Mit PostgreSQL® 9.3 wurde die API für Foreign Data Wrapper (FDW) für DML-Kommandos erweitert. Dies ermöglicht die Implementierung von aktualisierbaren FDW-Modulen. Gleichzeitig wurde der Foreign Data Wrapper für PostgreSQL® (postgres_fdw) als Extension integriert. Dies erlaubt nun den transparenten Zugriff auf entfernte PostgreSQL®-Instanzen. Tabellen erscheinen dabei in der Datenbank als lokale Tabellen und können ohne weiteres zum Beispiel in komplexen SQL-Konstrukten wie JOINs oder Views verwendet werden. FDW werden in einem späteren Artikel an dieser Stelle noch ausführlicher erläutert.

Event Trigger

Ein schon länger von Anwendern gewünschtes Feature sind Event Trigger für DDL (Data Definition Language) Operationen, wie beispielsweise ALTER TABLE oder CREATE TABLE. Dies ermöglicht das automatische Reagieren auf bestimmte Ereignisse per DDL, wie beispielsweise bestimmte Aktionen zu protokollieren. Unterstützt werden im Moment Aktionen für ddl_command_start, sql_drop und ddl_command_end. Triggerfunktionen können mit C oder PL/PgSQL erstellt werden. Folgendes Beispiel für sql_drop verhindert beispielsweise das Löschen von Tabellen:

CREATE OR REPLACE FUNCTION del_event_func() RETURNS event_trigger AS $$
DECLARE
        v_item record;
BEGIN
        FOR v_item IN SELECT * FROM pg_event_trigger_dropped_objects()
        LOOP
                RAISE EXCEPTION 'deletion of object %.% forbidden', v_item.schema_name, v_item.object_name;
        END LOOP;
END;
$$ LANGUAGE plpgsql;
 
CREATE EVENT TRIGGER delete_table_obj ON sql_drop WHEN tag IN ('drop table') EXECUTE PROCEDURE del_event_func();
 
DROP TABLE child ;
FEHLER:  deletion of object public.child forbidden

Prüfsummen in Tabellen

Mit PostgreSQL® 9.3 gibt es nun die Möglichkeit, in Umgebungen, in denen die Zuverlässigkeit der verwendeten Speicherlösungen nicht garantiert werden kann (beispielsweise bestimmte Cloudumgebungen), den Datenbankcluster mit Prüfsummen zu initialisieren. PostgreSQL® organisiert Tupel in standardmäßig 8KB großen Blöcken. Diese bilden die kleinste Einheit, mit der die Datenbank auf dem Speichersystem arbeitet. Prüfsummen versehen diese Blöcke nun mit zusätzlichen Informationen, um Speicherfehler wie korrupte Blockheader oder Tupelheader frühzeitig erkennen zu können. Prüfsummen lassen sich nicht nachträglich aktivieren, sondern erfordern das Initialisieren des physikalischen Datenbankverzeichnisses mit initdb und dem neuen Kommandozeilenparameter –data-checksums. Dies gilt dann für sämtliche Datenbankobjekte wie Tabellen oder Indexe und hat eine Auswirkung auf die Geschwindigkeit.

Materialized Views

Die neue PostgreSQL® Version 9.3 enthält nun auch eine grundlegende Implementierung für Materialized Views. Normale Views in PostgreSQL® sind keine materialisierten Objekte im Sinne einer Tabelle. Im übertragenen Sinne muss man sich Views als eine Art Makro vorstellen, die PostgreSQL®auf die zugrundeliegende View anwendet. So wird ein SELECT * FROM <view> dann zum eigentlichen, beliebig komplexen SELECT umgeschrieben. Dies hat jedoch zur Folge, dass bei großen Datenmengen immer wieder das Ergebnis von neuem geplant, ausgeführt und materialisiert werden muss. Mit Materialized Views lassen sich Views erstellen, die die materialisierte Ergebnismenge direkt vorhalten. Die Implementierung in PostgreSQL® 9.3 ist jedoch noch sehr generisch. Auch blockiert das  REFRESH MATERIALIZED VIEW Kommando alle Zugriffe auf den Materialized View.

Dies sind nur einige Beispiele aus der langen Liste von Neuerungen, die in die neue PostgreSQL® Version Einzug gehalten haben. Mit JSON, Verbesserungen in Streaming Replication und einigen Verbesserungen in der Konfiguration wie Shared Memory Nutzung sind noch viele andere Neuigkeiten hinzugekommen. Allen, die an detaillierten Ausführungen aller neuen Features interessiert sind, seien die Release Notes ans Herz gelegt. Für RedHat, CentOS, Scientific Linux und Fedora liegen RPM Pakete unter http://yum.postgresql.org bereit. Für Debian steht das PGAPT Repository zur Verfügung. Genaue Instruktionen findet man unter http://wiki.postgresql.org/wiki/Apt

Dieser Artikel wurde ursprünglich von Bernd Helmle geschrieben.

Auch lesenswert: PostgreSQL Foreign Data Wrapper für Informix

PostgreSQL® 9.3 ist da! Die neue Hauptversion bringt viele Verbesserungen und neue Funktionen. Dieser Artikel stellt einige der interssanten Neuerungen vor.

Verbessertes Locking mit Fremdschlüsseln

Fremdschlüssel sind unabdingbar für die referentielle Integrität der Daten. Allerdings brachten diese bis einschließlich PostgreSQL® 9.2 auch unter bestimmten Bedingungen Lockingprobleme bei UPDATE auf Spalten mit Fremdschlüsseln mit sich. Vor allem bei überlappenden Aktualisierungen mehrerer Transaktionen über einen Fremdschlüssel kann es sogar zu Deadlocks kommen. Das folgende Beispiel ist in PostgreSQL® 9.2 problematisch, exemplarisch an diesem einfachen Datenmodell demonstriert:

CREATE TABLE parent(id integer, value text);
ALTER TABLE parent ADD PRIMARY KEY(id);
CREATE TABLE child(id integer, parent_id integer REFERENCES parent(id), value text);
INSERT INTO parent VALUES(1, 'bob');
INSERT INTO parent VALUES(2, 'andrea');

 

Zwei Transaktionen, jeweils Session 1 und Session 2 genannt, werden zeitgleich in der Datenbank gestartet:

Session 1

BEGIN;
INSERT INTO child VALUES(1, 1, 'abcdef');
UPDATE parent SET value = 'thomas' WHERE id = 1;

 

Session 2

BEGIN;
INSERT INTO child VALUES(2, 1, 'ghijkl');
UPDATE parent SET value = 'thomas' WHERE id = 1;

 

Session 1 und Session 2 führen beide den INSERT erfolgreich aus, der UPDATE blockiert jedoch in Session 1, da der INSERT in Session 2 einen sogenannten SHARE LOCK auf das Tupel mit dem Fremdschlüssel hält. Dieser steht in Konflikt mit der Sperre, die der UPDATE auf den Fremdschlüssel haben möchte. Nun versucht Session 2 seinerseits seinen UPDATE abzusetzen, dies erzeugt jedoch wiederum einen Konflikt mit dem UPDATE aus Session 1; Ein Deadlock ist entstanden und wird automatisch in PostgreSQL® 9.2 aufgelöst. In diesem Fall wird jedoch die Transaktion in Session 2 abgebrochen:

ERROR:  deadlock detected
DETAIL:  Process 88059 waits for ExclusiveLock on tuple (0,1) of relation 1144033 of database 1029038; blocked by process 88031.
Process 88031 waits for ShareLock on transaction 791327; blocked by process 88059.

 

In PostgreSQL® 9.3 gibt es jetzt ein deutlich verfeinertes Locking bei Aktualisierungen auf Zeilen und Tabellen mit Fremdschlüsseln, die das angeführte Problem entschärfen. Hierbei werden Tupel, die kein gezieltes UPDATE auf einen Fremdschlüssel darstellen (d.h. der Wert eines Fremdschlüssels wird nicht verändert), mit einem schwächeren Lock (FOR NO KEY UPDATE) gesperrt. Für das einfache Prüfen eines Fremdschlüssels verwendet PostgreSQL® des weiteren den neuen FOR KEY SHARE Lock, der hiermit nicht in Konflikt steht. Dies verhindert im gezeigten Beispiel einen Deadlock, der UPDATE in Session 1 wird zunächst ausgeführt, der in Konflikt stehende UPDATE in Session 2 muss warten, bis Session 1 erfolgreich die Transaktion bestätigt oder zurückrollt.

Parallel pg_dump

pg_dump besitzt mit der neuen Kommandozeilenoption -j die Möglichkeit, parallel Tabellen und deren Daten zu sichern. Diese Funktion kann einen Dump sehr großer Datenbanken erheblich beschleunigen, da Tabellen gleichzeitig gesichert werden können. Dies funktioniert nur mit dem Directory Ausgabeformat (-Fd) von pg_dump. Mittels pg_restore können diese Dumps dann ebenfalls mit mehreren Restoreprozessen gleichzeitig wiederhergestellt werden.

Updatable Foreign Data Wrapper und postgres_fdw

Mit PostgreSQL® 9.3 wurde die API für Foreign Data Wrapper (FDW) für DML-Kommandos erweitert. Dies ermöglicht die Implementierung von aktualisierbaren FDW-Modulen. Gleichzeitig wurde der Foreign Data Wrapper für PostgreSQL® (postgres_fdw) als Extension integriert. Dies erlaubt nun den transparenten Zugriff auf entfernte PostgreSQL®-Instanzen. Tabellen erscheinen dabei in der Datenbank als lokale Tabellen und können ohne weiteres zum Beispiel in komplexen SQL-Konstrukten wie JOINs oder Views verwendet werden. FDW werden in einem späteren Artikel an dieser Stelle noch ausführlicher erläutert.

Event Trigger

Ein schon länger von Anwendern gewünschtes Feature sind Event Trigger für DDL (Data Definition Language) Operationen, wie beispielsweise ALTER TABLE oder CREATE TABLE. Dies ermöglicht das automatische Reagieren auf bestimmte Ereignisse per DDL, wie beispielsweise bestimmte Aktionen zu protokollieren. Unterstützt werden im Moment Aktionen für ddl_command_start, sql_drop und ddl_command_end. Triggerfunktionen können mit C oder PL/PgSQL erstellt werden. Folgendes Beispiel für sql_drop verhindert beispielsweise das Löschen von Tabellen:

CREATE OR REPLACE FUNCTION del_event_func() RETURNS event_trigger AS $$
DECLARE
        v_item record;
BEGIN
        FOR v_item IN SELECT * FROM pg_event_trigger_dropped_objects()
        LOOP
                RAISE EXCEPTION 'deletion of object %.% forbidden', v_item.schema_name, v_item.object_name;
        END LOOP;
END;
$$ LANGUAGE plpgsql;
 
CREATE EVENT TRIGGER delete_table_obj ON sql_drop WHEN tag IN ('drop table') EXECUTE PROCEDURE del_event_func();
 
DROP TABLE child ;
FEHLER:  deletion of object public.child forbidden

Prüfsummen in Tabellen

Mit PostgreSQL® 9.3 gibt es nun die Möglichkeit, in Umgebungen, in denen die Zuverlässigkeit der verwendeten Speicherlösungen nicht garantiert werden kann (beispielsweise bestimmte Cloudumgebungen), den Datenbankcluster mit Prüfsummen zu initialisieren. PostgreSQL® organisiert Tupel in standardmäßig 8KB großen Blöcken. Diese bilden die kleinste Einheit, mit der die Datenbank auf dem Speichersystem arbeitet. Prüfsummen versehen diese Blöcke nun mit zusätzlichen Informationen, um Speicherfehler wie korrupte Blockheader oder Tupelheader frühzeitig erkennen zu können. Prüfsummen lassen sich nicht nachträglich aktivieren, sondern erfordern das Initialisieren des physikalischen Datenbankverzeichnisses mit initdb und dem neuen Kommandozeilenparameter –data-checksums. Dies gilt dann für sämtliche Datenbankobjekte wie Tabellen oder Indexe und hat eine Auswirkung auf die Geschwindigkeit.

Materialized Views

Die neue PostgreSQL® Version 9.3 enthält nun auch eine grundlegende Implementierung für Materialized Views. Normale Views in PostgreSQL® sind keine materialisierten Objekte im Sinne einer Tabelle. Im übertragenen Sinne muss man sich Views als eine Art Makro vorstellen, die PostgreSQL®auf die zugrundeliegende View anwendet. So wird ein SELECT * FROM <view> dann zum eigentlichen, beliebig komplexen SELECT umgeschrieben. Dies hat jedoch zur Folge, dass bei großen Datenmengen immer wieder das Ergebnis von neuem geplant, ausgeführt und materialisiert werden muss. Mit Materialized Views lassen sich Views erstellen, die die materialisierte Ergebnismenge direkt vorhalten. Die Implementierung in PostgreSQL® 9.3 ist jedoch noch sehr generisch. Auch blockiert das  REFRESH MATERIALIZED VIEW Kommando alle Zugriffe auf den Materialized View.

Dies sind nur einige Beispiele aus der langen Liste von Neuerungen, die in die neue PostgreSQL® Version Einzug gehalten haben. Mit JSON, Verbesserungen in Streaming Replication und einigen Verbesserungen in der Konfiguration wie Shared Memory Nutzung sind noch viele andere Neuigkeiten hinzugekommen. Allen, die an detaillierten Ausführungen aller neuen Features interessiert sind, seien die Release Notes ans Herz gelegt. Für RedHat, CentOS, Scientific Linux und Fedora liegen RPM Pakete unter http://yum.postgresql.org bereit. Für Debian steht das PGAPT Repository zur Verfügung. Genaue Instruktionen findet man unter http://wiki.postgresql.org/wiki/Apt

Dieser Artikel wurde ursprünglich von Bernd Helmle geschrieben.

Auch lesenswert: PostgreSQL Foreign Data Wrapper für Informix