Rubrika: Otázky

Děláme průzkum, jaké formáty obrázků máme v Collboardu podporovat.
(ať už přetažením nebo kliknutím na ikonku importu obrázku)

Už teď podporujeme formáty .jpg a .png.

Z obrázků bychom rádi ještě podporovali:
– .heic
– .webp
– .gif
– .tiff
– .svg

Také chceme (asi v nějaké druhé várce) přidat možnost vkládání pdf.

Naopak asi nebudeme podporovat .raw a .ai u kterých se dělá podpora velmi blbě a .bmp, který už není moc používaný a zároveň není vhodný pro web.

Nezapoměli jsme na něco důležitého?

V @Collboardu nám začíná databáze přerůstat trochu přes hlavu, máme 150GB dat, 300 000 000 řádků, jenom databáze; (mnoho assetů (jako obrázku) máme úplně separátně na AWS S3).

Naše databáze má to specifikum, že máme obrovské množství řádků, kde každý obsahuje malinký druh informací (je to event-sourced). A do databáze se zapisuje velmi často a čte se po dávkách (vždy, když si někdo otevře tabuli).

Když jsme projekt začínali, nějaké super optimalizace jsme úplně neřešili, momentálně by se to ale možná hodilo? Používáme MySQL InnoDB (a nedělíme tabulky do partitions). Nejsme však na téhle databázi závislý, komunikace s databází probíhá přes docela dobře přepsatelnou vrstvu, dokážeme se přihodit na kteroukoliv SQL (a asi i hodně NoSQL).

Máte nějaký tip, co udělat, aby byla databáze:

💾 Spolehlivá a rychlá
💾 Škálovatelná do mnohem větší míry
💾 Optimalizovatelná (momentálně nám příkaz OPTIMIZE neprojde, protože ten potřebuje jednou tolik místa na disku)
💾 Redundantní
💾 Dobře zálohovatelná někam externě

Nebo zůstat u MySQL
🗃️ InnoDB vs. MyISAM
🗃️ Rozdělit DB na partitions po jednotlivých tabulích?

Kdyby se chovala jakákoliv soukromá (přepravní) firma jako stát, stát by ji zaklekl zaživa.

https://www.idnes.cz/ekonomika/domaci/vraceni-dalnicni-znamky-dlouhodobe-jizdenky-mhd-praha-brno-ostrava.A210325_093434_ekonomika_rie

Chceme udělat podporu Ctrl+C/V/X do Collboardu.

Pro prohlížeče existuje Clipboard API které umí pracovat s plaintextem, ale ne s dalšími datovými typy. Respektive umí pomocí zatím nestandardizovaných metod read/write.

Jakou strategii zvolit:

– využít zatím nestandardizované metody
– ohackovat to přes plaintext
– mít oboje; resp. plaintext jako fallback pro pořádnou schránku

https://web.dev/async-clipboard/

Stalo se nám, že se nám na webinář přihlásilo mnohem víc lidí, než jsme čekali. Obvykle děláme webináře přes Zoom, který máme v tomhle ohledu docela ošahaný.

https://www.facebook.com/events/357915202047650

Přemýšlíme, jakou nejrozumnější strategii postupovat, nemyslím, aby to jenom fungovalo technicky, ale aby to dávalo pro účastníky smysl a bylo interaktivní:

– Omezit počet účastníků a udělat webinář vícekrát
– Streamovat webinář na YouTube
– Kombinovat Zoom a YouTube
– Dokoupit možnost více účastníků v Zoomu
– Využít nějakou jinou videokonferenční platformu – Teams, Meets, ( https://docs.google.com/spreadsheets/d/1KVkFFS-3shmvryQS_hGwXy05oMapsFoi1W42fMBHh1g/edit#gid=0 )…

Děláme virtuální tabuli pro učitele, hodně jsem jako primárně frontend vývojář podcenil zájem a jak to server (ne)zvládá. Momentálně řešíme problém s místem na disku. Máme klasickou Digital ocean VPS s diskem 160 GB (maximální, co DO nabízí).

Máme disk zaplněný asi z 95%, prakticky jenom MariaDB databází tabulkami v InnoDB.

Ještě teď bych mohl udělat nějaké optimalizace, ale to už jsem dělal několikrát a dlouhodobě to není úplně udržitelný postup. Někdy prostě narazíme na limit.

Digital ocean nabízí MySQL/MariaDB jako samostatnou službu, co mě ale opravdu překvapuje, že je tento postup naprosto násobně dražší. Droplet, kde můžu mít nainstalovanou databázi + cokoliv stojí pro nás 40 USD vs. ekvivalentní databáze jako služba 240 USD.

A ještě kromě databáze, nabízí DO volume. Chápu, že jde prostě o lépe škálovatelný přídavný disk ke dropletu, ale jaké má výhody/nevýhody oproti disku dropletu a databázi jako službě?

Překvapují mě tak rozdílné ceny u pro mě vlastně velmi podobných služeb, takže tam asi bude nějaký zásadní rozdíl, co mi uniká.

Proto se vás, zkušenějších serverařů ptám, kde je optimální mít umístěnou databázi?

💽 Přímo na VPS?
💽💾 Pokud na VPS, kolik má být na takovém stroji ideálně volného diskového místa?
💽 Na VPS v rámci Docker containeru?
💽 V rámci volume?
💽 Na separátní VPS/Containeru ve stejném regionu?
💽 Jako dedikovanou službu ve stejném regionu?
💽 Klidně kdekoliv, klidně u jiného poskytovatele (např. AWS) pokud jde o Frankfurt/Frankfurt?

PS: Naše databáze má to specifikum, že máme obrovské množství řádků, kde každý obsahuje malinký druh informací (je to event-sourced). A do databáze se zapisuje velmi často a čte se po dávkách (vždy, když si někdo otevře tabuli).

PPS: Těch 150GB databáze je opravdu jenom databáze; mnoho assetů (jako obrázku) máme na AWS S3.