PmWiki (deutsch) für die Liste aller Seiten

• Was ist ein Wiki?
• PmWiki-Elemente
• Installation
• Dokumentations-Index
• WikiSandbox

Englisch:

• HomePage
• WikiSandbox

PmWiki

• Initial Setup Tasks
• Basic Editing
• Documentation Index
• PmWiki FAQ
• PmWikiPhilosophy
• Release Notes
• ChangeLog

pmwiki.org

• Cookbook (addons)
• Skins (themes)
• PITS (issue tracking)
• Mailing Lists

edit SideBar

für die Liste aller Seiten

PmWiki speichert Seiten in einfachen Dateien (flat files) anstatt Datenbanken wie MySQL zu benutzen. Diese Seite erklärt, warum diese Design-Entscheidung gefallen ist.

Pms Erklärung

Pm: Ich habe einfache Dateien zum Speichern von PmWiki-Seiten gewählt, weil ich keine wirklichen Vorteile in der Benutzung einer Datenbank gesehen habe, und es gibt definitiv einige Nachteile. Für die Standardoperationen (Lesen, Bearbeiten, Versionen) ist die Vorhaltung der Informationen in einfachen Dateien klar schneller als der Zugriff darauf in einer Datenbank, und mit Seiten-Caching-Möglichkeiten (kommt in Kürze) wird das noch schneller. Die einzige Operation, die wirklich von der Datenbank profitiert, ist die Suche, aber ich habe immer geglaubt, dass es für schnelle, flexible Such-Fähigkeiten besser ist, existierende Progamme wie ht://Dig oder Google zu benutzen als selbst eine weitere Suchmaschine nachzuerfinden. PmWikis Site.Search ist funktionell und schnell für die meisten Zwecke und wenn ein höherer Durchsatz gebraucht wird, ist es besser zu einer richtigen Suchmaschine umzuschalten.

Und es gibt große Nachteile bei der Benutzung einer Datenbank – mit einer Datenbank müssten wir ein Bündel von "Verwaltungswerkzeugen/Skripten" schreiben, um Dinge wie massenweises Löschen von Seiten aus der Datenbank, Sichern und Wiederherstellen der Seiten, Wiederherstellen von Seiten, die versehentlich gelöscht wurden etc zu unterstützen. Das Meiste dieses Programmier-Wasserkopfes ist durch die Benutzung einfacher Dateien gestrichen, da die Administratoren vorhandene Werkzeuge benutzen können (FTP-Clients, web-basierte Datei/Verzeichnis-Manager, Shell-Kommandos). Die Administratoren sind mit diesen Werkzeugen schon vertraut. Es ist auch viel einfacher, ausgefuchste und angepasste Management-Werkzeuge und Skripten für spezielle Anwendungen zu schreiben.

Letztendlich ist PmWiki schon so strukturiert, dass die einfache-Datei-Struktur leicht durch eine Datenbank ersetzt werden kann, sollte es sich je als notwendig erweisen. Allerdings funktionieren selbst PmWikis mit mehr als 40'000 Seiten mit den einfachen Dateien gut ohne spürbare Durchsatzprobleme.

PmWiki bietet die Möglichkeit, das wiki.d/-Verzeichnis in getrennte Unterverzeichnisse für jede Gruppe zu unterteilen, womit das "too large"-Problem von Verzeichnissen vermieden wird. Sehen Sie sich das Cookbook:PerGroupSubDirectories (in englisch) wegen weitere Informationen an.

Kommentare

• Einfache Dateien sind tatsächlich viel einfacher zu verwalten und meine Erfahrung zeigt, dass es überhaupt kein Problem für PmWiki gibt. Wohl aber hatte ich Probleme damit, meinen Boss von der Benutzung von PmWiki zu überzeugen, weil es keine "richtige" Datenbank benutzt. Je über die Benutzung von Unterverzeichnissen für jede Gruppe wie bei den Anhängen nachgedacht? Bei Solaris gibt es bekannte Aspekte bei Verzeichnissen mit mehr als 20'000 Dateien. Uli?
  PmWiki unterstützt bereits die Möglichkeit, das wiki.d/-Verzeichnis in getrennte Unterverzeichnisse für jede Gruppe zu unterteilen, womit das "too large"-Problem von Verzeichnissen vermieden wird. Kontaktieren Sie mich via E-Mail oder pmwiki-users. –Pm?

  Das ist jetzt in Cookbook:PerGroupSubDirectories (in englisch) spezifiziert. Danke, Ben und Patrick – Sproaticus?
