Ukládání dat do souboru po vzoru mysql (hlasovací systém) – PHP – Fórum – Programujte.com

Chtěl bych si založit web na webzdarma kde nabízí 500MB zdarma. Mají dost nedostačující prostor na db a chtěl bych si tedy naprogramovat systém na zápis do souboru a čtení podobně jak je tomu na mysql, ale v jednodušší verzi. SQLite je pro mě částečně náhrada ale jen tam kde se nevyžaduje častý zápis do souboru. Tak například, uživatel se může registrovat a přihlásit do systému pomocí databáze SQLite - v tom není problém. Ale vrámci inzerce má fungovat "samospráva". Každý uživatel bude mít určité body a právo hlasovat nebo schvalovat inzeráty. Pokud to ovšem nebude dělat správně může mu být právo odebráno apod. Nový uživatel má mít např. právo hlasovat o tom jestli nový inzerát bude schválen nebo ne; osvědčený uživatel má právo hlasovat o odebrání práva, o zrušení účtu, o potrestání uživatele apod. Čímž se dostávám k jádru věci. Zde by bylo třeba častého zápisu do souboru s daty. Moje otázka je: jak velké bloky dat je optimální načítat? Dejme tomu že databáze uživatelů se časem rozroste na 100.000 (možná extrém, ale budiž). Tabulka s hlasováním tedy bude mít 100.000 záznamů. Každý záznam má dejmetomu 64 bytů.

Když pošlu přes AJAX příkaz na update záznamu uživatele s id 88888, kde chci updatovat hodnotu pro hlasování... jak optimální bloky načítat, aby sdílený server neměl problém s pamětí? Dejme tomu, že online bude 20-30 lidí a z toho 2 budou zrovna hlasovat během jednoho okamžiku. Co je třeba provést je projít téměř všechny záznamy dokud nenajdu dané id. Ale jak velké bloky nastavit? 64 bytů téměř určitě není ideální - posouvat fseek po 64 bytech je holý nesmysl protože čtení z disku je pomalejší než čtení z paměti. Mám načítat po 4kb? Nebo po 64kb? Co je a co není příliš pro sdílený hosting? Je třeba počítat s tím že samotná aplikace během běhu zabírá paměť a když bude např. 30 lidí online tak to bude záhul? Nevím co si dovolit.

Říkám si že texty inzerátů se dají uložit zvlášť do SQLlite, protože inzeráty se neukládají často. Tabulka se vzkazy, tu bych měl asi navrhnout jako vlastní systém zápisu do souboru, protože uživatelé si budou často psát. Další tabulka je tabulka s informacemi o počtu vzkazů které odešly, přišly, přečtené.... Takže takových tabulek tam bude více.

Příklad s tabulkou o hlasování asi není ideální. Předpokládejme že bych měl nějakou "mapku" záznamů která bude mít velikost 100000x4byty. Tam si najdu záznam s id 88888 a zjistím na který řádek mám skočit. Ale pokud bych chtěl procházet třeba tabulku s inzeráty, kde je třeba procházet sloupce a porovnávat jejich hodnoty se zadáním, tak to by už nejspíš chtělo načítat po rádcích/blocích. Tedy mohu mít texty inzerátů v jiné tabulce než sloupce co mají pevný číselný rozměr. Procházel bych tedy tu tabulku s pevným rozměrem, kde by délka mohla být např. 64 bytů. K této bych potřeboval znát velikost. Nebo mám psát aplikaci tak, abych mohl změnit velikost bloku podle počtu řádků, který si nastavím aktuálně podle potřeby? Podle toho co je nejvýkonnější řešení?

#1 oxidián
Klidně použij SQLite. Bude to zcela jistě lepší řešení, než práce s holým souborem. Při správném nastavení umí SQLite i rychle zapisovat.

Můžeš to i rozdělit: Texty inzerátů v SQLite, logické vazby a hlasování v MySQL. Jenže na WZ je ta databáze MySQL permanentně přetížena, takže se tam tohle řešení nehodí.

#2 Kit
Právě proto se chci mysql vyhnout. Jak bys chtěl nakonfigurovat sqlite aby rychle zapisoval?

#3 oxidián
Dá se tam vypustit čekání po zápisu na disk. Na běžném PC se totiž čeká, než se jednou otočí disk a teprve pak se databáze SQLite odemkne pro další zápis. Tohle na serveru, který běží nonstop, není potřebné.

Také je dobré zapnout WAL a PRAGMA synchronous

Takže ve zkratce: 

PRAGMA journal_mode = WAL
PRAGMA synchronous = NORMAL

Tak dík, to si ještě budu muset přečíst až to budu dělat protože o tom nic nevím.

Ja bych asi sel taky do SQL-Lite. Nebo si muzes udelat vlastni db, treba jako csv soubory. ale to je narocne n programovani.
Ale vyhnul bych se wz.cz, je posledni dobou nespolehlive. A naposled mi smazali web, ikdyz pred tim 10 let nebyl zadny problem. Jj, db je tam pretizena. Misto, mno, da se to.
A co treba vlastni server treba s rasberry pi? Treba se domluvit s nejakou firmou, kamarad, stryc, kamarad otce... Zapojis si to k nim a pujdes pres jejich domenu na svuj pc. Takze jedine, co jim vemes je linka a trochu proudu. A muzes tam mit 1T disk. Nebo 350G ssd, coz je teda vic nez 0.5G :)

#6 peter
Ta databáze se jmenuje SQLite.

#6 peter
Nemám nikoho žádnou firmu neznám a jak mohu vědět že ta firma nezneužije soukromá data uživatelů, např. emaily k rozesílání reklamy atd. To nepřichází v úvahu.

Jak ti mohli smazat stránky, to si musel snad přetěžovat, správně napsané stránky nemají důvod mazat. Nejspíš si porušil provozní podmínky. Nebo tam nikdo nechodil. Pokud napíšeš stránky které jsou špatně zabezpečené a dochází k přetěžování tak se nediv že je smazali. Já tam mám stránku na netu už tak od roku 2004 , návštěvnost je tam celkem jen 7000 ale stále jedou bez problému.

Od r. 2004, 140.000 navstevnost. Nesahal jsem do nich od r. 2007. A kdyz mi je smazali nedavno, tak asi jsem nemohl ani nijka porusovat podminky. Tohle proste slusna firma nedela, ze stalemu zakaznikovi zrusi web.
http://mujweb.cz/peter.mlich/ - klon
peter-mlich.wz.cz - co mi nejede

Peter, já do toho tvého kódu nevidím a nevím proč to smazali.  Je možné že webzdarma přecházel na vyšší verzi php a smazali stránky které už nepodporují.

#10 oxidián
Nejčastější příčinou smazání stránek na volném hostingu bývá zakrývání reklamy tak, aby ji návštěvník neviděl. Pokud si dobře pamatuji, peter to umí.

Umi, ale nedela :) Rikam, od roku 2007 jsem stranky nemenil. Ta reklama tam vzdycky byla. Ale teda podle starych podminek v poradku. Jestli zmenili podminky... Jenze i tak maji brat ohled. Mou duveru uz neziskaji a radeji si zaplatim vlastni techniku. Coz se uz deje nekolik let, jen se mi tam nechtelo zatim presunovat i moji webku :)