Hlavní navigace

Otevření 602SQL Serveru: s křížkem po funuse

5. 10. 2007
Doba čtení: 8 minut

Sdílet

Překvapivé otevření kódu 602SQL Serveru je patrně jednou ze zásadních událostí na domácí IT scéně. 602SQL Server je ukázkou, jak relativně kvalitní produkt díky špatnému marketingu a podpoře nedokáže držet krok s konkurenčními produkty a ani s open-source konkurencí. Otevření kódu bohužel přichází pozdě.

Historie Software602

Se jménem RNDr. Januše Drózda jsem se poprvé setkal ještě v osmdesátých letech, kdy ještě spolu s Petrem Coufem napsali překladač a prostředí tzv. Mikrobáze Pascalu pro ZX Spectrum. Bylo to v roce 1986 a byla to absolutní bomba. Prostředí MB Pascalu bylo na poměry ZX Spectra nadupané funkcemi. Škoda, že už nepřepsali MB Pascal pro Didaktik Gama, který přece jen měl o 32 K paměti víc. S tím už by se daly dělat věci. Nebudu asi jediný, kdo díky jejich práci zůstal u počítačů a živí se v IT.

Pak už přišlo CP/M s TurboPascalem 3.0, poté první PC a přelomové verze Turbo Pascalu 5.0 a 6.0. Zřejmě to nebyla náhoda, že první produkty 602 měly integrovaný Pascal. První funkce v S-Pascalu jsem napsal v Calc602, což byl na svou dobu docela progresivní spreadsheet. V devadesátých letech začal 602 ujíždět vlak. Calc602 byl první tabulkový procesor s integrovaným plnohodnotným jazykem, ale byl a zůstal pouze ve verzi pro DOS a byl neskutečně pomalý. Co se dělo v té době v 602, nevím, pro mne naprosto nepochopitelně postupně vyklízela veškeré pozice.

Produkty, které byly uvedeny na trh, byly uvedeny pozdě a za naprosto nesmyslné ceny (v cenových relacích ne nepodobných Microsoftu). V 602 si až příliš pozdě všimli, že existují Microsoft Windows, a později opět podcenili konkurenci open-source. Na RNDr. Januše Drózda nevzpomínám z návalu nostalgie, ale proto, že je jedním z autorů 602SQL Serveru – SQL RNDBS, jehož kód byl minulý týden otevřen pod licencí LGPL.

602SQL

602SQL pod LGPL? Bohužel pozdě

Podle optimistického vyjádření obchodního řiditele 602 je otevření 602SQL Serveru pod LGPL dlouho připravovaným krokem, který má zajistit produktu další vývoj.

„Uvolnit software do open source není tak jednoduché, jak by se mohlo na první pohled zdát. Zdrojový kód je naší vizitkou a jakákoliv nešikovnost nebo dokonce chyba by byla okamžitě veřejně viditelná. A samozřejmě, že jsme zvažovali i obchodní stránku věci. Ale jsme přesvědčeni, že to bylo rozhodnutí potřebné a správné. Globální komunita open source je obohacena o dobrý databázový produkt, prestiž českých vývojářů dále vzrostla a práce tisíců IT expertů celého světa zajistí produktu další rozvoj. To je kombinace, na níž nakonec vydělají všichni zúčastnění,“ řekl obchodní ředitel Software602 Ing. Pavel Nemrava.

Nejsem tak optimistický. Nevím, ale obávám se, že Ing. Nemrava zažije nepříjemné zklamání. IT expertů, kteří se účastní vývoje open-source databází, rozhodně nejsou tisíce. Vývojářů Firebirdu je něco kolem desítky, PostgreSQL je výsledkem práce zhruba max. třech desítek lidí z celého světa a řekl bych, že podobně na tom budou u MySQL. Kdyby k otevření kódu došlo před čtyřmi roky, tak by možná 602SQL Server mohl přetáhnout vývojáře Firebirdu nebo PostgreSQL a zaujmout – snad – lepší postavení. Nemyslím si, že by kdokoliv dnes investoval do vývoje dalšího databázového serveru.

Ještě před čtyřmi lety byla jiná situace. Stejně tak pozdě přišlo otevření SAPDB a Ingressu. A je mi to, přiznám se, docela líto. Na to, jaké má 602SQL Server nároky, toho umí opravdu hodně. Implementace SQL respektuje standard, je konzistentní a úplná. GUI je praktické a funkční. Není mi známo, kolik vývojářů stojí za 602SQL Serverem, odhadoval bych to tak na jednoho až tři, což opět nedává 602SQL příliš šancí. Poslední tři verze byly víc zaměřené na klientské rozhraní a na opravu chyb než na databázový engine. Každý si musí udělat jednoznačný obrázek při porovnání Release Notes 602SQL a PostgreSQL, Firebirdu nebo MySQL. Ono se toho ale v málo lidech příliš udělat nedá.