• Auf einem Linux-basierten Betriebssystem mit einem Dateisystem wie ReiserFS, das Verzeichnisse mit Tonnen von Dateien handhaben kann, sollte der Durchsatz kein Problem sein und besser sein als mit der Benutzung einer Datenbank. – Pouik
• Es gibt eine Reihe von Vorurteilen gegen die Bevorzugung einer Datenbank gegenüber den einfachen Dateien. Die Wahl, was von beiden in einem Projekt benutzt werden soll, sollte vergleichbar behandelt werden wie die Wahl der Programmiersprache. Einige der Fragen, die man sich stellen sollte, sind:
  • Welche Wahl erfüllt das Problemfeld am Besten (Datenbanken passen für zufällige Zugriffe auf einen sehr großen Satz von Datensätzen besser, einfache Dateien erfüllen die Belange von Wikis besser).
  • Womit sind die Programmierer vertraut? Was mögen sie lieber?
  • Was ist erreichbar; was erlaubt die Geschäftskultur; wie viel kosten sie? – David Spektor
• Ich persönlich speichere unstrukturierte Daten lieber in einfachen Dateien. Allerdings glaube ich, dass Datenbanken ihre Vorteile bei der Speicherung strukturierter Daten haben. Ich denke so, wenn ich andere Wikis benutze (Tiki, Wikipedia, phpWiki, ...). Ich möchte sie durch einfache Dateien ergänzen. Wie wäre es also mit einer gemeinsamen API? – Duncan Hsu
  • PmWiki hat schon eine API, implementiert durch die PageStore-Klasse in pmwiki.php. Kochbuch-Autoren können eine Klasse mit dem gleichen Interface wie PageStore erzeugen, die die Seiten in alternativen Stellen wie Datenbanken speichern. – PM?
• Ich habe eine Frage: Würde es nicht Probleme mit gleichzeitigem Zugriff vieler Autoren auf eine Datei geben? (Ich meine schreibend - unter dem möglichen Verlust anderer Änderungen)
  • Das halte ich für ein Problem. Ein anderes ist die Verwaltungsseite davon. Natürlich kann ich in FTP eintauchen und dort mit den Dateien arbeiten, aber ich bevorzuge ein Admin-Interface, um Artikel wiederherzustellen. Hauptsächlich weil ich Autoren habe, die nicht so vertraut mit FTP sind wie ich. – sjoerd
  • PmWiki setzt alle notwendigen Sperren, die sicherstellen, dass mehrfacher Zugriff auf eine Datei nicht zu Verlusten von Änderungen führt. PmWiki unterstützt auch automatisches Zusammenführen von gleichzeitigen Bearbeitungen. – PM?
• Ich habe ein 8000-Dateien-Wiki zum Testen angelegt. Die Basisbehandlung der Seiten ist o.k., keine Durchsatzprobleme. Suche ist akzeptabel. Allerdings ist es ein Problem, die .linkindex-Datei von grundauf zu erzeugen. Der Host, wo ich die Site untergebracht habe (und meine Testmaschine), haben ein Time-Out von 30 Sekunden. Ich habe den Linkindex abgeschaltet, jedenfalls keine Backlinks (pagelist link={$FullName}) sind zu langsam. – BrBrBr?
  Setzen Sie den Linkindex wieder ein und führen sie ein paar Backlink-Suchen aus (selbst wenn Sie die Zeit überschreiten). PmWiki baut den Index inkrementell auf. Wenn der Index erst einmal aufgebaut ist, wird alles schnell gehen und es wird keine großen Kosten mehr machen, den Index up-to-date zu halten. – PM?
