V dôsledku rýchlej devalvácie rubľa sa nákup Microsoft SQL DBMS stal veľmi drahým a pre niektoré spoločnosti sa náklady na tieto licencie stali úplne nedostupnými. IN tento moment na nasadenie servera Microsoft SQL pre 20 používateľov si musíte zakúpiť nasledujúce licencie:

1 licencia operačného systému (WinSvrStd 2012R2)

20 licencií na pripojenie k serveru (WinSvrCAL 2012)

1 licencia pre server DBMS (SQLSvrStd 2014)

20 licencií na pripojenie k DBMS (SQLCAL 2014)

Odhadované náklady na takýto balík 275 000 rub.,čo je pre firmu len s 20 ľuďmi dosť drahé. Týmto nákladom sa môžete vyhnúť, ak vytvoríte server DBMS pomocou bezplatného softvéru. Nainštalujte operačný systém Linuxová rodina A bezplatná verzia DBMS - PostgreSQL. Na takomto serveri môžete jednoducho nasadiť podnikový server 1C, ako aj ďalšie roly, ktoré možno potenciálne kombinovať s úlohou databáz, napríklad WebServer alebo úložisko súborov.

Keďže používanie slobodného softvéru je z finančného hľadiska veľmi atraktívne, rozhodli sme sa zistiť, aký dobrý je z hľadiska výkonu.

Testovanie výkonu 1C:

Na vykonanie testu bolo odobraté vybavenie a softvér uvedené v tabuľke 1. Fyzický server pre oba stojany bol rovnaký, zmenil sa len softvér. Nastavenia oboch DBMS boli použité štandardne a v článku ich bližšie nepopisujeme. Distribučný kit PostGreSQL s príslušnými záplatami bol prevzatý z webovej stránky spoločnosti 1C, verzia je najnovšia dostupná na tejto stránke.

Tabuľka 1. Skúšobné lavice

	Charakteristika	Stánok č.1	Stánok č.2
	operačný systém	CentOS 6	Windows Server 2012R2
		PostgreSQL 9.3.3	Microsoft SQL Server 2012R2
	CPU	Intel Core i 5 3330 (3,0 GHz)
	RAM	24 GB DDD 3 1333 GHz
	HDD	SSD 240 GB Intel

Na začiatok bol vykonaný „Gilev test“, ktorý ukázal miernu výhodu stánku číslo 2 oproti stánku so slobodným softvérom.

Pozrite si výsledky nižšie, rozdiel v hodnotách je len 3 %.

Pre informáciu:„Gilev test“ je populárny syntetický test 1C, ktorý vykonáva množstvo štandardných operácií – čím rýchlejšie je test vykonaný, tým vyššie je skóre. Hodnotenie sa vykonáva v konvenčných jednotkách. Výsledné skóre je možné porovnať so stupnicou priloženou k testu, ktorá ukáže, aký vysoký je výkon súčasného systému.

Obrázok 1. Výsledok Gilevovho testu. Stojan č. 2 DBMSPANI SQL

Obrázok 2. Výsledok Gilevovho testu. Stojan č.1 DBMSPostgreSQL

Ďalej bolo rozhodnuté vykonať testovanie pomocou metódy APDEX. Podstatou metódy je meranie času potrebného na vykonanie základných operácií v 1C; merania sa vykonávajú niekoľkokrát za určité časové obdobie. Potom sa získaný výsledok porovná s prijateľným časom na dokončenie konkrétnej operácie.

Na tento účel sme vzali skutočnú pracovnú základňu jednej z najťažších konfigurácií 1C, charakteristiky základne sú uvedené v tabuľke č.

Tabuľka 2. Základné charakteristiky testu

Meral sa čas vykonania 7 štandardných operácií s objektmi v databáze. Každý test sa vykonal 10-krát a získal sa priemer. Merania sa uskutočnili pomocou hrubého klienta cez lokálna sieť. Klient bol nainštalovaný na pracovná stanica pod Ovládanie Windows 7. Skúšali sme spustiť testy aj z klienta nainštalovaného na Ubuntu Linux, ale nefungovalo to stabilne a bolo rozhodnuté spustiť všetky testy iba z klienta na Windows.

Tabuľka 3. VýsledkyAPDEX

Operácia kľúčom		Čas vykonania v sekundách			Odchýlka
		stánok č. 2 (MSSQL )	Stánok č.1 (slobodný softvér)
Otvorenie dokumentu	Zákaznícka objednávka
Vyhotovovanie dokladov	Zákaznícka objednávka
Uverejnenie nového dokumentu	Objekt dokumentu: Objednávka zákazníka
Vygenerovaný prehľad	Analýza príjmov a výdavkov
Vygenerovaný prehľad	Zoznam šarží tovaru
Vygenerovaný prehľad	Zoznam tovaru na skladoch
Vygenerovaný prehľad	Zúčtovanie s klientmi

V priemere naša skutočná databáza pri používaní MSSQL fungovala o 45 % rýchlejšie ako na lavičke so slobodným softvérom. Pri niektorých testoch bol rozdiel veľmi výrazný, ale pri iných, napríklad pri vypracovaní nového dokumentu, to bolo len 11 %.

Záver:

1C na MSSQL DBMS funguje približne 1,5-krát rýchlejšie ako na PostgreSQL. Preto, ak je možné zakúpiť alebo prenajať licencie MSSQL, je lepšie ich použiť na viac vysoký výkon. Pre malé a ľahké databázy môžete skúsiť použiť verziu MSSQL Express. Nerobili sme s ním testy, takže sa môže prejaviť z hľadiska výkonu buď lepšie alebo horšie ako PostgreSQL. Toto vydanie je obmedzené na použitie 1 procesora a 1 GB pamäte RAM a tiež nefunguje s databázami väčšími ako 10 GB. Ak databáza narastie na túto veľkosť, potom prestane fungovať úplne, ale ako ukazuje prax, ak je v databáze 15-20 používateľov, potom môžete pohodlne pracovať s veľkosťou databázy 4-5 GB, potom sa databáza začne výrazne spomaliť.

Hodnotenie Gilevovým testom ukazuje extrémne miernu prevahu MSSQL, čo nám umožňuje predpokladať, že ostatné 1C databázy môžu pracovať na PostgreSQL rovnako dobre ako na MSSQL a možno aj rýchlejšie. Pred výberom DBMS odporúčame spustiť testy na vašej konkrétnej databáze a porovnať výsledky.

Použitie PostgreSQL DBMS na nasadenie 1C na ňom je prijateľným riešením v podmienkach obmedzeného rozpočtu. Databáza nebude fungovať tak rýchlo ako na MSSQL, ale nemusíte platiť za licencie.

Koncom roka 2017 sme urobili nové testy a zverejnili ich v ďalšom článku.

Ďalším spôsobom, ako ušetriť peniaze pri používaní 1C, je prenajať si server 1C.

Integrácia systému. Poradenstvo

Obsahová séria:

1. História vývoja MySQL a PostgreSQL

História MySQL sa začína v roku 1979, pri jej počiatkoch stála malá spoločnosť pod vedením Montyho Wideniusa. V roku 1996 sa objavilo prvé vydanie 3.11 pre Solaris s verejnou licenciou. MySQL bol potom prenesený na iné OS, objavila sa špeciálna obchodná licencia. V roku 2000, po pridaní rozhrania podobného Berkeley DB, sa databáza stala transakčnou. Replikácia bola pridaná približne v rovnakom čase. V roku 2001 verzia 4.0 pridala k existujúcemu MyISAM engine InnoDB, čo viedlo k ukladaniu do vyrovnávacej pamäte a zvýšeniu výkonu. V roku 2004 bola vydaná verzia 4.1, ktorá zaviedla poddotazy, čiastočné indexovanie pre MyISAM a Unicode. Vo verzii 5.0 v roku 2005 sa objavili uložené procedúry, kurzory, spúšťače a zobrazenia. MySQL rozvíja komerčné trendy: v roku 2009 sa MySQL stalo ochrannou známkou spoločnosti Oracle.

História Postgresu sa začala v roku 1977 databázou Ingress.

V roku 1986 bola na University of Berkeley v Kalifornii premenovaná na PostgreSQL.

V roku 1995 sa Postgres stal otvorenou databázou. Objavil sa interaktívny psql.

V roku 1996 bol Postgres95 premenovaný na PostgreSQL verziu 6.0.

Postgres má niekoľko stoviek vývojárov po celom svete.

2. Architektúra MySQL a PostgreSQL

PostgreSQL– jednotný databázový server s jediným motorom – ukladacím mechanizmom. Postgres používa model klient-server.

Pre každého klienta a nový proces(nie stream!). Na prácu s takýmito klientskymi procesmi server používa semafory.

Žiadosť klienta prechádza nasledujúcimi fázami.

1. Pripojte sa.
2. Analýza: skontroluje sa správnosť požiadavky a vytvorí sa strom dotazov. Analyzátor je založený na základných unixových nástrojoch yacc a lex.
3. Prepísať: vezme sa strom dotazov a skontroluje sa v ňom prítomnosť pravidiel, ktoré sa nachádzajú v systémových adresároch. Zakaždým, keď sa užívateľský dotaz prepíše na dotaz, ktorý pristupuje k databázovým tabuľkám.
4. Optimalizátor: pre každú požiadavku sa vytvorí plán dotazov, ktorý sa odovzdá realizátorovi. Zmyslom plánu je, aby sa z toho všetci dostali možné možnosti získanie výsledku (či použiť indexy, spojenia atď.) a výber najrýchlejšej možnosti.
5. Vykonávanie dotazu: vykonávateľ rekurzívne prechádza stromom a získava výsledok pomocou triedenia, spájania atď. a vracia riadky. Postgres je objektovo-relačná databáza, každá tabuľka v nej predstavuje triedu a medzi tabuľkami sa implementuje dedičnosť. Implementované štandardy SQL92 a SQL99.

Transakčný model je vybudovaný na základe takzvaného multi-version concurrency control (MVCC), ktorý poskytuje maximálny výkon. Referenčná integrita je zabezpečená prítomnosťou primárneho a sekundárneho kľúča.

MySQL má dve vrstvy – vonkajšiu sql vrstvu a vnútornú sadu enginov, z ktorých je najčastejšie využívaný InnoDb engine, keďže najviac podporuje ACID.

Implementovaný štandard SQL92.

Z modulárneho hľadiska možno kód MySQL rozdeliť do nasledujúcich modulov.

1. Inicializácia servera.
2. Správca pripojenia.
3. Správca streamu.
4. Ovládač príkazov.
5. Overenie.
6. Analyzátor.
7. Optimalizátor.
8. Správca tabuľky.
9. Motory (MyISAM, InnoDB, MEMORY, Berkeley DB).
10. Ťažba dreva.
11. Replikácia.
12. Sieťové API.
13. Rozhranie API jadra.