Proč neuspěje?

Jako největší mínus vidím dlouhodobě špatnou podporu z 602. Oficiální fórum má poslední odpověď Jana Šímy z června 2002. Neoficiální fórum uživatelů na Pandoře stále žije, nicméně podle počtu příspěvků je zřejmé, že zenit 602SQL Serveru byl v roce 2003:

1999 (3)] [2000 (0)] [2001 (0)] [2002 (189)] [2003 (306)] [2004 (107)] [2005 (58)] [2006 (19)] [2007 (32)]

Druhé a zásadní mínus, pro open-source vývoj, je nedostatek (resp. neexistence) vývojářské dokumentace. Nikde jsem nenašel popis zpracování dotazu, popis architektury, datového formátu ani další důležitou dokumentaci. Buďto neexistuje, a nebo tuto dokumentaci 602 nechce zveřejnit. Bez ní ale není pravděpodobné, že by se někdo vážněji 602SQL Serverem zabýval. Zdrojový kód je docela hutný a bez znalosti interních mechanismů nedešifrovatelný. Hádám, že minimálně 30 % komentářů je v češtině. Tudíž potenciální vývojáři se musí rekrutovat z Čech nebo Slovenska. Kdo zná zdejší komunitu, ví, jaký je tu nedostatek vývojářů.

Databázové produkty 602 trpí nekoncepčností. Nejdříve tu byl klasický relační databázový systém 4GL, poté databáze, která se snažila o symbiózu jak 4GL architektury, tak architektury klient/server a nakonec 602SQL Server je ukázkovou aplikací klient/server. To, že 602SQL Server přišel o 4GL vlastnosti, hodně uživatelů nepochopilo a odmítlo. To, že 602 se snažila o prosazení vlastního prostředí pro vývoj www aplikací, jsem zase nechápal já. V době PHP nebo ASP neměli šanci, bez ohledu na to, jak kvalitní jejich návrh byl.

Jak je na tom s výkonem?

Ze zvědavosti jsem si 602SQL Server nainstaloval a dva dny jsem si „hrál“. Test na vyhledávání prvočísel není typickým databázovým testem, ale generuje velký počet triviálních příkazů SELECT a DELETE. Pokud používáte triviální nebo jednoduché SQL příkazy, pak v reálné aplikaci (v jednouživa­telském režimu) nikdy nebude rozdíl mezi databázovými platformami větší než jaký ukazuje tento test (PostgreSQL je dvakrát rychlejší než 602SQL Server).

Test pgbench testuje průchodnost serveru ve víceuživatelském prostředí, obsahuje jak dotazy na data, tak změny dat. Netýral jsem 602SQL Server komplikovanými SQL dotazy, vzhledem k tomu, že jeho query planner není postavený na posouzení nákladů na provedení dotazu, by byl 602SQL Server těžce znevýhodněn vůči PostgreSQL. Obdobný Q.P. měly i starší verze Firebirdu a MySQL. Současné verze mají podobně navržen Q.P. jako PostgreSQL. Jaký typ Q.P. má 602SQL Server skutečně, jsem se nikde nedozvěděl. To, že se jedná o první generaci Q.P., spíš odhaduji z neexistence statistik.

Testovací příklad (určení prvočísel):

FUNCTION siete( ) RETURNS integer; -- zde podle ANSI SQL nemá být středník (snad
BEGIN                              -- jediný prohřešek standardu)
  DECLARE _f integer;
  DECLARE _l integer DEFAULT 1;
s_loop:
  LOOP
    SET _f = (SELECT MIN(a)
                 FROM numbers
                WHERE a > _l);
    IF _f IS NULL THEN LEAVE s_loop; END IF;
    DELETE
       FROM numbers
      WHERE a MOD _f = 0 AND a > _f;
    SET _l = _f;
  END LOOP;
  RETURN (SELECT COUNT(*)
             FROM numbers);
END; 

S dalším testem bylo víc práce. Aplikační rozhraní 602SQL Serveru se dost liší od API PostgreSQL. Ovšem výsledky mají, pro mně, podstatně vyšší váhu než určování prvočísel. Díky pgbench testu si lze ověřit průchodnost databáze při vysokém zatížení v typizovaném podnikovém prostředí. Výsledky ukazují, že 602SQL server drží krok s Postgresem pouze v případě menším počtu transakcí na spojení a při malém počtu klientů (a pokud se nevynucuje zápis změn při commitu). Tady je třeba konstatovat, že pouze vynucený zápis změn při commitu zaručuje konzistenci databáze, a že výchozí nastavení 602SQL Serveru není bezpečné.

1 klient                    1Kt 5Kt 10Kt
602SQL Server    fsync = off    1.2s    16.5s   1m51.1s
         fsync = on 9.0s        2m20.6s

PostgreSQL 8.3  fsync = on  1.4s        13.6s

