NoSQL med Rebel-AS: Berkeley DB prestanda optimerat i två kraftfullt enkla steg

Sammanfattat: 1. För-sortera (design pattern sort) stora chunk och 2. Stoppa in. Men glöm inte att stoppa in det sista datat.

Tidigare har jag haft stora problem Berkeley DB i att skapande av databaserna vid resp. 80 MB mängd databas gjord kom en stor tidskostnad. Längre ut kunde det i princip gå hur länge som helst. Av den orsaken hade jag tänkt ersätta det med något färdigt mer paketerat inkluderande mer av färdiga funktioner för dimensioner m.m. Men standardprodukter kommer ju med viss kostnad inlärning, legacy och för ex. MongoDB jag lutade åt att jag ogärna just nu vill installera om utvecklings-server från 32-bitar Ubuntu till 64-bitar (med 32-bitar är MongoDB ej meningsfull relativt vanliga hash-tabeller inlästa från fil därför att datat är väldigt litet).

Varför brytpunkt ligger där vet jag inte. Ev. är det just relaterat 32-bitars adressering i OS (jag har fått för mig att både den Berkeley DB jag använder, MongoDB m.m. alla normalt ej gör något mer underliggande eller långt ner i OS nära disk eller adressering utan använder ett färdigt anrop för stora filer att adressera likt minne i Linux). Det stämmer i alla fall ungefär i magnitud:

2³² (82 * 1024 * 1024) ~ 49.951

Men har alltid prövat det på samma filsystem (ej prövat det på mitt Ext3 - eller om det är Ext4 - jag prövar eller formaterat för att pröva i alla fall som tänkbart just för disk där NoSQL databaserna ska ligga längre fram: givet bl.a. ingen checksum m.m. passande för databaser där ej tänkt att ändras kontinuerligt och i behov av god prestanda relativt begränsad hårdvara - osäker om det gör praktiskt kommer göra märkbar skillnad eftersom jag egentligen aldrig varit i närheten av storleks-magnitud totalt data som kommer behöva hämtas kontinuerligt men anar att det kanske gör skillnad).

I Rebel-AS jag döpte en fortsatt egen legacy NoSQL jag byggt ovanpå just Berkeley DB har jag samma fördröjning som funktion av cirka 80 MB nedsläppt. Men nu mycket snabbt skapande av databasen. Ett natal GB med inlägg från bloggar och sociala media för fortsatt analys handlar om ett fåtal timmar eller kortare tid (satt ej och tog tid på det framför datorn).

Berkeley DB snabbt: Sätt dig ner och sortera nycklarna åt datan (likt programmera: människa gör det kostsamma - datan gör egentligen föga)

Och hela skillnaden i prestanda ligger i vad jag trots av och till utdragna - säg fyra timmar totalt - försök att hitta en förklaring och lösning ej hittade alls. Förutom mer av slump slutligen i en kort kommentar till en fråga svår-hittad både nu och tidigare (möjlig utgångspunkt: Berkeley DB Slow via sajt-sökning med Google).

I övrigt läsande på Stack overflow fick jag ut föga värde. De flesta verkar heller inte göra särskilt stora databaser. Exakt vad orsaken är eller varför det ev. är god vana vet jag inte. Databaser har aldrig särskilt intresserat mig och ingenting jag direkt önskar att lära något mer än nödvändigt om. Jag hade snarare föreställt mig att det logiska vore att om distans eller skillnad mellan nycklar som går in pre-expanderar man motsvarande fil mycket mer för att slippa flytta om datat senare alt. slippa hantera kollisioner via redundant för träffar nycklar eller pekare vidare till annan position.

Hans reflekterar vad han redan lärt och slutade lära cirka 2003 rörande databaser och tyckte sig inse att det räckte bra nog ändå: Datan gör ungefär samma fel varje år även om skärmen blivit skarpare och hårddisken större

Det är när jag spekulerar kreativt utåt bra att komma ihåg att min vetskap databaser snarare än hash-funktioner, kataloger (typ Open LDAP) eller för evigheter sedan fil-databaser via radnummer respektive:

LIST RANDNUMMER

på Commodore 64 någon gång i årskurs fyra när datorernas sanna små-defekta natur inte doldes lika smygande riskfyllt som idag: Ex. databas genom att lista "programkod" - lika gärna text eller annat data så länge man inte kör koden som BASIC II. Istället listade man programmet - eller en del av programmet där datat fanns men som ej kördes just för dom raderna. Ex. LIST 3210 - 40000. LIST liknar hemvant trevliga goto men var sundare strukturerat genom att utnyttja entydiga nummer istället för dom kvalitetsprobglematiska labels vi säkert alla gärna förfaller till likt abc, donxt, do_next en bit nedanför med svårbegriplig beräkning mellan förändrande värde, odd_erorr, debug_but_do_not_remove_it m.m.) syntax för att ta ut en datapost från dess början på rad enligt första numret till dess slut på den andra siffran - plus så klart för stora databaser behov av att ladda in grupper av poster från olika delar på kassetband utiliserande s.k. "spolning" / "att spola fram eller bak bandet§" - eller rent av krävande många kassetband) är så begränsad men dessa tre tillsammans gav mig en känsla av att jag sådant som Berkeley DB borde vara begripligt för mig. LIST är heller inte olikt hur många idag gör lookup från indikation vi vill fråga med (ex. URL eller sökord) till radnummer i enorm fil där själva datat för sökord eller URL ligger lagrat (och så klart snabbare i absolut-mening idag jämfört med C64 men inte mycket högre relativ prestanda).

Stora nycklar en aning mer kostnad ibland för-sortera men ev. högre prestanda skapande databas

Något besläktat - kanske relaterat implementation på vad - ges här också StackOverflow: BerkeleyDB - implications of incorrect sorting order? (via cache-Google: ibland når jag ej StackOverflow vilket jag trodde berodde på att jag råkat spindla deras kategorier hårdare än korrekt programmerat för statitistiskt analys av inlägg men ganska ofta fungerar den så ev. relaterat någon defekt på Stackoverflow kanske relaterat last så jag länkar indirekt istället och tror ej det tolkas av spindlande entiteter som problem prestanda eller tillförlitlighet med sajt länkad). Om det egentligen stämmer som skrivet ofta eller alls vet jag inte.