Poradie činnosti modulov je nasledovné: najprv sa načíta prvý modul, ktorý načíta možnosti príkazový riadok, konfiguračné súbory, alokuje pamäť, inicializuje globálne štruktúry, načíta systémové tabuľky a odovzdá riadenie správcovi pripojení.

Keď sa klient pripojí k databáze, riadenie sa prenesie na správcu vlákien, ktorý vytvorí vlákno (nie proces!) pre klienta a skontroluje sa jeho autentifikácia.

Požiadavky klientov v závislosti od ich typu spracúva na najvyššej úrovni štvrtý modul (dispečer). Žiadosti budú zaznamenávať 11. modul. Príkaz sa odovzdá analyzátoru a skontroluje sa vyrovnávacia pamäť. Ďalej môže požiadavka prejsť na optimalizátor, tabuľkový modul, replikačný modul atď. V dôsledku toho sa údaje vrátia klientovi prostredníctvom správcu toku.

Najdôležitejší kód je v súbore sql/mysqld.cc. Obsahuje základné funkcie, ktoré sa od verzie 3.22 nezmenili: init_common_variables() init_thread_environment() init_server_components() grant_init() // sql/sql_acl.cc init_slave() // sql/slave.cc get_options)_new handle_connect) handle_one_connection() check_connection() acl_check_host() // sql/sql_acl.cc create_random_string() // sql/password.cc check_user() // sql/sql_parse.cc mysql_parse() // sql/sql_compatchparse. ::store_query() // sql/sql_cache.cc JOIN::optimize() // sql/sql_select.cc open_table() // sql/sql_base.cc mysql_update() // sql/sql_update.cc mysql_check_table() sql/sql_table.cc

Hlavička sql/sql_class.h definuje základné triedy: Query_arena, Statement, Security_context, Open_tables_state class, THD. Objekt triedy THD je deskriptor vlákna a je argumentom pre veľké množstvo funkcií.

3. Porovnanie MySQL a PostgreSQL: podobnosti a rozdiely

ACID štandard

Štandard ACID je založený na atomicite, integrite, izolácii a spoľahlivosti. Tento model sa používa na zabezpečenie integrity údajov. Toto sa realizuje na základe transakcií. PostgreSQL je plne kompatibilný s ACID. Ak chcete plne podporovať ACID v MySQL, musíte v konfigurácii nastaviť default-storage-engine=innodb.

Výkon

Databázy sú často optimalizované na základe prostredia, v ktorom fungujú. Obe základne majú rôzne technológie na zlepšenie výkonu. Historicky bol MySQL vyvíjaný s ohľadom na rýchlosť, zatiaľ čo PostgreSQL bol od samého začiatku navrhnutý tak, aby bol vysoko prispôsobiteľný a vyhovoval štandardom. PostgreSQL má množstvo nastavení, ktoré zvyšujú rýchlosť prístupu:

• čiastkové indexy;
• kompresia dát;
• alokácia pamäte;
• vylepšená vyrovnávacia pamäť.

MySQL má čiastočnú podporu pre čiastočné indexy v InnoDB. Ak vezmete motor MySQL ISAM, ukáže sa, že je rýchlejší pri plochých dopytoch, zatiaľ čo neexistujú žiadne blokovanie vložiek, žiadna podpora transakcií, cudzie kľúče.

Kompresia

PostgreSQL komprimuje a dekomprimuje údaje lepšie, čo vám umožňuje ušetriť viac údajov na disku. Zároveň sa z disku rýchlejšie načítavajú údaje o kompresii.

Kompresia MySQL pre rôzne motory je čiastočne podporovaná, čiastočne nie, a to závisí od konkrétnej verzie konkrétneho motora.

Z hľadiska výkonu viacerých procesorov má PostgreSQL výhodu oproti MySQL. Aj samotní vývojári MySQL priznávajú, že ich engine na tom v tomto smere nie je až tak dobre.

Typy údajov

MySQL: na ukladanie binárnych údajov používa typy TINYBLOB, BLOB, MEDIUMBLOB, LONGBLOB, ktoré sa líšia veľkosťou (do 4 GB).

Charakter: štyri typy - TINYTEXT, TEXT, MEDIUMTEXT, LONGTEXT.

PostgreSQL: Podporuje užívateľský dátový stroj s príkazom CREATE TYPE, typ BOOLEAN, geometrické typy.

Znak: TEXT (obmedzenie – max. veľkosť riadku).

Na ukladanie binárnych údajov slúži typ BLOB, ktorý je uložený v systém súborov. Stĺpce tabuľky možno definovať ako viacrozmerné pole s premenlivou dĺžkou. Objektovo-relačné rozšírenie: Štruktúru tabuľky možno zdediť z inej tabuľky.

Uložené procedúry

PostgreSQL aj MySQL podporujú uložené procedúry. PostgreSQL sa riadi štandardom Oracle PL/SQL, MySQL štandardom IBM DB2. MySQL podporuje rozšírenie SQL pre písanie funkcií v C/C++ od verzie 5.1. PostgreSQL: PL/PGSQL, PL/TCL, PL/Perl, SQL, C pre písanie uložených procedúr.

Keys

