Kanske är NoSQL (Oracle) delvis en kontroll fråga. SQL är ju ett tillämpat språk och tror jag säkert med säkerhet bäst lärs ut i alla grundläggande utbildningar medan en datainriktning. Men jag tror andelen arbetande där med utbildningar med ett traditionellt större tillämpade smalare solution-inriktade språk minskat. Datavetare antar jag normalt lär sig grunderna i SQL medan inriktningen data teknisk fysik har större fokus på numeriska metoder.
För Oracle's artikel lyfter de förvisso fram en bra lösning men ändå tror jag ofta en lösning för att hantera plattformarnas begränsningar:
- Hash-tabellen om logiken är i hög utsträckning anpassad är excellent om det är givet att vår plattform orkar mängden data.
- Ingen datastruktur - när hänsyn till minneskostnad i mängd eller accesstid finns - är snabbare med en god hashfunktion.
- Jag är en stor vän av hashtabeller. Om möjligt skulle jag gärna lägga allt i dem.
Abstraktionen Berkeley DB gör är dock en hash-tabell endast i mening av hur vi räknar vår index-nyckel till en lokalsiering i datamedia. Jag är mindre vän av dom än hash-tabeller som i verklig mening kan ha hela tabellen i snabbt-minne redo.
Berkeley DB är den bästa lösning praktiskt enkel jag hittat för när minnet vs mängden inte orkar mer utan att behöva själv göra anpassade in och ut ur minnet (vilket vanligen i min erfarenhet endast lönar sig mer för statiska one-time genereringar mer eller mindre gigantiska medan det i konkurrerad miljö i alla fall för resurserna jag som person representerar relativt tid för lösningen är gigantiskt bättre med en färdig lösning).
Poängen jag vill göra illustreras dock av att när jag sista gången handlade dator ej bärbar hade jag räknat med att hårdvaru-access-indexering av minne skulle ha utvecklats mycket mer än vad tillgängligt i standard-plattformar.
Man har förvisso abstraherat en massa lösningar ovanpå på mer hårdvara - och tycks det ovanpå Ubuntu och tror jag säkert Linux allmänt med gigantiska förluster avseende tillgång multipla-cpu:er och minne för processerna där de gärna sitter och gör ingenting på utan särskilda åtgärder till och med mer än 20 - 60% - medan mängden minne jag eller en tolk som Perl direkt kan indexera ex. för hashtabeller egentligen inte gått särskilt vidare.
<7p>
Vad jag egentligen mer hade räknat med att kunnat köpa plattform till vettigt pris för att göra var att sätta kanske 400 GB filstruktur direkt i snabbt accessbart minne (inget krav på senaste minnesgenerationen: normal ram-prestanda senaste åtta åren hade varit excellen) för data där det ej är ett problem att hantera förändring. Och sedan indexera det som hash-tabell.
Vi kan se problemet avsaknaden av möjlighet ger mer än själva bristen på de konceptuellt eleganta abstraktioner som blir allt mer av verklighet för att lösa ungefär det här problemet på sätt som försämrar prestandan magnituder mer per datamängd-enhet: ex. klustra över nätverk oftare nu, eller innan klustra med sämre kommunikationshastighet för synkning m.m. mellan plattformen, eller innan mellan stoppa-in-ett-stycka-hårdvara kallat "grid" (eller vad nu buzz-wordet för hela den koncept-gruppen över-expensive lösning som var populärt ett tag bl.a. med lösningar från Sun om än säkert inte direkt opraktiska om du är en riktigt fet aktör vars hårdvaru-budget inte ifrågasätts och inte har lust att beställa en ordentligt snabbare lösning via jobbigare konfiiguration antingen mer hårvara-nära eller mer av massor av vekare enheter - jfr ready-to-run super computers i den här gruppen vs dom som toppat sista åren inte sämre än topp 1000 kanske där en hel del riktigt billigt finns - och också om jag här kanske låter kritiskt: är inte budget scarce väljer jad tveklöst ready-to-run - timmar kostar också).
Poängens poäng är att jag upplever att hårdvaru-utvecklingen har för mig icke-optimala preferenser gående åt fel hål. Kan jag indexera riktigt ordentligt med RAM i en PC försvinner en fet mängd tillämpningar som idag kanske rent av når upp till att kräva topp 1000 superdatorer. Med det blir mycket riktigt snabbt.
Jämför med att sitta att köra in data i en databas via ett konfigurationssystem (ex. MediaWiki) där konkurrenta lösningar m.m. krävs. Där går det ner till filaccess varje gång och med åtminstone tidskorta låsningar. Vad som kan ta en timme att med tidsdyr logik att generera handla om dagar att köra. Antag på det att vi inte ens har diskarna med snabb-access utan med en några gånger (i bästa fall) långsammare kanal. Och sätt på det ett kluster av lagringsenheter med processer för at förstå logik-orders på kanske några tusen enheter i plug-in-more-hardware as needed. Eller ännu värre över ett LAN.
Eller nu populärt access data över nätet istället för att ladda ner ofta inte mer än några hundra MB datafiler (och från min praktiska erfarenhet verksamhetskritiska för alla antaganden runt det: uppdelad i behandiga delar på maximalt en 400 - 500 MB) och sällan mer än en 10 - 30 Gig att köra in i säg 500 MB ram-disk med vad du ofast behöver.
Jag är inte så säker på att det just är affärskoncept som drivit utvecklingen så här. Oavsett hur mer lönsamt det är med all surplus-hårdvara. Snarare tror jag delvis i alla fall dom abstrakta koncepten känns väldigt eleganta och naturliga - tyngre i mening och lösnings-djup än i verkligheten - medan detaljer utvecklande vidare standard-komponenter att beställa från valfritt legot-tilverkare är jobbigt, svårt och kanske inte vad dom från förr välkända varumärkena här längre klarar att konkurrera om den kompetenshöjd och innovationsförmåga per individ som egentligen krävs för att ta något som inte tycks gå längre vidare.
Datarkitektur i hårdvara är väl kanske inte längre riktigt vad som attraherar samma antal personer med nivå av att skapa verkligt värde när det är nytt. Mer skruva runt med vad man har och lägga till lite lan-kablar mellan olika datorer istället för att ge möjlighet att adressera mer minne.
Och om jag nu har fel tvivlar jag verkligen på någon kommentar eller ilsket e-post runt det med mindre än att verifierbara instruktioner om hur jag modifierar min linux-kernel för att adressera gigantiskt mer minne tillsammans med instruktioner om var jag får tag i "ram-minneskort" att stoppa in i den i lämplig "port" (eller vad det kallas på insidan - förr fanns något som hetta isa tror jag). Tänk evidensnivå adressera 500 GB ungefär eller gärna mer.
Sun's varumärke är en annan sak. Där det etablerades under år om än föga om alls annat än tappat bit-för-bit sista åren dröjer det väldigt länge innan det inte värt en bra köpe-skilling för hela företaget oavsett om gående mycket dåligt. Bra koncept-ord från början och ytterst under många år etablera redan under grundutbildning såväl som tidigare industrikoncept inom data mången idag ser bakåt till som en lite mytisk-idé om verkligt dataarbete med kvalitet, stort o.s.v.
Jämför lite med Dell's problem som knappast skulle existera med den här adresserings-begränsningen löst medan många dyrare riktade leverantörer av hårdvaruplattformar hade slutgiltigt gjort ett sista ordentligt tapp på så oerhört mycket.
Faktisk när jag tänker på det skule förövrigt vardagligt surfande också bli mycket snabbt åtminstone på Windows p.g.a. det sätt den hanterar minne vs disk. Mycket temporära-filer vs. underliga kontroller av dem via egna subsystem eller add-on-program som går snabbare eller ej är nödvändiga på ett ej för annat än utvalda nedladdningar persistent lagringsmedium.
