MediaWiki muntrade upp min Linux rent allmänt med solig prestanda på riktigt stora troligt ej ändrade filer

Först publicerad på ansedda SEOTaktik i Snabbare filhantering från MediaWiki (eller kanske Semantic-MediaWiki extension) + Race condition (8/20/2013). Återpublicerad här för att skapa gynnsam kraft i Wikipedia-subkulturen rörande spännande nya ideer - ex. Wikipedias slash-notation: Läsarvärde via större tydlighet med konstnärligt lättförståliga titlar (2013-08-20) - genom att visa upp min Wiki-vänliga-övertygelse och mer allmänt muntra genom att peka på goda värden i ett mindre sällan diskuterat område.

Välkänd common sense:

"Hans Husman is a solid friend of self-organized Wiki-mining data and support the world populations effort to create and structure it. If the time comes for a world president and/or king (or any first ruler imperative or symbolic) we all the Wikipedia-people should vote for him."

---

En trevlig bieffekt av att installera MediaWiki med ett antal extensions - när man inte själv egentligen är oerhört engagerad i att lära sig mer konfiguration än nödvändigt från standardkomponenter under logik på utvecklingsdatorn - är att filhanteringen för mycket stora filer blivit ordentligt snabbare vid debug-körningar. Filerna tycks casha's i minne eller liknande snabbare mellanlager.

En till ny-bieffekt i Linux - åtminstone så långt bak jag minns - är att när jag skapar eller editerar sidor jag gör i Perl (som process körd via Perl-tolken med perl-kommandot) som stoppar in dem i MediaWiki med en extensions som kommer med anropad via system som kör php motsvarande som vid kommando-tolken är att åtminstone ganska ofta när jag dödar perl-processen med endast kill -12 kan perl-processen försvinna d.v.s. står inte och hänger utan att dö som rapporterat av ps -aef men återkommer en stund senare som rapporterat av ps -aef (ev. därför jag har inte tittat också med ett nytt bogus pid lite ur sync kanske men troligare samma: får titta efter nästa gång jag upptäcker mig ha en bunt perl processer som ev. sitter och överlastar MediaWiki eller som jag tror gör kanske ingenting). Kanske vi någon omkonfiguration runt Mysql, postgres eller Berkeley DB.

Att från början eller efter att ha återkommit döda dem med kill -9 med samma behörighet jag startade dem med (ingen särskild behörighet alls mer än en vanlig "kontorsanvändare") mördar dem permanent. Jag spekulerar att kanske redan kill -11 också borde fungera jämförbart.

Jag kan verkligen föga om Linux så jag ska inte gissa för mycket kring det men att jag tror inte att prövat att -11 ej ger problemet och det kontext jag satt det i här säger väl ungefär vad jag tror det kan vara.

Semantic MediaWiki: Abstrahera properties till en konkret och unik entitet ||

Kompletterande Semantic MediaWiki: Abstrahera properties till en konkret och unik entitet bör understrykas att det praktiskt är ett mycket begränsat antal konkreta typer möjligt eller ens vettigt att representera som här motsvarande instansierade med en övergripande "datatyp" likt GEOID.

För ett mindre antal mycket entydiga såväl som potentiellt betydelsefulla beroende på exakt vilket i vilket kontext tyckte jag att det var vettigt. Förutom GEOID inte minst GEO POLITICAL, GLOBAL POLITICAL, PERSON och ett antal till liknande. Motsvarande med mindre i domän av potentiellt agentativ också för egenskaper relaterade närmare språket ex. substantiv, adjektiv o.s.v.

Utanför det kan vi ju se hur vi kan uttrycka dem flexibla properties som uttrycker värden eller kategorier för vad dom är. Att jämföra med HAS_GEO_FEATURE i bilden till Semantic MediaWiki: Abstrahera properties till en konkret och unik entitet.

