tekstbestand VS mySQL

[ewoutw]

Goede dag Tweakers,

Ik en een collega hadden vanmiddag een leuke discussie. Voor een website die als een sort van blog moet dienen is het dan beter om de post in losse tekstbestanden op te slaan of is het toch handiger om het in een mySQL database te gooien. Het zijn artikelen die in principe 1 keer aangemaakt worden.

Ik vermoed zelf dat een tekst bestand op groote websites sneller werkt met opvragen omdat er geen verbinding met een database server nodig. Maar het voordeel komt dan pas echt naar voren als meer handelingen te gelijk op de database zijn. Het voordeel van een datebase lijken mij dat het makkelijke doorzoek baar is.

Nu vraag ik mij af klopt dit en wat is jullie ervaring. Waarom gebruiken jullie juist tekstbestanden of juist een database?

[Room42]

ewoutw schreef op maandag 11 juli 2016 @ 01:22:
[...] is het dan beter om de post in losse tekstbestanden op te slaan of is het toch handiger om het in een mySQL database te gooien.[...]

Beter voor wat?

En wat sla je in het tekstbestand op? De hele pagina of alleen het kale artikel (in HTML, dus zonder styling (CSS))?

En waarom per sé MySQL en niet een andere database engine?

Waarom denk je dat een tekstbestand sneller werkt? Heb je de sites van Tweakers.net, Google.com, Nu.nl, etc. al eens bekeken? Denk je dat dat allemaal in tekstbestandjes staat?

[Oyster]

Wat beter is hangt af van de eisen die jij stelt aan het systeem dat verantwoordelijk is voor de opslag van jouw blog posts. Ik beperk de functionaliteit van dit systeem in mijn omschrijving express tot enkel het opslaan van blog posts, aangezien dat min-of-meer ook de functionaliteit van een database betreft. Kortom, een tekstbestand met een gegevenscollectie - is - een database.

MySQL is een RDBMS, waarbij MS voor management system staat. Die toevoeging heeft betrekking op de uitbreiding van het specifieke opslagmodel met query en manipulatiefunctionaliteit. Deze functionaliteiten zijn toegevoegd om gegevens in min-of-meer hetzelfde tijdsbestek te kunnen blijven invoeren, lezen, wijzigen en verwijderen terwijl de totale omvang van de eventueel versplinterde dataset toeneemt.

Zolang jij geen problemen ondervindt met 1) het opvragen van de gewenste gegevens binnen 2) een acceptabel tijdsinterval in een 3) dataset met een variërende omvang, dan is een eenvoudig tekstbestand database zonder uitgebreide management functionaliteit voldoende.

Er zijn nog veel meer mitsen-en-maren maar over het algemeen kan je stellen dat een DBMS het beheren van een dataset eenvoudiger maakt. De keerzijde is dat daarbij vrijwel altijd de toegang tot deze dataset juist minder eenvoudig wordt.

[Douweegbertje]

ewoutw schreef op maandag 11 juli 2016 @ 01:22:
Goede dag Tweakers,

Ik en een collega hadden vanmiddag een leuke discussie. Voor een website die als een sort van blog moet dienen is het dan beter om de post in losse tekstbestanden op te slaan of is het toch handiger om het in een mySQL database te gooien. Het zijn artikelen die in principe 1 keer aangemaakt worden.

Ik vermoed zelf dat een tekst bestand op groote websites sneller werkt met opvragen omdat er geen verbinding met een database server nodig. Maar het voordeel komt dan pas echt naar voren als meer handelingen te gelijk op de database zijn. Het voordeel van een datebase lijken mij dat het makkelijke doorzoek baar is.

Nu vraag ik mij af klopt dit en wat is jullie ervaring. Waarom gebruiken jullie juist tekstbestanden of juist een database?

Omdat een database wel flexibel is, en je er ongeveer 10000 dingen meer mee kunt doen. Hoe wil je het nu koppelen, tags gebruiken, dynamisch menu maken of wat dan ook? Dat kan niet.
Waarom zou je überhaupt een txt willen gebruiken terwijl je ook HTML hebt zodat je het gelijk kan laten zien ?

