Archiv der Kategorie: this();

this() is blog-related;

is blog related stuff. hat irgendwie dann mit dem ding hier zu tun, also der domain hier.

cloud, this();

bigData

nun bin ich also doch beim thema „big-data“ gelandetund eher wie die jungfrau zum kinde zu diesem thema gelangt. daher ein paar gedanken zur einleitung in dieses thema.

bisher hatte ich mich mit erp-systemen ( enterprise resource planning aka sap&co. ) beschäftigt. dann gings um reporting-systeme ( abrechnungen, abschätzungen, berichte ) und darüber bin ich nun in der ecke gelandet, die aktiv wird, wenn die datenbank nicht mehr weiter kommt oder sogar dicke backen macht.

im wesentlichen geht es darum, eine große aufgabe so zu dimensionieren und zu portionieren, dass viele kleine maschinen damit zurecht kommen und in der summe dann mehr dampf haben, als eine dicke maschine.  statt die daten jedoch normalisiert ( möglichst ohne duplikate ) wie eine datenbank zu halten, wird bei big-data  jede tabelle im csv/tsv ( comma / tab separated value ) format als flatfile vorgehalten. die daten sind de-normalisiert, weil aufgrund der heutigen plattenkapazitäten, die schrumpfung auf das letzte byte aufgegeben ist und jeder eintrag ( eine zeile ) durchaus mega- oder gigabyte betragen kann.

die daten sind in einem verteilten dateisystem ( hadoop distributed file system / hdfs ) über mehrere rechner redundant verteilt und werden in einer „salami-taktik“ durchgerechnet und wieder zusammengeführt. so kann es passieren, dass ein quell-tabelle in einem full-cross-join ( alle mit allen vergleichen ) auf 300 oder 400 gigabyte swap-file explodiert. normalerweise ist diese menge mit den üblichen sytemen ( fibrechannel oder iscsi ) kaum zu bewältigen, da das nadelöhr / flaschenhals ( bottleneck )  der zugang zum speichersystem ist. in einem cluster mit 10 nodes macht das nur noch 40 gb swap pro node, bei 20 nodes nur noch 20 gb, die ausgelagert werden müssen. die so nutzbaren skaleneffekte sind ein hauptargument dieses verfahren.

die üppigen datenmengen, die so miteinander verglichen werden können, übersteigen die üblichen verfahren des business-intelligence ( bi ) oder data-mining ( dm ) bei weitem, da korrelationen durch model- und testgetriebene entwicklung ausprobiert und das jeweils sinnvollste modell anwendung finden kann. durch verschiedene konfigurationen des systems können die aufgaben optimal auf verarbeitet werden, da bestimmte jobs mal mehr ram, mal mehr cpu oder mal mehr festplatte benötigen. der flaschenhals läßt sich nach identifizierung weiten, in dem auch weitere maschinen in den cluster genommen werden können, um das gewünschte ergebnis zu produzieren.

so wird die möglichkeit geschaffen, völlig neue ansätze oder alte verworfene, durch try&error automatisiert die verschiedenen szenarien durchzuspielen, die bisher aus technischen oder wirtschaftlichen gründen ausser reichweite waren. die verknüpfung verschiedenster datenquellen kann somit über das bestehende datenmodell hinaus erfolgen, ohne dass die ein klassisches datenmodell verändert werden muss. durch transformationsprozesse werden genau die daten zur berechnung herangezogen, die dafür notwendig und sinnvoll sind.

das gängige werkzeug am markt nennt sich hadoop und wurde von yahoo in eigenregie entwickelt und ist seit 2007 ein teil der open-source-community. verschiedene dienstleister bündeln einige dieser frameworks und bibliotheken und sind mit ihren distributionen auch im kommerziellen sektor vertreten. die großen marken der it sind inzwischen auch vertreten und haben die kombination von relationalen und in-memory-datenbanken auch im großen stil im portfolio.

die ursprüngliche idee, legacy-hardware ( standard server / pizza boxen ) zu benutzen, um aufgaben zu lösen, für die vorher sechs- oder siebenstellige beträge notwendig waren, ist damit aber nicht vorbei. im gegenteil, die nutzung diverser resourcen im verbund ist immer noch zentrales argument. da die bisher verwendete hardware jedoch nicht für solch riesige datenmengen gedacht war, haben hersteller oder firmen wie facebook eine open-compute-initiative geschaffen, die server mit 24 und mehr festplatten in einem gehäuse möglich machen. da diese kategorie jedoch nicht mehr in die üblichen racks passte, wurde dort auch ein neuer standard geschaffen, der statt 19 zoll nun 21 zoll anwendung, die verschiedene verbesserungen mit sich bringen.

der ausgangspunkt für die sammlung solche riesiger datenmengen war im internet gegeben. durch suchmaschinen wurden immens viele seiten und damit daten zur bearbeitung, sichtung, indexierung, bewertung und zur verfügungstellung neu geschaffen. in sozialen netzwerken gab es themen und beiträge, die vorher kaum oder nur wenig miteinander verknüpft wurden.