PostgreSQL aj MySQL podporujú jedinečný primárny kľúč a cudzí kľúč. MySQL nepodporuje kontrolné obmedzenie a sekundárne kľúče sú čiastočne implementované. PostgreSQL: úplná implementácia plus podpora pre ON DELETE CASCADE a ON UPDATE CASCADE.

Spúšťače

MySQL: základná podpora. PostgreSQL: deklaratívne spúšťače: SELECT, INSERT, DELETE, UPDATE, INSTEAD OF; procedurálne spúšťače: CONSTRAINT TRIGGER. Udalosti: BEFORE alebo AFTER na INSERT, DELETE, UPDATE.

Automatický prírastok

MySQL: V tabuľke môže byť len jeden takýto stĺpec, ktorý musí byť indexovaný. PostgreSQL: dátový typ SERIAL.

Replikácie

Podporované v MySQL aj PostgreSQL. PostgreSQL má modulárnu architektúru a replikácia je zahrnutá v samostatných moduloch:

• Slony-I je hlavným replikačným mechanizmom v Postgrese, výkon klesá ako kvadratická funkcia počtu serverov;

Replikácia v PostgreSQL je založená na spúšťači a je pomalšia ako v MySQL. Plánuje sa pridanie replikácie do jadra od verzie 8.4.

IN Replikácia MySQL je súčasťou jadra a má dve príchute, počnúc verziou 5.1:

• SBR – replikácia založená na príkazoch;
• RBR – riadková replikácia.

Prvý typ je založený na protokolovaní záznamov do binárneho protokolu, druhý je založený na protokolovaní zmien. Od verzie 5.5 MySQL podporuje takzvanú semi-synchrónnu replikáciu, pri ktorej hlavný server (master) pri každom potvrdení resetuje dáta na iný server (slave). Motor NDB vykonáva úplnú synchrónnu dvojfázovú replikáciu.

Transakcie

MySQL: Iba InnoDB. Podpora SAVEPOINT, ROLLBACK TO SAVEPOINT. Úrovne uzamknutia: úroveň tabuľky (MyISAM). PostgreSQL: podporované plus úroveň potvrdenia čítania a úrovne izolácie. Podpora ROLLBACK, ROLLBACK TO SAVEPOINT. Úrovne uzamknutia: úroveň riadkov, úroveň tabuľky.

Úrovne privilégií

PostgreSQL: Privilégiá môžu byť priradené používateľovi alebo skupine používateľov.

Export-import dát

MySQL: sada exportných nástrojov: mysqldump, mysqlhotcopy, mysqlsnapshot. Importovať z textové súbory, html, dbf. PostgreSQL: export - pomôcka pg_dump. Import medzi databázami a súborovým systémom.

Vnorené dopyty

Dostupné v MySQL aj PostgreSQL, ale nemusí fungovať efektívne v MySQL.

Indexovanie

Hašovanie indexu: čiastočné v MySQL, úplné v PostgreSQL. Fulltextové vyhľadávanie: čiastočné v MySQL, úplné v PostgreSQL. Čiastočné indexy: nie sú podporované v MySQL, podporované v PostgreSQL. Viacstĺpcové indexy: v MySQL je limit 16 stĺpcov, v PostgreSQL – 32. Indexy výrazov: v MySQL – emulácia, v PostgreSQL – plné. Neblokujúce vytváranie indexu: v MySQL - čiastočné, v PostgreSQL - plné.

Rozdelenie

MySQL podporuje horizontálne rozdelenie: rozsah, zoznam, hash, kľúč, kompozitné rozdelenie. PostgreSQL podporuje RANGE a LIST. Automatické rozdelenie tabuliek a indexov.

Automatické zotavenie z porúch

MySQL: čiastočné pre InnoDB - musíte manuálne vytvoriť zálohu. PostgreSQL: zapisovanie do denníka vopred (WAL).

Data Storage Engines

PostgreSQL podporuje jeden engine – Postgres Storage System. V MySQL 5.1 ich je niekoľko:

• MyISAM – slúži na ukladanie systémových tabuliek;
• InnoDB – maximálna zhoda ACID, ukladá dáta s primárnymi kľúčmi, cache inserty, podporuje kompresiu od verzie 5.1 – pozri atribút ROW_FORMAT=COMPRESSED;
• NDB Cluster – pamäťovo orientovaný engine, klastrová architektúra využívajúca synchrónnu replikáciu;
• ARCHÍV – podporuje kompresiu, nepoužíva indexy;
• a tiež: MERGE, MEMORY (HEAP), CSV.

InnoDB je vyvinutý InnoBase, dcérskou spoločnosťou Oracle. Vo verzii 6 by sa mali objaviť dva motory – Maria a Falcon. Falcon je motor založený na transakciách ACID.

Licencovanie

PostgreSQL: BSD (Berkeley Software Distribution) open source. MySQL: GPL (Gnu General Public License) alebo Commercial. MySQL je produkt s otvoreným zdrojovým kódom. Postgres je open-source projekt.

Záver

Aby sme to zhrnuli, môžeme povedať nasledovné: MySQL a PostgreSQL sú dve najpopulárnejšie open-source databázy na svete. Každá základňa má svoje vlastné charakteristiky a rozdiely. Ak potrebujete rýchle úložisko pre jednoduché dotazy s minimálnym nastavením, odporučil by som MySQL. Ak potrebujete spoľahlivé úložisko pre veľké množstvo dát s možnosťou rozšírenia, replikácie a plne v súlade s modernými štandardmi jazyk SQL, Odporúčam použiť PostgreSQL.