Als een page puur voor de read is, en vrijwel niet wijzigt dan kun je ook iets van caching gebruiken zodat je de DB ontlast.

Ik vermoed zelf dat een tekst bestand op groote websites sneller werkt met opvragen omdat er geen verbinding met een database server nodig.

En je denkt dat multi concurrent reads op een txt bestand geen resources kost? Een DB is tenminste er nog voor gemaakt om data op te slaan en te returnen per request. Probeer maar eens een txt bestand te - openen, lezen en weer sluiten met 1000 users tegelijkertijd.

Uiteraard zijn er bepaalde cases dat je een soort plaintext achtige oplossing hebt, er zijn zelfs websites die puur gehost worden op github waar dan daar de data wordt opgehaald. Maar in dit geval heb je gewoon met alle respect een kleine website en probeer je nu dingen te verzinnen waar jij nog niet aan moet denken.

Een DB voor een blogje is gewoon de facto standaard.

[GlowMouse]

Douweegbertje schreef op zondag 17 juli 2016 @ 16:34:
[...]

Probeer maar eens een txt bestand te - openen, lezen en weer sluiten met 1000 users tegelijkertijd.

Zolang je alleen leest zie ik hierin geen probleem.

[Ramon]

Je kan natuurlijk ervoor kiezen om de server-side taal helemaal weg te laten en je site te laten genereren door een static site generator. Met static site generators kan je best ver gaan qua tags, 'dynamische' menu's e.d. Het enige waar je een vervanger voor zou moeten zoeken zijn de comments, maar hier zijn third-party systemen voor.

[Douweegbertje]

GlowMouse schreef op zondag 17 juli 2016 @ 16:58:
[...]

Zolang je alleen leest zie ik hierin geen probleem.

Dat is ook geen probleem, ik probeer alleen aan te geven dat een txt bestand in feite een ander soort type van het filesystem is, terwijl een DB er juist meer voor gemaakt is om met zulke data om te gaan. Vandaar ook het voorbeeld met open / lees / sluit ipv iets als domweg 'file_get_contents'.

Ik snap heus de redenatie wel, maar ik wil TS er liever voor behouden om allerlei funky meuk te gaan maken met .txt bestandjes.

Ten eerste kan een Pentium 4 met 256kb geheugen zijn site draaien aan zeker 50 bezoekers tegelijk, al staat het in een DB, en ten tweede zijn er veel gemakkelijkere oplossingen (db + heel de pagina cachen om maar iets te noemen).

[RM-rf]

ewoutw schreef op maandag 11 juli 2016 @ 01:22:

Ik vermoed zelf dat een tekst bestand op groote websites sneller werkt met opvragen omdat er geen verbinding met een database server nodig.

ook bij het opvragen van de data uit een tekstbestand maak je gebruik van het file-systeem en in theorie is dat evengoed een file-server, inclusief bv cahce-mogelijkheden (waarbij over het algemeen databases betere caching hebben en meer gebouwd zijn op snelle lees-acties)..

een test door iemand van Apache.org om te vergelijken tussen leesacties via een filesystem en een mySQL database
http://people.apache.org/...cess_speed_comparison.pdf


in zijn geval maakte hij gebruik van 100000 files of database recors en deed daarop 1000 leesacties voor korte data en 300 leesacties voor grotere databrokken..

in zn eerste test was de database duidelijk sneller, voroal het vinden van de data ging veel sneller...
in zn tweede test was het filesystem sneller, met minder zoekacties en langere databrokken in wat minder files was een filesystem idd sneller.

het komt dus sterk aan op hoe groot je structur is en hoeveel zoekacties je moet maken om specifieke data in files of in een database te vinden.

uiteindelijk kan het ook sterk meespelen of een bepaald systeem later nog verder uitgebreid kan worden..
een custom op basis van filesystem gebouwd systeem kan steds moeilijker uit te breiden zijn en bij meer functionaliteiten ok sterk leiden qua performance,

[Wolfboy]

Het is een sneller versus eenvoudiger verhaal. Elke grote site gebruikt diverse caching lagen waarbij het ook niet ongewoon is alles als tekst (of wat het uitvoerformaat ook is) op te slaan om de renderingstappen over te slaan wanneer de gegevens niet wijzigen.

