Skaalautuvuus on järjestelmän kyky mukautua kasvaviin vaatimuksiin ja lisääntyviin ratkaistavien tehtävien määrään.

Yhden sovellusratkaisun käyttö eri olosuhteissa

1C:Enterprise 8 -järjestelmässä on hyvät skaalausominaisuudet. Sen avulla voit työskennellä sekä tiedostotilassa että käyttämällä asiakaspalvelintekniikkaa.

• Henkilökohtainen käyttö, työn tiedostoversio
  Kun työskentelet tiedostoversiossa, alusta voi toimia paikallisen tietokannan kanssa, joka sijaitsee samassa tietokoneessa, jolla käyttäjä työskentelee. Tätä työvaihtoehtoa voidaan käyttää kotona tai kannettavalla tietokoneella.
• Pieni työryhmä, työn tiedostoversio
  Tiedostovaihtoehto tarjoaa myös mahdollisuuden useille käyttäjille työskennellä paikallisessa verkossa yhden tietokannan avulla. Tätä työskentelytapaa voidaan käyttää pienissä työryhmissä ja se on helppo asentaa ja käyttää.
• Suuri yritys, asiakas-palvelin versio työstä
  Suurille työryhmille ja yritysmittakaavassa voidaan käyttää työasema-palvelinversiota, joka perustuu kolmikerroksiseen arkkitehtuuriin, jossa käytetään 1C:Enterprise 8 -palvelinta ja erillistä tietokannan hallintajärjestelmää. Se tarjoaa luotettavan tiedon tallennuksen ja tehokkaan käsittelyn, kun suuri määrä käyttäjiä työskentelee samanaikaisesti.
• Hallinta, hajautettu tietokanta
  Suuret holdingyhtiöt voivat käyttää työtä hajautetussa tietokannassa yhdistettynä sekä tiedosto- että asiakas-palvelin-työvaihtoehtojen käyttöön. Hajautetun tietokannan avulla voit yhdistää toisistaan ​​etäällä olevia holdingyhtiön divisioonoita, ja kukin näistä divisioonoista voi puolestaan ​​käyttää tiedosto- tai asiakaspalvelinvaihtoehtoja. Hajautetun tietokannan mekanismi varmistaa kussakin tilan osastossa käytettävien konfiguraatioiden identiteetin ja vaihtaa tietoja hajautettuun järjestelmään kuuluvien yksittäisten tietokantojen välillä.

On tärkeää huomata, että samoja sovellusratkaisuja (konfiguraatioita) voidaan käyttää sekä tiedosto- että asiakaspalvelin-toimintamuodoissa. Siirrettäessä tiedostoversiosta asiakas-palvelin-tekniikkaan, sovellusratkaisuun ei tarvitse tehdä muutoksia. Siksi työvaihtoehdon valinta riippuu täysin asiakkaan tarpeista ja hänen taloudellisista mahdollisuuksistaan. Alkuvaiheessa voit työskennellä tiedostoversiossa, ja sitten käyttäjien määrän ja tietokannan määrän kasvaessa voit helposti vaihtaa tietokannastasi työskentelyn asiakas-palvelin-versioon.

Monen käyttäjän työ

Yksi järjestelmän skaalautuvuuden tärkeimmistä indikaattoreista on kyky työskennellä tehokkaasti, kun ratkaistavien tehtävien määrä, käsiteltävien tietojen määrä ja intensiivisesti työskentelevien käyttäjien määrä kasvavat:

Asiakas-palvelin-versio tarjoaa mahdollisuuden suurelle määrälle käyttäjiä työskennellä rinnakkain. Testit osoittavat, että käyttäjien määrän kasvaessa asiakirjojen syöttönopeus laskee hyvin hitaasti. Tämä tarkoittaa, että intensiivisten käyttäjien määrän kasvaessa automatisoidun järjestelmän vastenopeus pysyy hyväksyttävällä tasolla.

1C:Enterprise 8 -järjestelmän tukemassa tietomallissa ei ole tietokantataulukoita, jotka johtaisivat selvästi useiden käyttäjien samanaikaiseen käyttöön. Samanaikainen pääsy tapahtuu vain käytettäessä loogisesti toisiinsa liittyviä tietoja, eikä se vaikuta tietoihin, jotka eivät aihealueen kannalta liity toisiinsa.

Rutiinitoimintoja suoritettaessa suljetaan pois tilanteet, joissa toiminnan aloittaminen tietyllä raportointijaksolla edellyttää eksklusiivisen tilan asennusta. Rutiinitoiminnot voidaan suorittaa käyttäjille ja organisaatiolle sopivina aikoina. Eksklusiivista tilaa ei asenneta järjestelmän käynnistyksen yhteydessä, vaan silloin, kun on tarpeen suorittaa toiminto, joka vaatii sen ottamista käyttöön. Tällaisten toimintojen suorittamisen jälkeen yksinoikeustila voidaan poistaa käytöstä.

Optimointimekanismit

1C:Enterprise 8 -teknologiaalusta sisältää useita mekanismeja, jotka optimoivat sovellusratkaisujen nopeuden.

Suoritus palvelimella

Asiakas-palvelin-versiossa 1C:Enterprise 8 -palvelimen käyttö mahdollistaa siihen, että voit keskittyä siihen laajimpiin tietojenkäsittelytoimintoihin. Esimerkiksi suoritettaessa erittäin monimutkaisiakin kyselyitä, käyttäjälle ajettava ohjelma saa vain tarvitsemansa valinnan ja kaikki välikäsittely suoritetaan palvelimella. Tyypillisesti palvelinkapasiteetin lisääminen on paljon helpompaa kuin koko asiakaskonekannan päivittäminen.

Tietojen välimuisti

1C:Enterprise 8 -järjestelmä käyttää mekanismia tietokannasta luettujen tietojen välimuistiin tallentamiseen, kun käytetään objektitekniikkaa. Objektiattribuuttia käytettäessä kaikki objektitiedot luetaan RAM-muistissa olevaan välimuistiin. Myöhemmät kutsut saman objektin tietoihin lähetetään välimuistiin, ei tietokantaan, mikä vähentää merkittävästi tarvittavien tietojen hakemiseen kuluvaa aikaa.

Sisäänrakennetun kielen käyttö palvelimella

Asiakas-palvelin-versiossa työskenneltäessä kaikki sovellusobjektien työ suoritetaan vain palvelimella. Palvelimelle on toteutettu myös lomakkeiden ja komentorajapinnan toiminnallisuus.

Palvelin valmistelee lomaketiedot, järjestää elementit ja tallentaa lomaketiedot muutosten jälkeen. Asiakas näyttää palvelimella valmiiksi valmistetun lomakkeen, syöttää tiedot ja soittaa palvelimelle tallentaakseen syötetyt tiedot ja muut tarvittavat toimenpiteet.

Vastaavasti komentorajapinta muodostetaan palvelimelle ja näytetään asiakkaalla. Lisäksi raportit luodaan kokonaan palvelimella ja näytetään asiakkaalla.

Versiot 8.1 ja 8.0 - suorituskyvyn ja skaalautuvuuden vertailu

Sen arvioimiseksi, kuinka järjestelmän suorituskyky ja skaalautuvuus muuttuivat eri olosuhteissa, versiossa 8.1 suoritettiin useita testejä:

• Järjestelmän suorituskyvyn ja skaalautuvuuden arviointi, kun suuri määrä käyttäjiä työskentelee samanaikaisesti
• Järjestelmän suorituskyvyn ja skaalautuvuuden arviointi huippukuormituksen aikana
• Suorituskyvyn arviointi tietyntyyppisten toimintojen osalta