Vad jag märkt är emellertid att ingen kostnad för mig existerar av att använda större nycklear (undantaget ev. ökad risk för kollisioner och hantering av det: men jag vågar gissa att vettig hash-funktion används och om så troligt föga problem). Och längre nycklar om en mappning mellan nyckel och position (snarare än jag hade föreställt mig motsvarande MD5 - jag vill gissa att föregripande lookup-up till värden från nyckel finns och att hasching kanske ej görs till en redundans-reducerad form som för MD5) finns motsvarande "komplexiteten summerad" nyckel innebär det ju mer exakt vetskap om relativ positionering. D.v.s. kommer fler entiteter gå in och vi tar in dem i chunk vettigt urtagna innan sorterade föreställer jag mig att det kanske tvingar upp lite vettigare initial hantering föreberedande för att mycket kommer in. Jämför att sortera:

AAAAAB AABAAA br/> resp br/> AAAAAABAAAABBBBAAAA AAABAAABAAAABBBBAAAA Eller motsvarande mina nycklar datum och tid publicering, länk indikerad övergripande RSS eller ATOM "sajt", domän uttagen över inläggen för resp. länk till inlägg (d.v.s. kan vara annan än sajt), titel på sajt indikerad, titel inlägg, resp. hela sökväg feed där data hämtades (ej exakt i samma ordning mot mitten ev. samt inkluderande en till indikation om källa i URL-mening). Poängen längd ligger i att gå över alla nycklar utan hänsyn dimensioner för annan lookup för enklare förändringar, kontroller m.m. där allt nödvändigt för mycket finns direkt för varje nyckel (ex. för en del underhåll kontrollera om ett datum finns eller ex. som nyligen defekt-data ej önskat som läckte in: <![ eller liknande ibland förekommande i RSS-strömmar ev. för "sekundärt" data-relaterat innehåll (just här för sajt-länken för ganska många vilket missades vid skapandet).

I en värld där resp. två nycklar för de två grupperna egentligen motsvarar samma nycklar men där de första kommer ge fler kollisioner tvingande fram att append görs för resp. om plats finns, och när plats lokalt i filen där lagring redan skett saknas tvinga fram en pekare till nytt data allokerat på disken eller värre (ej kanske otroligt givet prestanda kostnaden jag fick tidigare) att data flyttas om ständigt görande att en ny växande jätte-fil behöver lagras gång på gång för varje 80 MB med exponentiellt växande tid för det eftersom komplexiteten att göra det ökar när resp. omflyttning kan inverka på nästa omflyttning. Om nu den Berkeley DB implementation jag fick via Perl (eller om den ligger ovanpå något i Linux) är riktigt dum kodad (elegansen i Berkeley DB är ju att det är enklaste tänkbara så mycket möjligt förväntas förståelse och ansvar hantering liggan ovanpå).

Tänkbart faktiskt en tids-kulturell-atavistisk företeelse. Berkeley DB har ju funnits så pass länge att problemen och utmaningarna när etablerad var mycket annorlunda: RAM-minne relativt litet (men kanske problem-baserat jämförbart) men förr var hårddiskar som nu inte mer eller mindre kostnadsfria om man inte behöver lägga på mer än några tera byte. Ev. lite default optimerad för att ej börja med att skapa en rimligt tilltagen fil (kanske konfigurerbart men jag såg det ej via Perl gränssnitt i DB FILE och utan att kontrollera konfigurations-loggar vet jag ej om jag installerade på något kompletterande).

Appendix A: Design pattern sortera nycklar i två enkla steg

Pre Berkeley DB power sorting:

1. Ta ut nycklar från mellan-lagring i Perl's vanliga hash-tabell. Exempel:

my @keys = keys %ldb

2. Sortera nycklarna. Exempel:

@keys = sort @keys;

Och stoppa in i Berkeley DB via lämpligt för det. Glöm inte att synkronisera mellan-lagrat data i sista steget. Vi antar att vi stoppar när överskridande viss storlek med målsättning att söka göra det med så stora chunk i taget som möjligt för att inte Berkeley DB ska allokera onödigt små-utrymmen i varje steg givet att om inte allt data redan är sorterat gäller att en del omflyttningar eller vad Berkeley DB nu gör behöva ske. För mig cirka 900 000 blogginlägg med RSS-meta översatt till trevlig CSV-fil (som vi i en rimlig värld hade haft direkt på webbsidan istället för SGML-rekursionens onödiga komplexitet praktiskt oavsett hur elegant språkteoretiskt). EFtersom blogginlägg kan komma från entiteter vid en tidpunkt efterföljande vad vi stoppar in idag okänd gäller att inlägg vi ska stoppa in ofta nog i perioder när tidskostnaden kan ha betydelse (d.v.s. spindlande ifatt internet där jag just nu ett tag expanderar antalet entiteter publicerande med cirka 50 000 till 100 000 per 24 - 36 timmar men räknar med att stoppa det om en eller ett par veckor) vara äldre och ej följande logisk ordning i övrigt samtidigt som jag tyckte det mindre tilltalande att försöka lägga till en bokstavsräknare initialt eftersom jag gärna vill kunna ta ut alla nycklar optimerat i meningsfull ordning att se ungefär var saker befinner sig i tiden vid underhåll o.s.v. via snabbtitt skärm.

Betryggande nog när vi står kvar på en robust gammal välkänd komonent är den välanvänd av andra gamla lösningar man känner igenom sedan snart 20 år. Ett fåtal från Wikipedias längre lista:

"MySQL database system – Prior to v5.1, MySQL included a BDB data storage backend.
OpenLDAP – A free/open source implementation of the Lightweight Directory Access Protocol (LDAP)
Postfix – A fast, secure, easy-to-administer MTA for Linux/Unix systems"

Även om det får erkännas att min lilla praktiska erfarenhet av MySQL och Postfix var en brutalt plågsamt fascinerande verklighet: Så slött saker kan bli med eller utan på det Apache resp. karttjänster ovanför. Men OpenLDAP är ju bra även om det var ett antal år sedan jag gjorde något med den. Och menar - det kan kanske diskuteras - Wikipedia dessutom något färskare news-fresh:

"Bitcoin - A distributed peer-to-peer open source digital currency."

Fortfarande lite små-coolt att skapa stabila stengolv med Berkeley DB hellre än något vulgärt IKEA-färdigt golv som limmas eller nitas. Riktiga värden som håller många år byggs med stenhacka och förståelse av problemen man vill lösa med att bygga golv.

Tidigare från samma domän av stegvis kreativt skapande för undvikka samma välkända strunt-problem i datan nu som på 1980-talet

Som Rebel-AS levererar sin lösning till:

1. Steg I: Behovet av praktisk big-data utan mina enkla ganska brutala ta in och ut ur minnet läsande data uppdelat i mindre filer resp. den gamla Berkeley DB lösningen där ingen databas praktiskt gick att ta större än 80 MB (d.v.s. samma problem praktiskt ungefär: många fil-accesser, opraktiskt att strukturera, och ordentligt med extra-logik i koden). Men eftersom vi är i domän av databaser blir det ändå segt eftersom jag varken kan eller vill lära mig teorin för dem. Varande så inarbetat sedan år borde det tycker man bara fungera.... Likt hash-funktionen i Perl.

• NoSQL och Sun's och övriga hårdvaru-inriktades problem att orka med dom teoretiska utmaningarna vi alla behövt sedan år (2013-09-02)

Plattform jag reflekterade som tänkbar lösning: Mongodb.org. Huvudsakligen därför att den av flera indikerades snabb och endast i föga läsande dokumentationen verkade ha "överdrivna databas" relaterade funktioner: enkel och begriplig närmare hash-funktioner jag ju redan tycker mig kunna. Mindre risk onyttig inlärning. Och startade smidigt dessutom. Men hade fodrat ny installation Ubuntu om praktiskt funktionell vilket just nu ett tag är opraktiskt på utvecklingsservern.

Och diverse små-tester, läsande m.m. resulterar slutligen i att jag väljer samma teknik-plattform som tidigare förutom att skärande cash-logiken för parallell också utan Berkeley DB (användes uteslutande för similarity beräkningar mellan koncept där cirka 900 MB - 2 GB förberäknade värden fanns mellan koncept vars similarity oftare var efterfrågade eller förväntades vara det: dessa tar annars upp till för värsta tänkbara om gjord med hög exakthet närmare 20 minuter - och för aktuell version Blue light gällande i denna lösning fanns cirka om jag minns rätt 10 miljoner relationer bedömda troliga över cirka 140 000 existerande koncept jämfört med nu några miljoner koncept och ett okänt antal relationer troliga att återkommande behöva ta ut likhet m.fl. operationer applicerade för inkl. nu att fler resp. större andelar av vikter använda ska beräknas kontinuerligt uppdaterade vilket expanderar upp data tvingat via cash än mer så att det kan göras u bulk ett par gånger pe rdag - hence att databas-problem blev löst trots databas-fobi).

• Riktad sampling Blogger för ökad tillförlitlighet (och pågående unikt problematiskt internet från min accesspunkt) (2014-04-21) (och Google: Feedburner, Youtube och Feedproxy.)
• Resultat spindling efter RSS- och ATOM-strömmar (2014-04-27)

Mycket typisk mänsklig problemlösning i den ena av två grova grupper kreativitet vi kan se. Här stegvis-förändring sökande behålla värde vi har (eller ofta nog slippa lära något nytt). Äldre mer erfarna kan prestera väl i företagsutveckling i denna domän. Vanligt i antal nya företag ovanför detta är konsultverksamhet byggande på upparbetad vetskap om en form av problemlösning eller förståelse av en verksamhet. Den andra domänen är innovation i emergence skapande något radikalt nytt.

Säger vi att emergence är kontextuellt beroende utifrån ett perspektiv - här jag om tvingad att behöva lära något externt system nytt för mig resp. behöva plåga mig med att sätta upp nya version Ubuntu och ett ganska komplext legacy-system liggande ovanpå: ny kunskap, nya komponenter adderade och inte otroligt nya värden svåra att förstå från Berkeley DB perspektivet - har vi ex. när en metod från ett annat expertområde inses optimera i ett annat eller när en upplevt ny upptäckt kommer (för vilka ofta gäller att olika individer oberoende i vad ytligt uppenbart gör samma upptäckt ungefär samtidigt i tiden d.v.s. latenta faktorer existerar). Tidigare diskuterat många gånger även nyligen i år Emergence relationer - Emergence demokrati (2014-04-21). Innovation via emergence är ibland oftare lättare för yngre: de kan ju föga från början och har inte lärt sig hur det ska gå till att hämta upp data lagret (kanske inte ens hört talas om X.500, LDAP eller MD5).

Lite som att redan förstå varför allt i datat alltid ställer till med små-problem och hur vi ungefär löser det. Relativt att söka en ny givet viss tid mellan inlärt problemen och nutid möjligt bättre lösning kanske genom att elt undvika problemen.

• Minimalistiskt sido-algoritm-skiss beräknande läsare nyhetsmedier (2014-04-30)
• Minimalistiskt sido-algoritm-skiss beräknande läsare nyhetsmedier II: Algoritm omvandlande tidskostnad referera nyhet till förtroende publicist (2014-04-30)
(Och mer kompletterande de sista snarare än just relaterat lösning i problem-domänen för mig varande vad inarbetade algoritmer med föga behov förändring finns för: arbetet här och relaterat har mer att göra med att ta saker större i antal koncept vi förstår och ser, mängden statistik relationer, antalet publicister hanterade, antalet "skrivande läsare" analyserade o.s.v. för vikter diskuterande rörande ungefär emotionell intensitet: Att välja mellan kontext och känsla vid betraktande av "minnen" (2014-04-20) i mening att göra referensen begriplig ungefär vad avsett).

Minimalistiskt sido-algoritm-skiss beräknande läsare nyhetsmedier II: Algoritm omvandlande tidskostnad referera nyhet till förtroende publicist

Eftersom jag behövde strukturera tankar lite till fortsatt Minimalistiskt sido-algoritm-skiss beräknande läsare nyhetsmedier (2014-04-30) och ej algoritm eller område jag bedömer centralt för mig (en liten nödvändighet bäst hanterad enklast möjliga). Givet att jag valde att utnyttja relationer via äldre men inarbetat etablerad och snabb för analys länkar kan den troligt intressera en del.

Eftersom jag för ett antal i ev internets subkulturer förnöjelse (strävar och hoppas jag liksom alltid: läsaren är vår ledstjärna) pekade på motsvarighet i klassiska SEO-koncept rörande association koncept till domän relativt undersida resp. väg dit från donerande noder med text och länkar i föregående avslutade jag skissen med att göra det samma (och en av de föregripande faktorer jag tog hänsyn till för att förebygga problem från när de av och till görs lite väl stort). Jag citerar ut det direkt här men ligger i övrigt:

1. [Läsarens egen] skriven text [där denne länkar].



1.1. "Medelvärde" (i bäst fungerande variant fortfarande snabb) funktion av BLI, PA och textens längd. Högt värde är HÖGRE ***kostnad tid***. Komiskt kan vi föreställa oss Obama görande tidskostnad att leta upp lämpligt udda law domain termer ingen hederlig datorarbetare hört talas om (och lika otroligt för dessa en typiskt medborgare).



2. Indikerat "läst" ej news provider.



2.1. "Medelvärde" (i bäst fungerande variant fortfarande snabb) funktion av BLI, PA och textens längd. Högt värde är MINDRE ***kostnad tid***.



2.2. Praktiskt måste dessa tror starkt för god prestanda skattas från lämpligt medelvärde öve säg news providers istället.



3. Hantering ett par förekomster som kan störa:



X.1.1. Jämför "godtycklig" social eller "easy trade" länkning. Görs ofta nog snabbt d.v.s. tar ej tid från att läsa nyhet.



X.1.2. Jämför advancerad easy trade med anpassad given text kanske unik. Här ligger oftare komplexitet högre d.v.s. tar tid från övrigt reducerande ev. störning av säg news providers länkade riktat eller för taggign / länk-kontext.

Vidare för att ge ett exempel motsvarande vad som noterades särskilt relaterat SEO föregående motsvarar mitt gamla koncept (från säg 2006) om ambassader i sociala media eller vilka som helst samhällen på nätet bundna till en nod vi enkelt kan särskilja (d.v.s. typiskt minst ett domännamn och ibland pået mindre grupper). Vi kan ex. se hur Vitahuset (kanske också för rättvisa mot olika ofta amerikanska företag) lokaliserar sig i ganska många motsvarigheter samhällen. Motsvarande företag p.s.s. ger det möjlighet att möta samhället där de oftast här och ofta nog viktigare praktiskt finns relaterat innehåll när samhället söker det lokalt eller reagerar och uttrycker om företaget, organisation o.s.v. En inarbetad väg att tala lokalt vid behöv. Skillnaden relevant här som ex. finns där mellan default-publiceringen t.ex. samma filmklipp på resp. video-social-media-sajt (Youtube, Vimeo och jämförbart) resp. när reaktionen är riktad eller en meningsfull reaktion lokalt. Och för default-publicering om denna är direkt associerad till samma entitet eller uttrycks för ett antal olika entiteter där det senare kan indikera bl.a. "spam", behov av anonym publicering andra orsaker, eller något viralt.

Jag engagerade mig inte i att korrekturläsa det. Ingenting jag vanligen spar utan uttrycker i kod resp. samhörande kod när det prövas ut. Mer av en tankeprocess samt för att reducera risk att göra kod initialt "lite för bra" med något onödigt i tidskostnad utan att leverera värde i domän intressant övergripande. BLI avser Blue light intensity. PA avser sannolik for ett koncept (av totalt några miljoner ngram som erkänns existera) och här ev. snarast först uttryckt till vad jag brukar kalla WP vilket "förvandlat" sannolikhet för ett tänkt kontext-löst värde till en vikt man kan räkna med efter behovet i algoritm (här vill vi förslagsvis antagligen kunna summera sannolikheter för koncept i en text vilket för PA inte har någon egentlig vettig betydelse i sannolikslära: ett logiskt alt. till WP eller anvnt WP är entropi men applikationer nära nog just som tänkt nedan brukar det prestera sämre än en del andra lika enkla alternativ).

3. För resp. diskret tidsfönster - förslagsvis tillsvidare ett datum utan
överdriven hänsyn tidszoner (finns i news id) - fördelar vi skattning tid
utifrån den explicita snabba relations indikator utvald här:



3.1. Indikation mot en större grupp ej självklart förstådda sajter men saknade
snabbt kontrollerade parametrar överrensstämmande med övriga: Antags vara
shopping. Shopping kommer med en tidskostnad vi skattar från en filosofisk idé
om att de läser (eller lyssnar på någon d.v.s. social time cost). Eftersom
jag för första version big slow change stat. valde att ej göra mining på
Amazon review eller liknande känns rimligt givet inexaktheten hur som helst
samt [Små censurerad för läsarens bästa.].



:::: Negativt verkande tid kvarstående att läsa new entity.



3.2. Blogg-länkning, tweets m.m. antas socialt. För kors-blogglänkning ändras
det kanske senare men just nu ska de ju ändå inte hanteras gissar jag (beroende
på om det känns att skapa upp det i Rebel-AS.



:::: +/-. Social aktivitet. Vi ser gillande på att läsare som fokuserar
på sin core function men bestraffar inte sådant vi vet ej påverkar
kostnad läsande en tidning tryckt eller på webben. Ofta nog har de ju
trots allt inte annat än vid diskret tidpunkt eller några läst utan
varit sociala (eller gjort trade i andra dimensioner).



3.3. Wikipedia eller jämförbart. Kan vara "tagging" i vilket fall det förekommer
med news provider. Annars är det en tidskostnad. Allt länkat uppvisande trivial
form text samt refererar något publicerat vi saknar stämplat själv uppfyller
detta.



:::: Stör läsarens core-business. Negativt verkande tid att läsa
news entities. Kostnad tycker jag känns rimligt att beräkna med samma
funktion som för news entity tillsvidare.



3.4. News entity för gammal. Räknas tagging. Ingen tidspåverkan.



3.5. News entity i fönster. Tidskostnad enligt enkel funktion.



3.6. Läsande sig själv. Tidskostnad enligt samma funktion.



4. Enkel funktion tidskostnad.



4.1. Läsaren börjar för varje diskret tidpunkt med tillgänglig tid 1 HH-TIME.
Allas HH-TIME är olika men för en population är det endast mycket långsamt
föränderlig. Troligt 3D normalfördelad vilket vi hanterar indirekt.



4.2. Tidskostnad beräknas från komplexitet för aktuell text given.



4.2.1. Kostnaden faller enligt en exponentiellt avtagande funktion utifrån
mängd för parametrar indikerande kostnad som summerade för hela texten. Ex.
tänkbart.



1 komplexitet
1 kostnad

2 komplexitet
1.5 kostnad

3 komplexitet
1.75 kostnad

4 komplexitet
1.något en kvinna eller färgad med moraliskt
ansvar att hantera matematik negativa stereotyper
borde huvudräkna åt mig men vi avstår från som
primärt ett politiskt ställningstagande och
sekundär av mindre [Uppenbara] orsaker [Roar föregående läsaen: här
eg. att jag är föga bra på att huvudräkna och varande man ej behöver känna motivation att motbevisa
det för att reducera påverkan av negativa stereotyper rörande
kvinnor och matematik.]



4.2.2 Kostnadsparametrar kan man tänka sig tas med något läsbarhetsindex men
jag tror mer på att göra något själv som jag är van att se på text.



4.2.2.1. Vi önskar ej utnyttja DO och DESCRIBE över text. Kostar beräkning.



4.2.2.2 Längre text tar längre tid att läsa. Men köper vi bok och ska välja
läser vi inte hela boken i bokhandeln. Så vi bottnar ut ungefär i tidskostnad
med en typisk Reuters nyhet d.v.s. ungefär som baksida på en seriös bok.



4.2.2.3. Låg BLI bör i dessa sammanhang oftare vara dyrare. Det stämmer mindre
i allt vi ser som DESCRIBE sannolikt med cue-aktivering. Samma resonemang går
att ta för PA såväl också inarbetat jfr utnyttjande thesaurus och def. ordlistor
för de enklast sim sakerna folk gjort längre bak när data var mer färskt kring
sådant i datamedier (men ej hos mig med något enstaka undantag för småsak kanske) n i ngram.
Men skummar man tror jag nog det sista ej är avgörande och ovant för mig struntar
vi i det. D.v.s. ju större som funktion av BLI och PA över text desto mer tid
investerade läsaren (i en annan värld än den annat än ett få tag likt jag bor
i) eller alt. egentligen läst väldigt lite av den (för vår stereotypiska
läsare).



4.2.2.4 Ju mer "emotionell potential" desto troligare p.s.s. som ovan men för
resp. riktning omvänt. Eftersom konvergerad DESCRIBE -> DO transformation av
den samma ej är gjord bra (för få nyheter i förra krävande massor om meningsfullt
över då bara cirka 140 000 BL-koncept) struntar vi i denna. Alt gör projektion
nu ev. dumt till 1gram.



4.3, I Sammanfattning enklast tänkbara start variant:



*) Total mängd BLI för DESCRIBE.

*) Total mängd PA för DESCRIBE.



*) Ev. med därefter hantering rörande länk på text. Det är eg. onödigt
förutom att vid optimerad hantering vill vi kanske få viss naturlig
filtrering här mer att göra med att vi ej överanalyserar säg struktur.