• Ein weiterer großer Vorteil der einfachen Dateien ist, dass man sie direkt bearbeiten kann. – Babak
  • Genau! Ich kenne viele Szenarien, wo Datenverlust, ausgelöst durch Hardware- oder Übertragungs-Fehler (Speichermedium versagt, Stromversorgungseinbrüche und so etwas), mit einem simplen Datei-Editor auf der Kommandozeile des Servers einfach zu reparieren und die Fehlerursache rückgängig zu machen war. Ich hab' so etwas noch nie mit vergleichbarer Einfachheit bei MySQL gemacht (und in solchen Fällen hasse ich meinen Job). – SomeSysAdmin
• Vielleicht funktionieren die einfachen Dateien ja so gut, weil ein Dateisystem eine hierarchische Datenbank IST. – William
• Noch ein Vorteil einfacher Dateien: Man kann PmWiki auf Servern installieren, die keine Datenbank anbieten (z. B. ein nackter Akademie-Server mit PHP, aber ohne MySQL). Als jemand, der lange schon einfache Textdateien und einfache Versionskontrolle benutzt, habe ich alle meine Änderungen gern in einfachen Dateien. – Matthew
• Ist eine Datenbank sicherer? Der zusätzliche Passwortschutz, den man braucht, um auf eine Datenbank zuzugreifen, muss doch etwas bedeuten .. oder? – Xen
  • Warum sind dann Sites, die PmWiki mit einfachen Dateien nutzen (von denen ich weiß), noch nie kompromittiert worden? ;-) – Julius
  • Wenn man auf die einfachen Dateien von PmWiki zugreifen kann, kann man auch auf das PHP-Skript zugreifen, das das Datenbankpasswort enthält. Das ist also keine Extrasicherheit. – Andrew
    • Genau. Aber man sollte auch die PHP-Datei, die das Passwort der Datenbank enthält, nicht in einem Bereich speichern, der vom Internet aus eingesehen werden kann. Stattdessen fügt man ein 'include' ein und speichert die Datei außerhalb des web/docroot-Verzeichnisses. – Julius
  • Die meisten Datenbanken erlauben keinen Zugriff auf die Daten von außerhalb des Web-Servers selbst, damit ist ein Lesezugriff auf das Passwort der Datenbank noch nicht ausreichend, um irgendetwas damit zu machen, man kann noch nicht einmal die passwortgeschützten Seiten lesen. – Spyro
• ich meine, der größte Nachteil der Nutzung eines einfachen Dateisystems ist, dass es den Programmierern zu viel Zeit kostet, es zu entwerfen und seine Stabilität aufrecht zu erhalten, insbesondere, wenn dem Projekt mehr und mehr Features hinzugefügt werden und mehr und mehr Erfordernisse nötig werden. Und das fügt Risiken der Benutzerdaten hinzu, das Fehler bei Progammupdates wahrscheinlicher sind. Dies fügt auch Schwierigkeiten beim Lösen von Kompatibilitätsproblemen hinzu. Auf der anderen Seite arbeiten Systeme mit einfachen Dateien in den meisten Fällen effizienter als Datenbanken. – Adam
  • Dem muss ich widersprechen (in Teilen). Etwas zu programmieren, mit dem man mit MySQL sprechen (und davon lesen) kann, kann ebenso schmerzhaft sein, genau weil es nicht dein eigener Kode oder dein eigenes Design ist. Das kann ein riesiger Nachteil sein: du weißt nie, wann ein Update von MySQL veränderte Queries braucht, wann es was tut, wenn es tut was du brauchst und so weiter. – Julius
• Ich fürchte, das kann eine endlose Debatte werden, denn die Linie zwischen Vor- und Nachteilen kann ziemlich schmal sein, imho ist immer die sichere Wette, die Option anzubieten und die Leute wählen zu lassen nach ihren eigenen Bedürfnissen, cheers. – h3
  • Ich glaube nicht, dass die Linie so schmal ist. Mit einer separaten Datenbank hat man immer eine viel größere Chance auf Crashes und Downtimes. Man macht sich abhängiger, indem noch ein weiterer Dienst notwendig ist, der auch wieder für sich gesichert werden muss, etc. Zähle die Zeit zusammen, in der man Dinge nicht laufen sieht und MySQL-Fehlermeldungen online erhält. Ich habe selten, wenn überhaupt, so etwa mit einfachen Dateien erlebt. – Ben
    • Viele Leute haben schon Kopien von MySQL laufen, das ist also kein Problem. Die MySQL-Probleme haben Sites, die zu viele / zu langsame Queries für ihre Hardware haben. Etwas so Einfaches wie der Zugriff auf eine Wikiseite wird solche Probleme nicht machen.
      • Noch mehr Leute haben keine Kopie von MySQL laufen. In der Tat kenne ich mehr Leute, die das nicht auf ihrem Server laufen haben, genau weil es ein solches Resourcenmonster für seine Aufgaben ist: lediglich ein paar Textdateien zu speichern. – Steven