Saatuja 1C:Enterprise 8.1:n indikaattoreita verrattiin vastaaviin indikaattoreihin

1C:Enterprise 8:lle.

Versiot 7.7 ja 8.0 - suorituskyvyn ja skaalautuvuuden vertailu

1C:Enterprise 8:n asiakaspalvelinversion suorituskyvyn ja skaalautuvuuden arvioimiseksi suoritettiin useita testejä, jotka mahdollistivat:

• vertaa ja näytä 1C:Enterprise 8:n etuja vakiokäyttötiloissa;
• arvioida 1C:Enterprise 8:n skaalautuvuutta kuormituksen lisääntyessä ja käsitellyn datan määrän kasvaessa;
• arvioida 1C:Enterprise 8:n skaalautuvuutta ja samalla lisätä käytettyjen laitteiden laskentaresursseja;
• arvioida 1C:Enterprise 8:n suorituskykyä ja suorituskykyä, kun se toimii huippukuormitusolosuhteissa;
• arvioi moniprosessorialustojen käytön tehokkuutta 1C:Enterprise-ongelmien ratkaisemisessa 8.

Manufacturing Enterprise Management -ratkaisun skaalautuvuuden arviointi

Testauksella arvioitiin Manufacturing Enterprise Management (PEM) -sovellusratkaisun skaalautuvuutta useiden käyttäjien samanaikaisessa käytössä.

Testin suorittamisessa käytettiin yleisesti hyväksyttyjä lähestymistapoja yrityksen tietojärjestelmien suorituskyvyn arvioimiseen:

• Käytä tyypillisen sovellusratkaisun testaamiseen.
• Testaa toimintaa, joka on tyypillisen organisaation toiminnan kannalta kriittisintä.
• Testaustoimintoja kiinteillä parametreilla, tyypillistä useimmille organisaatioille
• Järjestelmän käyttäjien tyypillisten työskenaarioiden ohjelmistosimulaatio, joka luo kuormituksen, joka ylittää merkittävästi todellisten käyttäjien luoman kuorman
• Pääindikaattoreina käytetään järjestelmään heijastuneiden liiketapahtumien määrää aikayksikköä kohden ja keskimääräistä toimenpiteen suorittamiseen kuluvaa aikaa.

Esimerkkejä teknisistä parametreista "Manufacturing Enterprise Management" -ratkaisun toteuttamiseksi

Tässä osiossa julkaistaan ​​yksityiskohtaisia ​​tietoja teknisistä parametreista, jotka liittyvät "1C:Enterprise 8. Manufacturing Enterprise Management" -sovelluksen käyttöönotossa erikokoisissa ja -profiilisissa yrityksissä.

Tämän osion tarkoituksena on perehdyttää IT-asiantuntijat tietoihin tosiasiallisesti käytetyistä laitteista ja esimerkkeihin todellisten 1C:Enterprise 8 -toteutusten kuormituksesta.

Nämä tiedot voivat olla hyödyllisiä myös kaikkien 1C:Enterprise 8 -järjestelmän ohjelmien käyttäjille.

Varusteiden valinta

Tämä asiakirja sisältää tietoa siitä, kuinka laitteiden ominaisuudet vaikuttavat järjestelmän käytön tehokkuuteen eri tiloissa, ja antaa suosituksia laitteiden valinnasta ratkaistavien tehtävien mukaan.

1C:Performance Management Center - suorituskyvyn seuranta- ja analysointityökalu

1C:Performance Management Center (1C:PMC) on työkalu tietojärjestelmien suorituskyvyn seurantaan ja analysointiin 1C:Enterprise 8 -alustalla. 1C:PMC on suunniteltu arvioimaan järjestelmän suorituskykyä, keräämään yksityiskohtaisia ​​teknisiä tietoja olemassa olevista suorituskykyongelmista ja analysoimaan nämä tiedot lisäoptimointia varten.

1C:TestCenter - kuormitustestausautomaatiotyökalu

1C:TestCenter on työkalu tietojärjestelmien usean käyttäjän kuormitustestausten automatisointiin 1C:Enterprise 8 -alustalla. Sen avulla voit simuloida yrityksen toimintaa ilman todellisten käyttäjien osallistumista, minkä avulla voit arvioida soveltuvuutta. , tietojärjestelmän suorituskyky ja skaalautuvuus todellisissa olosuhteissa.

Yritystietojärjestelmien käyttöönotto alustalle
1C: Yritys 8

Kokemus sovellusratkaisujen toteuttamisesta 1C:Enterprise 8 -alustalla osoittaa, että järjestelmän avulla voit ratkaista monimutkaisia ​​​​ongelmia - yhden työpaikan automatisoinnista yritystason tietojärjestelmien luomiseen.

Samaan aikaan suuren tietojärjestelmän käyttöönotto asettaa suurempia vaatimuksia verrattuna pieneen tai keskikokoiseen toteutukseen. Yritystason tietojärjestelmän on tarjottava hyväksyttävä suorituskyky useiden käyttäjien samanaikaisen ja intensiivisen työskentelyn olosuhteissa, jotka käyttävät samoja tieto- ja laitteistoresursseja kilpailutilassa.

Verkkologistiikan hallintaan tarvittavien tietojärjestelmän lukuisten toimintojen joukossa keskitymme ensin kahteen keskeiseen ”verkosto”-toimintoon: valikoimanhallintaan ja kategoriahallinnan tukeen.

1. Lajitelmanhallinta verkkokauppayrityksessä.

Vähittäiskaupan verkkoyrityksille, erityisesti elintarvikealalla, on johtamistehtävien monimutkaisuus. Erityisen haastava on valikoiman hallinta.

Mitä paremmin se on ratkaistu, sitä tehokkaammin vähittäiskaupan yritys kokonaisuutena kehittyy ja sen kilpailukyky paranee.

Lajitelmanhallintatehtävä voidaan jakaa kahteen osatehtävään – "ulkoiseen" ja "sisäiseen".

Ensimmäinen on tarkoitettu työskentelyyn ostajan kanssa valikoiman suhteen, toisen tarkoituksena on helpottaa henkilökunnan työtä valikoimaluokkien kanssa.

Näiden ongelmien onnistuneen ratkaisun pitäisi johtaa tuotteiden myynnin tulosten paranemiseen.

Tehokas ratkaisu "ulkoinen" tehtäväryhmä tarpeellista:

• 1) tarjota asiakkaille tietoa tuotteista. Tieto- ja multimediatukijärjestelmät on suunniteltu auttamaan asiakkaita navigoimaan rajattomassa tavarameressä, tekemään oikean valinnan ja hankkimaan arvokasta tietoa mahdollisimman lyhyessä ajassa. Samalla ne auttavat vähittäiskauppiaita analysoimaan kuluttajien mieltymyksiä, stimuloimaan tarvittavien tavaroiden myyntiä, optimoimaan myyntilattian asettelua, sijoittamaan valikoiman järkevästi, mikä varmistaa valikoimanhallinnan automatisoinnin ulkoisten tehtävien onnistuneen ratkaisun;
• 2) ratkaisemaan henkilökohtaisia ​​markkinointiongelmia. Henkilökohtaisen markkinoinnin toteuttaminen on yksi tärkeimmistä valikoimien hallinnan tehtävistä "supermarket" ja "hypermarket" -formaateissa. Lisäksi, jos supermarketille on tärkeintä suorittaa kohdennettua henkilökohtaista markkinointia, jossa seurataan tietyn myymälän tiettyjen kanta-asiakkaiden mieltymysten vaihtelua, niin hypermarketille on tärkeää työskennellä tyypillisten asiakasryhmien kanssa, jotka kuuluvat perinteisesti määriteltyyn luokkaan. vakituisista asiakkaista. Mitä tulee alennusmyymälöihin, henkilökohtainen markkinointi on heille vähemmän merkityksellistä. Kanta-asiakkaiden mieltymysten tunnistamiseksi on erittäin tärkeä tehtävä myös se, että tietojärjestelmässä on mahdollisuus tehdä kattava myyntianalyysi ja määrittää ostojen rakenne;
• 3) suorittaa laadukasta visuaalista myyntiä. Tehokas tavaroiden esillepano myymälän hyllyillä lisää merkittävästi myyntimääriä. Visuaalisen merchandising-ongelmien ratkaisujen laadun arvioimiseksi tietojärjestelmän tulee pystyä ylläpitämään ja analysoimaan planogrammeja, jotka kuvaavat tavaroiden sijoittelua myymälähyllyille.