Het direct opslaan van bestanden als tekst heeft natuurlijk ook nadelen. Zo moet de webserver dan opeens bestanden weg kunnen schrijven op het bestandssysteem wat een beveiligingsprobleem kan zijn. Maar dat is sowieso iets wat een probleem is als je meerdere servers hebt. Stel je hebt 3 webservers, dan moet je toch bestanden synchroniseren en/of bij gedeelde storage gaan uitkijken dat er niet 2 tegelijk naar een bestandje gaan schrijven.

[The Eagle]

Of je nou met php een stukje text uit een mysql db ophaalt en parsed, danwel een stukje textfile inleest en parsed, dat maakt vrij weinig tot niks uit. Vroeger had een DBMS een zekere overhead, maar met de hedendaagse hardware merk je dat niet eens meer.
Het voordeel van het gebruik van een DBMS zit hem met name in de doorzoekbaarheid van de data. Of dat nou blogposts (textsearch) of iets anders is. Door platte text heen zoeken kan uiteraard ook, maar daar heb je vaak speciale software voor nodig, zeker als je meer dan 1 bestand door wilt zoeken.

[Ramon]

The Eagle schreef op zondag 17 juli 2016 @ 20:39:
Of je nou met php een stukje text uit een mysql db ophaalt en parsed, danwel een stukje textfile inleest en parsed, dat maakt vrij weinig tot niks uit. Vroeger had een DBMS een zekere overhead, maar met de hedendaagse hardware merk je dat niet eens meer.
Het voordeel van het gebruik van een DBMS zit hem met name in de doorzoekbaarheid van de data. Of dat nou blogposts (textsearch) of iets anders is. Door platte text heen zoeken kan uiteraard ook, maar daar heb je vaak speciale software voor nodig, zeker als je meer dan 1 bestand door wilt zoeken.

Je kan client-side search gebruiken, zoals http://lunrjs.com/

[servies]

Ramon schreef op maandag 18 juli 2016 @ 08:36:
[...]

Je kan client-side search gebruiken, zoals http://lunrjs.com/

Dan moet je wel eerst alle tekstbestanden naar de client gooien voor je ze kan doorzoeken...
Dat kan ik nou niet echt een denderende oplossing noemen...

[Ramon]

servies schreef op maandag 18 juli 2016 @ 08:58:
[...]

Dan moet je wel eerst alle tekstbestanden naar de client gooien voor je ze kan doorzoeken...
Dat kan ik nou niet echt een denderende oplossing noemen...

Mwoch dat valt wel mee. De topicstarter heeft het over een blog. Dat zullen dan over het algemeen geen duizenden berichten zijn. Eerder honderden; je kan een hoop blogposts in één MB kwijt. Dan kan je een hele hoop zoeken

Verder wel eens met The Eagle. De beste manier om je blog sneller te maken is om te zorgen dat je server-side taal niet gebruikt wordt. Ik durf wel te garanderen dat een statische site sneller is dan een simpele PHP site, puur om het feit dat PHP "opgestart" moet worden. Eventuele caching natuurlijk buiten beschouwing gelaten.

[Wolfboy]

servies schreef op maandag 18 juli 2016 @ 08:58:
[...]

Dan moet je wel eerst alle tekstbestanden naar de client gooien voor je ze kan doorzoeken...
Dat kan ik nou niet echt een denderende oplossing noemen...

Zolang je fatsoenlijke indexes bouwt is het weinig anders als wat de server doet. Heel groot of traag hoeft het ook echt niet te zijn hoor. Neem bijvoorbeeld de Python documentatie, dat is toch best een aardig boekwerk en de search daarvoor werkt prima:
https://docs.python.org/3...keywords=yes&area=default

Intern gebruikt het gewoon deze index (WAARSCHUWING, GROOT JS BESTAND!): https://docs.python.org/3/searchindex.js

[mocean]

Waarschijnlijk een typisch geval van "premature optimisation". Als het verschil tussen leessnelheid tussen een database en tekstfiles echt relevant is, dan heb je het over echte high-traffic sites waarbij dan vast al heel veel meer dingen spelen dan alleen deze optimalisatie: redundancy, load-balancing, failover etc. etc.