klientů (1000 transakcí)  1   3   10
602SQL Server   fsync = off 1.2s    3.7s    29s
PostgreSQL 8.3  fsync = on  1.4s    3.7 14s 

Samozřejmě, že to není fér vůči 602SQL Serveru (I když verze 11 je v podstatě pouze o půl roku starší než PostgreSQL 8.3). Multigenerační architektura PostgreSQL je při víceuživatelském přístupu zásadní výhodou.

Plusy a mínusy, na které jsem narazil:

Plusy:

  • přitažlivé prakticky navržené jednoduché administrativní prostředí
  • konzistentní a dostatečně široká podpora SQL respektující standard
  • jednoduchá administrace (v podstatě není co konfigurovat)
  • česky psaná dokumentace (psaná víc pro programátory než pro DBA)
  • fulltext podporuje češtinu (podpora COLLATES je na velice dobré úrovni)
  • IDE dynamicky zobrazuje počet aktualizovaných řádků DML příkazem
  • cca 3M zdrojových kódů databázového jádra
  • úplná podpora uložených procedur dle standardu (IN OUT parametry, procedury a funkce, volné dotazy (multirecordset), což je hodně praktická vlastnost, která ovšem není zakotvena ve standardu)
  • Integrovaný profiler a integrovaný debugger uložených procedur
  • limit pro typ text je 16M

Mínusy:

  • neodladěná instalace v prostředí Linux (a to nepoužívám žádnou exotickou distribuci)
  • problémy s kompilací (neodladěnost pro vícero platforem)
  • V IDE nelze přerušit prováděný SQL příkaz
  • limit 4G na tabulku
  • neexistence jakékoliv popisu interních procesů, datových struktur atd., vyjma komentářů; kromě oficiální uživatelské příručky neexistují žádné další zdroje
  • výchozí konfigurace preferuje kompatibiltu se staršími verzemi 602SQL před shodou se standardem
  • při intenzivní zátěži občas nestabilní, nelineární závislost průchodnosti serveru a zátěže
  • obsahuje komentáře v češtině (mám rád, ale nepatří do o.s. produktu)
  • neexistence (utajení) zodpovědných (klíčových) osob v projektu, kritický nedostatek uživatelů – neexistují žádné věrohodné studie použití 602SQL Serveru v praxi (zvlášť při větším zatížení a větších aplikacích)
  • starší verze Q.P. (stejná generace byla v Firebirdu 1.x a MySQL 4.x)
  • kromě profileru a tabulky zámků chybí detailnější diagnostika
  • zdrojový kód obsahuje pravděpodobně mrtvý kód (např. parser S-Pascalu, který oficiálně není podporován, stejně tak replikace). U řady modulů byla poslední revize naposledy v roce 1992, tj. zdrojový kód vyžaduje revizi (kterou po svém vzniku prošel jak Firebird, tak PostgreSQL)
  • placený fulltext

Specifika:

  • zabudovaný jednoduchý HTTP server umožňující výměnu dat ve formátu XML (placený),
  • starší verze podporovaly replikaci skrz elektronickou poštu (602 je mistrem v prošlapávání slepých cest – „českých řešení“) ,
  • spolu s 602SQL Serverem je dodávaný SMTP a POP3 server, který jako úložiště používá SQL server.

Je 602SQL Server pro vás?

a) Pokud udržujete produkt, který je na 602SQL Serveru závislý a neplánujete absolutní refaktoring, pak 602SQL Server je to pravé ořechové.

root_podpora

b) Pokud jste pamětníci a z nostalgie sbíráte artefakty historie IT (doma oprašujete PC Fand), pak (602SQL Server má nepochybně své místo v historii české IT) 602SQL Server musíte mít.

c) Pokud studujete IT, pak v 602SQL Serveru dostanete balík kódu, který je funkční a který není tak objemný jako konkurenční databáze. Docela bych si dovedl představit použití 602SQL Serveru na středních i vysokých školách pro výuku databází (100 % jako náhrada MS Accessu). Pokud by si dal někdo práci a pohrál si instalací, pak by si možná pár dalších lidí tento SQL server nainstalovalo a používalo jako osobní SQL server (i když mi to připadá zvláštní, chybí GUI pro tvorbu formulářů). Určitě má 602SQL Server na to, aby se na něm daly stavět menší aplikace. Ale je tu příliš velké riziko, že jeho vývoj skončí. Otevřený kód alespoň garantuje šanci opravit chyby, na které se časem přijde.

Má 602SQL smysl?

  • Ano, pro malé aplikace.
    7 %
  • Ano, i pro velké projekty.
    2 %
  • Ano, ale chce to hodně vylepšit.
    14 %
  • Jen jako hračka a studijní materiál.
    52 %
  • Ne, je to k ničemu.
    25 %

Byl pro vás článek přínosný?

Autor článku

Pavel Stěhule je odborníkem na relační databázový systém PostgreSQL, pracuje jako školitel a konzultant.