Päätettäessä sisäiset valikoimanhallintatehtävät on tarpeen automatisoida seuraavat liiketoimintaprosessit:

1) aktiivinen valikoimanhallintaprosessi (lajimamatriisien ylläpito).

Tosiasia on, että tiedot tuotteesta, kun se on syötetty tietokantaan, säilyvät siinä pitkään. Esimerkiksi nykyisellä 7 000 tavaran valikoimalla järjestelmään mahtuu 20–30 tuhatta tavaraa. Näissä olosuhteissa on välttämätöntä tarjota järjestelmän käyttäjälle mahdollisuus työskennellä vain aktiivisen valikoiman ajankohtaisilla tiedoilla (kuva 3.4).

Riisi. 3.4.

Tämän ongelman ratkaisemiseksi tarvitaan varmistaa seuraavat toiminnot:

• tavaroiden tuominen aktiiviseen valikoimaan. Tätä prosessia edeltää yleensä sarja koemarkkinointitoimenpiteitä tietyllä tuotteella, logistiikan valmistelu ja tuotteen myyntiä edeltävä valmistelu;
• tavaroiden ostojen lopettaminen ensimmäisenä vaiheena tavaroiden poistamisessa aktiivisesta valikoimasta. Tämän prosessin tyypillisiä syitä ovat:
  • a) tyytymättömyys tuotteen myynnin tuloksiin;
  • b) valmistajan tekemä valikoiman muutos;
  • c) suhteiden esiintyminen toimittajan kanssa; jne.;
• varastojen täydentämisen lopettaminen yrityksen jakelukeskuksesta;
• tuotteen kanssa työskentelyn lopettaminen viimeisenä vaiheena tuotteen poistamisessa tiedoissa olevasta valikoimasta

järjestelmä (tapahtuu yleensä, kun reservit saavuttavat nollan);

Tavaratietojen poistaminen kassajärjestelmistä (yleensä inventoinnin jälkeen).

Tämän liiketoimintaprosessin automatisoinnin edut :

• mukavuus käyttäjille työskennellessään tuotevalikoiman kanssa;
• merkittävä vähennys virheiden määrässä, joka liittyy mahdottomuuteen sisällyttää asiakirjoihin tuotetta, joka ei kuulu aktiiviseen valikoimaan;
• kyky vastaanottaa analyyttisiä raportteja vain aktiivisesta valikoimasta;
• valikoimanhallintaan osallistuvien johtajien tuottavuuden lisääminen; jne.;
• 2) erimuotoisten vähittäiskaupan yritysten aktiivisen valikoiman hallintaprosessi , sisältyy monimuotoiseen verkkokauppayritykseen (usean valikoiman matriisien hallinta).

Tämän liiketoimintaprosessin automatisointi mahdollistaa tavaroiden siirtymisen hallintaobjektiin, jonka valikoimamatriiseihin tämä tuote ei kuulu (kuva 3.5).

Riisi. 3.5.

On myös huomioitava, että laadukas ratkaisu ”sisäisiin” valikoimanhallinnan ongelmiin on monimuotoisen ketjun vähittäiskaupan yritykselle tärkeintä.

2. Luokkahallinnan tukiprosessi muodostamalla tuotenäkymiä ja näkymiä hallintaobjekteista, joiden kanssa tietty luokkapäällikkö työskentelee.

Tiettyjen tuotekategorioiden, ns. strategisiksi liiketoimintayksiköiksi yhdistettyjen, hallintaan osallistuvan johtajan on tietojärjestelmän parissa työskennellessään tärkeää keskittyä tiettyyn tuotteiden ja hallintaobjektien osajoukkoon.

Kategorioiden johtajan on suositeltavaa nähdä vain se, mikä koskee "hänen tuotekategorioitaan", jolloin syntyy illuusio, ettei tietojärjestelmässä ole mitään muuta kuin hänen liiketoimintayksikköönsä sisältyvät tavarat ja ne hallintaobjektit, joista hän on vastuussa.

Johtajan on luotava tuotevirtaan näkökulmia, jotka esittäisivät logistista ja analyyttistä tietoa sen strategisen liiketoimintayksikön prisman kautta, jonka kanssa hän työskentelee tehtäviensä puitteissa.

Tietojärjestelmän kanssa työskentelyn varmistamiseksi tässä tilassa sen on otettava käyttöön kyky määrittää tuotenäkymiä ja hallintaobjektien näkymiä.

Samanaikaisesti tuotenäkymiä on ainakin kaksi perustyyppiä - staattinen ja dynaaminen.

Jokaisella johtajalla on oma tuotenäkökulmansa, joka määrittelee hänen strategisen liiketoimintayksikkönsä. Tässä tapauksessa samasta liiketoimintayksiköstä vastaaville esimiehille on määritetty yksi näkymä.

Jos määritetään staattinen tuotenäkymä, tuotejoukko itse asiassa tallennetaan nimettynä listana (kuva 3.6). Se on kätevä sarjan tiukkaan kiinnittämiseen (esimerkiksi analyysin suorittamiseen).

Riisi. 3.6.

Jotta tuotenäkymiä voidaan hallita tehokkaasti liiketoimintayksiköiden määrittelyä varten, on parempi määrittää ne tuoteluokittajan solmuissa. Kutsutaan tällaisia ​​näkymiä dynaamiksi (kuva 3.7).

Riisi. 3.7.

Tässä tapauksessa heti kun uusi tuote tuodaan tiettyyn alaryhmään, joka sisältyy kategoriapäällikön dynaamiseen näkökulmaan, siitä tulee automaattisesti osa strategista liiketoimintayksikköä ja johtaja alkaa työskennellä sen kanssa viipymättä.

Kun tuote siirretään toiseen alaryhmään (esimerkiksi luokituksen muutoksen vuoksi), se siirtyy toiseen strategiseen liiketoimintayksikköön ja siirtyy automaattisesti toiselle luokkapäälliköksi työhön.

Hallintaobjektien näkymä muodostetaan samalla tavalla - tämä on staattinen näkymä, joka määrittelee listan myymälöistä ja jakelukeskuksista, joissa tietty luokkapäällikkö toimii (kuva 3.8).

Riisi. 3.8.

Tämä lähestymistapa mahdollistaa järjestelmän käyttäjien, mukaan lukien tavaroiden valmistajat tai toimittajat, pääsyn tietoihin ja tarvittaviin tietojärjestelmän toimintoihin aktiivisen tuotevalikoiman ja vastaavien kauppaobjektien tietyssä osajoukossa.

Tämä toiminto on erittäin tärkeä VMI-logistiikkakonseptia toteutettaessa, kun toimittaja tai valmistaja on mukana "omien" tuotteidensa toimitusketjun hallinnassa.