Budeme diskutovať o problémoch s konfiguráciou pre MySQL a PostgreSQL.

Zdroje na stiahnutie

static.content.url=http://www.site/developerworks/js/artrating/

Zone=Open source, Linux

ID článku=779830

ArticleTitle=MySQL & PostgreSQL: Časť 1. Porovnávacia analýza

Buďme úprimní, hoci 1C Enterprise je kompatibilný s mnohými DBMS, v skutočnosti 99 percent funguje buď v MS SQL alebo v bezplatnom PostgreSQL.

Inými slovami, tieto dva „sub-desk“ dobyli trh klient-server 1C.

A môžeme pokojne predpokladať, že ak firma nepracuje v MS SQL, tak s najväčšou pravdepodobnosťou jednoducho používa PostgreSQL.

Preto má zmysel porovnávať Postgres s MS SQL.

Dnes sa veľa píše o MS SQL aj PostgreSQL, ale zvyčajne sa neporovnávajú objektívne.

V tomto článku budeme analyzovať hlavné technické aspekty bezplatného PostgreSQL a porovnáme ho s MS SQL.

Čo vám umožní robiť v budúcnosti? optimálna voľba a buďte pripravení na rôzne „prekvapenia“ alebo aké by boli správnejšie „funkcie“ práce v tomto bezplatnom DBMS.

Vyhodnotíme všetko tak, ako to je, bez toho, aby sme Postgresu pridávali tie zásluhy, ktoré nemá a bez prikrášľovania platených MS.

Okamžite odpoviem na otázku, ktorá znepokojuje mnohých nováčikov!

ÁNO! MS SQL funguje rýchlejšie ako PostgreSQL, to je fakt! A existuje na to niekoľko dôvodov!

Možno som hneď niekoho sklamal a možno s týmto tvrdením nesúhlasíte, ospravedlňujem sa, ale samotná fyzika tohto bezplatného DBMS mu neumožňuje predbehnúť MS SQL, najmä ak hovoríme o takej kombinácii, ako je "Monster 1C" a PostgreSQL.

S podobnými argumentmi sa stretnete viackrát rôzne konferencie a semináre venované tomuto DBMS. Nikto nič neskrýva ani nepopiera, fakt je fakt.

Výkon PostgreSQL je však pre používateľov úplne dostatočný mohol pohodlne pracovať v 1C.

Či už ide o tucet používateľov alebo dokonca niekoľko stoviek súčasne pracujúcich v 1C Enterprise.

Prečo "Monster 1C"?

V skutočnosti takto 1C vidí PostgreSQL bez nainštalovaných špeciálnych „záplat“ a rozšírení.

Áno, ako sa hovorí, hneď po stiahnutí distribúcie PostgreSQL v kancelárii. webovú stránku, nebudete ju môcť používať na prácu v spojení s 1C. 1C strašne spomalí a jednoducho sa zastaví a odmietne pracovať.

Prečo sa to deje a prečo „záplaty“?

Faktom je, že 1C Enterprise vytvára v procese svojej práce obrovské množstvo dočasných tabuliek, o ktorých môžeme hovoriť asi tisíce tabuliek za sekundu, a ak si vezmete napríklad register „Plátok najnovších“ – „Zostatky a obraty“, a každý milión riadkov byť.

Faktom je, že štandardne (bez „záplat“) PostgreSQL nevypočítava štatistiky o týchto veľkých dočasných tabuľkách; inými slovami, optimalizátor dotazov, ktorý sa riadi údajmi zo štatistík (a ako si pamätáme, je prázdny, existuje nie je čo počítať), zhruba povedané, robí výber pomocou metódy VYBRAŤ *čo samozrejme bude fungovať veľmi, veľmi pomaly!

Preto tie obrovské brzdy v 1C!

Samozrejme, toto nie sú všetky problémy, ktoré je potrebné vyriešiť, aby PostgreSQL správne fungoval v spojení s 1C. Budú potrebné ďalšie „záplaty“ a špeciálne rozšírenia a po 15 až 20 používateľoch budú potrebné ďalšie. nastavenia v "config"

Áno, v skutočnosti všetko vyzerá oveľa komplikovanejšie, ako som opísal vyššie, ale takto bude vyzerať, ak sa výrazne zjednoduší, hlavný problém pomalej práce 1C s PostgreSQL.

Druhá vec, ktorá sa mi na PostgreSQL nepáči, je nedostatok multithreadingu v rámci jednej požiadavky v porovnaní s MS SQL.

(Od verzie 9.6 sme urobili prvý pokus o paralelizáciu dotazov, no zatiaľ to funguje slabo, niekedy je efekt opačný). ale za vyskúšanie 5!)

Čo, samozrejme, ovplyvňuje výkon, aby ste to jednoducho pochopili -

PostgreSQL je schopný zrútiť váš 48-jadrový server jedným veľkým dotazom!

Je to jednoduché, nedochádza k paralelizácii vlákien v rámci jednej požiadavky a jedna veľká požiadavka „načíta“ iba jedno jadro.

Áno, ak existuje veľa požiadaviek, načítajú sa všetky jadrá a všetko bude fungovať dobre.

A skoro som zabudol PostgreSQL porovnávame s MS SQL Standard nie Express!

Hoci Express možno použiť na komerčné účely, existuje množstvo obmedzení

napríklad 10 GB na základňu, použitie jedného procesora, 1 GB RAM,

prakticky znemožňuje používanie takéhoto produktu v 1C Enterprise.

