MySQL zdarma

Však hledej. To tady nemusíš hlásit.

To se mi zdá dost šílené, už jen proto, že pokud vím, MySQL komunikace není by default ani šifrovaná. Krom toho se od databáze očekává nějaká rychlost, ne že bude na druhém konci planety...

co si mam predstavit pod pojmom sifrovana MySQL komunikacia?

Sifrovane spojeni mezi serverem a klientem.

To som chcel pocut od neho. MySQL samozrejme ponuka sifrovane spojenie a urcite nema problem s vykonom ako bolo naznacene. MySQL v Enterprise verziii pouzivaju dokonca v bankach a vacsich instituciach, ale samozrejme je vhodnejsie pouzit nejaku z databaz typu MS SQL, Oracle ci so sebazaprenim aj PostgreSQL

Tak já vám to zopakuji. MySQL komunikace není by default šifrovaná. Kromě toho, že mě to kvůli bezpečnosti zajímá, jsem si to před necelým půlrokem i ověřil, když nějaká bestie napadla switche v datacentru, zaplnila MAC tabulky a udělala z nich huby. A do mých síťových rozhraní na firewallech najednou začala plynout cizí MySQL komunikace, a to včetně jmen a hesel, jak jsem si Wiresharkem ráčil vytáhnout.Nejsem databázista, MySQL umím nainstalovat a udělat pár základních selectů, více bez Google nedám. Ale jako síťař tak nějak tuším, že když umístím MySQL server do jiné lokality než klienta, tak odezva nebude v řádu jednotek milisekund, ale klidně ve stovkách milisekund. A pokud se budou řešit dotazy s rozsáhlejší odpovědí, narazím i na problém s rychlostí konektivity jako takové. Ještě nikdy jsem neviděl scénář, který by počítal s tím, že MySQL server bude vteřinu daleko; zato jsem viděl bžilion scénářů, kde se řešila synchronizace *SQL servery na různých lokalitách, a odezva byla kritickým požadavkem.

Abychom si nalili cisteho vina, tak "by default" neni sifrovana komunikace snad v zadne bezne relacni databazi. Ale to uz jsme hodne offtopic - troufnu si tvdit, ze tazatele "s dvema CS:GO servery" zajima sifrovani komunikace asi tolik, jako souhrn letosnich srazek ve Rwande.

1000 - 1500 mm

To máte asi pravdu. Ale i ta rychlost může být problém, byť to asi bude řešit maximálně loginy a možná nějaké statistiky.Offtopic: Šifrovaná komunikace se nepoužívá kvůli délce uzavírání šifrovaného spojení?

sifrovana komunikacia sa nepouziva pretoze sa riesi sifrovanie dat priamo na databazovom servri alebo na klientovi, skoro vobec sa nepouzviva sifrovana komunikacie medzi klientom a servrom. Uz tak je niekedy velky problem medzi klientom a servrom kvoli velkemu objemu dat alebo kvoli neoptimalizovanym dotazom a nieto to este spomalovat sifrovaniem

Nezlobte se, ale to, co jste napsal, se mi zdá jako nesmysl.To, že data budou šifrovaná na SQL serveru je sice super, ale v dotazech budou nešifrovaná, a pak půjdou v plaintextu internetem i takové věci jako loginy, v případě horší implementace i hesla (pokud bude hashe vytvářet až db), nehledě na spoustu jiných privátních dat.Krom toho samotné šifrování komunikaci nijak zpomalovat nemusí, zvlášť když dneska má každý procesor AES-NI instrukce - zvýšení odezvy a snížení rychlosti je naprosto minimální.Kde vidím problém, je to uzavření spojení, protože to vyžaduje pár podání ruky navíc, a to zbytečně zvýší odezvu každého dotazu (pokud se s každým dotazem uzavírá nové spojení). Ale to se dá zase řešit tak, že to celé zabalím do nějakého šifrovaného spojení, které budu udržovat trvale - např. VPN. A nebo upravím aplikaci tak, aby při každém dotazu nevytvářila samostatné spojení; pokud to lze. U nějakých PHP aplikací, např. Wordpress, to asi půjde těžko.

Ale notak, dnešní CPU už mají instrukce, které to tak ulehčí, že nějaké šifrování ani nepostřehneš.