Tehdään lopuksi useita johtopäätöksiä yllä olevasta:

• 1) kauppayrityksen valikoiman hallinta on tärkein tehtävä, jonka ratkaisun laatu määrää suoraan sen menestymisen;
• 2) ulkopuolisen valikoimanhallinnan ongelmien, erityisesti suurmuotoisten vähittäiskaupan yritysten, ratkaisut on suunniteltu tarjoamaan asiakkaiden tietojärjestelmiä (tietokioski, multimediapääte, tietokärryt jne.);
• 3) kyky ylläpitää valikoimamatriiseja, tuotenäkymiä ja hallintaobjektinäkymiä tietojärjestelmässä mahdollistaa kyvyn ratkaista sisäinen valikoiman hallinnan tehtävien ryhmä, joka liittyy suoraan luokkahallintatoiminnon toteutuksen laatuun kauppayrityksessä .

Tietojärjestelmän skaalautuvuus

Verkkokaupan yrityksen kehittyessä tulee joskus hetki, jolloin tietojärjestelmä ei enää pysty tukemaan liiketoiminnan kasvua. Siksi kysymys tietojärjestelmän riittävyydestä yrityksen kasvuun on erittäin tärkeä.

Tässä tapauksessa on otettava huomioon kaksi näkökohtaa - riittävyys kasvuun ja järjestelmän skaalautuvuus.

Jos yrityksen kasvuun liittyy suhteettoman suuri IT-infrastruktuurikustannusten nousu, tietojärjestelmä ei pysty optimaalisesti tukemaan liiketoiminnan laajentamista.

Yrityksen kasvuun riittämättömät tietojärjestelmät voivat johtaa niiden toimintakustannusten kiihtyvään nousuun.

Ensinnäkin ratkaisuarkkitehtuurin tulee vastata yrityksen kasvua. Kun yritys kasvaa ja sillä on satoja toimitiloja, järjestelmän rakentaminen hajautetun arkkitehtuurin varaan merkitsee mielestämme jatkuvasti kasvavaa IT-tukikustannusten nousua myymälää kohden.

Sataa tai useampaa myymälää hallinnoivan verkkoyrityksen kontekstissa tietojen synkronointi niiden myöhempään yhdistämiseen keskustassa vaikeutuu ja tulee hetki, jolloin se on mahdotonta.

Tietojärjestelmän skaalautuvuuden varmistamiseksi (kyky tarjota tarvittava määrä käyttäjiä, toimia vaaditulla tietomäärällä tyydyttävällä suorituskyvyllä) on tarpeen valita oikea alusta - sopiva ohjelmisto ja palvelinlaitteisto.

Jos vähittäiskauppayritys kasvaa, myyntitiedon määrää ei lasketa gigatavuina, vaan teratavuina, eikä tämä onnistu ilman "teollisia", skaalautuvia tietokannan hallintajärjestelmiä, kuten Oracle, Progress jne.

Tarvitaan myös käyttöjärjestelmiä, joiden avulla olisi mahdollista ”siirtyä” toiseen laskentalaiteluokkaan.

On selvää, että nopean kasvun strategian mukaisten kauppaketjuyritysten on tietojärjestelmää valittaessa ja sitä käyttäessään pohdittava vakavasti tietojärjestelmän skaalautuvuutta ja omistuskustannuksia.

Olemme vakuuttuneita siitä, että yrityksen kasvaessa hajautetusta arkkitehtuurista tulee valtava este liikkeenjohdon ja IT-infrastruktuurin käyttökustannusten vähentämiselle.

Tietojärjestelmän keskitetty arkkitehtuuri merkitsee alhaisempia omistuskustannuksia eikä vaadi IT-henkilöstön jatkuvaa lisäystä kauppaverkoston kasvaessa.

Skaalautuvuus - laitteen kyky lisätä sitä
mahdollisuuksia
lisäämällä toiminnallisten lohkojen määrää,
esiintyy yksin ja
samat tehtävät.
Sanasto.ru

Yleensä ihmiset alkavat miettiä skaalausta, kun se tapahtuu
palvelin ei pysty selviytymään sille osoitetusta työstä. Minkä kanssa hän ei oikein ole?
selviytyä? Minkä tahansa verkkopalvelimen toiminta tiivistyy suurelta osin perusasioihin
Tietokoneiden ammatti on tietojenkäsittely. Vastaus HTTP- (tai mihin tahansa muuhun) pyyntöön
edellyttää joidenkin toimintojen suorittamista joillekin tiedoille. Vastaavasti,
meillä on kaksi pääkokonaisuutta - data (joka on ominaista sen määrällä) ja
laskelmat (joille on ominaista monimutkaisuus). Palvelin ei ehkä pysty selviytymään siitä
toimi suuren tietomäärän vuoksi (se ei ehkä mahdu fyysisesti
palvelin) tai raskaan laskentakuorman vuoksi. Täällä puhutaan
tietysti kokonaiskuormasta - yhden pyynnön käsittelyn monimutkaisuus voi olla
on pieni, mutta suuri määrä niistä voi ylittää palvelimen.

Puhumme pääasiassa skaalauksesta esimerkin avulla
tyypillinen kasvava verkkoprojekti, mutta tässä kuvatut periaatteet sopivat myös
muut käyttöalueet. Ensin tarkastellaan projektin arkkitehtuuria ja yksinkertaista
jakaa sen komponentit useille palvelimille, ja sitten puhumme siitä
laskennan ja datan skaalaus.

Tyypillinen sivuston arkkitehtuuri

Tyypillisen verkkosivuston elämä alkaa hyvin yksinkertaisesta arkkitehtuurista
- tämä on yksi verkkopalvelin (yleensä Apache toimii roolissaan),
joka hoitaa kaiken HTTP-pyyntöjen huoltotyön,
vierailijoilta saatuja. Hän antaa asiakkaille niin sanottua "statiikkaa".
palvelinlevyllä on tiedostoja, jotka eivät vaadi käsittelyä: kuvat (gif,
jpg, png), tyylisivut (css), asiakaskomentosarjat (js, swf). Sama palvelin
vastaa laskelmia vaativiin kyselyihin - yleensä muodostuu
html-sivuja, vaikka joskus kuvat ja muut asiakirjat luodaan lennossa.
Useimmiten vastaukset tällaisiin pyyntöihin luodaan PHP:llä kirjoitetuilla skripteillä,
perl tai muut kielet.

Tällaisen yksinkertaisen työsuunnitelman haittapuoli on erilainen
pyyntöjen luonne (tiedostojen lataaminen levyltä ja skriptien laskennallinen työ)
käsittelee sama verkkopalvelin. Laskennalliset kyselyt vaativat
pitää paljon tietoa palvelimen muistissa (skriptikielen tulkki,
skriptit itse, data, jonka kanssa ne työskentelevät) ja voivat viedä paljon
laskentaresurssit. Staattisten tietojen antaminen sitä vastoin vaatii vähän resursseja
prosessori, mutta voi kestää kauan, jos asiakkaalla on alhainen
viestintänopeus. Apache-palvelimen sisäinen suunnittelu olettaa, että jokainen
yhteys hoidetaan erillisellä prosessilla. Tämä on kätevä skriptien suorittamiseen,
se ei kuitenkaan ole optimaalinen yksinkertaisten kyselyjen käsittelyyn. Osoittautuu, että raskas (alkaen
komentosarjat ja muut tiedot) Apache-prosessit viettävät paljon aikaa odottaessaan (ensin vastaanottaessaan
pyyntö, sitten vastausta lähetettäessä), tuhlaa palvelimen muistia.

