Jen pro zajímavost... v době kdy Alza vznikla, jaké konkrétní jiné řešení, pro daný účel použitelné a, pokud vím, tehdy snad ještě studentem zafinancovatelné, by náš regionální svatý expert doporučil? Protože architektura systému se snadno mění v době návrhu, trochu hůř u rozjetého projektu ve výstavbě, v malé produkci už jdou změny poměrně dost ztuha, a jakmile to vyroste do rozměrů dnešní Alzy, znamená to nasypat desítky milionů do druhého datacentra, na něm rozběhat novou verzi, a pak to buď přemigrovat s odstávkou (což obchodně může dost bolet, když je dat hodně, a tady jich hodně bude), nebo to udělat tak aby nový centrum dokázalo zpracovávat objednávky, přidat nějakou formu balanceru, a data od nejčerstvějších přesypat za provozu. A tahle fáze přelívání dat může trvat klidně několik měsíců.
Jenomže udělat to tak, aby balancer mohl provoz házet na nový systém za současného provozu starého, a přitom aby to pro zákazníka vypadalo úplně stejně, je vyšší dívčí a stojí to ranec. Schůdné je to, při výchozí pozici kdy je všechno na jedné hromadě, jedině skrz roztrhání databáze na menší celky a jejich "rozestěhování", jenomže to TAKY "pár mandayů" a hromadu peněz sežere, a přitom se tím "jen" připraví pozice pro další fázi. A dokud to není HOTOVO, padají všechny ty mandaye a peníze do žumpy, a veškerý rozvoj většinou stojí, protože hrabat do původního systému vývojářům a správcům pod rukama, když mají připravit migraci do nového, je koledování si o nakládačku na firemním parkovišti.
A z te vasi zakazky vyrobite objednavku smerem k dodavateli jak? Pak z toho vyrobite prijem? A vydej? A faktury? Takze se da rici, ze vy nechapete, ze proces prodeje nejsou zdaleka jen nejake objednavky od zakazniku. Pominul jsem pochopitelne spousty dalsich veci - reklamace, vraceni zbozi atd atd. To vse musi mit navaznost do ucetnicvi, skladu ...
ked neviem o com hovorim radsej mlcim. Keby kupili rovnaky storage v druhej lokalite (neveim ze maju svoje datacentrum, pouzivaju verejne), mozu zacat zrkadlit absolutne bez odstavky. Ak by chceli potom automaticky failover, je to mozno o kratsej odstavke a rekonfiguracii clustru, ale nic velke
nestřílejte specialisty, ale člověka co tam dal SQL server od Microsoftu. Ze všech databází co znám je nejpomalejší a má nejzvrácenější logiku. Jinak se imho jedná o problém návrhu že jsou aktivní data v jedné obří databázi se starými objednávkami ale to je oproti selhani cele db detail. Btw proč nemají active-active cluster?
Jako sorry, ale jedná se pořád pouze o obchod, který bere objednávky.
Takže bych obchod rozdělil na nějakou víceméně RO část (typu zobrazování produktů, diskuse a podobné blbosti).
A zmigroval bych až samotné tvoření objednávek, expedici, tracking pošty atd.
Ono fakt mít databázi v řádu TB na OBJEDNÁVKY je dobrý hnus.
Proč se nerozdělí samotný obchod, kde je plno obrázků, komentů, specifikácí a obchodní část, která je kritická? Je fakt nutné mít TB databázi, která pak bude čekat řadu hodin na obnovu a mezitím bude celý kolos stát?
Sorry, ale i kdyby se to mezitím duplikovalo do nějakého .txt souboru (ty objednávky) jen aby to jelo, než najede obnova hlavní databáze, tak by to bylo lepší řešení.
Prostě pořád nechápu, proč obchod, pitomý obchod potřebuje terabajtovou databázi na objednávky, opakuji objednávky?! Pak trvá obnova dva dny... Proboha rozdělte to na super duper "zobrazovací" pasivní část obchodu a to, co je nezbytně nutné pro objednávky, expedici atd.
Je to, jako by někdo (pejsek a kočička) si navrhli eshop, narvali vše do jedné databáze i s obrázky produktů, komenty, popisky, pak najednou má pejsek úspěch, vyroste z toho velký business a ono ups. je to vše pořád splácané v jedné databázi (navíc de*bilní, tedy DB2 je taky dobrý bastl a Oracle je pro změnu arogantní) a pak se dělá obnova půl roku.
A když nemá IT firma investice do IT zařízení, tak ať vyhodí nějakého IT manažera, ono ten dům za prahou a dvě tesly to se rovná plus mínus platu jednoho managera, který v případě fail overu stejně nakonec pak po vás bude chtít něco v excellu, protože nic jiného neumí.