Pokiaľ nemáte veľmi malú databázu a iba pár používateľov (a aj tak existuje len veľmi málo 1 GB bŕzd pre DBMS).

Porovnajme si teda PostgreSQL s populárnou verziou Standard.

SKRIPTY!!!

PostgreSQL sú primárne skripty v porovnaní s MS SQL, väčšina operácií sa musí robiť ručne a samozrejme môžete nainštalovať a urobiť niektoré základné veci cez rozhranie, ale zdôrazňujem, že tie základné a krok doľava je krok doprava a musíte napísať skript alebo BAS na Linuxe alebo cmd, powershell na Windows.

Zobrazenie a analýza stôp pomocou nástroja SQL Server Profiler.

Známy SQL Server Profiler v PostgreSQL chýba a slovom „neprítomný“ myslím úplne, bohužiaľ, v PostgreSQL nič také neexistuje.

Existujú samozrejme nástroje, ktoré vám umožňujú, ak máte čas zachytiť požiadavku alebo nastaviť bod prerušenia 1C v debuggeri, získať niečo a pozrieť sa na to, ale v porovnaní s Profiler, ako sa hovorí, to nebolo t ani blízko.

Môžete založiť denník a potom to všetko triediť - ale bude to trvať dlho!

Tu je príklad:

Programátor 1C sa snaží odladiť nejaký veľký dotaz, jeho vykonanie trvá dlho, napríklad 30 minút, ale v PostgreSQL, aby sa údaje dostali do protokolu, musí byť tento dotaz vykonaný! Viete si predstaviť, ako dlho by trvalo odladenie takejto požiadavky?

Zatiaľ čo v MS SQL môžete prerušiť vykonávanie dotazu a analyzovať ho v Profileri, pretože tam už bude, ale so stavom „zlyhalo“.

Postgres nemá obdobu v rôznych možnostiach vytvárania záloh!

Tu máte prírastkovú „zálohu“ aj úplnú zálohovanie a nepretržitá archivácia WAL.

V skutočnosti existuje čiastočná záloha a čiastočná obnova dát.

Môžete nakonfigurovať nepretržitú archiváciu a obnovu v určitom čase (Obnova v bode v čase (PITR)).

Tiež replikácie, je k dispozícii natívne v PostgreSQl bez akýchkoľvek „záplat“ nástrojov alebo doplnkov!

• Kaskádová replikácia
• Streamovacia replikácia
• Synchrónna replikácia
• Priebežná archivácia na záložnom serveri

Toto všetko je už pôvodne dostupné v PostgreSQl a samozrejme nie v „expres“ a nie je dostupné vo verzii MS SQL Standard.

Ak chcete získať všetko vyššie uvedené v MS SQL, musíte si kúpiť veľmi drahý MS SQL Enterprise, teraz asi 15 000 dolárov.

Čo chýba v porovnaní s MS SQL?

ŽIADNA rozdielová „záloha“

Áno, v PostgreSQl neexistuje rozdielová „záloha“, ale existujú rôzne analógy postupného vytvárania „záloh“.

Napríklad prírastkové „zálohovanie“ na úrovni bloku.

EXISTUJE oddelenie TABLESPACEs, ktoré už štandardne podporuje 1C!

Čo, mimochodom, nie je v MS SQL!

Môžete napríklad nakonfigurovať, na ktorom disku budete mať „indexy“ a na ktorom disku bude umiestnená „tabuľka“, čo je veľmi výhodné pri plánovaní vašej IT infraštruktúry, pokiaľ ide o veľké databázy 1C. ONLINE_ANALYZE na prepočítanie štatistík. To isté platí pre súbor *dt.

Pomocou PostgreSQl zriedka potrebujete REINDEX!

V skutočnosti by sa mal používať iba vtedy, keď existuje podozrenie, že je narušená integrita databázy.

Vylúčením tabuliek môžete vytvárať „zálohy“!

Napríklad, ak vo vašej spoločnosti pracuje niekoľko 1C programátorov, zaručene sa vyrobia sami zálohy vytvárať „zálohy“ pre ďalší rozvoj.

V dôsledku toho užívatelia trpia, databáza sa pri vytváraní veľkej „zálohy“ spomaľuje, najmä ak táto databáza obsahuje rôzne priložené súbory, archívy a dokumenty z listov. Takéto tabuľky so súbormi môžu ľahko obsahovať stovky gigabajtov. A môžu byť vylúčené v PostgreSQl vytvorením „zálohy“, teda malej veľkosti a so všetkými funkciami súčasne.

Takto sa nepreťažujeme sieťové zariadenia, kanál neupchávame, vytváraním takejto „zálohy“ trávime oveľa menej času

Nakoniec vyhráva každý! Používatelia, programátori aj správcovia pokojne spia.

V tomto článku sme skúmali iba základné rozdiely medzi PostgreSQl a MS SQL (existujú aj iné), ale pri rozhodovaní o výbere v prospech jedného alebo druhého DBMS by mal článok pomôcť!

Veľa šťastia kolega!

P.S. Teraz pracujem na novom kurze „1C a PostgreSQL“ (už v štádiu nahrávania, počkajte, čoskoro!)

S pozdravom Bogdan.