Ratkaisu tähän ongelmaan on jakaa käsittelytyö
pyynnöt kahden eri ohjelman välillä - ts. jako etuosaan ja
tausta Kevyt etupalvelin palvelee staattista sisältöä ja loput
pyynnöt ohjataan (välityspalvelin) taustajärjestelmään, jossa muodostus suoritetaan
sivuja. Hitaiden asiakkaiden odottamisesta huolehtii myös käyttöliittymä ja jos se käyttää
multipleksointi (kun yksi prosessi palvelee useita asiakkaita - niin
työ, esimerkiksi nginx tai lighttpd), odotus ei ole käytännössä mitään
kustannuksia.

Sivuston muiden osien joukossa on huomioitava tietokanta
joka yleensä tallentaa tärkeimmät järjestelmätiedot - suosituimmat ovat täällä
ilmaiset DBMS MySQL ja PostgreSQL. Varastointi on usein jaettu erikseen
binääritiedostot, jotka sisältävät kuvia (esimerkiksi artikkelien kuvituksia
sivusto, avatarit ja käyttäjien valokuvat) tai muita tiedostoja.

Näin ollen saimme arkkitehtuurikaavion, joka koostui
useita komponentteja.

Tyypillisesti sivuston elinkaaren alussa kaikki arkkitehtuurin osat
sijaitsevat samalla palvelimella. Jos se ei kestä kuormaa, niin
on yksinkertainen ratkaisu - siirrä helpoimmin erotettavat osat toiseen
palvelin. Helpoin tapa aloittaa tietokannan käyttö on siirtää se erilliseen palvelimeen ja
muuttaa pääsytietoja skripteissä. Muuten, tällä hetkellä kohtaamme
oikean koodiarkkitehtuurin tärkeys. Jos työskentelet tietokannan kanssa
siirretty erilliseen moduuliin, joka on yhteinen koko sivustolle - korjaa sitten parametrit
liitännät tulee olemaan helppoja.

Myös tavat erottaa komponentteja edelleen toisistaan ​​ovat selvät - voit esimerkiksi siirtää käyttöliittymän erilliseen palvelimeen. Mutta yleensä frontend
vaatii vähän järjestelmäresursseja ja tässä vaiheessa sen poistaminen ei tuota merkittävää
tuottavuuden kasvu. Useimmiten sivustoa rajoittaa suorituskyky.
komentosarjat - vastauksen (html-sivun) luominen kestää liian kauan.
Siksi seuraava vaihe on yleensä taustapalvelimen skaalaaminen.

Laskennan jakautuminen

Tyypillinen tilanne kasvavalle sivustolle - tietokanta on jo
siirretty erilliselle koneelle, jako käyttöliittymään ja taustajärjestelmään on valmis,
liikenne kuitenkin kasvaa edelleen, eikä taustalla ole aikaa käsitellä
pyynnöt. Tämä tarkoittaa, että meidän on jaettava laskelmat useille
palvelimia. Tämä on helppo tehdä – osta vain toinen palvelin ja asenna se siihen
Se sisältää ohjelmia ja komentosarjoja, jotka ovat tarpeen taustajärjestelmän toimimiseksi.
Tämän jälkeen sinun on varmistettava, että käyttäjien pyynnöt jaetaan
(tasapainotettu) vastaanotettujen palvelimien välillä. Tietoja erilaisista tasapainotusmenetelmistä
käsitellään alla, mutta toistaiseksi huomaamme, että tämän tekee yleensä käyttöliittymä,
joka on määritetty niin, että se jakaa pyynnöt tasaisesti välillä
palvelimia.

On tärkeää, että kaikki taustapalvelimet pystyvät oikein
vastata pyyntöihin. Tämä vaatii yleensä jokaisen työskentelyn
sama ajan tasalla oleva tietojoukko. Jos tallennamme kaikki tiedot yhteen
tietokanta, DBMS itse varmistaa jaetun pääsyn ja tietojen johdonmukaisuuden.
Jos joitakin tietoja on tallennettu paikallisesti palvelimelle (esimerkiksi php-istunnot
asiakas), sinun kannattaa harkita niiden siirtämistä jaettuun tallennustilaan tai muuhun
monimutkainen pyynnön jakelualgoritmi.

Ei vain työtä voi jakaa useille palvelimille
komentosarjoja, mutta myös tietokannan suorittamia laskelmia. Jos DBMS toimii paljon
monimutkaisia ​​kyselyitä, jotka vievät palvelimen CPU-aikaa, voit luoda useita
kopiot tietokannasta eri palvelimille. Tämä nostaa esiin synkronointiongelman
tiedot muuttuessaan, ja tässä voidaan soveltaa useita lähestymistapoja.

• Synkronointi sovellustasolla. Tässä tapauksessa meidän
  komentosarjat kirjoittavat itsenäisesti muutoksia kaikkiin tietokannan kopioihin (ja itse kuljettavat
  vastuu tietojen oikeellisuudesta). Tämä ei ole paras vaihtoehto, koska se on
  vaatii huolellisuutta toteutuksessa ja on erittäin virhesietoinen.
• Replikointi- eli automaattinen replikointi
  yhdellä palvelimella tehdyt muutokset vaikuttavat kaikkiin muihin palvelimiin. Yleensä milloin
  Replikointia käytettäessä muutokset kirjoitetaan aina samalle palvelimelle - sitä kutsutaan isäntäpalvelimeksi ja jäljellä olevia kopioita kutsutaan orjaksi. Useimmissa DBMS-järjestelmissä on
  sisäänrakennetut tai ulkoiset työkalut replikoinnin järjestämiseen. Erottaa
  synkroninen replikointi - tässä tapauksessa tietojen muutospyyntö odottaa
  kunnes tiedot on kopioitu kaikille palvelimille, ja vasta sitten se valmistuu onnistuneesti - ja asynkronisesti - tässä tapauksessa muutokset kopioidaan orjapalvelimille
  viive, mutta kirjoituspyyntö valmistuu nopeammin.
• Multi-master replikointi. Tämä lähestymistapa on samanlainen
  edellinen, mutta täällä voimme tehdä datamuutoksia ilman pääsyä
  tietylle palvelimelle, mutta mihin tahansa tietokannan kopioon. Samalla muutoksia
  synkronisesti tai asynkronisesti siirretään muihin kopioihin. Joskus tätä järjestelmää kutsutaan
  termi "tietokantaklusteri".

Järjestelmän jakamiseen palvelimien välillä on erilaisia ​​vaihtoehtoja.
Meillä voi esimerkiksi olla yksi tietokantapalvelin ja useita taustaohjelmia (erittäin
tyypillinen järjestelmä) tai päinvastoin - yksi taustaohjelma ja useita tietokantoja. Mitä jos skaalaamme
sekä taustapalvelin että tietokanta, voit yhdistää taustajärjestelmän ja kopion tietokannasta
yksi auto. Joka tapauksessa heti kun meillä on useita kopioita
millä tahansa palvelimella, herää kysymys, kuinka jakaa oikein niiden välillä
ladata.

Tasapainotusmenetelmät

Luodaan useita palvelimia (mihin tahansa tarkoitukseen - http, tietokanta jne.), joista jokainen voi käsitellä pyyntöjä. Ennen
edessämme on, kuinka jakaa työ heidän kesken, miten selvittää mikä
palvelin lähettää pyynnön? Pyyntöjen jakamiseen on kaksi päätapaa.