• Einfache Dateien haben einen sehr wichtigen Vorteil – man kann mit Merge-Tools Differenzen der Dateien feststellen und Dateien zusammen führen. Damit ist man in der Lage, mehr als eine Wiki-Site auf allen seinen Rechnern zu haben und sie periodisch zusammen zu führen. Ich meine, dass viele Leute diese Funktion brauchen. Schließlich bin ich von mediawiki zu dokuwiki aus eben diesem Grund umgeschwenkt. – Edward
• Datenbanken sind immer auf ein Dateisystem aufgesetzt – schließlich speichern alle "richtigen" Datenbanken ihre Daten in Dateisystemen. Sie bieten eine Abstraktionsebene für Aufgaben wie z. B. Authentifikation, Transaktion oder nur Bequemlichkeit auf verschiedenen Betriebssystemen und sie haben eine gemeinsame Abfragensyntax (SQL). Deshalb beziehen sich die Durchsatzbelange hauptsächlich auf die folgenden Punkte:
  • Durchsatz des Dateisystems
  • effiziente Caching-Strategien (für Daten, Abfragen, ...)
  • effiziente interne Dateiorganisation
  • Effizienter Kode (Client und Server) – Heiko
• Die meisten Dateisysteme bilden Dateien auf Sektoren auf den Platte ab. Datenbanken bieten eine Ebene der Virtualisierung:

• Nur so gesagt: Ich bevorzuge in diesem Fall einfache Dateien, einfach weil mein Heimserver ein MMX ist, aber werden SQL-Server nicht in den Speicher geladen?. Speicherzugriffe sind viel langsamer als HD, um nicht die ganz alten zu erwähnen (meiner ist 2GbDATA100). Klar dass nicht alle Seiten die ganze Zeit in den Speicher geladen sind, aber für die am häufigsten Abgefragten ... Auch ist es einfacher, eine einzige Download-Datei für alle Dateien anzubieten, die alle Wikidaten enthält, für den Benutzer, der das Wiki offline lesen will. Er braucht nur eine Möglichkeit, sie zu lesen ... Und mein dritter Punkt ist , dass es besser für ein Wiki ist, weil kein JOIN nötig ist.
• Den einzigen Nachteil, den ich in der Benutzung einfacher Dateien im Vergleich zur Datenbank finden kann, ist, dass man gewisse Datenoperationen nicht ausführen kann, wie z. B. Suchen und Ersetzen (was mit einer SQL-Abfrage leicht zu machen ist). Besonders, wenn man eine große Site hat, ist es ein ziemlich ermüdender Job in PmWiki (aber vielleicht sollte ich die letzten Kochbuchrezepte durchstöbern nach einer ähnlichen Funktion). Außer dieser keine Klagen - ich bleibe bei PmWiki. – Bien
• Ich stimme dem dateibasierten Ansatz zu. Natürlich verschwinden die meisten Argumente, wenn man gute SQLite-Unterstützung anfügt (ein überwältigendes Werkzeug). Nichtsdestotrotz denke ich, dass das aktuelle Dateiformat, das PmWiki benutzt, nahe an binärer Speicherung ist, da es Filter zum Auslesen und Einfügen braucht Cookbook.AdminByShell?, bevor man irgend etwas Nützliches mit den Daten machen kann, z. B. sie mit Vim bearbeiten. Abgesehen davon, wie gut PmWiki ist, musste ich DokuWiki für die Arbeit wählen, insbesondere aus diesem Grund.

Category: PmWiki Design

<< | Dokumentations-Index | >> für die Liste aller Seiten