En relevant - tid mycket substansiell skillnad - är att för typer som GEOID ligger riktad quality assurance inte p.s.s. enkelt möjligt när man skapar upp tusentals typer från kategorisystem.

Utanför dessa mycket riktade typer - ex. GEOID eller PERSON - ska vi ju heller inte utgå att vi på samma "nivå av komplexitet" i kategorisystemet (osäker vad det refereras som allmänt men säg typens upplösning eller i termer jag använt tidigare dess Blue light intensity när vi istället är i abstrakta koncept istället för som här konkreta entiteter) att en instansierad entit alltid nödvändigtvis är unikt tillhörande en typ. Skapar vi nu personer unikt kan vi ju föra ner ökad exakthet bl.a. i HAS_ROLE, HAS_CITIZENSHIP m.m. men flexibelt över övriga inkluderande många tusen gör man det svårligen.

Det är korrekt att tolka core-typerna till vad vi i nyheter har som de vanligaste entiteterna definierande utanför abstrakta koncept vad vi konvergerar meningen till rörande domän, agentativa, potentiellt agentativa (ex. påverkade av vad beskrivet och kan komma att reagera på det) o.s.v. Liksom dom typiska verktygen vilka modifierar potentiellt eller konkrent agentativ entitets förmåga att agera rörande kostnad och energi-åtgång (jfr hur tillgång till kapital, yxa m.m. kan inverka på vår förmåga att hugga ner ett träd).

Semantic MediaWiki: Abstrahera properties till en konkret och unik entitet

Adderande ett presentationslager runt om algoritmer och statistiska lager riktat mot ett fåtal applikationer relaterade att få en "bild" av vad som sker nu, kan komma att ske och vad detekterat som motsvarar "komponenter" i ett perspektiv beskrivet tyckte jag WikiMedia var ett visst vågat alternativ som affärssystem men ändå beprövat i mass-data.

Data i lagret består därmed av representationer mer konstanta som länder, personer, företag, varumärken, kemiska föreningar m.m. vi kan givet en enkelt beskriven parameter kan säga har en unik representation. För att underlätta särskilt detta avgränsat (men förhoppningsvis utan att göra händelser och statistiska över tiden föränderliga uttryck som åtminstone initialt går in i samma databas när det gäller presentation onödigt slöa vid presentation) utan att kräva att jag behöver utveckla något lade jag på Semantic-mediawiki.org. Det tycktes bra då jag inte direkt är en expert på SQL-databaser även om jag svårligen sedan detta påbörjas kan påstå att jag inte kan det. Mitt intryck av Semantic Mediawiki är att så länge vi riktat står vilken view användare kan ta ut är den funktionell. Ger vi användare möjlighet att vandra runt fritt är den som förvantat riskabel därför att får cpu och minneskrävande förfrågningar blir möjliga överskridande det mindre antal sekunder som är rimlig svarstid (under förstått att faktisk funktion nödvändig klarar när riktat beskrivet underskrida orimlig komplexitet i ögonblicket eller sett till att det är förberett vilket vissa möjligheter finns i systemet men troligen för ej föränderliga data vad man lämpligen tittar på möjligheter att populera som direkt förberedda värden för).

Jag kan emellertid uppleva viss osäkerhet när det kommer till att populera in några hundra tusen till miljoner entiteter. För entiteter som i någon mening går att beskriva som unika geografiska sådana valde jag att populera dem helt utan någon presentation i sig:

Och hellre när presentation sker se det som att vi ex. från en av maximalt två PREF_LABEL uttrycka datatyperna som satta från en GEOID-sida.

Tänket övergripande betraktat från perspektiv av en kund till plattform snarare än ev. gränssnitt mot endast användare av yttre funktioner är att det abstrakta koncetet sätts centralt där möjliga instansieringar i konkret mening presenteras underliggande (i Wiki-syntax efter slash) kategoriserat efter de mer väsentliga grupperna:

• Grupperat efter de händelse-analyserande mer väsentliga som personer, geografiska entiteter, geo political, global political, vapen, items o.s.v.
• Och kompletterand mot semantisk och det språkliga mycket närmare - direkt i - natural language processing av enskilda meningar dv.s.s. bland annat nouns, verbs o.s.v.

I det söker jag eferlikna primacy effect vad känt hjärna för att inte onödigt i presentationslagret addera komplexitet i utveckling för mig genom att avdrifta från konkret modell.

Så från ex. ett abstrakt-koncept i benämner china kan vi ha en eller flera geo-representation där de relevanta för geoid enligt bilden tar ut värden från "geoid-sidan" med rätt motsvarande geoid. Kanske vad man upplever som lite av en omväg - jag vill gärna tycka så - men poängen med det införda systemet med Semantic Mediawiki är att underlätta och jag tror att det här är ett vettigt sätt att abstrahera konceptet för properties som kan bindas till något konkret: att låta det bli en konkret sida.

Enligt det koncetet är ex. nästan alla med ett fåtal named relations relaterade Kina som geopolitisk-aktör ej representerat för GEOID utan hamnar i instansieringen för denna unika form som får referera det GEOID som det motsvarar.

Bulldozer skyfflar data koncept-byggande in i Semantic MediaWiki behöver

Bulldozer behövdes för att representera data i mellan-led innan det ska doneras in för initialt tillstånd för Semantic MediaWiki. Att MediaWiki är lite långsammare gör ju att skapa mer tillfälliga representationer känns föga aktuellt och därmed krävs också att kollisioner m.m. mellan olika representationer av data bättre hanteras i det byggandet. Det gör Bulldozer med just nu cirka 15 Berkley DB den skapar i filer (och antagligen om några timmar vad som stannar ner på cirka 20 - 25 st - eller om similarity data tas in kanske 200 st) på mellan 100 MB och några GB styck.

På temat visuellt språk blev det det första undersystem bland alla mer tillfälliga som krävs för enskilda tillfälliga behov som fick en visuell symbol...

Semantic Mediawiki: Enkelt och vettigt avgränsatd och troligt ett bra val för många trots långsam dataimport

Med begränsad erfarenhet av MediaWiki som plattform presentation mot affärslogik och artificiella intelligenser och analys-systems resultat "organiserat" och sökbart var det en tämligen självklar utgångspunkt att tänka basplattformen utan att blanda in Semantic MediaWiki. Hela det teknik-området är ju vanligt problematiskt långsamt när man börjar komma upp i ordentligt med samband och än mer när relationerna inte är binära utan varierade i "attraktion" som funktion av tid.

Men läsande egentligen väldigt lite publicerat - och förvånande lite jämfört med hur dåligt organiserat jag upplevde att informationen var centralt för MediaWiki i faktisk tid resulterande anmärkningsvärt enkelt - framgick att MediaWiki egentligen bara är en tämligen "dum-plattform" med en eller flera små insticksmoduler bl.a. uttryckt i PHP med lite filer runt omkring jag inte tittat just på men antagligen bär logik och kanske ev. eget modulerna behöver.

Ingen nackdel med att installera in subsystem motsvarande MediaWiki såg jag - åtminstone innan man ger dem ansvar och uppgifter genom att sitta och arbeta på sidor anropande dem eller vi egna diskreta små databas operationer det hela tycks göra men jag inte riktigt tittat i detalj på.