A teraz vyvstala voľba DBMS na ukladanie základných údajov. Začal som vyvíjať na MySQL, ale teraz si nie som istý výberom. Prechod na iný DBMS v tejto fáze pre mňa nebude problém (používam PDO). Som ďaleko od jasného pochopenia toho, čo je „vysoké zaťaženie“ pre DBMS. Ide len o to, že podľa mojich výpočtov bude základ asi o rok dosť vážny (pozri nižšie)

Hlavná voľba je medzi MySQL, PostgreSQL, MariaDB. Tiež možné, ale neodporúča sa Microsoft SQL Server na Windows Azure

Situácia je takáto:

1. Neexistujú žiadne zložité otázky do databázy. Maximálne JOIN z dvoch stolov
2. B O Väčšina žiadostí sa číta
3. Je tu jedna najdôležitejšia a „hlavná“ tabuľka (štruktúra tabuľky je pod spojlerom). Tabuľka sa denne rozrastie približne o 10-30 tisíc záznamov. Zápis údajov do tejto tabuľky je najdôležitejšia vec!
4. B O Väčšina požiadaviek na čítanie bude smerovaná do „hlavnej“ tabuľky. Táto tabuľka bude prehľadávaná podľa ktoréhokoľvek z polí (v extrémne zriedkavých prípadoch ~0,5 % - podľa viacerých naraz). Pátranie je potrebné vykonať rýchlo (napriek bodu č. 3)
5. Indexy budú s najväčšou pravdepodobnosťou pridané do každého z polí pre dve polia naraz (ownerID a Field Name, pretože ownerID bude špecifikované vo všetkých dotazoch). Rýchle vyhľadávanie bude potrebné pre ktorékoľvek z polí, ale toto nie je taká prioritná úloha. (Alebo je lepšie použiť Sphinx?)
6. Leví podiel dopytov (~80 %) na čítanie do „hlavnej“ tabuľky sú jednoduché výbery na indexy od a personalID s limitom = 20. Zostávajúce dopyty na akékoľvek iné polia na indexy (zatiaľ neexistujúce) ownerID a Field Meno, aj s limitom = 20
7. Zmeny údajov v záznamoch „hlavnej“ tabuľky sa vyskytnú veľmi zriedkavo. Z tabuľky nebudú odstránené žiadne záznamy.
8. Podpora transakcií a cudzích kľúčov je voliteľná
9. Potrebujeme schopnosť replikovať dáta typu master-slave
10. Vítaná je možnosť shardingu na úrovni DBMS
11. Spoľahlivosť databázy je mimoriadne dôležitá (t. j. pád ako MyISAM s manuálne obnovenie okamžite zmizne)
12. Do „hlavnej“ tabuľky je možné pridať nové polia. Toto je, samozrejme, extrémne zriedkavý výskyt a zďaleka nie najdôležitejšia požiadavka, ale pridanie nového stĺpca do tabuľky s veľkosťou desiatok GB je pre MySQL veľmi zdĺhavý proces a ja naozaj nechcem presúvať nové polia do samostatnej tabuľky
13. Toto všetko bude spočiatku bežať na takomto dedikovanom serveri
14. Ostatné stoly budú rásť pomaly a prístup k nim bude dosť zriedkavý, nebojím sa o ne. Často mám aktualizované údaje spustené v redis"e

Štruktúra „hlavnej“ tabuľky VYTVORIŤ TABUĽKU, AK NEEXISTUJE `klienti` (`id` bigint(11) NOT NULL AUTO_INCREMENT, `personalID` int(11) NOT NULL, `ownerID` int(11) NOT NULL, `fromID` int(11) NOT NULL DEFAULT "4", `fromDomain` varchar(255) NOT NULL, `datetime` datetime NOT NULL, `status` int(11) NOT NULL DEFAULT "0", `paid` tinyint(1) NOT NULL DEFAULT "0", ` paymentType` tinyint(4) NOT NULL DEFAULT "1", `wmSum` float NOT NULL DEFAULT "0", `wmCommission` float NOT NULL DEFAULT "20", `sysNumber` varchar(14) NOT NULL, `sysNumberLastUpdate` časová pečiatka NOT NULL DEFAULT CURRENT_TIMESTAMP, `sysNumberStatus` varchar(250) NOT NULL, `timezone` float NOT NULL, `comment` varchar(500) NOT NULL, `countryID` int(11) NOT NULL, `postIndex` varchar(6) NOT NULL , `región` varchar(500) NOT NULL, `mesto` varchar(500) NOT NULL, `address` varchar(500) NOT NULL, `fio` varchar(500) NOT NULL, `phone` varchar(15) NOT NULL , `email` varchar(255) NOT NULL, `price` float NOT NULL, `quantity` int(11) NOT NULL DEFAULT "1", `label` varchar(30) NOT NULL, `tag` int(11) NOT NULL, `ip` varchar(15) NOT NULL, `referer` varchar(200) NOT NULL, PRIMÁRNY KĽÚČ (`id`), KEY `from` (`ownerID`,`fromID`), KEY `paid` (` zaplatené`), KEY `stav` (`stav`), KEY `label` (`label`), KEY `sysNumberLastUpdate` (`sysNumberLastUpdate`), KEY `personalID` (`ownerID`,`personalID`)) ENGINE= InnoDB DEFAULT CHARSET=utf8;