*) Korrigering. Vi är tror jag ev. tvingande att hantera storlek:

- Givet. För riktiga nyheter snarare än bestraffning skillnad
vad som exporteras av DESCRIBE via optimerad kanal hämtande.



Det tycks vettigt att hantera det enligt välkända funktionen för det
från inverse-tf funktionerna. Den enklaste mest välkända har jag mycket
god erfarenhet av. Den fungerar bra just för denna skillnad (d.v.s.
man accepterar att man väljer att ej dra nytta av större DESCRIBE vilket
är rimligt här).



4.4. PROBLEMET KVAR:



4.4.1. Föregående fungerar perfekt för vad vi accepterar som godtagbara nyheter donerande
kraft till dem. Men vill jag egentligen sitta och spindla ner hela webben
för varje länk-referens? Nja. Istället tillsvidare - och sunt för att förebygga
atavist-risk - tar vi säg medelvärdet av 4.3. (undantaget läsa eget skrivet
som vi ju har).



4.4.2. Fördelning mellan indikerat i samma enhet analyserad. Jfr resonemang
föregående rörande enklast initiala form (som jag tror kan räcka också fortsatt
länke) för att reducera risk för atavistiska strukturer störande prestanda
eller introducera udda fel betraktar vi om det tycks praktiskt funktionellt
varje tidsfönster som en samlat enhet. Ev. går detta sämre eftersom det kan
vara brutalt snabbare att bara gå över alla newsid's direkt i Rebel-AS föregripande
eller görande tillstånd onödig alt. sparande extra referens till resp. sådan.
Jag tror ev. kostnad tillstånd är olämplig att försöka komma ifrån. Ev.
news-headline-app eller dyligt kan annars göra saker tämligen underliga om de
råkar tas upp i ström underligt.



