{"id":55231,"date":"2020-01-16T00:00:00","date_gmt":"2020-01-15T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/pro-multitenancy"},"modified":"2020-02-18T14:03:19","modified_gmt":"2020-02-18T11:03:19","slug":"pro-multitenancy","status":"publish","type":"post","link":"https:\/\/prohoster.info\/hu\/blog\/administrirovanie\/pro-multitenancy","title":{"rendered":"A multitenancy","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Sajnos ennek a kifejez\u00e9snek nincs j\u00f3 magyar megfelel\u0151je. A \u201eWikip\u00e9dia\u201d a k\u00f6vetkez\u0151t adja ford\u00edt\u00e1s<\/a><\/noindex> \u201emultib\u00e9rlet, t\u00f6bbsz\u00f6r\u00f6s b\u00e9rl\u00e9s\u201d. N\u00e9ha ezt \u201et\u00f6bbs\u00e9gi ownership\u201d-nek is nevezik. Ezek a kifejez\u00e9sek kiss\u00e9 zavar\u00f3ak lehetnek, mivel a t\u00e9ma l\u00e9nyeg\u00e9ben sem a b\u00e9rl\u00e9ssel, sem a tulajdonnal nincs \u00f6sszef\u00fcgg\u00e9sben. Ez val\u00f3j\u00e1ban a szoftverarchitekt\u00fara \u00e9s annak \u00fczemeltet\u00e9se k\u00e9rd\u00e9se. R\u00e1ad\u00e1sul az ut\u00f3bbi nem kev\u00e9sb\u00e9 fontos. <\/p>\n

Az multitenancy meg\u00e9rt\u00e9s\u00fcnket egy id\u0151ben kezdt\u00fck el kialak\u00edtani, amikor megkezdt\u00fck az \u201e1C:Enterprise\u201d felh\u0151 (szolg\u00e1ltat\u00e1si) modellj\u00e9nek terveit. Ez n\u00e9h\u00e1ny \u00e9ve t\u00f6rt\u00e9nt. Az\u00f3ta meg\u00e9rt\u00e9s\u00fcnk folyamatosan b\u0151v\u00fcl. Folyamatosan felfedez\u00fcnk \u00fajabb \u00e9s \u00fajabb aspektusokat (el\u0151ny\u00f6ket, h\u00e1tr\u00e1nyokat, neh\u00e9zs\u00e9geket, saj\u00e1toss\u00e1gokat stb.). <\/p>\n

\"A
\n<\/a><\/noindex>
\nN\u00e9ha a fejleszt\u0151k a multitenancy alatt egy viszonylag egyszer\u0171 dolgot \u00e9rtenek: \u201eahhoz, hogy t\u00f6bb szervezet adatai egy adatb\u00e1zisban t\u00e1rol\u00f3djanak, hozz\u00e1 kell adni az \u00f6sszes t\u00e1bl\u00e1hoz egy oszlopot a szervezeti azonos\u00edt\u00f3val, \u00e9s sz\u0171r\u0151t kell be\u00e1ll\u00edtani r\u00e1.\u201d Mi is ezzel a k\u00e9rd\u00e9ssel foglalkoztunk. De el\u00e9g gyorsan r\u00e1j\u00f6tt\u00fcnk, hogy ez csak egy kis ter\u00fclet (ami szint\u00e9n nem egyszer\u0171). Val\u00f3j\u00e1ban ez egy \u201eeg\u00e9sz orsz\u00e1g\u201d. <\/p>\n

A multitenancy f\u0151 \u00f6tlet\u00e9t \u00edgy lehetne k\u00f6r\u00fcl\u00edrni. A szokv\u00e1nyos alkalmaz\u00e1s egy csal\u00e1dnak sz\u00e1nt nyaral\u00f3, amely a saj\u00e1t infrastrukt\u00far\u00e1j\u00e1t (falak, tet\u0151, v\u00edzell\u00e1t\u00e1s, f\u0171t\u00e9s stb.) haszn\u00e1lja. Egy multitenancy alkalmaz\u00e1s pedig egy t\u00e1rsash\u00e1z. Abban minden csal\u00e1d ugyanazokat az infrastrukt\u00far\u00e1kat haszn\u00e1lja, de maga az infrastrukt\u00fara az eg\u00e9sz h\u00e1z sz\u00e1m\u00e1ra van megval\u00f3s\u00edtva. <\/p>\n

De a multitenancy megk\u00f6zel\u00edt\u00e9s j\u00f3 vagy rossz? Err\u0151l nagyon elt\u00e9r\u0151 v\u00e9lem\u00e9nyek l\u00e9teznek. \u00dagy t\u0171nik, hogy nincs \u201ej\u00f3 vagy rossz\u201d egy\u00e1ltal\u00e1n. Az el\u0151ny\u00f6ket \u00e9s h\u00e1tr\u00e1nyokat a konkr\u00e9t feladatok kontextus\u00e1ban kell \u00f6sszehasonl\u00edtani. De ez egy k\u00fcl\u00f6n t\u00e9ma\u2026 <\/p>\n

A legegyszer\u0171bb \u00e9rtelemben a multitenancy c\u00e9lja a k\u00f6lts\u00e9gek cs\u00f6kkent\u00e9se az alkalmaz\u00e1s fenntart\u00e1s\u00e1ban az infrastrukt\u00fara \u201ek\u00f6z\u00f6s\u00edt\u00e9se\u201d r\u00e9v\u00e9n. Ez hasonl\u00f3 mozg\u00e1s, mint az alkalmaz\u00e1s k\u00f6lts\u00e9geinek cs\u00f6kkent\u00e9se egy sorozatmegold\u00e1s alkalmaz\u00e1s\u00e1val (lehet, hogy konfigur\u00e1l\u00e1ssal \u00e9s m\u00f3dos\u00edt\u00e1ssal), nem pedig \u201eegyedi\u201d \u00edr\u00e1sa. Csak annyiban k\u00f6z\u00f6s\u00edtj\u00fck a fejleszt\u00e9st, a m\u00e1sik esetben pedig az \u00fczemeltet\u00e9st. <\/p>\n

Meg kell eml\u00edten\u00fcnk, hogy itt nincs k\u00f6zvetlen kapcsolat az \u00e9rt\u00e9kes\u00edt\u00e9si m\u00f3ddal. A multitenancy architekt\u00fara teljes m\u00e9rt\u00e9kben alkalmazhat\u00f3 v\u00e1llalati vagy k\u00f6zigazgat\u00e1si informatikai infrastrukt\u00far\u00e1kban, lehet\u0151v\u00e9 t\u00e9ve sz\u00e1mos hasonl\u00f3 fi\u00f3k, holdingv\u00e1llalat automatatiz\u00e1l\u00e1s\u00e1t. <\/p>\n

Azt mondhatjuk, hogy a multitenancy nem csup\u00e1n az adatmez\u0151k szervez\u00e9s\u00e9nek k\u00e9rd\u00e9se. Ez a teljes alkalmaz\u00e1s m\u0171k\u00f6d\u00e9si modellje (bele\u00e9rtve annak architekt\u00far\u00e1j\u00e1nak jelent\u0151s r\u00e9sz\u00e9t, a telep\u00edt\u00e9si modellt \u00e9s a karbantart\u00e1s megszervez\u00e9s\u00e9t). <\/p>\n

Ami a multitenancy modellben a legbonyolultabb \u00e9s leg\u00e9rdekesebb, az az, hogy az alkalmaz\u00e1s l\u00e9nyege \"megkett\u0151z\u0151dik\". A funkci\u00f3k egy r\u00e9sze konkr\u00e9t adatmez\u0151kkel (lak\u00e1sokkal) dolgozik, \u00e9s \"nem \u00e9rdekli\", hogy m\u00e1s lak\u00e1sokban kik a b\u00e9rl\u0151k. A funkci\u00f3k egy m\u00e1sik r\u00e9sze viszont az eg\u00e9sz h\u00e1zat \u00e9rz\u00e9keli, \u00e9s az \u00f6sszes b\u00e9rl\u0151 sz\u00e1m\u00e1ra dolgozik. Ut\u00f3bbi azonban nem tud elvonatkoztatni att\u00f3l, hogy ezek m\u00e9giscsak k\u00fcl\u00f6n\u00e1ll\u00f3 lak\u00e1sok, \u00e9s biztos\u00edtani kell a sz\u00fcks\u00e9ges szint\u0171 r\u00e9szletezetts\u00e9get \u00e9s biztons\u00e1got. <\/p>\n

Az \"1C:Enterprise\" multitenancy modellje t\u00f6bb technol\u00f3gia szintj\u00e9n val\u00f3sul meg. Ezek az \"1C:Enterprise\" platform mechanizmusai, mechanizmusai1C: A 1cFresh megold\u00e1sok publik\u00e1l\u00e1s\u00e1nak technol\u00f3gi\u00e1ja<\/a><\/noindex>\u00e9s a \"1C: A 1cFresh megold\u00e1sok fejleszt\u00e9s\u00e9nek technol\u00f3gi\u00e1ja<\/a><\/noindex>mechanizmusai BSP<\/a><\/noindex> (a standard alrendszerek k\u00f6nyvt\u00e1rai). <\/p>\n

Ezek a t\u00e9telek mind hozz\u00e1j\u00e1rulnak a t\u00e1rsash\u00e1z \u00e1ltal\u00e1nos infrastrukt\u00far\u00e1j\u00e1nak ki\u00e9p\u00edt\u00e9s\u00e9hez. Mi\u00e9rt val\u00f3sul meg ez t\u00f6bb technol\u00f3gia r\u00e9v\u00e9n, \u00e9s nem egyetlen platformban? Els\u0151sorban az\u00e9rt, mert egyes mechanizmusok, v\u00e9lem\u00e9ny\u00fcnk szerint, teljesen indokoltak a telep\u00edt\u00e9s konkr\u00e9t v\u00e1ltozatait illet\u0151en. De \u00e1ltal\u00e1noss\u00e1gban ez nem egyszer\u0171 k\u00e9rd\u00e9s, \u00e9s folyamatosan azon a d\u00f6nt\u00e9s el\u0151tt \u00e1llunk, hogy mely szinten \u00e9rdemes megval\u00f3s\u00edtani a multitenancy egyes aspektusait. <\/p>\n

Nyilv\u00e1nval\u00f3, hogy a mechanizmusok alapvet\u0151 r\u00e9sz\u00e9t a platformon kellett megval\u00f3s\u00edtani. P\u00e9ld\u00e1ul az adatok t\u00e9nyleges sz\u00e9tv\u00e1laszt\u00e1sa. Ez az, amivel \u00e1ltal\u00e1ban a multitenancy-r\u00f3l besz\u00e9l\u00fcnk. De v\u00e9g\u00fcl a multitenancy modell \"v\u00e9gigment\" a platform mechanizmusainak jelent\u0151s r\u00e9sz\u00e9n, \u00e9s ig\u00e9nyelte azok tov\u00e1bbfejleszt\u00e9s\u00e9t, s\u0151t bizonyos esetekben \u00fajragondol\u00e1s\u00e1t. <\/p>\n

A platform szintj\u00e9n pontosan az alapvet\u0151 mechanizmusokat val\u00f3s\u00edtottuk meg. Ezek lehet\u0151v\u00e9 teszik olyan alkalmaz\u00e1sok l\u00e9trehoz\u00e1s\u00e1t, amelyek a multitenancy modellben m\u0171k\u00f6dnek. De ahhoz, hogy az alkalmaz\u00e1sok \"\u00e9ljenek \u00e9s m\u0171k\u00f6djenek\" egy ilyen modellben, sz\u00fcks\u00e9g van egy olyan rendszere, amely a \"\u00e9letciklusuk\" ir\u00e1ny\u00edt\u00e1s\u00e1\u00e9rt felel\u0151s. Ezt a 1cFresh technol\u00f3gi\u00e1k \u00e9s a BSP szintj\u00e9n egys\u00e9ges\u00edtett \u00fczleti logik\u00e1ra \u00e9p\u00fcl\u0151 r\u00e9teg biztos\u00edtja. Ahogyan egy lak\u00f3h\u00e1z infrastrukt\u00far\u00e1ja minden sz\u00fcks\u00e9geset megad a lak\u00f3knak, \u00fagy a 1cFresh technol\u00f3gi\u00e1k is mindent biztos\u00edtanak a multitenancy modellben m\u0171k\u00f6d\u0151 alkalmaz\u00e1sok sz\u00e1m\u00e1ra. Ahhoz, hogy az alkalmaz\u00e1sok kapcsolatba l\u00e9phessenek ezzel az infrastrukt\u00far\u00e1val (jelent\u0151s m\u00f3dos\u00edt\u00e1sok n\u00e9lk\u00fcl), a megfelel\u0151 \"csatlakoz\u00f3kat\" helyezik el benn\u00fck a BSP alrendszereinek form\u00e1j\u00e1ban. <\/p>\n

A platform mechanizmusait tekintve k\u00f6nnyen \u00e9szlelhet\u0151, hogy a \"1C: V\u00e1llalkoz\u00e1s\" felh\u0151 alap\u00fa alkalmaz\u00e1s\u00e1nak tapasztalatainak \u00e9s fejl\u0151d\u00e9s\u00e9nek fokoz\u00e1s\u00e1val b\u0151v\u00edtj\u00fck a mechanizmusok \u00f6sszet\u00e9tel\u00e9t, amelyek r\u00e9szt vesznek ezen architekt\u00far\u00e1ban. Egy p\u00e9ld\u00e1t hozunk. A multitenancy modellben l\u00e9nyegesen megv\u00e1ltozik az alkalmaz\u00e1sok karbantart\u00e1s\u00e1ban r\u00e9szt vev\u0151 szerepl\u0151k szerepe. Jelent\u0151sen n\u0151 azok szerepe (felel\u0151ss\u00e9gi szintje), akik az alkalmaz\u00e1sok \u00fczemeltet\u00e9s\u00e9rt felel\u0151sek. Sz\u00e1mukra sz\u00fcks\u00e9gess\u00e9 v\u00e1lt, hogy er\u0151sebb eszk\u00f6z\u00f6k \u00e1lljanak rendelkez\u00e9sre az alkalmaz\u00e1sok ellen\u0151rz\u00e9s\u00e9re. Mivel az alkalmaz\u00e1sokat haszn\u00e1l\u00f3 felhaszn\u00e1l\u00f3k (b\u00e9rl\u0151k) els\u0151sorban abban b\u00edznak, akivel dolgoznak. E c\u00e9lb\u00f3l a 8.3-as verzi\u00f3ban \u00faj biztons\u00e1gi profilok mechanizmus\u00e1t<\/a><\/noindex>val\u00f3s\u00edtottuk meg. Ez a mechanizmus lehet\u0151v\u00e9 teszi a szolg\u00e1ltat\u00f3 adminisztr\u00e1torainak, hogy a fejleszt\u0151k munk\u00e1j\u00e1nak szabads\u00e1g\u00e1t a sz\u00fcks\u00e9ges biztons\u00e1gi szintre korl\u00e1tozz\u00e1k \u2013 l\u00e9nyeg\u00e9ben az alkalmaz\u00e1s munk\u00e1j\u00e1t izol\u00e1lj\u00e1k minden b\u00e9rl\u0151 sz\u00e1m\u00e1ra egy adott \"homokoz\u00f3\" keretein bel\u00fcl. <\/p>\n

A multitenancy application management architecture, as seen in technologies like 1cFresh and BSP, is of great interest. Compared to a standard deployment model, it significantly raises the requirements for process automation. There are dozens of such processes: creating new data areas ('apartments'), application updates, regulatory information updates, backups, etc. Furthermore, the demands for reliability and availability increase. For example, to ensure reliable interaction between applications and management system components, we have implemented an asynchronous call system with guaranteed delivery. <\/p>\n

A very subtle aspect is how to share data and processes. It may seem simple at first glance (if anyone thinks so). The greatest challenge lies in balancing data and process centralization with decentralization. On one hand, centralization reduces costs (disk space, CPU resources, administrator efforts, etc.). On the other hand, it restricts the freedom of 'residents'. This is one of the moments of 'splitting' the application, where developers must think about the application both in a narrow sense (serving one 'apartment') and in a broad sense (serving all 'residents' at once). <\/p>\n

A good example of such a 'dilemma' is regulatory reference information. Of course, there is a strong temptation to make it common for all 'residents' of the building. This allows for storage in a single instance and immediate updates for everyone. However, sometimes a specific resident may require unique changes. Surprisingly, this occurs even for information specified by regulators (government bodies). It raises a complex question: to share or not to share? It is tempting to make general information for everyone and private for those who want it. Yet this leads to quite a complicated implementation. But we are working on it... <\/p>\n

Egy m\u00e1sik p\u00e9lda a rendszeres folyamatok (\u00fctemezett, a vez\u00e9rl\u0151rendszer \u00e1ltal kezdem\u00e9nyezett stb.) megval\u00f3s\u00edt\u00e1s\u00e1nak tervez\u00e9se. Egyr\u00e9szt elk\u00e9pzelhet\u0151, hogy minden adatmez\u0151re k\u00fcl\u00f6n val\u00f3s\u00edtjuk meg \u0151ket. Ez egyszer\u0171bb \u00e9s k\u00e9nyelmesebb. M\u00e1sr\u00e9szt azonban egy ilyen apr\u00f3 granularit\u00e1s nagyobb terhet r\u00f3 a rendszerre. A terhel\u00e9s cs\u00f6kkent\u00e9se \u00e9rdek\u00e9ben k\u00f6z\u00f6s folyamatokat kell megval\u00f3s\u00edtanunk. De ezek alaposabb kidolgoz\u00e1st ig\u00e9nyelnek. <\/p>\n

Term\u00e9szetesen felmer\u00fcl egy nagyon l\u00e9nyeges k\u00e9rd\u00e9s. Hogyan biztos\u00edthatj\u00e1k az alkalmaz\u00e1sfejleszt\u0151k a multitenancy \u00fczemm\u00f3dban val\u00f3 m\u0171k\u00f6d\u00e9st? Mit kell tenni\u00fck ehhez? Nyilv\u00e1nval\u00f3, hogy arra t\u00f6reksz\u00fcnk, hogy a technol\u00f3giai \u00e9s infrastrukt\u00fara k\u00e9rd\u00e9sek terhe a lehet\u0151 legnagyobb m\u00e9rt\u00e9kben a biztos\u00edtott technol\u00f3gi\u00e1ra h\u00e1ruljon, \u00e9s az alkalmaz\u00e1sfejleszt\u0151 csak az \u00fczleti logika feladataira gondoljon. De, mint m\u00e1s fontos architektur\u00e1lis k\u00e9rd\u00e9sekn\u00e9l, az alkalmaz\u00e1sfejleszt\u0151knek sz\u00fcks\u00e9g\u00fck van valamilyen elk\u00e9pzel\u00e9sre a multitenancy modell m\u0171k\u00f6d\u00e9s\u00e9r\u0151l, \u00e9s bizonyos er\u0151fesz\u00edt\u00e9sekre az alkalmaz\u00e1sok fejleszt\u00e9se sor\u00e1n. Mi\u00e9rt? Mert vannak olyan szempontok, amelyeket a technol\u00f3gia nem tud automatikusan biztos\u00edtani a adatok szemantik\u00e1j\u00e1nak figyelembev\u00e9tel n\u00e9lk\u00fcl. P\u00e9ld\u00e1ul az inform\u00e1ci\u00f3k k\u00f6z\u00f6ss\u00e9gi hat\u00e1rainak meghat\u00e1roz\u00e1sa. De arra t\u00f6reksz\u00fcnk, hogy ezek a neh\u00e9zs\u00e9gek kicsik legyenek. M\u00e1r l\u00e9teznek p\u00e9ld\u00e1k az ilyen alkalmaz\u00e1sok megval\u00f3s\u00edt\u00e1s\u00e1ra. <\/p>\n

A multitenancy megval\u00f3s\u00edt\u00e1s\u00e1nak fontos szempontja a \"1C:V\u00e1llalat\" keretein bel\u00fcl, hogy hibrid modellt hozunk l\u00e9tre, amelyben egy alkalmaz\u00e1s m\u0171k\u00f6dhet multitenancy m\u00f3dban \u00e9s hagyom\u00e1nyos m\u00f3dban is. Ez meglehet\u0151sen neh\u00e9z feladat, \u00e9s k\u00fcl\u00f6n megbesz\u00e9l\u00e9st ig\u00e9nyel.
\n
Forr\u00e1s: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041a \u0441\u043e\u0436\u0430\u043b\u0435\u043d\u0438\u044e, \u0443 \u044d\u0442\u043e\u0433\u043e \u0442\u0435\u0440\u043c\u0438\u043d\u0430 \u043d\u0435\u0442 \u0445\u043e\u0440\u043e\u0448\u0435\u0433\u043e \u0440\u0443\u0441\u0441\u043a\u043e\u044f\u0437\u044b\u0447\u043d\u043e\u0433\u043e \u0430\u043d\u0430\u043b\u043e\u0433\u0430. \u00ab\u0412\u0438\u043a\u0438\u043f\u0435\u0434\u0438\u044f\u00bb \u0434\u0430\u0435\u0442 \u043f\u0435\u0440\u0435\u0432\u043e\u0434 \u00ab\u043c\u0443\u043b\u044c\u0442\u0438\u0430\u0440\u0435\u043d\u0434\u043d\u043e\u0441\u0442\u044c, \u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u0430\u044f \u0430\u0440\u0435\u043d\u0434\u0430\u00bb. \u0418\u043d\u043e\u0433\u0434\u0430 \u044d\u0442\u043e \u043d\u0430\u0437\u044b\u0432\u0430\u044e\u0442 \u00ab\u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u044b\u043c \u0432\u043b\u0430\u0434\u0435\u043d\u0438\u0435\u043c\u00bb. \u042d\u0442\u0438 \u0442\u0435\u0440\u043c\u0438\u043d\u044b \u043c\u043e\u0433\u0443\u0442 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043f\u0443\u0442\u0430\u0442\u044c, \u0442\u0430\u043a \u043a\u0430\u043a \u043f\u0440\u0435\u0434\u043c\u0435\u0442 \u043d\u0435 \u0441\u0432\u044f\u0437\u0430\u043d \u043f\u043e \u0441\u0443\u0442\u0438 \u043d\u0438 \u0441 \u0430\u0440\u0435\u043d\u0434\u043e\u0439, \u043d\u0438 \u0441 \u0432\u043b\u0430\u0434\u0435\u043d\u0438\u0435\u043c. \u042d\u0442\u043e \u0432\u043e\u043f\u0440\u043e\u0441 \u0438\u043c\u0435\u043d\u043d\u043e \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u044b \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u043e\u0433\u043e \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u044f \u0438 \u043e\u0440\u0433\u0430\u043d\u0438\u0437\u0430\u0446\u0438\u0438 \u0435\u0433\u043e \u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u0438. \u041f\u0440\u0438\u0447\u0435\u043c \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0435\u0435 \u043d\u0435 \u043c\u0435\u043d\u0435\u0435 \u0432\u0430\u0436\u043d\u043e. \u041c\u044b \u043d\u0430\u0447\u0430\u043b\u0438 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":55232,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-55231","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Multitenancy | ProHoster","description":"Sajnos ennek a sz\u00f3nak nincs j\u00f3 magyar megfelel\u0151je.","canonical_url":"https:\/\/prohoster.info\/hu\/blog\/administrirovanie\/pro-multitenancy","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"hu_HU","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041f\u0440\u043e multitenancy | ProHoster","og:description":"\u041a \u0441\u043e\u0436\u0430\u043b\u0435\u043d\u0438\u044e, \u0443 \u044d\u0442\u043e\u0433\u043e \u0442\u0435\u0440\u043c\u0438\u043d\u0430 \u043d\u0435\u0442 \u0445\u043e\u0440\u043e\u0448\u0435\u0433\u043e \u0440\u0443\u0441\u0441\u043a\u043e\u044f\u0437\u044b\u0447\u043d\u043e\u0433\u043e \u0430\u043d\u0430\u043b\u043e\u0433\u0430.","og:url":"https:\/\/prohoster.info\/hu\/blog\/administrirovanie\/pro-multitenancy","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-01-15T21:00:00+00:00","article:modified_time":"2020-02-18T11:03:19+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"55231","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 19:47:39","updated":"2022-09-29 20:30:21","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/posts\/55231","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/comments?post=55231"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/posts\/55231\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/media\/55232"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/media?parent=55231"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/categories?post=55231"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/tags?post=55231"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}