Primarne kvuli tomu, ze to zeslozituje instalaci a konfiguraci a zavadi celou dalsi skupinu moznych problemu. Vetsinou se sifruje pomoci TLS a tim padem musis distribuovat na klienty certifikaty, resit expiraci atd atp.Samotna rychlost obvykle problemem neni, horsi je extra handshake na zacatku spojeni.

Tušil jsem ten handshake, ale komplikace kvůli nastavení mě nenapadly; ono v případě clusterů a HA se to asi zkomplikuje dost. Díky.

Nejhorší je, když ti to podepíšou ruští hackeři a pak ten handshake dopadne nějak takhle - https://img-9gag-fun.9cache.com/photo/aR0g1xj_700bwp.webp

ja databazista som, robil som roky admina a aj architekta a ver mi, ze vediet spravovat databazy je trochu viac ako len naistalovat. Su to aj indexy, co je vcelku komplexna disciplina, je to vyvazovanie a ladenie vykonu dotazov a tak dalej. Pokial ako sietar aspon trochu rozumies svojej praci, tak urcite vies,ze zlu odovzu v sieti mozes mat z akehokolvek aplikacneho servra a nielen z MySQL ktory moze mat a urcite ma svoje vykonove nedostatky, ale ten problem nie su sposobene len MySQL ale moze byt zle napisanym dotazom na akomkolvek databazovom servi. Tvrdit an block,ze ked umiestnis do siete MySQL mas automaticky problem v sieti je skratka blbost. Poziadavky na kriticnost som riesil aj ja, napriklad clustre ci ine druhy high availabilit databazovych servrov umiestnenych v datacentrach vzdialenych od seba stovky kilometrov, kde latecia medzi dvoma nodami clustru nemohla presiahnut par desiatok milisekund....

Vůbec netuším, proč mi podsouváte takové kecy. Opravdu mě nemusíte poučovat o tom, že to není tak jednoduché, a jak moc tomu nerozumím - na to mám kolegy databázisty, se kterými společně řešíme výkonové problémy zákazníků, a pátráme, co je příčinou.Psal jsem o tom, že dávat databázi na druhý konec světa prostě není dobrý nápad, protože pokud už chci databázový server, a ne třeba SQLlite, asi od toho chci i nějakou rychlost. Když jsem si kdysi hrál s měřením a vyhodnocováním většího množství dat, ráčil jsem si všimnout, že některé dotazy projdou za milisekundu, jiné za 40s, a také záleží na indexaci, a jak dotaz zoptimalizuji. Ale fakt nevidím důvod házet si klacky pod nohy špatnou sítí, to teda ne. Taky se staráme o zákazníky s vyhrazenými linkami a slepými vlákny právě kvůli odezvě, jenže to není případ tazatele, že, ten chce MySQL zdarma, s deseti milisekundami opravdu počítat nemůže.Ale jak psal Jirka Vejražka, tazatele tohle asi nebude vůbec zajímat. Ani bezpečnost, ani latence. Když něco nebude fungovat, vykašle se na to, protože mu to ani nestálo za to, aby si MySQL přiinstaloval k tomu CS:GO serveru.

Znám enterprise řešení kdy aplikační server leží v cloudu kdesi v německu, ten se zeptá nějaké integrační platfromy co je u zákazníka v praze, ta začne sbírat potřebná data ať z jiných systémů v praze, tak v německu, třeba voláním databázových procedur, aby výsledek zpracovala poslala zpět do německa tomu aplikačnímu serveru a ten to poslal klientovi na obrazovku.Někdy to způsobuje problémy kvůli timeoutům na integraci, protože na hraně běžící databázová api se prodlouží o latence spojení a už to přeteče únosnou mez, ale vesměs to řešení běhá velice dobře.

Asi budes muset projit nabidku hostingu zdarma a zjistit, ktere z nich ti dovoli pripojit se na MySQL zvenku. Vic ti neporadim, hostingy nejsou moje krevni skupina.

nebo se rozšoupnout a za 40 korun měsíčně si někde koupit hosting.Taková pálka.

Otázkou je, zda pak takový hodsting za 40 tohle nabídne, ono ne každý si nechá lidi lézt do své sítě zvenčí. U hostingu většinou problém bývá, pokud tam ale pronajme celý virtuál, tak si může dělat co chce.

mám pocit že u forpsi tohle šlo. Kdysi sem druhou db na tamním hostingu použil na cms jinde a problémy nebyly.