• Tasapainotusyksikkö. Tässä tapauksessa asiakas lähettää pyynnön yhdelle
  hänen tuntemaansa kiinteään palvelimeen, ja se ohjaa jo pyynnön jompaankumpaan
  toimivat palvelimet. Tyypillinen esimerkki on sivusto, jossa on yksi käyttöliittymä ja useita
  taustapalvelimet, joille pyynnöt välitetään. Kuitenkin "asiakas" voi
  olla järjestelmässämme - esimerkiksi komentosarja voi lähettää pyynnön osoitteeseen
  tietokannan välityspalvelimelle, joka välittää pyynnön jollekin DBMS-palvelimista.
  Itse tasapainotussolmu voi toimia sekä erillisellä palvelimella että yhdellä
  toimivilta palvelimilta.

  Tämän lähestymistavan edut ovat
  että asiakkaan ei tarvitse tietää mitään järjestelmän sisäisestä rakenteesta - määrästä
  palvelimet, niiden osoitteet ja ominaisuudet - vain
  tasapainottaja Haittana on kuitenkin se, että tasapainotusyksikkö on yksittäinen
  järjestelmän vikapiste - jos se epäonnistuu, koko järjestelmä on
  ei toimi. Lisäksi raskaan kuormituksen alaisena tasapainotin voi yksinkertaisesti pysähtyä
  selviytymään työstään, joten tämä lähestymistapa ei aina sovellu.

• Asiakaspuolen tasapainotus. Jos haluamme välttää
  yksi vika, on vaihtoehtoinen vaihtoehto - uskoa palvelimen valinta
  asiakkaalle itselleen. Tässä tapauksessa asiakkaan tulee tietää yrityksemme sisäinen rakenne
  järjestelmät voivat valita oikein, mihin palvelimeen ottaa yhteyttä.
  Kiistaton etu on epäonnistumiskohdan puuttuminen - jos jokin niistä
  palvelimilla asiakas voi ottaa yhteyttä muihin. Hinta tälle kuitenkin on
  monimutkaisempi asiakaslogiikka ja vähemmän tasapainottavaa joustavuutta.

Tietysti on myös näiden lähestymistapojen yhdistelmiä. Esimerkiksi,
niin tunnettu kuormanjakomenetelmä, johon DNS-tasapainotus perustuu
että määritettäessä sivuston IP-osoitetta asiakkaalle annetaan
yhden useista identtisistä palvelimista osoite. Siten DNS toimii a
sen tasapainotussolmun rooli, josta asiakas vastaanottaa "jakelun". kuitenkin
DNS-palvelimien rakenne tarkoittaa, että vikakohtaa ei ole
päällekkäisyys - eli kahden lähestymistavan edut yhdistyvät. Tietenkin tämä
Tasapainotusmenetelmässä on myös haittoja - esimerkiksi tällaista järjestelmää on vaikea dynaamisesti toteuttaa
rakentaa uudelleen.

Työskentely sivuston kanssa ei yleensä rajoitu yhteen pyyntöön.
Siksi suunnittelussa on tärkeää ymmärtää, voivatko peräkkäiset kyselyt
eri palvelimet käsittelevät asiakasta oikein, tai asiakkaan täytyy käsitellä sitä oikein
sidottu yhteen palvelimeen työskennellessään sivuston parissa. Tämä on erityisen tärkeää, jos
sivusto tallentaa väliaikaisia ​​tietoja käyttäjän istunnosta (tässä
Tässä tapauksessa myös ilmainen jakelu on mahdollista - mutta silloin se on tallennettava
istunnot (kaikille palvelimille yhteinen tallennustila). "Sitoudu" vierailijaan
voit määrittää tietyn palvelimen sen IP-osoitteen perusteella (joka voi kuitenkin muuttua),
tai evästeellä (johon palvelintunniste on tallennettu valmiiksi), tai jopa
yksinkertaisesti ohjaamalla se haluttuun verkkotunnukseen.

Toisaalta laskentapalvelimilla ei välttämättä ole yhtäläisiä oikeuksia.
Joissakin tapauksissa on edullista tehdä päinvastoin, varata erillinen palvelin
yhden tyyppisten pyyntöjen käsittely - ja saat vertikaalisen jaon
toimintoja. Sitten asiakas tai tasapainotussolmu valitsee palvelimen
riippuen vastaanotetun pyynnön tyypistä. Tämä lähestymistapa antaa meille mahdollisuuden erota
tärkeitä (tai päinvastoin, ei kriittisiä, mutta vaikeita) pyyntöjä muilta.

Tietojen jakelu

Olemme oppineet jakamaan laskelmia, niin suuria
läsnäolo ei ole meille ongelma. Tietomäärät kuitenkin jatkavat kasvuaan,
niiden säilyttäminen ja käsittely on yhä vaikeampaa - mikä tarkoittaa, että on aika rakentaa
hajautettu tiedon tallennus. Tässä tapauksessa meillä ei ole enää yhtä tai
useita palvelimia, jotka sisältävät täydellisen kopion tietokannasta. Sen sijaan tiedot
jaetaan eri palvelimille. Mitkä jakelujärjestelmät ovat mahdollisia?

• Pystysuuntainen jakautuminen(pysty osiointi) - yksinkertaisimmassa tapauksessa
  edustaa yksittäisten tietokantataulukoiden siirtoa toiselle palvelimelle. klo
  Tässä tapauksessa meidän on muutettava komentosarjoja päästäksemme eri palvelimiin
  eri dataa. Limiitissä voimme tallentaa jokaisen taulukon erilliselle palvelimelle
  (vaikka käytännössä tästä ei todennäköisesti ole hyötyä). Ilmeisesti tämän kanssa
  jakelussa, menetämme kyvyn tehdä SQL-kyselyitä, jotka yhdistävät tietoja
  kaksi pöytää eri palvelimilla. Tarvittaessa voit toteuttaa
  logiikan yhdistäminen sovelluksessa, mutta se ei ole yhtä tehokas kuin DBMS:ssä.
  Siksi tietokantaa osioitaessa sinun on analysoitava taulukoiden väliset suhteet,
  jakaa mahdollisimman itsenäisiä taulukoita.

  Monimutkaisempi tapaus
  pystysuuntainen perusjakauma on yhden taulukon jakauma osana
  osa sen sarakkeista päätyy yhdelle palvelimelle ja osa toiselle. Tämä tekniikka
  on harvinaisempi, mutta sitä voidaan käyttää esimerkiksi pienten erottamiseen
  ja usein päivitetyt tiedot suuresta määrästä harvoin käytettyä dataa.

• Vaakasuora jakautuminen(vaakasuora osiointi) - koostuu
  tietojen jakaminen yhdestä taulukosta useille palvelimille. Itse asiassa päällä
  jokainen palvelin luo samanrakenteen taulukon ja tallentaa
  tiettyä dataa. Voit jakaa tietoja palvelimille eri tavoin
  kriteerit: alueen mukaan (tietueet tunnuksella< 100000 идут на сервер А, остальные - на сервер Б), по списку значений (записи типа «ЗАО» и «ОАО» сохраняем на сервер
  A, loput - palvelimelle B) tai tietyn kentän hash-arvon mukaan
  levyjä. Tietojen vaakasuora osiointi mahdollistaa rajoittamattoman määrän tallentamisen
  tietueiden määrä vaikeuttaa kuitenkin valintaa. Tehokkain tapa valita
  tallentaa vain, kun tiedetään, mille palvelimelle ne on tallennettu.

Oikean tiedonjakelumallin valitsemiseksi sinun on
analysoida huolellisesti tietokannan rakenne. Olemassa olevat taulukot (ja mahdollisesti
yksittäiset kentät) voidaan luokitella tietueiden käyttötiheyden mukaan, tiheyden mukaan
päivitykset ja suhteet (tarve tehdä valintoja useista
taulukot).

Kuten edellä mainittiin, tietokannan lisäksi sivusto usein tarvitsee
tallennustila binääritiedostoille. Hajautetut tiedostojen tallennusjärjestelmät
(itse asiassa tiedostojärjestelmät) voidaan jakaa kahteen luokkaan.

• Työskentely käyttöjärjestelmän tasolla. Lisäksi varten
  sovelluksia, tiedostojen käsittely tällaisessa järjestelmässä ei eroa tavallisesta työstä
  tiedostot. Palvelimien välisestä tiedonvaihdosta vastaa käyttöjärjestelmä.
  Esimerkkejä tällaisista tiedostojärjestelmistä ovat pitkään tunnetut
  NFS-perhe tai vähemmän tunnettu mutta nykyaikaisempi Luster-järjestelmä.
• Toteutettu sovellustasolla hajautettu
  Tietovarastot tarkoittavat, että tiedonvaihtotyö suoritetaan itse
  sovellus. Yleensä tallennustilan kanssa työskentelyyn liittyvät toiminnot sijoitetaan
  erillinen kirjasto. Yksi silmiinpistäviä esimerkkejä tällaisesta tallennustilasta on MogileFS, jonka on kehittänyt
  LiveJournalin luojat. Toinen yleinen esimerkki on käyttö
  WebDAV-protokolla ja sitä tukeva tallennustila.

On huomattava, että tiedon jakelu ei ratkaise vain
kysymys varastoinnista, mutta myös osittain kuorman jakautumisesta - jokaisessa
Palvelimella on vähemmän tietueita, ja siksi ne käsitellään nopeammin.
Laskelmien ja tietojen jakelumenetelmien yhdistelmä mahdollistaa rakentamisen
mahdollisesti rajattomasti skaalautuva arkkitehtuuri, joka pystyy toimimaan
mikä tahansa datamäärä ja mikä tahansa kuormitus.

johtopäätöksiä

Yhteenvetona sanotusta tehdään johtopäätökset lyhyiden teesien muodossa.

• Kaksi pääasiallista (ja siihen liittyvää) skaalaushaastetta ovat laskennallinen jakelu ja tietojen jakelu
• Tyypillinen sivustoarkkitehtuuri sisältää roolien jakamisen ja
  sisältää käyttöliittymän, taustajärjestelmän, tietokannan ja joskus tiedostojen tallennustilan
• Käytä pienille tietomäärille ja raskaille kuormille
  tietokannan peilaus - synkroninen tai asynkroninen replikointi
• Suuria tietomääriä varten on tarpeen jakaa tietokanta - split
  sitä pysty- tai vaakasuunnassa
• Binaarit tallennetaan hajautettuihin tiedostojärjestelmiin
  (toteutettu käyttöjärjestelmätasolla tai sovelluksessa)
• Tasapainotus (pyyntöjen jakautuminen) voi olla yhtenäistä tai
  jaettu toiminnallisuudella; tasapainotussolmun kanssa tai asiakkaan puolella
• Oikea menetelmien yhdistelmä antaa sinun kestää kaiken kuorman;)