selbst für große cluster gibt es auch heute noch aufgaben, die durch datenmodellierung von graphen erst erfassbar wurde ( kaufempfehlung als klassisches beispiel: leute die schuhe gekauft haben, kauften auch socken ). die verschiedenen mega- und metaebenen lassen sich mittels dieser technologie verknüpfen und ins verhältnis stellen, einhergehend mit diesem thema kam auch der begriff „nosql“ auf, da keine sequenziellen abfragen mehr gestellt wurden, sondern pipeline- oder baumartige abläufe die irgendwie miteinander verkettet waren.

ergebnis solcher analysen sind dann am ende ganz herkömmliche tabellen, wie man sie aus der tabellenkalkulation kennt, jedoch ist der unterschied, dass diese ein paar hundert millionen oder milliarden einträge lang sein können.

zusammengefasst: information overload industries™

cloud, english, this();

moreDNSEntries

as i had the wish to play with more then one server, i felt the need to configure the domain-name-service ( dns ) much more, then before.

my provider, where the usual webspace resides gave me access to the dns-infrastructure he had. that was cute, as i wasnt a reseller by fact and the need to maintain such things where another level of hosting configuration.

with that tool, to register a-records within the dns, i was able to build the cluster to cloud, with the ability to handle different sites for the different machines/server. i played with cdn.ioioioio.eu and other subdomains as the dataflow where handed-over between different services. several services were to handled by ip-addresses before, now i made that more niceley with names. that was a big step toward the idea of a cloud as the complexity was raising with each service and each instance.

the amount of subdomains and service-aliases raised quickly and i reduced them as i i wanted to keep the overview over the different things, that were hidden behind that curtain.

cloud, coding, english, this();

tomcatServer

as i have the rootServer, i can try and play niceley with my own coded stuff in java, running on tomcat. as the default-webserver just having the php stuff on it, i was looking for my own machine ( or at least for the chance to deploy my stuff ) since a long time.

with no big experience in the hosting field, iam not sure to put the tomcat naked onto the web, so i decide to hide the service behind a proxy/router. after i looked into the given examples, apache could be used therefore. thats to easy, i thought and i remembered some lighthttpd from my school, that one professor took for his page.

configuring the ports and the reverse-proxy was done quite quick, but having more then one subdomain means more then a single config-file. another thing is, that i want to play with load-balancing, so the config was done in three parts.  as example, the workflow of a domain like reporteer.ioioioio.eu

part 1:

reporteer.ioioioio.eu to localhost:80. the gateway with round-robbin load-balancing on a virtual host (server-0) in berlin and redirect to the server-1 in jena.

part 2:

redirect from port 80 on server-0 to server-1 port 80, where another lighty was running.

part 3:

redirect from port 80 to port 8080, where tomcat was running and targeting the servlet-path like http://server1:8080/reporteer/

caching on each layer for different filesizes and different file-types was done that way. as the commong filesize on the http level is mostly below 64 kilobyte ( to measure ) i passed files from the servlet between 64kb and 1mb as java-cache, smaller files on the lighty-instances, separated for images and js/css.  so, some css and some javascript ( lets say up to 8 ) per request was reasonable. a unbounded amount of images where handled by the servlet, beside tiny pictures, like thumbnails and icons.

so i felt a bit save for my tomcat, that exploits or my shity code wont run into a desaster for external incomming requests on port 80.  „the evil hacker“, who wanted to get inside the machine would have to overcome the multiple redirect-layers on the plain/vanilla web-server, to catch the tomcat. beside the fact, that i didnt used any php/cgi nor sql-engine, the chance to fail to quick was not my point anymore.

but the main aspect is, that i can run active code now on the machine. before that, i just made passive / xml based stuff with gwt to run on the vhost i had. now remote-procedure-calls ( rpc ) are possible, beside general httpRequest.

cloud, english, mukke, this();

shoutcastStreamServer

as i run the webradio ( hardcore-central.net this time ) with craig and the amount of listeners are raising, iam looking for an own root-server, to stream the channels by our own. we send with shoutcast-server, which is listed on the portal for a bigger audience and a lot of customers to catch.

therefore i look for the cheapest machine, with unlimited traffic and i pick up one in southern-germany, in jena at euserv. i take the „misurf-m“ with singlecore athlon, 160 gb hdd and 1 gb ram. the price for that machine is ~28€/month, the slots on citrus, we used before costs around 16 british pounds per 25 users. that means, the machine is a lot of money worth, if fully usable.

configuring and customizing the server takes two days or so, then two streams are ready to play that funky music loud boy.  the machine is connected with 100mbit/s and with 160 kbit/s per stream, ~600 listeners / slots are estimated. that is the initial idea as use-case for streaming.

but during the tests i see, that 20-30 mbit/s is the average bandwith before drop-outs take place and interrupting the stream is not so niceley. anyhow, digging the stats from the logfile, observing the customers wants and needs came into the focus, but a good shout-stats-analyzer is not in sight, the same with a nice player for the browser, with streaming-abilities.

ill take some free widgets from the net, to drop them into  the html page and the radiostation is online then. using winamp or vlc player as stream-client is quite easy, so we stream both the gabba and hardcore channels and later on, i switched electro and acid on as well.

therefore, i register the domain ioioioio.eu to handle the url and links and to present the material somehow neutral, with a to close binding to hc. but to be true, my drive and motivation came out of the music    ( mukke ) at i see that as essential influence in life.