Názory k článku Smazali jste příspěvek na Facebooku? Nedivte se, když se znovu objeví
-
Zvládá-li Facebook spravovat ono obrovské množství dat a navíc složitě provázaná, pak zvládne tato data i mazat. Neříkám, že se takové záznamy smažou do 5 vteřin. Může to trvat i delší dobu, třeba dny nebo týdny, ale dojde-li ke skutečnému odstranění, je to nevratné a není možné, že se po 1/2 roce smazaná data zase někde objeví. Objeví znamená, že byla "smazána" a najedou zase existují, to znamená, že s daty se pracovalo a tedy byl na práci s nimi vynaložen nějaký čas a výkon. To, že se objevila znamená, že na jejich objevení byl opět vynaložen nějaký čas a výkon. Mě z toho plyne, že FB mrhá časem a výkonem... Mimo jiné, celý problém nemá se složitostí a objemem nic společného. Je jasné, proč se "smazaná" data znovu objevují. Nejsou smazaná. No a cena? Pokud by FB měl aplikaci naprogramovanou správně nestálo by jej "smazání" víc než stojí jiné běžně prováděné databázové operace... Vím, že FB má hodně programátorů, ale systém mění tak často a už je tak překombinovaný, že v tom musí mít minimálně počínající chaos. Moc dobře vím, jak to s takovými, za běhu měněnými databázemi a aplikacemi chodí. Moc dobře vím, že např. jenom udržet předem stanovenou normu při pojmenovávání objektů, procedur, funkcí a proměnných nakonec sklouzává k chaosu a není snadné ji udržet a dělat refaktoring nad db jako má FB musí být noční můra i s případnými nástroji...
-
Martin Kučera (neregistrovaný)
Vy jste se tu teda sešli.
Sice tu "odborně" plkáte o MS SQL a MS Access a vydáváte se za programátory, ale zapomínáte, že Facebook řeší obrovská kvanta dat, navzájem spletitě provázaná. Tam neplatí běžné poučky o normalizaci dat, stejně jako se nehraje na transakce a konzistenci dat.
V praxi je jeden příspěvek v databázi mnohokrát v různých kontextech, ještě redundantně rozlezlý po HA clusteru a po různých keších. Mazání dat a zajištění konzistence přes celý cluster je "drahé". Při návrhu takových aplikací vývojáři řeší, jestli je nějaká situace kritická. Pokud dojdou k závěru, že situace nastane jen v pár případech a za tuto cenu se ušetří spousta výkonu, tak se jednoduše rozhodnou těch pár případů vědomě ignorovat.
Problém je, že v měřítku stovek milionů uživatelů může být "pár případů" klidně pár tisíc výskytů denně. Někdo mávne rukou, někoho to naštve.
-
Já číst umím, ale ty jsi nějak roztržitý nebo sebestředný. Jinak bys zaznamenal, že jsem neodpovídal na tvůj příspěvek, ale na příspěvek od
Ditys Cidae ... No a pozornému čtenáři je jasné, že máme v podstatně shodný názor...To, že se po DELETE záznam nesmaže ovšem nemusí být chyba programátora. Například v případě použití triggeru "INSTEAD OF", což je ovšem akce vynucená programátorem, se záznam nemusí smazat. Je správná programovací technika pokud je výsledkem to, že záznam v databázi zůstane přístupný i do budoucna.
A zde se vracíme k původnímu problému a tím je, že chce-li programátor (respektive zadavatel) aby byl záznam smazán, je to možné a to bez možnosti návratu ať už je provedení jakékoliv (Záznam se smaže fyzicky nebo je jen db systémem označen jako smazán a odstraněn až při nejbližší komprimaci db.).. Neznám databázi, ve které by se po smazání záznamu daný záznam nějakou "chybou" daného db systému (tedy nikoliv chybou programátora) znovu objevil.
-
x (neregistrovaný)
Pokud se posle do db delete, tak zadny where nepomuze ... jak sem rek (a jak si negramotnej zen neumi precist) data jeste nejakou(obecne nedefinovaou) dobu zustanou v souborech ... ale rozhodne nejsou dostupny aplikaci, ktera pouziva tu databazi. U nekterych databazi pak existujou zpusoby jak vynutit okamzity prepis tech dat tak, aby je proste ziskat nebylo mozne vubec (samo, pokud se pominou zalohy).
Samo, nektery aplikace misto detele poslou do DB nejaky update (zcela zjevne to tak dela FB) a zaznamy si jen nejak oznacuji. Ovsem i v takovem pripade ... je jejich "znovuobjeveni se" minimalne zasadni programatorskou/administratorskou chybou. Nadto u firem nakladajicich s osobnimi udaji je neodstraneni takovych udaju na zadost uzivatele dokonce nelegalni a trestne.
-
A k dohledání jste použil Access? Pochybuji. Musel jste použít nějakou jinou aplikaci. My se ovšem bavíme o smazání takového rázu, že po DELETE příkaz SELECT bez nějakých podmínek typu WHERE smazano <> 1 zázname nenajde. Pokud bude proveden v DB DELETE, není pak následně možné, aby se daný záznam znovu objevil, což u Facebooku asi neplatí. Facebook zcela jednoznačně záznamy nemaže, ale cíleně označuje jako "smazané". Pokud někdo tvrdí, že je to kvůli relační integritě, pak je to hloupost. Smažu celou osobu z celé databáze a chci-li ponechat nějaká data, musím změnit u těchto dat primární klíč na nějakou virtuální osobu např. "Mgr.Deletovna Smazaná"...
-
Delete neznamená, že data jsou pryč, jen je záznam v tabulce označen jako neplatný. Např. u souborů DBF je to první bajt záznamu. V tabulce Access se zase vymazání řádku projevilo změnou 5 bajtů, původní data se ale pořád dala dohledat. U větších databází to bude stejné, jde o rychlost - minimalizují se drahé požadavky na zápis. Pokud tedy chci mazat bezpečně, musím nejdřív data přepsat a následně vymazat. Ještě elegantnější způsob (dnes jsem si dohledal) by byl zakódovat řádek tabulky jiným certifikátem, než byl původní. To už je ale databáze s vyšším bezpečnostním standardem :-)
-
x (neregistrovaný)
Zen, neplkej tu svoje kravoviny, maze naprosto kazda databaze, je jen otazka na jaky urovni, ale z pohledu pouzivani tech dat, jakmile poslu do DB delete, tak sou pryc. Samo, kdybych se zacal hrabat v datovych souborech, tak tam jeste nejakou dobu budou (nez je prepise neco dalsiho).
Z duvodu bezpecnosti/auditovani/... se pak v nekterych pripadech zcela planovite nemaze, ale data se jen jako smazana oznaci (a uchovavaji se trebas i veskere dalsi zmeny), ale to vubec neznamena, ze je smazat nelze.
-
Normálně v MS SQL Serveru se pro příkazu DELETE snaže záznam. Pokud danou věc neprovádíte v transakci, pak je záznam smazán. Nemáte-li zapnutý log, tj. máte-li nastaven Recovery model na Simple a nemáte-li zálohu databáze, data jsou nenávratně pryč. Ještě více destruktivní je pak příkaz TRUNCATE, který kompletně promaže celou tabulku a máte-li nějaké pole Autoincrement, pak nastaví toto pole na výchozí prvotní hodnotu. Stejně pak funguje MS Access... Fyzické smazání záznamu se mimo jiné musí provést v případě, kdy je nad tabulkou vytvořen clastrovaný index (obvykle primární klíč), při kterém dojde k přerovnání indexu... Je ovšem zřejmé, že záznamy v tabulce nejsou fyzicky "setřeseny" a vznikají "mezery". Tyto se nechají "defragmentovat" např. MS Access má volbu "komprimovat při zavření".
-
Rdm (neregistrovaný)
Je jedno jestli o tom rozhodne programátor nebo nějaký manažer, ta podstata zůstává stejná. Neomezené hromadění dat i přes nesouhlas uživatele - ano v případě FB je to v tomto ohledu horší, protože ten o vás shromažďuje data aniž byste byl u něj registrovaný, tedy dal k tomu jakýkoliv souhlas.
-
Skřetík (neregistrovaný)
Zjevně jste dnešnímu "modernímu" světu vzdálen již poměrně delší dobu, jinak byste si uvědomoval, že projekty typu Facebook nejsou nějaká one man show, kde programátor dělá co se mu zlíbí. Tam dělá to, co dostane zadané od manažera. A manažer se nepochybně rozhodl že se mazat nebude nic, protože potřebuje pořádné datové sklady pro svůj datamining díky kterému bude později moc lépe cílit reklamu.
-
Rdm (neregistrovaný)
Nic jako FB jsem sice nikdy nedělal, ale ve všech aplikacích, ve chvíli kdy se řekne "smazat", tak se smaže. Pokud smazání těch dat nezpůsobí nějaké problémy s integritou, tak neexistuje jejich ponechání jinak než v rámci pravidelných záloh, což je také bezpečnostní opatření pro případ, že by někdo někdy objevil nějakou bezpečnostní mezeru.
Opravdu přestávám rozumět dnešnímu "modernímu" světu, kdy programátoři pod záminkou "bezpečnostní opatření" ignorují právo na soukromí a bez souhlasu majitele, neomezeně dlouho, nakládají s jeho osobními daty. -
Petřík (neregistrovaný)
Kdo někdy vytvářel jakoukliv složitější formu webové aplikace ví, že data se nikdy z databáze natvrdo nemažou, pouze se označí za smazaná nebo expirovaná, není to vůbec důvod aby se data dále posílali na servery NSA ale je to jeden z hlavních bezpečnostích opatření, aby někdo nevyužil bezpečností mezery ve skriptu a nenávratně nevymazal všechna data.
ČLÁNKY DO MAILU