Linkit

Voit jatkaa tämän aiheen tutkimista mielenkiintoisilla englanninkielisillä sivustoilla ja blogeissa.

Yritysjärjestelmien skaalautuvuus tarkoittaa kykyä lisätä tehoaan yhdistämällä uusia laitteita ja ohjelmistoja ilman, että jälkimmäisiin tehdään lisämuutoksia. Tämä kohta on tärkeä käytettäessä nykyaikaisia ​​tietokone- ja verkkotekniikoita. Esimerkkinä voidaan antaa hajautettu tietojenkäsittely keskuspankissa ja sen konttoreissa.

Skaalautuvuus saavutetaan eri tasoilla: a) Tekninen; b) systeeminen; c) Verkko; d) DBMS; d) Sovellettu. Käyttöjärjestelmässä skaalautuvuus tarkoittaa, että käyttöjärjestelmä ei ole sidottu yhteen prosessoriarkkitehtuuriin. Jos käyttäjän tehtävät monimutkaistuvat ja tietokoneverkon vaatimukset laajenevat, käyttöjärjestelmän on tarjottava mahdollisuus lisätä tehokkaampia ja tuottavampia palvelimia ja työasemia yritysverkkoon. Voit ottaa huomioon laitteiston, ohjelmiston skaalautuvuuden ja koko järjestelmän skaalautuvuuden. Skaalautuvuus perustuu seuraaviin teknologioihin: a) Kansainväliset standardit; b) Verkko- ja tietoliikennetekniikat; c) käyttöjärjestelmät; d) Asiakas/palvelintekniikka ja monet muut keinot.

Työ loppu -

Tämä aihe kuuluu osioon:

Tietotekniikka johtamisessa. Ohjausjärjestelmien luokittelu

CIS:n tarkoituksena on valmistautua nykyaikaisen tietotekniikan käyttöön CIS:n puitteissa tieteellisten ja käytännön ongelmien ratkaisemisen työkaluna. Tietotekniikan käsite Yritystieto..

Jos tarvitset lisämateriaalia tästä aiheesta tai et löytänyt etsimääsi, suosittelemme käyttämään hakua teostietokannassamme:

Mitä teemme saadulla materiaalilla:

Jos tämä materiaali oli sinulle hyödyllistä, voit tallentaa sen sivullesi sosiaalisissa verkostoissa:

Kaikki tämän osion aiheet:

Tietotekniikan käsite. Yritysten tietotekniikat
Teknologia on järjestelmä, jossa on toisiinsa yhdistettyjä menetelmiä materiaalien käsittelyyn ja tuotteiden valmistusmenetelmiin tuotantoprosessissa. Tietotekniikka on toisiinsa liittyvien teknologioiden järjestelmä

Tietojenkäsittelytekniikka. Yhteentoimivuuden, avoimuuden ja modulaarisuuden käsite
Tieto on joukko tosiasioita, ilmiöitä, kiinnostavia tapahtumia, jotka ovat rekisteröinnin ja käsittelyn alaisia. Tämä tarkoittaa kahden pisteen läsnäoloa: tiedon lähde ja vastaanottaja (kuluttaja).

Tietojärjestelmien tukityypit
ASOEI-tuen tyypit: a) Tekninen; b) matemaattinen; c) Kielellinen; d) Ohjelmisto. Tietotuki – tiedon luokittelu- ja koodausjärjestelmä, käsittelyn tekninen kaavio

Yrityksen tietojärjestelmän arkkitehtuuri
CIS:n arkkitehtuuri koostuu useista tasoista: a) Informaatiolooginen taso – on joukko tietovirtoja ja -keskuksia (solmuja), joista syntyy, kulutetaan

Yritystietojärjestelmien vaatimukset
Tietojenkäsittelyteknologioiden aktiivisen parantamisen prosessit ovat seurausta siitä, että nykyaikaisille tietojärjestelmille (CIS) asetetaan yhä enemmän seuraavia vaatimuksia: a) rakenne

Yritysten tietojärjestelmien heterogeenisyys. Ratkaisuja yritysten tietojärjestelmien heterogeenisyyden ongelmiin
Tärkein rooli on kysymyksillä, jotka liittyvät yritysjärjestelmien heterogeenisyyden ongelmien ratkaisemiseen ja sen koostumukseen sisältyvien komponenttien yhteensopivuuden varmistamiseen. Heterogeenisuus laskentajärjestelmissä voi aiheuttaa

Kansainväliset standardit tietokonetietotekniikan alalla
Tällä hetkellä ISO:n (International Standards Organisation) tai tarkemmin sanottuna ISO:n teknisen komitean kehittämä standardisarja yrityksen laatujärjestelmälle on levinnyt maailmanlaajuisesti.