4.4.3 Fördelning mellan resp. referens indikerande för oss att de menar sig
ha läst något är icke-trivial. Emellertid gäller:



4.4.4. Känd content-summary pressmeddelanden och news-fire ger oss initial
mening i Describe resp. första andra stycket. Delvis kulturellt skapande av
dessa tror jag. Resp. för närminne rörande list-innehåll har motsvarande
d.v.s. boost-tidigt samt dessutom boost det sista d.v.s. motsvarande redaktionellt
knorr. Korrekt spekulerar jag bör tidigt och ev. sista värderas högre. Praktiskt
tillsvidare värderas första till news-provider och övriga i samma betraktas
endast som tagging (d.v.s. ej kostnad de senare: läsaren antas endast läst
det första och sedan Wikipedia länkat lite p.g.a. ex. en tro att de flesta
i övrigt inte helt lärt sig att slå upp i Wikipedia eller liknande lika snabbt
som att följa länkar ofta bara med ankartext utan indikation var man hamnar
eller alt. sorterande för egen del eller hjälpa tredje-generationens sökmotorer
vi har förfallit ner till tagande värde där länk-struktur troligt räcker
excellent sparande beräkningstid analys implicita relationer eller än värre
göra NLP på det hela m.m.



5. Step by step.



1. Egen skriven text.



1.1. "Medelvärde" (i bäst fungerande variant fortfarande snabb) funktion av
BLI, PA och textens längd. Högt värde är HÖGRE ***kostnad tid***. Komiskt
kan vi föreställa oss Obama görande tidskostnad att leta upp lämpligt udda
law domain termer ingen hederlig datorarbetare hört talas om (och lika otroligt
för dessa en typiskt medborgare).



2. Indikerat "läst" ej news provider.



2.1. "Medelvärde" (i bäst fungerande variant fortfarande snabb) funktion av
BLI, PA och textens längd. Högt värde är MINDRE ***kostnad tid***.



2.2. Praktiskt måste dessa tror starkt för god prestanda skattas från lämpligt
medelvärde öve säg news providers istället.



3. Hantering ett par förekomster som kan störa:



X.1.1. Jämför "godtycklig" social eller "easy trade" länkning. Görs
ofta nog snabbt d.v.s. tar ej tid från att läsa nyhet.



X.1.2. Jämför advancerad easy trade med anpassad given text kanske unik. Här
ligger oftare komplexitet högre d.v.s. tar tid från övrigt reducerande ev.
störning av säg news providers länkade riktat eller för taggign / länk-kontext.



4. En till störning i co-locomotion - om vi för de plattformar avsedda i första
hand denna mining har motsvarande Twitter volation med plötsliga stötar - är
ej i hantering indikerat föregående. Men samma avtagande expoentiell form är
att förvänta men där vi nu betraktar distans från normalt tillstånd. I en
artikel tyckte jag mig uppleva att de fick motsvarande en exponent 3/2 men
läste ej nog för att se direkt motsvarighet. Praktiskt från vad jag minns av
news events är emellertid tids-längden inverkande såväl som mängden news providers
deltagande i event. Optimerad förenklad sannolikt överskådlig tid sannolikt är
att istället sätta hantering i den temporala dimensionen för diskreta tidsfönster
d.v.s. effekt vid en punkt avtar övertiden och ska helst avta mer när avvikande
innebärande att för etablerat förändrlig vikt kan varje inverkan på vikten
tror jag - och kan ha algoritmer för det i besläktade områden - beräknas direkt
från avståndet värde snarare än det faktiska värdet gående igenom reduktion
exponentiellt.

Sista April Uppsala: Flykt disk, eldsläckare, eldstålets gnista, pistolen och den tibetanska sensmoralen

1. Tools of the Trade: När elden kommer

Brandsläckare kommer raket träffar i närheten av datalager men ogärna om brinnande nära (pulver- och vatten-släckare är nog lika problematiska). En del år tycks det beskjutas. Möjligen något religiöst extremistiskt och tänkbart kristet och varande gender-politiskt i svenskt tradition efter reflekterande efterföljande forskning som indikerade att viss tro kan vara bra pagan tillbedjande gudinnan har jag väpnat upp mig.

Mer avskräckande snarare än nödlösning är det även förberett med eldstålet. Eldar man upp mina hårddiskar kanske jag kommer över och slår gnistor på fiendens hårddisk. Vidare viss mängd vatten om det går fel mer tillbaka riktat.

Kultur-atavistiskt såväl som mer eld-relaterat hade så klart ett spjut gjort hårt med eld. Samtidigt behöver man bibehålla viss realism och tänka praktiskt såväl som att ej onödigt divergera mellan det i information elegantare och konkret verklighet (jag vill t.ex. inte ha på ansvar att någon ger sig på att försvara sig vid beskjutning med ett spjut: det är viktigt att minnas att man är föredöme för en försvarlig andel av befolkningen).

2. Korrekt eld-relaterade skämt

I all sanning alltid gällande:

"Jag tog förövrigt inte med först tänkta algoritm nedan. Texten var endast för att tänka så när utgångspunkten tänkt avslutades det. Ev. kan jag av en del upplevt förolämpa läsare som skrivet. Det för de som de berör ska inses för uttryck för en hos dem mycket osäker självbild snarare än något besläktat hos mig. Riktigare ska förstås som en hyllning till läsarens visdom varande alltid min ledstjärna här i livet. "

Från: Minimalistiskt sido-algoritm-skiss beräknande läsare nyhetsmedier (2014-04-30)

Och med läsarens nöje styrande allt här korrekt för högtiden eld-relaterade skämt.

`

2.1. Anpassat Dalai Lama tänkande: Leende mot fienden.

2.2. Tibetanskt kärnvapen. Alla tillsammans hemma i Tibet.

I någon mening illustrerar resp. skämtteckning problematiken i effekt rörande självmords-eldandet: Det tenderar - lämnande övriga invändning - att ge reducerad effekt när tillämpat minst sagt ofta och regelbundet. Och en personlig verkan av det är att jag inte upplever något problem att göra skämtteckninganra vilket jag inte kan se överhuvudtaget hade varit möjligt 2010 - 2012.

• Att motverka "tända eld på sig själv" subkulturen: Positiva åtgärder (2012-02-02)
• Himmelska fridens torg: Diskussion metodgrupper riktad information för konkret värde resp. risken att tappa värde redan byggt om moraliskt defekta metoder används (2013-10-28)

Irlands längtan tillbaka till tryggheten i Storbritannien

Kan vi uppleva från deras hemsida:

Och lika intressant har vi tre från kulturområdets (jag vill inte skriva England eller något associerat men vi har åtminstone det som gemensam nämnare) mycket välkända stycken revolutions-musik.

Ye Jacobites by Name jag fann intressant i den humoristiska varianten. Medan jag tror jag kan ha uppfattat den första som på pro-jabote men ev. fattande den fel (lyriken framförs inte i någon version jag hört spelad för mig i allt riktigt tydligt rörande uttal relativt min motivation utanför själva upplevelsen) Humoristisk version här: Humoristisk anti-separistisk musik-lyrik: Skottland under jakobinernas och the Pretenders tidsålder. Inte helt olikt Irland upplever jag här viss ambivalens upplevande en ytlig preferens både för jakobinerna och England men mindre vetande just om Skottland.

Från tiden föregripande den Sydafrikanska befrielsen. Även om nu inte Storbritannien bär särskilt ansvar för förtrycket i Sydafrika ligger åtminstone polariseringen föregående någonstans såväl som styrande att lyriken nu är skriven just på engelska.

Annorlunda från resp. variant i har vi så vitt jag vet inte någon pro-engelsk-variant av pro-(vosoriska)-irländska:

Upplevd ambivalens när etablerad sedan evigheter tenderar gärna att kvarstå en evighet till. D.v.s. i konflikter tenderar just det volativt konflikt-uttryckande inte skrämma iväg dom andra utan är oftast mer av att göra vad resp. tycker speglar vad den andra gjort och utan att egentligen någon behöver ha fel i det skapar eller predikterar det lika rätt den upplevda orsaken.

Ett enkelt samband som emellertid inte just gör problemen enklare att lösa genom att de i mycket är mindre "ockuperande" hjärnans mer rationellt tänkande delar med istället kraftiga upplevelser av relativa (ex. ned i en riktigt föranledande försök att göra ner på dom andra) flock-värden (se t.ex. från 2011 Online social network size is reflected in human brain structure, Proceedings B of the Royal Society).

Men även om amygdala är associerad till dessa områden är sådana uttryck i sig ens när de är välutvecklade till direkt imponerande social graf-intelligens inte vad som säger något om reflekterande intelligens utan lika gärna att båda kan vara potenta bedömt från några möten individer presterande väl i båda områdena om än inte i konflikt-doäner och därav att jag ibland kallat det the LF projection efter LF som inte minst hade en vitt-spännande socialt nätverk på "nätet" år innan internet såväl som en ganska imponerande matematisk och liknandeinvolverande räkna som fysisk intelligens - lämnar vi matematik, fysik och BBS:er och återvänder till Nordirland ser vi samma motsvarighet som potentiellt problematiskt på resp. sida givet att analytiskt intelligens tenderar att lätt bli verktygs-betonad fokuserande på vad emotionellt upplevs värde-stort även om det senare i sig är irraationellt - och projektion från att uttryck i känslor tenderar att vid förändring tillstånd reducera information till en samlat upplevd "vikt" utan kvarstående detaljer).

Minimalistiskt sido-algoritm-skiss beräknande läsare nyhetsmedier

Och kärnan i vad det syftar till är ej predikterande läsare i morgon eller längre fram utan läsare samma dag eller rimligen nära i tiden föregående.

Sista punkten är möjligen upplevt intressantare av en hel del från annorlunda (men besläktade) perspektiv och jag tar ut den direkt. Samt adderar en visuell illustration av vad som ibland är ett besläktat fenomen (men som jag ej vet om det är fallet just med ex. jag råkade träffa på igår). I visualisering tänker vi oss att en konceptuell rymd blivit associerad till själva domänen vilket gör att individuellt data där publicerat tenderar att gynnas åtminstone när domänen i sig är sitt eget rum. Det är när så direkta motsatsen till egenskapen önskat för den typ av samplingspunkter indikerade i punkten. Frågeställningen - det potentiella problemet oavsett visuell illustration eller användning indikerad i punkten - är att associationen avser tjänsten som sådan för domänen medan innehållet ej nödvändigtvis är relaterad denna.

"2.0 Och självklart - färre inte fler - avgränsade habitat läsare för mining är bättre. Medan i övrigt förvisso en del fler krävs men ej stora där det kritiska för dessa endast är att fånga när något uttrycks brett utan rimlig varians över resp. habitat. Hence det mest exklusiva är självklart att själv kontrollera ett habitat om man grundläggande är mycket beroende av denna typ av nod-relations information medan vi här klarar oss jämförbart bra med tillgängliga utan att ex. känna behov av att försöka hitta pengar nog för att köpa Wordpress.com, Blogspot.com eller liknande inte helt olikt vad primärt tänkt här."

[Red. Referensen köpa Wordpress.com ska inte förstås som att det är ett tänkbart alternativ utan mer humor kanske. Jag har flera gånger genom åren försökt övertyga Matt m.fl. jag upplevt associerade redan utan att lyckats. /HH[]

Google.com: Illustration punkt 2.0. Association (tänkbart) mellan domän och sökords-clustren relaterade sökningen påverkande undersida visad och relativt konkurrerande undersidor samma domän resp. andra domäner.

Komplettering: En komisk detalj är att oavsett hur föga läst ett tydligare tråkigare inlägg mest skrivet för egen bearbetning typiskt är gäller att nära nog hur föga indikerat eller undangömd en sido-notering relaterat SEO är i det tenderar det att ge viss mycket enkelt mätbar reaktion under en efterliggande period av upp till cirka en månad. Av det förstår vi att den enklast mest framgångsrika webbaffären enkelt tänkbar är den som ger användaren läsare (jämför ex. med just Google) eller motsvarande internet-värde (ex. editor / skribent status i Wikipedia). Därmed inte sagt att det just är en metod att lära känna någon eller något nytt på internet :-)

Jag tog förövrigt inte med först tänkta algoritm nedan. Texten var endast för att tänka så när utgångspunkten tänkt avslutades det. Ev. kan jag av en del upplevt förolämpa läsare som skrivet. Det för de som de berör ska inses för uttryck för en hos dem mycket osäker självbild snarare än något besläktat hos mig. Riktigare ska förstås som en hyllning till läsarens visdom varande alltid min ledstjärna här i livet.

Vidare föranledande mini-alg.-kompletteringen är att antalet entiteter hanterade i mening att innehåll hanteras in i datalayer expanderar kraftigt vilket gör mappning mot läsare via andra metoder ganska begräsnat (resp. p.s.s. görande approximationen att värdera varje publicist snarare än läsare som ett mindre funktionell vilket tillsammans med andra viktsystem är funktionell "ner till" cirka de 10 000 - 15 000 största nyhetsmedierna på engelska).

1. "Easy" news-entity trust



I proof-of-concept motsvarande "fysikernas" lilla konstant men i FL ett eget
universum. Vi gör här något mer sofistikerat men ej överdrivet och utgår från:



1.1. Särskilda på domän identifierbara kan antas i rimlig utsträckning
representera: En individ.



1.2. En individ har per diskret tidsenhet betraktad en viss tid denne gör vad
läsare bör göra.



1.3. Individ kan dessutom söka för byggande referens-vetande eller ofta nog
argumentation eller illustration om uttryckande.



1.4. Vi är endast intresserade av det första för tänket här men ser det senare
ej som särskilt filtreras i någon textanalys-mening.



1.5. Vi identifierar läsande och därefter baffled, sur, utiliserande i
low-impulscontrol, larmande eller liknande typiskt i sig onyttigt beteende
läsaren gör genom att betrakta tidsfönster.



1.6. Potentiell risk tidsfönster är auto-publicerande där jag är osäker om det
är en läsare eller ska bort. Ev. kan jag sätta en brutal snabb id för identifikation
och innan för läsare habitat filtrera bort uppenbart förkortade strömmar
(filtrering naturlig för vad som är planerat att utilisieras).



1.5. Här - helt tänker jag i analys separerat projection describe -> do - är
vad läsaren säger ointressant. Kritiskt dock:



1.5.1 Att dimensioner till news-id i HH-NOSQL ger lookup per genuin
länk. ID i sig fick det ej och de känns redan ganska långa även om jag
inte vill utesluta att det ev. snabbar upp BDB skapandet eller i alla
fall inte slöar ner det. Men en av kanske 20 räknande alla koncept och
symboler som en snarare än de miljoner det maximalt kan bli när språket
orkat i fatt till allt existerande BL.



1.6. 90 miljoner frågan här är om koppling cognition mellan REWARD och attention
där förnärvarande attention endast existerar abstrakt och ej ens nära konkret
eller implementerad modell är meningsfull:



1.6.1. Värderar vi attention som andel?



1.6.2. Och är en som ex. notorisk Wikipedia engagerad värderad mer eller
mindre när mer tid regelmässigt prioriteras? Och om så vill jag - är
det värt det - att skapa ett tillståndssystem för historik i nuvarande
version? Vi säger nej där för att hålla initialt enkelt.



1.7. 900 miljoners frågan - och betryggande nog är vi nu mycket mer i inarbetad
core-funktionalitet i andra tmp. delar - är om reaktion, attention, läsande
o.s.v. speglande / indikerande större andel DESCRIBE läsande eller indikerande
att åtminstone inte endast DO läsande och reaktion (det senare får jag erkänna
till min irritation ofta nog genom åren är mycket vanligt hos reaktions-benägna
läsare) är möjlig utan ev. indikation att de faktiskt läst mer än titel, lite
ingress, och kanske läst en bild.



1.7.1. Det är ev. intressant återkopplande feedback för referens-checkup.



1.7.2. Men här kan vi ej värdera det utan vetskap mer om hur folk läser
jfr läsande som effect population än jag har just nu även om det lätt
nog kan tas ut effektivt.



1.7.3. Viktigare är headline (DO bättre sagt i analys mer än löpsedel
mening) i sig i bra mycket av all mening vad som är
grejen betraktande prediktion snarare än DESCRIBE -> PROJEKTIONERNa.



1.7.4. Vidare värderas DESCRIBE upp ges väl en del referens.



Inte otroligt ska dock DESCRIBE värdering till men vi lämnar det nog bäst
initialt så en utgångspunkt finns utan något som införs och riskerar att bli
atavistiskt.



1.8. Hur gör man med multipla läsande-indikationer i samma reaction-node?
Flera kan indikera att läsaren tänker, resonerar och argumenterar. D.v.s. söker
fram [argument försvarande] någon tanke eller idé de har utan just läst
det. Här särskiljer det från 1.7 givet att DO i 1.7 här blir inte heller
DESCRIBE egentligen utan vad som läsaen upplever har similarity med den cue-
aktivering tanken de har d.v.s. upp-aktiverande noder i dennes gärna nära stämmer
med och ev. med någon föreställande - argumenterande funktion jag ej har i
något regel oavsett modell tror jag. Samtidigt visst. De kanske intresserar sig
runt ex. Ukraina och överläser sig. Särskilt events upplevt lärmande eller
agiterande i övrigt kan läsaren ibland polla.



1.9 Oavsett 1.8 eller ev. en del i övrigt är frågan om analys-materiel är
scarce? om inte kan man ju mer exklusivt kasta bort en del som känns mer än
vad jag tror de har läst för att inte riskera att få bias från Google's sökning
eller liknande via läsaren. Jag kan ev. tänka mig att översättnings-filtrering
är egentlgien rörande mer direkt auto-publicering numera är viktigare än just
antalet länkar.



((( 2.0. Vidare lämnande indikation i 1. är frågan om optimering att ta på länkarna
räcker och/eller förenklar märkbart? Jfr att göra det the good old HH way?
Jag tror vi här för att begränsa mindre i förståelse etablerade
rundgångs-riskområden tar på länkarna givet att de är unika och jag heller inte
känner för separation-probabilistiska viktsystem rörande kollisioner runt entitets-system
jag starkt ser kommer ligga efter att mer direkt nödvändiga story-lookup
existerar. )))



1.10 Donering: Läsaren donerar sin tid. Läsaren reagerar på vad som har
potential. Potentialen är vad vi helst helt slipper här eftersom det skattas
mycket bättre många magnituder korrektare redan. Antal reaktion kan indikera
att personen läser mer. Emellertid vet jag ej nog här för att våga riskera
atavister.



1.11. Låt oss besluta att tillstånd finns. Konceptet här i sig kräver det
per newsprovider så varför inte på allt som importeras från?



1.12 "Problemet" här är sökmotor. Utan dem kan man enkelt med historiken nå
en skattning. Men det är nu läsare i spread som intresserar oss dit saker slutligen
hamnar så det känns lite underligt begränsade att kräva att de just ska vara
regelbundna. Men det är just motsvarande Google News front-page eller klistrade
topics medan riktade sökningar bär risk av resonerande-argumentation.



[1.NN Dummy point for good luck.]



1.14 De tre grupperna läsare i:

http://vcj.sagepub.com/content/5/1/65.abstract#aff-3

http://kodu.ut.ee/~cect/teoreetilised%20seminarid_2011/teoreetiline%20seminar%2019.04.2011/Holsanova_jt2006.pdf
[Red. Förövigt åtminstone en svensk författare - K. Holmqvist, Lunds Universitet, om jag minns rätt.]

Tycks motsvarande ungefär vad vi har resonerat här i reaktion men utan
att de är mängd-kvantierade så att totalen kan skattas från resp. motsvarande
i reaktion focused and general (medan editorial snarare riskerar att oftare
tror jag blandas med risk för sök-bias implicit från större sökmotorer).



1.15 Och mer hemvant från Netrunner prototypen är locomotion i social media
problematiskt p.s.s. "Re-tweeting" kan och är ofta någon läsande - agerande
från - tweet men ej nödvändigtvis vad där indikerat oavsett optimerat länkar
eller via konceptuell BL-rel. Desto ovanligare desto mer läst i mening av att
vi kastar bort all specifik information emellertid känns det ganska osäkert
om inte också bra information om läsande också försvinner för att filtrera
co-locomotion samtidigt om search-beteende för arg. utan läsande
riskerar att störa. Och omvänt lokalt på blogg ju vanligare.



2.0 Och självklart - färre inte fler - avgränsade habitat läsare för mining är
bättre. Medan i övrigt förvisso en del fler krävs men ej stora där det kritiska
för dessa endast är att fånga när något uttrycks brett utan rimlig varians över
resp. habitat. Hence det mest exklusiva är självklart att själv kontrollera
ett habitat om man grundläggande är mycket beroende av denna typ av nod-relations
information medan vi här klarar oss jämförbart bra med tillgängliga utan att
ex. känna behov av att försöka hitta pengar nog för att köpa Wordpress.com,
Blogspot.com eller liknande inte helt olikt vad primärt tänkt här.



HH-NOSQL: Vi avbryter och sätter bättre namn på det. Rebel-As? As för
asymmetric. Domänen har ju tradition av lite flexiblare namn även om jag eg.
inte vet om mongo är en slure som i svenskan. [Red. Men lite fegt as snarare än
uppenbara alternativ.]