Als je een framework gebruikt, is een database ook nauwelijks complexer dan een file-system zelf aanspreken.

[The Eagle]

Wat aanvullend ook meespeelt of er speciale fulltext search of andere indexen aangelegd kunnen worden. MySQL kan dat sinds 5.6.4 ook met de InnoDB engine (myISAM engine kon al langer, maar heeft wat andere nadelen, o.m. is die niet ACID compliant en geen referentiele integriteit ). Andere DBMS'en kunnen dat ook, maar lang niet allemaal, zeker de gratis jongens niet.

Maar sowieso, als je de keuze hebt moet je je DBMS op het gebruik daarvan kiezen. Of Oracle pakken, dr is maar weinig dat daar niet mee kan. Kost alleen wat centjes

[Ventieldopje]

En wil je toch flat file pak je SQlite

[_Erikje_]

Waarom bouw je de site niet met Jekyll of andere static site generators? Hier kan je dan met markdown je blog items schrijven en deze builden tot HTML die je dan weer naar je webserver SFTP/SCP

Douweegbertje schreef op zondag 17 juli 2016 @ 16:34:
[...]
Een DB voor een blogje is gewoon de facto standaard.

Dat is dus echt onzin. Het is totaal overkill in de meeste gevallen om het in een database te plempen. Zo lang jij alleen documenten heb, is het niet nodig om deze in een tabel te stoppen.

Pas als je complexe dingen gaat doen, kan je kijken naar een database kijken.
Gerelateerde artikelen, tags etc kunnen makkelijk handmatig beheerd worden zonder een database.

https://jekyllrb.com/

[Wolfboy]

The Eagle schreef op dinsdag 26 juli 2016 @ 20:35:
Wat aanvullend ook meespeelt of er speciale fulltext search of andere indexen aangelegd kunnen worden. MySQL kan dat sinds 5.6.4 ook met de InnoDB engine (myISAM engine kon al langer, maar heeft wat andere nadelen, o.m. is die niet ACID compliant en geen referentiele integriteit ). Andere DBMS'en kunnen dat ook, maar lang niet allemaal, zeker de gratis jongens niet.

Maar sowieso, als je de keuze hebt moet je je DBMS op het gebruik daarvan kiezen. Of Oracle pakken, dr is maar weinig dat daar niet mee kan. Kost alleen wat centjes

Dan zou ik eerder PostgreSQL pakken. Heeft op de meeste punten net zoveel mogelijkheden als Oracle en loopt op sommige vlakken zelfs voor. En het is volledig gratis en open source

Er is ook een bijzonder uitgebreide Full Text Search aanwezig: https://www.postgresql.or...nt/static/textsearch.html
Voor zover ik tot nu toe getest heb zeker even krachtig als Oracle Text

[The Eagle]

Weet ik. Toevallig net voor de zaak een vergelijking getrokken tussen de (on)mogelijkheden van PostgreSQL tov Oracle, MySQL en MS SQL. Kwamen wel wat grappige resultaten uit. En ook vervelende resultaten, zoals het feit dat PostGreSQL geen echte multimaster clustering kent en ook niet handig is met failovers. Beide niet handig als je een omgeving HA wilt maken

[CodeCaster]

The Eagle schreef op vrijdag 29 juli 2016 @ 13:37:
Weet ik. Toevallig net voor de zaak een vergelijking getrokken tussen de (on)mogelijkheden van PostgreSQL tov Oracle, MySQL en MS SQL. Kwamen wel wat grappige resultaten uit. En ook vervelende resultaten, zoals het feit dat PostGreSQL geen echte multimaster clustering kent en ook niet handig is met failovers. Beide niet handig als je een omgeving HA wilt maken

Dat was ook de ervaring van Uber.

[b2vjfvj75gjx7]

Kijk anders eens naar een flat-file CMS als bv. Kirby;

https://getkirby.com

Extreem snel, tot 10.000 posts geen probleem (zeker met SSD als server), en je kan gewoon queries draaien, chained filters toepassen, etc... sowieso ondersteunt het 3 niveau's van caching (file, ram, etc...).

Een database is echt niet nodig "als default" (en worden flat-file systems steeds populairder).