Ohjausobjektin tietomallit
Nykyaikaista yritystä voidaan pitää tehokkaana tietokeskuksena, jonka tiedon lähteinä ovat ulkoinen ja sisäinen liiketoimintaympäristö. Ulkoinen liiketoimintaympäristö -

Tietotuki yritysten tietojärjestelmille
Tietotuki - järjestelmä tietojen luokittelua ja koodausta varten, tietojenkäsittelyn tekninen järjestelmä, sääntely- ja viitetiedot, asiakirjavirtajärjestelmä jne. Tiedollinen

Politiikka tietoresurssien muodostamiseksi yhtenäiseksi tietotilaksi
Tietoresurssien vuorovaikutuksen varmistamiseksi eri tasoilla on välttämätöntä: a) Nykyaikaisen tietotekniikan käyttö; b) Nykyaikainen liikennetietoympäristö; c) Syö

Tietojenkäsittelyjärjestelmien käytön edut
Usean koneen ja usean prosessorin tietokoneiden käytön ansiosta on mahdollista saavuttaa seuraavat edut: 1) Lisääntynyt tuottavuus ja nopeus

Viestintälaitteet ja viestintälaitteet
Viestintätekniikka tarjoaa yhden johtamistoimintojen päätehtävistä - tiedonsiirron hallintajärjestelmän sisällä ja tiedonvaihdon ulkoisen ympäristön kanssa.

Käyttöjärjestelmät (OS). OS-tekniikat
Järjestelmäohjelmien joukossa käyttöjärjestelmällä (OS) on erityinen paikka. Käyttöjärjestelmä (OS) ymmärretään sarjaksi ohjelmia, jotka hallitsevat

OS Unix ja rakenneratkaisut yritysten tietojärjestelmissä. Liikkuvuuden käsite
Unix-käyttöjärjestelmän kehitys alkoi Bell Laboratoriesilla vuonna 1968. Usean käyttäjän 32-bittistä Unix-käyttöjärjestelmää ehdotettiin pääkehykselle. Vuonna 1976 AT&T (johon kuului B

Tietokoneverkkojen käsite ja niiden ominaisuudet
Tietokoneverkko on joukko maantieteellisesti hajallaan olevia tietokoneita, jotka on yhdistetty tiedonsiirtokanavien avulla laskentaresurssien tehokasta käyttöä varten. Toteutettavuus

Tietokoneverkkojen kokoonpano
Tietokoneverkot sisältävät laitteistoja, ohjelmistoja ja tietotyökaluja. Toisin sanoen tietokoneverkkoa voidaan pitää järjestelmänä, jonka laitteistot ja ohjelmistot on hajautettu koko alueelle.

Tietokoneverkkoarkkitehtuuri
Yleisesti ottaen tietokoneverkkojen arkkitehtuuria voidaan tarkastella kahdesta näkökulmasta - tietokoneverkon fyysinen organisaatio (verkkotopologia) ja verkon organisointi loogisella tasolla

Tietokoneverkot, joissa on oma palvelin ja niiden ominaisuudet
Client-server on verkkoarkkitehtuuri, jossa laitteet ovat joko asiakkaita tai palvelimia. Asiakas on pyytävä kone (yleensä PC), palvelin on kone, joka vastaa.

Globaalien tietokoneverkkojen rakenne
Globaalit verkot (WAN, Wide Area Networks) ovat järjestelmiä, joissa on laajakaistakanavat ja joiden avulla voit järjestää tietokoneiden välistä vuorovaikutusta pitkien etäisyyksien päässä. Ihannetapauksessa globaali tietokone

Tietokoneverkkojen skaalautuvuus
Skaalautuvuus – kyky lisätä verkkoresursseja ja tilaajia. Tietokoneverkoissa, joissa on oma palvelin, työasemat yhdistetään dedikoituihin palvelimiin ja palvelimet puolestaan ​​ryhmitellään.

Internet-protokollat
Protokolla on tässä tapauksessa kuvaannollisesti sanottuna "kieli", jota tietokoneet käyttävät tiedon vaihtamiseen verkossa työskennellessä. Jotta verkon eri tietokoneet voivat kommunikoida, niiden on kommunikoitava

Internet-osoite
Internet on maailmanlaajuinen yhteenliitettyjen tietokoneverkkojen järjestelmä, joka perustuu IP-protokollan käyttöön ja datapakettien reitittämiseen. Internet muodostaa globaalin informaatiotilan, palvelevan

Skaalautuvuus on kyky lisätä prosessorien määrää ja tehoa, RAM-muistin ja ulkoisen muistin määrää ja muita CS-resursseja. Skaalautuvuus on varmistettava tietokoneen arkkitehtuurilla ja suunnittelulla sekä siihen liittyvillä ohjelmistotyökaluilla.

Joten esimerkiksi kykyä skaalata klusteria rajoittaa prosessorin nopeuden suhde tiedonsiirtonopeuteen, jonka ei pitäisi olla liian suuri (todellisuudessa tämä suhde suurille järjestelmille ei saisi olla suurempi kuin 3-4, muuten se on ei edes mahdollista toteuttaa yhtä käyttöjärjestelmän kuvatilaa ). Toisaalta prosessorien ja kommunikaattorien kehityshistorian viimeiset 10 vuotta osoittavat, että nopeusero niiden välillä kasvaa jatkuvasti. Jokaisen todella skaalautuvaan järjestelmään lisätyn uuden prosessorin pitäisi tarjota ennustettavaa suorituskyvyn ja suorituskyvyn kasvua hyväksyttävällä hinnalla. Yksi perustehtävistä skaalautuvien järjestelmien rakentamisessa on minimoida tietokoneen laajennuskustannukset ja yksinkertaistaa suunnittelua. Ihannetapauksessa prosessorien lisääminen järjestelmään johtaa sen suorituskyvyn lineaariseen kasvuun. Näin ei kuitenkaan aina ole. Suorituskykyhäviöitä voi esiintyä esimerkiksi silloin, kun väylän kaistanleveys ei ole riittävä prosessorien ja päämuistin sekä muistin ja I/O-laitteiden välisen lisääntyneen liikenteen vuoksi. Todellisuudessa todellista suorituskyvyn lisäystä on vaikea arvioida etukäteen, koska se riippuu suurelta osin sovelluksen käyttäytymisen dynamiikasta.

Järjestelmän skaalaamiskyky ei määräydy ainoastaan ​​laitteistoarkkitehtuurista, vaan riippuu myös ohjelmiston ominaisuuksista. Ohjelmiston skaalautuvuus vaikuttaa kaikilla tasoilla yksinkertaisista viestinvälitysmekanismeista monimutkaisiin objekteihin, kuten tapahtumamonitorit ja koko sovellusjärjestelmäympäristö. Erityisesti ohjelmiston tulee minimoida prosessorien välinen liikenne, mikä voi haitata järjestelmän suorituskyvyn lineaarista kasvua. Laitteistot (prosessorit, väylät ja I/O-laitteet) ovat vain osa skaalautuvaa arkkitehtuuria, jossa ohjelmistot voivat tuottaa ennustettavia suorituskyvyn lisäyksiä. On tärkeää ymmärtää, että esimerkiksi pelkkä päivittäminen tehokkaampaan prosessoriin voi ylikuormittaa muita järjestelmäkomponentteja. Tämä tarkoittaa, että todella skaalautuvan järjestelmän on oltava kaikilta osin tasapainossa.

Skaalautuvuus - käsite ja tyypit. Skaalautuvuus-kategorian luokitus ja ominaisuudet 2017, 2018.