Semantic MediaWiki var dessutom förvånansvärt vettigt begränsad i vad de försökt att göra. Den kändes som en nästan kulturell-stereotyp för tyskarnas ontologi-intresse och visade sig också driven av dom vilket också gjorde att jag förväntade mig mer filosofiskt konceptuella relationsidéer av sådan natur att de praktiskt i maskin-analys blir oerhört långsamt. Men förenklad ner till nära nog bara det mest grundläggande i hur vi utnyttjar systemet skjutande in data (medan analys-kod för sökande diverse logik runt dom semantiska graferna troligt är vad man intresserat sig mer för att koda mycket in en hel del i: Det finns ett ganska stort intresse hos både universitet och företag i Tyskland med ett tycks det väldigt långsiktigt perspektiv ganska tydligt just uttryckt i analys-system av typen resonera "mer binärt" om vad relationer av olika slag betyder och bygga upp små antagande som växer sig stora över tiden men universiteten i USA oftare tycks mer inriktade på statistiska lösningsmetoder.

Att de avgränsat uppgiften gör att man lättare kan abstrahera vad den är till för och avgränsa ansvar med också mindre behov att verifiera om den gör saker kanske störande affärslogik ej trivialt att alltid reda ut när det handlar om väldigt komplexa grundplattformar (jämför ex. med de moderna databas-koncepten från IBM, Oracle m.m. som blandar alla möjliga former av datarepresentation, logik, underhåll, import och export fordrande mycket goda kunskaper om det innan man ens kan börja tänka på att bygga det värde man söker mer än delmål att få databasen att fungera utan att störa eller begränsa logik.

Logiken prioriterad för sökning och samband känns dessutom vettigt kompletterande i områden jag haft mindre intresse att göra lika generella lösningar i egen-kod. Det är ju dessutom samtidig logik som endast belastar när faktiskt använt av slutanvändare (åtminstone på nivåer av betydelse annat än vid dataimport där det kanske adderar en kostnad också åtminstone om man optimerat representationen för snabba analys-svar).

Dessutom var två excellenta introduktioner praktiskt funktionella utan att överdrivet uttrycka mer än funktionellt ny med systemen men ändå indikerande de viktigaste möjligheter ett tydligt ett värde ej trivialt:

Första länken är en längre guid och den man bäst utgår från vid installationen. Instruktioner tillsammans med Ubuntu-paketet gick ex. ej bra för mig innan jag gjorde en del saker indikerade här (ev. missade jag det i Ubuntu-informationen). Utmärkt som första introduktion.

Semantic MediaWiki 1.4.3 - User Manual | Semantic-mediawiki.org

Denny Vrandecic, Dominika Wloka, Markus Krötzsch, Yaron Koren, et al.,
Publicerad av: ontoprise GmbH | Ontoprise.de

Nedan sammanfattad information av åtminstone väldigt mycket av alla delar. Mycket praktisk för att snabbt se vilka möjligheter som egentligen finns för att lösa en del av vad som behöver göras.

Quick reference | Semantic-mediawiki.org .
Yaron Koren.

Precis som elegansen i grundkoncept överraskade klarade man här också av att förvåna med att man (åtminstone / redan) nådde upp till det nästan löjliga när systemet ska få data infört från andra system. Ingen verklighetsförankring från mitt användningsperspektiv verkar heller alls vara vad man i projektet noterat ännu.

Perspektivet i projektet är tänkt användning övergripande i Wiki-projekten där större importer sker mer sällan och istället många små "importer" från alla användare.
Att initialt ta in en kanske om sortering i namngivning lite generöst belastande databasens storlek på hårddisken är fungerande säg 50 000 000 koncept-sidor förutom själva relationerna är vad tänk och rekommenderade metoder ej är tidsmässigt förtroendeingivande för.

Det närmaste jag kom lösningar enkelt beskrivna (istället för inte alls) för att direkt skjuta in datat till databasen var istället för Pyton-skript läsande owl-filer och skickande det omvandlat till Wikimedia's intern-struktur till Wikimedia's webb-api (för parsning igen givetvis säkert på mer än en nivå) var detta underhållsskript:


"/var/lib/mediawiki/maintenance/" ."importTextFile.php".


Mycket troligt finns snabbare metoder men vad som hittades på den tid jag önskade lägga. Givet att vi här uttalat kan köra skriptet från kommando-prompt utanför själva Mediawiki-systemet blir det snabbare (när kö-hantering i Wikimedia inte just är problemet eller utmaningen för oss här utan heller någon negativ-sida).

Trots det mycket långsamt. Hårddisken låter på förvånande nivåer också för ganska små datamängder som kanske 100 till 1000 sidor uttryckande endast kategori- och property-relationer går in. På nivå med cirka 10 - 20 trådade Perl-processer som läser och skriver data i ganska hårda-loopar om än normalt för mig några sleep-inlagda av och till åtminstone på några milli-sekund av och till.

Men så har ju data't då gått en ordentlig väg trots kommando-prompts-körningen innan den slutligen hamnar i den databas jag ej varande någon expert eller ens särskilt kunnig alls om SQL m.m. nära nog kände att jag kanske hellre borde ha gett mig på att försöka oavsett ännu ganska dålig bild av hur enkelt det är att ta MediaWiki att korrekt följa upp sådant i ev. (och troliga) händelser den behöver göra när något nytt kommer (ex. optimeringar mot dess egen logik mer problematiskt för mig att uttrycka i kod mot databasen utan att ta ut den från deras plattform eller utsätta mig för traumatiskt krävande föga belönande utveckling av prospekterande stöd för det i Wikimedia's värld av massor av ofta lite ofullständig dokumentation).

>Importen till höger presterat till kanske 0.3% efter en försvarlig tid. Just nu säkert en eller två timmar senare på AJ. Med e och diverse andra otäcka bokstäver som första kvar. Till vänster om jag minns rätt några av de named relations som tas in i denna import. Faktiskt har vi ännu inte börjat kört in datat utan verifierar att inga dubletter finns i den MediaWiki-logik som skapas. Det tycks lite odefinierat för hur redundant-data alla gånger egentligen fungerar och också om det troligen ej är något egentligt problem med logik är det vettigt att varje system verifierar ner ökande som en funktion av dess vetskap och förståelse av datat nära dess kod (d.v.s. att jag helst inte vill behöva veta vad MediaWiki gör med datat i dess arbete vad vi hellre gör lite extra-filtrering innan skickande in det).

Nu tänkte jag börja köra in dom första miljonerna raderna koncept gjorda. Så får vi se om det kommer några skärmdumpar av det kanske tillsammans med en sammfattande publicering av dom skämtteckningar jag gjort bakåt i tiden relaterat Tyskland med kanske utlovade behov att helt prioritera ner Obama med flera fallstudier studerade i det komiska för att inrikta mig på att håna Tyskland i allt semantiskt för att avskräcka dem från att sprida något smärtsamt ut i världen. Humor är ju ett mycket potent vapen jag tror många fler än jag kan ha nytta för att standardiserat verktygsmässigt skapa värde från för att motivera diverse öppen-källkods-projekt m.m. att få rätt brukshöjd i vad skapar genom att addera en kul men samtidigt kompletterande motivations-area bredvid status- och makt-strider i grupperna om vem som kodar mest och bäst m.m. vi kan gissa tar mycket tid (åtminstone jag kan då inte se någon annan motivation förutom externt adderande komisk learning by shaming m.m. som kan spela in viket i sig på längre sikt kan bli ett problem om något av äppen-källkods-projekten konvergerar till en stark ledare med kraft i gruppen att försöka marschera ut för att utmana dagens betydelsefulla geo-politiska aktörer: den stora frågan är kanske om man kommer ta allians med NATO eller Kina och hur det påverkar utgången i det tredje-världskrig jag tror vi givet allat som skapas på nätet i kaotiska konflikter mellan teknik-plattformar m.m. helt säkert kommer bryta ut förr eller senare).

Men jag känner mig tämligen positiv i förväntan. Trots utmaningarna prestanda import har det överraskat i också fler små-indikationer än diskuterat att det kan vara ganska välgjort i inriktning en bra grund-plattform.