P.S. Žiadam tých, ktorí ma chcú poslať do Googlu, aby ani neodpovedali. Nepodarilo sa mi nájsť informácie porovnávajúce aktuálne verzie rôznych DBMS a štúdium možností, výhod a nevýhod PostgreSQL, Microsoft SQL Server a MariaDB bolo pre človeka, ktorý s nimi nepracoval, veľmi zdĺhavou úlohou. A nie som ani zďaleka odborníkom na MySQL a takýto veľký projekt je pre mňa novinkou a možnosti MySQL sa líšia od verzie k verzii. Jediné, čo viem určite je, že tabuľky ako MyISAM v MySQL mi určite nevyhovujú

• Otázka položená pred viac ako tromi rokmi
• 39571 videní

Je ťažké nájsť organizáciu, ktorá nepoužíva účtovné systémy od 1C - dokonca aj v megaholdingoch, kde sú SAP alebo OEBS implementované už dlhú dobu, sa takmer vždy používajú v jednej alebo druhej oblasti. Je potešujúce, že ruský aplikačný softvér sa stal de facto štandardom pre naše spoločnosti, ale je tu jedna jemnosť: rovnaký de facto štandard pre samotný 1C:Enterprise sa stal Použitie Microsoft SQL Server ako DBMS.

Medzi odborníkmi na 1C je najbežnejší názor, že bez komerčných DBMS od amerických výrobcov to nebude nič dobré, niekoľko stoviek používateľov si v tomto prípade nevyhnutne vyžaduje inštaláciu databázy na MS SQL, Oracle Database alebo IBM DB2. Názory nám známych odborníkov na prácu v rámci slobody PostgreSQL DBMS sa líšili, ale v rozsahu od „vôbec nefunguje“ po „vhodné pre niekoľko desiatok používateľov, nie viac“.

Pre takéto skromné ​​odhady existovalo niekoľko hodnoverných vysvetlení: aktívne používanie dočasných tabuľkových mechanizmov platformami 1C (ktoré sú v Postgrese implementované príliš „čestne“ - s transakčným DDL, všetkými možnosťami obnovy) a zvláštnosti práce s textovými údajmi. (zatiaľ čo v oblasti viacjazyčných textov je vanilka Postgres opäť príliš konzervatívna, používa nie práve najvýkonnejšie systémové knižnice) a množstvo ďalších menej významných aspektov.

Tajne sme však verili v Postgres, najmä preto, že zhromaždenie tvrdilo, že vyrieši všetky tie problémy, ktoré skeptici používali na ospravedlnenie výberu komerčného DBMS. Okrem toho bolo pre nás dôležité získať cieľové ukazovatele pre hardvérový a softvérový komplex – databázový stroj pre DBMS, postavený na báze sankcií bezpečného vybavenia a softvéru, ktorý vyvinula IBS spolu s Postgres Professional.

Z replikovaných aplikácií by najzrejmejšou aplikáciou pre takýto stroj mali byť, samozrejme, systémy 1C. A výsledky vykonaných benchmarkov nás úplne preniesli z kategórie „tajných veriacich“ (a dokonca aj pochybujúcich) do kategórie „presvedčených“: teraz môžeme s istotou povedať, že 1C:Enterprise verzia 8.3 na zostave PostgreSQL EE 1.5 pre Skala-SR / PostgreSQL funguje lepšie ako MS SQL 2012 na rovnakom hardvéri so všetkými možnými optimalizáciami.

Takže nejaké podrobnosti o experimentoch. Z hľadiska testovania výkonu má 1C všetko systematicky a vedecky typická konfigurácia„Štandardný záťažový test“, na ktorom sa spúšťa benchmark, postupným pridávaním nových používateľov do záťaže, až kým aplikácia dostatočne nezareaguje na pohodlné ovládanie. (Presnejšie, používatelia sa pridávajú, kým skóre výkonu štandardnej aplikácie Apdex neklesne pod hranicu 0,85 a maximálny počet takýchto používateľov s efektívnym výkonom sa považuje za výsledok benchmarku.)

Použili sme verziu 8.3.9.1850 1C:Enterprise, štandard záťažový test vo verzii 2.0.17.36. Pôvodne bolo rozhodnuté neposkytovať Postgres žiadne zľavy: robíme maximálne optimalizácie na MS SQL na uzle z komplexu Skala-SR / PostgreSQL (inštalujeme Windows na holý kov, konfigurujeme ho podľa všetkých kánonov, pre rýchlosť vytvorte ramdisk pre dočasné tabuľky) a potom ten istý uzol vrátime do komplexu Scala-SR, nainštalujeme Linux a Postgres Pro EE a na ňom (bez klastrových čipov dostupných v komplexe) spustíme rovnaký test.

Test jedna: začíname so 100 úlohami, záťaž je 50/50 – polovica generuje dokumenty, polovica generuje správy. Druhý test: začnite so 400, zaťaženie 70/30. MS SQL „skončil“ v ​​prvom teste s 360 používateľmi, v druhom s 540 používateľmi a obmedzovač v oboch behoch pracoval s lokálnymi I/O, a to aj napriek tomu, že procesor bol zaťažený v priemere len na 30 %. PostgreSQL dosiahol 440 úloh v prvom teste a až 660 v druhom teste, ale na databázovom serveri všetko padlo na procesor, ktorý bol na „maximálnych používateľoch“ zaťažený na viac ako 90 %.

Pre 1C, kde je počet súbežných používateľov najproblematickejším limitujúcim faktorom, je to pozoruhodný výsledok, a čo je najdôležitejšie, naznačuje to, že tieto najdôležitejšie ruské aplikačné systémy môžu nielen fungovať bez západných komerčných DBMS, ale dokonca to dokážu oveľa lepšie. .