...die eine dieser tollen "NoSQL"-Datenbanken nur deswegen benutzen, weil das momentan ganz in und der letzte Schrei ist.
Fachlich/sachliche Gründe für eine flache und ineffiziente Speicherung von Daten in einem Dateisystem (wie es diese "DBs" machen) konnte ich persönlich noch keine entdecken. Und was viel schlimmer ist: es sind noch nicht mal von den Entwicklern dieser "Datenbanken" stichhaltige Argumente zu bekommen, welche mehr als eine genauere Nachfrage überleben.
Im Grunde geht es bei NoSQL eben vor allem darum, Prinzipien als Standard festzulegen, die natürlich auch mit jeder SQL Datenbank möglich wären. Durch den Einsatz einer NoSQL Db fällt es aber leichter, sie hilft einem den Prinzipien zu folgen, die ein einfacheres hochskalieren erlauben. Joins, Autoincrements, feste Spalten usw. sind eben bei sehr großen Projekten echte Hindernisse. Allerdings, in 99,999% der Fälle sind sie es nicht, leider wird das wiederum oft vergessen. Auch Dienste wie Flickr kommen wunderbar mit SQL Datenbanken aus, allerdings verzichten sie bewusst auf Elemente wie Joins, und generieren ihre IDs Serverübergreifend, sodass auch eine komplexe umfangreiche Master/Master konfiguration möglich ist.
Warum man jetzt hier eine NoSQL DB braucht: Keine Ahnung. Vielleicht wissen sie es auch selbst nicht.
Im Grunde geht es bei NoSQL eben vor allem darum, Prinzipien als Standard festzulegen, die natürlich auch mit jeder SQL Datenbank möglich wären. Durch den Einsatz einer NoSQL Db fällt es aber leichter, sie hilft einem den Prinzipien zu folgen, die ein einfacheres hochskalieren erlauben. Joins, Autoincrements, feste Spalten usw. sind eben bei sehr großen Projekten echte Hindernisse. Allerdings, in 99,999% der Fälle sind sie es nicht, leider wird das wiederum oft vergessen. Auch Dienste wie Flickr kommen wunderbar mit SQL Datenbanken aus, allerdings verzichten sie bewusst auf Elemente wie Joins, und generieren ihre IDs Serverübergreifend, sodass auch eine komplexe umfangreiche Master/Master konfiguration möglich ist.
Warum man jetzt hier eine NoSQL DB braucht: Keine Ahnung. Vielleicht wissen sie es auch selbst nicht.
Ich zitiere hier einfach mal die deutsche Wikipedia :
Relationale Datenbanken leiden üblicherweise unter Leistungsproblemen bei datenintensiven Applikationen wie Indexierung von großen Dokumentmengen, Webseiten mit hohen Lastaufkommen, sowie Streaming-Media-Applikationen. Relationale Datenbanken sind nur dann effizient, wenn sie für häufige aber kleine Transaktionen oder für große Batch-Transaktionen mit seltenen Lesezugriffen optimiert sind. Sie können aber schlecht mit gleichzeitig hohen Datenanforderungen und häufigen Datenänderungen umgehen. Beispiele dafür finden sich bei Digg, Facebook und eBay.
> Relationale Datenbanken leiden üblicherweise unter Leistungsproblemen bei datenintensiven Applikationen wie > Indexierung von großen Dokumentmengen,
Jetzt mal egal, ob die Datenmengen groß oder klein sind, bei einer SQL-Datenbank sieht das im Prinzip so aus, dass ein bis zwei Dateien geöffnet sind, in denen dann hin- und hergesprungen wird. Dieses springen kostet nicht all zu viel Zeit, da die Blockgrößen bekannt sind.
Wie sieht das nun bei NoSQL aus? Da muss ebenfalls durch Dateien gegraben werden, allerdings durch ALLE vorhandenen Dateien - und das sind prinzipbedingt sehr viele, da es für jeden Datensatz mindestens eine eigene Datei gibt. Wo habe ich jetzt was gewonnen, wenn ich zusätzlich noch jede Datei einzeln öffnen und schließen muss? Und das quasi ständig, da sich die Daten ja geändert haben könnten?
An der Stelle steigen die ersten NoSQL-Verfechter immer aus, die etwas hartnäckigeren erzählen dann was von "intelligentem Indizieren" und einer separaten Indexdatei. Diese Indexdatei wiederum finde ich ganz toll - sowas haben SQL-Datenbanken auch. Also hat die NoSQL-DB jetzt sogar noch eine Datei mehr als eigentlich notwendig...tolle Software!
Von Sascha Vogt am Mi, 24. November 2010 um 12:49 #
Wieso muss bei einem sozialen Netzwerk durch alle Daten gegraben werden? Meistens wird ein Profil angeklickt. Beim Anklicken kennt man die ID und kann damit DIREKT zum Datensatz navigieren.
Wenn das jetzt 1000 Leute gleichzeitig machen, ist das kein Problem weil sie auf 1000 verschiedene Dateien zugreifen.
Bei einer relationalen DB wäre ein Profil mit ziemlicher Sicherheit über mehrere Tabellen verteilt (zum Beispiel um den Wohnort zu normalisieren) und somit müsstest du in zig Tabellen hin und her navigieren und korrelieren bis du dein Profil zusammen hast.
Dazu kommt, dass die wenigstens ihr Profil auch nur annähernd vollständig ausfüllen. Da du bei der relationalen DB aber die Records immer gleich groß hälst verschenkst du Unmengen an Platz. Und bei 500 Millionen Nutzer macht das ein gewaltigen Unterschied im Plattenplatz. Und große SANs sind verdammt teuer.
Übrigens, wenn eine stink normale Oracle den Spezial DBs von Amazon, Twitter, Ebay und Facebook überlegen wäre bin ich mir sicher, würden diese Firmen die auch verwenden. Immer dran denken, diese Firmen haben aus ner konkreten Not heraus diese Teile entwickelt.
Lies dir mal den Wikipedia-Artikel durch. Da ist die Rede von "Leistungsproblemen bei der Indizierung". Und "Indizierung" heißt eben NICHT, dass nur ein einzelner Datensatz angefasst werden muss.
Von Sascha Vogt am Mi, 24. November 2010 um 13:12 #
Warum sollte ich? Wenn du ein Problem mit dem Wikipedia Eintrag zu NoSQL DBs hast solltest du die dort kund tun und nicht hier. Meine Argumente kommen primär aus einem pro linux Artikel zum Thema NoSQL DBs. Sind die etwa falsch?
Von Sascha Vogt am Mi, 24. November 2010 um 13:27 #
Ahh, verstehe warum du dich auf den Wiki-Satz stürtzt. Hab deinen Beitrag im Prinzip als alleinstehend aufgefasst. My Bad...
Ich könnte aber ne Interpretation vom Wiki-Eintrag geben, ich denke das war eher so gemeint: Wenn ich 500 Mio Profile habe, muss ich die auch in einer Tabelle speichern. Sprich ich hab 500 Mio Zeilen. Die DB legt dann einen Index auf den Primary Key, damit ich noch halbwegs akzeptabel ein Select auf den Datensatz machen kann. Sprich bei jedem Insert oder update (falls noch andere Indizes existieren) muss der Index neu gebaut werden. Bei x writes pro Sekunde zieht das die Performance gewaltig in den Keller.
Das fällt bei ner NoSQL DB weg, da ich für den Primary Key keine Index benötige. Das macht das Dateisystem schon ziemlich gut für mich. Und ein Insert an anderer Stelle betrifft die Lese-Performance an aktueller Stelle nicht.
> Wenn ich 500 Mio Profile habe, muss ich die auch in einer Tabelle speichern. Sprich ich hab 500 Mio Zeilen. Die DB legt > dann einen Index auf den Primary Key, damit ich noch halbwegs akzeptabel ein Select auf den Datensatz machen kann. > Sprich bei jedem Insert oder update (falls noch andere Indizes existieren) muss der Index neu gebaut werden. Bei x writes > pro Sekunde zieht das die Performance gewaltig in den Keller.
Wieso musst du bei einem INSERT neu indizieren? Der neue Eintrag landet am Ende der Datendatei oder an einer Position, an der zuvor ein anderer Datensatz gelöscht wurde, eine Indizierung wird nur in Bezug auf den neuen Primary Key vorgenommen (der Unique sein sollte und deswegen auch nur am Ende seines Storagecontainsers angefügt wird). Wirklich übel tritt dieses Szenario doch nur in Erscheindung, wenn du deine Tabellenstruktur veränderst, dann fasst SQL wirklich jeden Datensatz einzeln an und baut ihn um (OK, der Punkt geht an NoSQL, da sind die Datenstrukturen self-contained).
Spannend wird es bei DEM Szenario doch erst, wenn du in deinen bestehenden Daten mal was suchen musst - und das möchte ich sehen, wenn das über 500 Millionen Dateien ausgeführt wird.
Von Sascha Vogt am Mi, 24. November 2010 um 13:54 #
Das ändert nix an meinen andern beiden Argumenten... Für Suchen nehmen NoSQL DBs meines Wissens SuchEngines a la Apache Lucene u.ä. Da kann man wohl suchen und nebenher neue Files adden ohne das die Performance leidet.
Für genaueres musst dich aber einfach mal selbst informieren im Gegensatz zu andern muss ich nämlich niemanden missionieren. Wer NoSQL DBs verwenden will solls tun, wer nicht solls lassen. Tatsache ist, das Amazon, eBay, Facebook, Twitter und co. vom Einsatz wohl profitieren. Sonst würden sie nicht den Aufwand da rein stecken.
Ich dachte immer, dass NoSQL sich auf SQL selbst bezieht und bedeutet, dass diese Datenbanken kein SQL können. Sonst ergäbe das Wort ja garkeinen Sinn. SQL ist doch nur die Sprache. Was dahinter wie Daten speichert, das interessiert SQL doch nicht.
Richtig, stellt sich aber überraschenderweise heraus, dass es sehr viele Wege gibt Daten zu speichern ohne SQL zu benutzen, weshalb der Term eben reichlich wenig aussagt, außer eben genau das.
Praktisch kaum eine NoSQL Datenbank arbeitet wie die andere, die eine unterstützt BASE, die andere ACID, die eine speichert nur Graphen, wieder eine andere Key/Values. Sie haben nichts gemeinsam, außer dass sie kein SQL unterstützen.
Edit: Doch eins haben sie noch gemeinsam, praktisch alle relevanten sind unter OpenSource Lizenz, ein großer Unterschied zu SQL-Datenbanken, aber heute fast schon so selbstverständlich, dass man es kaum noch bemerkt.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 24. Nov 2010 um 23:03.
"Bei x writes pro Sekunde zieht das die Performance gewaltig in den Keller."
Nicht wirklich, zumal man üblicherweise keine 500 Millionen Einträge hat, man verteilt sie auf mehrere Server (Sharding), und jeder hat z.B. nur 10 Millionen. Entsprechend kleiner ist der Index. Soetwas ist kein Problem, und ist die Basis der Arbeit aller großen Webseiten, außer Google.
"Das macht das Dateisystem schon ziemlich gut für mich."
Welche NoSQL DB verlässt sich hier bitte auf das Dateisystem? Zumal auch viele NoSQL DBs indexe pflegen, sonst wäre dort keine effiziente Suche möglich. 500 Millionen Einträge Eintrag per Eintrag durchsuchen...
"Spezial DBs von Amazon, Twitter, Ebay und Facebook überlegen wäre"
Facebook ist MySQL User. Nicht exklusiv, aber sie sind es, bis heute. Sie betreiben den wohl weltweit größten MySQL Cluster. Amazon ist ein großer Oracle Kunde. Amazon hat auch keine Spezial-DB, außer du meinst SimpleDB, die jedoch mit keiner echten DB, egal ob NoSQL oder SQL, mithalten kann. EBay ist auch Oracle Kunde, aktuell Infos liegen mir nicht vor, ich wüsste aber nicht was sie daran heute hindern würde, im Vergleich zu früher. Sharding ist bei EBays Daten kein Problem. Auch Twitter nutzt bis heute MySQL, warum auch nicht. Natürlich laufen die Messages zuerst durch ihre Message Broker, aber am Ende lagern diese sie nicht dauerhaft.
Auch z.B. Flickr nutzt MySQL, Yahoo hat es bei seiner wichtigen Finance Webseite schon immer getan.
Fast alle großen Seiten nutzen SQL Datenbanken, nur in Spezielbereichen sind es eben auch oft andere Datenspeicher, wie z.B. spezialisierte Suchserver. Das ist aber normal, und war schon früher üblich.
Eine Seite wie Twitter und Facebook besteht aus vielen Komponenten, die auch in anderen Webseiten zu finden sind, Open Source sei dank.
Die ganze Diskussion zum Thema Dateien sorgt bei mir nur für ein Kopfkratzen. DB Server die 1000 Dateien öffnen? Verlust durch feste Blockgrößen? Große Datencluster haben andere sorgen. Zudem ist Speicherplatz billig.
Also wenn ich mir dein Gekeife so durchlese, drängt sich mir der Gedanke auf, dass du für einen Hersteller einer relationalen Datenbank arbeitest. Oder bist du vielleicht ein Informatikprofessor, der keine Lust hat sich mit neuen Konzepten zu beschäftigen?
Nachvollziehen kann ich deinen "Hass" auf NoSQL-Datenbanken jedenfalls nicht.
Oh wow, aber dafür strotzt dein Beitrag ja nur so vor fachlichen Argumenten - ich bin beeindruckt! Spannend, immer die gleiche Reaktion, wenn man NoSQL mal etwas tiefgreifender hinterfragt.
Nein, er kotzt grundsätzlich bei jedem Thema. Es spielt keine Rolle über was. Er findet immer einen Grund zum meckern. Mach dir nichts draus. Manche Leute sind so.
Von VAX-Meister am Mi, 24. November 2010 um 13:09 #
...die eine dieser tollen "NoSQL"-Datenbanken nur deswegen benutzen, weil das momentan ganz in und der letzte Schrei ist.
Ja, bei der Wahl der Werkzeuge kann man schon erkennen, dass es sich bei den Entwicklern nur um Kiddies handeln kann. Würde mich nicht wundern, wenn die als nächstes node.js als Webserver wählen.
Dein Beitrag enthält keine Argumente. Er besteht aus Thesen. Es gibt in diesem Zusammenhang keine Verständnisfrage, sondern allenfalls eine Glaubensfrage, und ohne Argumentation muss es Dich nicht überraschen, wenn Du der einzige bist der an Deine Thesen glaubt.
Der anonyme User hat offenbar weder Ahnung von der Implementierung einer relationalen (SQL-)Datenbank, noch von NoSQL-Datenbanken.
Datensätze als einzelne Dateien speichern... ROTFL... bei den gängigen NoSQL-Datenbanken werden 1. bei schreibenen Zugriffen die neue Daten lediglich an die (flache) Datenbankdatei angehängt ("append-only") 2. die übrigen (lesenden) Queries zur Performancesteigerung stets inkrementell vorberechnet, und zwar immer genau dann, wenn ein neues Dokument angehängt wird (siehe 1.) Ausserdem ist es noch möglich, Indizes anzulegen, um z.B. neue Queries oder Updates effizienter auszuführen.
Im Unterschied zu relationalen (SQL-)Datenbank kann jeder Datensatz beliebig strukturiert sein, insbesondere ist es möglich, in einzelnen Feldern eines Datensatzes direkt Listenstrukturen zu speichern. Der "Typ" jedes Eintrags ergibt sich aus den Datenfeldern bzw. deren Inhalt.
Im Gegensatz dazu werden bei relationalen (SQL-)Datenbanken 1. bei schreibenden Zugriffen die Daten in ein oder mehrere Datenbankdateien geschrieben, wobei ein Datensatz einer bestimmten Tabelle im Idealfall eine feste Größe (in Bytes) beansprucht; Ausnahme: BLOBs oder VARCHARs, die wegen extremer Größenunterschiede der BLOB grundsätzlich separat verwaltet werden (müssen). 3. bei lesenden Zugriffen in der Regel eine SQL-Query geparst, per Optimizer auf eine Reihe von (möglichst wenigen) I/O-Operationen zurückgeführt, und dann aus verschiedenen Stellen der Datenbankdatei(en) zusammengestückelt; in der Regel müssen mehrere Tabellen durchsucht werden, die an unterschiedlichen Stellen auf der Festplatte oder im RAM liegen (was das ganze sehr ineffizient macht, speziell bei vielen Festplatten-Seeks, die deutlich langsamer sind als sequenzielles Lesen); bei sehr vielen Arten von Anfragen muss dabei (trotz Index-Dateien) wegen der "Normalisierung" (=Zerstückelung strukturierter Datensätze auf mehrere Tabellen) ein sogenannter "Full-Table-Scan" durchgeführt werden, d.h. bei einer oder mehreren kompletten Tabellen müssen alle Felder komplett mit Inhalt ausgelesen werden. Vorberechnen (VIEWs) und optimierte Indexe sind möglich, werden aber (v.a. wegen des Speicherbedarfs, bei Indexen auch wegen der chronischen Performance-Probleme bei Index-Updates) oft nur sparsam oder gar nicht eingesetzt.
Indexe (und auch die Datenbankfelder selbst) werden übrigens in der Regel als B-Bäume (BTREE) verwaltet, genau so wie praktisch jedes Dateisystem seine Dateien verwaltet. Mit dem Unterschied, dass eine Datei strukturierte (bzw. beliebige) Daten enthalten kann, ein echter relationaler Datensatz aber nicht. (Je nach Anwendungsfall kann das ein Vorteil oder ein Nachteil sein).
Der Vorteil eine SQL-Datenbank liegt in der Regel nicht darin, dass man darin Daten ablegen kann (denn das geht auch mit "Flat Files", d.h. einfachen Dateien im Dateisystem), sondern in einer quasi "automatischen" Dokumentation des Datenbankschemas ("sprechende", d.h. gut gewählte, Bezeichner für Tabellen und Felder vorausgesetzt), und in der mächtigen "SELECT"-Syntax für flexible Anfragen. Man erkauft sich diese Mächtigkeit mit einer gewissen Unflexibilität - z.B. bei Schema-Änderungen an Tabellen, oder bei der umständlichen und performance-fressenden Verteilung strukturierter oder im Programm "objektorientiert" genutzter Daten auf mehrere Tabellen. So muss man z.B. zur Verwendung einer "Liste" in einem Feld zunächst für den dazugehörigen Datensatz sowie *jedes* Listenelement eine eindeutige ID erzeugen (lassen), um dann über eine dritte (Verknüpfungs-)Tabelle die Verknüpfung (eben die "Relation"!) herstellen zu können. Um die Normalisierung sicherstellen zu können, sollte man dabei für jedes Listenelement zunächst ermitteln, ob dafür bereits eine ID existiert, oder ob es neu angelegt werden muss. Das ganze ist sehr ineffizient, und muss, weil es aus so vielen Einzeloperationen zusammengesetzt ist, mit einer Transaktion "umklammert" werden, damit (im Fehlerfall/"Rollback" ebenso wie im Erfolgsfall/"Commit") ein konsistenter Zustand erreicht wird. Ältere Datenbank-Managementsysteme (RDBMS) erfordern bei komplexeren Updates oft ein Sperren (Locking) von Tabellen oder Datensätzen für andere, gleichzeitige Zugriffe.
NoSQL-Datenbanken kann bzw. sollte man überall dort einsetzen, wo grosse Datenmengen, speziell mit vielen Zeichenketten und BLOBs, redundant gespeichert werden sollen (d.h. auf mehreren Servern gleichzeitig oder verteilt, d.h. über mehrere Server hinweg "partitioniert"), und die erzeugten Datensätze nur selten geändert, aber oft gelesen werden sollen. Ideal z.B. für Blogs (Artikel, Kommentare usw.), weniger ideal z.B. für ERP-Programme (z.B. Konto-Buchungen, Teilelisten).
SQL-Datenbanken sollte man überall dort einsetzen, wo Datensätze häufig geändert werden, oder wo eine (meist eher mittelmäßige) GUI-Eingabemaske "automatisch" (oder mit "RAD"-Tools) generiert werden soll. Auch für (gedruckte oder grafisch aufbereitete) Berichte (Reports) oder Statistiken existieren Tools, die zumindest einen Teil der notwendigen Programmierung ersparen.
Auch wenn man in einem grossen Team arbeitet, das (allein schon wegen der Teamgröße) Kommunikationsprobleme hat, bietet sich der Einsatz eines "klassischen" SQL-RDBMS an, da bei relationalen Datenbanken die Datenbank-Modellierung gewissen Standards folgen (kann), was die Abstimmung erleichtert. (Bei komplexen Projekten, d.h. früher oder später sowieso, muss man ohnehin um die Einschränkungen fast jeder Datenbank "herumprogrammieren", insbesondere wenn die zu speichernden Daten sich relational eben nicht "optimal" darstellen lassen.)
Die "Append-Only"-Speicherung in NoSQL-Datenbanken erlaubt übrigens einige nette Optimierungen (z.B. bei der Replikation oder bei inkrementellen Backups), so dass diese Technik auch bei vielen SQL-Datenbanken eingesetzt wird (z.B. für Rollback-Logs für Transaktionen, oder für Master-Slave-Replikation).
Übrigens würde ich persönlich einen (auch studierten) "Wirtschaftsinformatiker" auf gar keinen Fall in die Nähe einer NoSQL-Datenbank lassen... - wer nicht das Wissen, die Erfahrung oder die Zeit hat, Algorithmen selbst zu entwickeln und zu optimieren, sollte besser eine "Standardsoftware" nehmen (="ORACLE"-Datenbank, ersatzweise "MySQL"). Alle anderen benutzen die Werkzeuge, die (im Rahmen der Umstände) das beste Ergebnis liefern, und Möglichkeiten zum Lernen neuer Techniken bieten.
Wenn man Interesse an der Informatik oder am Programmieren hat, kann man bei der Beschäftigung mit NoSQL-Datenbanken sehr viel lernen - selbst dann, wenn man diese später selbst nicht einsetzt. (Ähnliches gilt für diverse Programmiersprachen wie z.B. Ruby, Smalltalk oder Erlang.)
Von Nichtanonym am Mi, 24. November 2010 um 18:18 #
Schön und gut, aber du tust ja so, als würden Ruby und Erlang ja gar nicht in der Wirtschaft genutzt. Vor allem Erlang wird doch gar nicht so selten benutzt?
Fast alle möglichen Programmiersprachen (auch Smalltalk, Lisp, F# usw.) werden irgendwo mit Erfolg benutzt. Meine Bemerkung bezog sich darauf, dass (speziell auch in Deutschland) im kommerziellen Umfeld traditionell eher wenig "experimentiert" wird, und daher wohl eher Java, C/C++, Visual Basic, Javascript, PHP, Objective-C auf Macs und in Einzelfällen vielleicht höchstens noch Perl, Python und Shellscripts die "Brot-und-Butter"-Sprachen der meisten Programmierer hierzulande sein dürften.
Der Grund dafür ist natürlich auch, dass man bei den "Standarsprachen" weniger stark von "speziellen" Kenntnissen eines Einzelnen abhängig ist, also leichter sowohl Ersatz bei Ausfall/Kündigung als auch weitere Teammitglieder findet. Je mehr Leute sich also z.B. mit Smalltalk, Ruby, Erlang, Lua, Perl 6 usw. auskennen, desto größer werden die Chancen, dass man diese Sprachen (als angestellter Programmierer) auch in der eigenen Firma einsetzen kann (bzw. "darf").
Dieses "Henne-Ei"-Problem haben z.B. Perl 5, PHP und Objective-C erfolgreich gemeistert, und auch Lua (für die Embedded-Programmierung) sowie Python (u.a. durch Google) sind inzwischen vielerorts "erlaubt".
Grundsätzlich kann es nicht schaden, sich mit den Konzepten von möglichst vielen Programmiersprachen zumindest ein wenig auseinander zu setzen. Die viel zitierten objektorientierten "Design Patterns" sind z.B. in Smalltalk viel einfacher zu verstehen als in C++ oder Java - mehrere der "Patterns" umschiffen z.B. in Wirklichkeit Unzulänglichkeiten dieser Sprachen, und sind z.B. bei der Smalltalk-Programmierung überflüssig oder werden zu "trivialen" Einzeilern.
In diesem Zusammenhang ist evtl. das im Dezember erscheinende Buch "7 Languages in 7 Weeks" interessant. Der Verlag, die "Pragmatic Programmers", ist übrigens dadurch bekannt geworden, dass die beiden US-Programmierer schon sehr früh, vor über 10 Jahren, das erste professionelle (und gute) Ruby-Buch geschrieben und kostenlos online gestellt haben. Die meisten Smalltalk-Bücher gibt es übrigens inzwischen dank Prof. Stephane Ducasse auch kostenlos online; mir persönlich hat "SmallTalk Best Practice Patterns" des Smalltalk-"Gurus" und "Extreme Programming"-Erfinders Kent Beck für den Einstieg am Besten gefallen. (Anders als der Titel vermuten lassen würde, beschäftigt sich das Buch aber nicht mit "Design Patterns", sondern mit Tipps zu Sprachstil und Lesbarkeit von Smalltalk-Programmen. Mit den Design-Patterns beschäftigt sich, ebenfalls sehr gut, der dicke Wälzer "Design Patterns Smalltalk Companion".) Was Erlang angeht, kann ich das Buch "Programming Erlang" des Spracherfinders Joe Armstrong empfehlen; die (recht vielen) anderen neuen und teilweise in Auszügen schon verfügbaren Erlang-Bücher sind im Vergleich dazu von sehr gemischter Qualität.
Da fällt mir ein: eigentlich ist Smalltalk (wider Erwarten) sehr verbreitet, zumindest die grundlegenden Konzepte und ein Teil der Syntax, denn Objective-C ist im Prinzip eine "Smalltalk-Syntaxerweiterung" für C.
(Apropos C - angeblich soll es sich auch lohnen, sich mit "D" zu beschäftigen, weil das vieles richtig machen soll, was C++ und Java falsch machen - ob "D" aber irgendwann wirklich einmal zum Mainstream gehören wird, kann man jetzt wohl noch nicht sagen. Wie immer hängt es davon ab, wie viele Leute sich mit "D" grundlegend auskennen und darin programmieren möchten.)
Ich höre immer wieder von vielen Leuten, dass bei größeren Systemen Ruby on Rails ziemlich schlecht skaliert und arg träge wird. Bin mal gespannt wann von den ersten Performance-Problemen zu hören ist. Aber was soll's, alle coolen Kids benutzen Ruby...
Du willst ernsthaft das Trafficaufkommen der Popelwebsite New York Times mit der eines Socialnetwork vergleichen? Geht's noch? Selbst Facebook hat nen nativen Compiler entwickelt, weil ihnen PHP zu langsam war. Die Twitter-Entwickler hatten auch Probleme mit der RoR-Performance und mussten ne menge Arbeit investieren bis es eingermaßen schnell genug war. Und Twitter und Facebook ist die Größenordnung wo Diaspora mal hin will.
Von Vertrau keinem Mod/Admin einer am Mi, 24. November 2010 um 18:47 #
Denn das ist das Problem, bei solchen selbsterwählten Community Moderatoren/Administratoren.
Sie halten sich für unkündbar und erlauben sich daher alles, auch und insbesondere auch die Durchsetzung von Unrecht gegenüber Mitgliedern und die Bevorzugung von Freunden, Seilschaften und Co.
Am besten sieht man das an der Wikipedia und ihren Admins.
Bei einem Konzern wie Facebook ist das nicht so. Das Unternehmen ist riesig und es gibt Mitarbeiter, die den Admins und Moderatoren auf die Finger klopfen, wenn sie schlechte Arbeit leisten und Mitglieder aus persönlichen Gründen benachteiligen. Und genau deswegen kuschen die Mods und Admins dort, da sie ganz genau wissen, daß sie jederzeit gefeuert und durch Kompetenzpersonal ersetzt werden könnten.
Bei einem Social Netzwerk eines Konzern ist man also als Benutzer besser aufgehoben.
Es geht glaube ich nicht um Nachbarn. Alle Anbieter von Webcontent (Hoster etc) können dei Anbieter sein. Es liegen nicht mehr alle Daten bei einem, der diese dann verscherbeln kann.
Schwachsinnig finde gesichtsbuch & co. trotzdem Blog und XMPP reichen, den Rest tauscht man einfach normal aus...
... ich habe von der ganzen technischen unterhalten wenig ahnung. ich bin user. und als user schon ganz lange weg bei facebook. aber jetzt von anfang an frisch mit dabei bei diaspora. und ich bin begeistert. it works. so soll es doch sein. für eine alpha ist das eine feine sache und kann nur noch immer besser werden. täglich. ich bin begeistert!
http://pod.geraspora.de/
anmelden und einfach sich selbst eine meinung bilden!!!
...die eine dieser tollen "NoSQL"-Datenbanken nur deswegen benutzen, weil das momentan ganz in und der letzte Schrei ist.
Fachlich/sachliche Gründe für eine flache und ineffiziente Speicherung von Daten in einem Dateisystem (wie es diese "DBs" machen) konnte ich persönlich noch keine entdecken.
Und was viel schlimmer ist: es sind noch nicht mal von den Entwicklern dieser "Datenbanken" stichhaltige Argumente zu bekommen, welche mehr als eine genauere Nachfrage überleben.
Im Grunde geht es bei NoSQL eben vor allem darum, Prinzipien als Standard festzulegen, die natürlich auch mit jeder SQL Datenbank möglich wären.
Durch den Einsatz einer NoSQL Db fällt es aber leichter, sie hilft einem den Prinzipien zu folgen, die ein einfacheres hochskalieren erlauben. Joins, Autoincrements, feste Spalten usw. sind eben bei sehr großen Projekten echte Hindernisse.
Allerdings, in 99,999% der Fälle sind sie es nicht, leider wird das wiederum oft vergessen.
Auch Dienste wie Flickr kommen wunderbar mit SQL Datenbanken aus, allerdings verzichten sie bewusst auf Elemente wie Joins, und generieren ihre IDs Serverübergreifend, sodass auch eine komplexe umfangreiche Master/Master konfiguration möglich ist.
Warum man jetzt hier eine NoSQL DB braucht: Keine Ahnung. Vielleicht wissen sie es auch selbst nicht.
Im Grunde geht es bei NoSQL eben vor allem darum, Prinzipien als Standard festzulegen, die natürlich auch mit jeder SQL Datenbank möglich wären.
Durch den Einsatz einer NoSQL Db fällt es aber leichter, sie hilft einem den Prinzipien zu folgen, die ein einfacheres hochskalieren erlauben. Joins, Autoincrements, feste Spalten usw. sind eben bei sehr großen Projekten echte Hindernisse.
Allerdings, in 99,999% der Fälle sind sie es nicht, leider wird das wiederum oft vergessen.
Auch Dienste wie Flickr kommen wunderbar mit SQL Datenbanken aus, allerdings verzichten sie bewusst auf Elemente wie Joins, und generieren ihre IDs Serverübergreifend, sodass auch eine komplexe umfangreiche Master/Master konfiguration möglich ist.
Warum man jetzt hier eine NoSQL DB braucht: Keine Ahnung. Vielleicht wissen sie es auch selbst nicht.
Ich zitiere hier einfach mal die deutsche Wikipedia :
Relationale Datenbanken leiden üblicherweise unter Leistungsproblemen bei datenintensiven Applikationen wie Indexierung von großen Dokumentmengen, Webseiten mit hohen Lastaufkommen, sowie Streaming-Media-Applikationen. Relationale Datenbanken sind nur dann effizient, wenn sie für häufige aber kleine Transaktionen oder für große Batch-Transaktionen mit seltenen Lesezugriffen optimiert sind. Sie können aber schlecht mit gleichzeitig hohen Datenanforderungen und häufigen Datenänderungen umgehen. Beispiele dafür finden sich bei Digg, Facebook und eBay.
Da geht der Schwachsinn doch schon los:
> Relationale Datenbanken leiden üblicherweise unter Leistungsproblemen bei datenintensiven Applikationen wie
> Indexierung von großen Dokumentmengen,
Jetzt mal egal, ob die Datenmengen groß oder klein sind, bei einer SQL-Datenbank sieht das im Prinzip so aus, dass ein bis zwei Dateien geöffnet sind, in denen dann hin- und hergesprungen wird. Dieses springen kostet nicht all zu viel Zeit, da die Blockgrößen bekannt sind.
Wie sieht das nun bei NoSQL aus? Da muss ebenfalls durch Dateien gegraben werden, allerdings durch ALLE vorhandenen Dateien - und das sind prinzipbedingt sehr viele, da es für jeden Datensatz mindestens eine eigene Datei gibt. Wo habe ich jetzt was gewonnen, wenn ich zusätzlich noch jede Datei einzeln öffnen und schließen muss? Und das quasi ständig, da sich die Daten ja geändert haben könnten?
An der Stelle steigen die ersten NoSQL-Verfechter immer aus, die etwas hartnäckigeren erzählen dann was von "intelligentem Indizieren" und einer separaten Indexdatei. Diese Indexdatei wiederum finde ich ganz toll - sowas haben SQL-Datenbanken auch. Also hat die NoSQL-DB jetzt sogar noch eine Datei mehr als eigentlich notwendig...tolle Software!
Wieso muss bei einem sozialen Netzwerk durch alle Daten gegraben werden? Meistens wird ein Profil angeklickt. Beim Anklicken kennt man die ID und kann damit DIREKT zum Datensatz navigieren.
Wenn das jetzt 1000 Leute gleichzeitig machen, ist das kein Problem weil sie auf 1000 verschiedene Dateien zugreifen.
Bei einer relationalen DB wäre ein Profil mit ziemlicher Sicherheit über mehrere Tabellen verteilt (zum Beispiel um den Wohnort zu normalisieren) und somit müsstest du in zig Tabellen hin und her navigieren und korrelieren bis du dein Profil zusammen hast.
Dazu kommt, dass die wenigstens ihr Profil auch nur annähernd vollständig ausfüllen. Da du bei der relationalen DB aber die Records immer gleich groß hälst verschenkst du Unmengen an Platz. Und bei 500 Millionen Nutzer macht das ein gewaltigen Unterschied im Plattenplatz. Und große SANs sind verdammt teuer.
Übrigens, wenn eine stink normale Oracle den Spezial DBs von Amazon, Twitter, Ebay und Facebook überlegen wäre bin ich mir sicher, würden diese Firmen die auch verwenden. Immer dran denken, diese Firmen haben aus ner konkreten Not heraus diese Teile entwickelt.
Gruß
Sascha
Lies dir mal den Wikipedia-Artikel durch. Da ist die Rede von "Leistungsproblemen bei der Indizierung". Und "Indizierung" heißt eben NICHT, dass nur ein einzelner Datensatz angefasst werden muss.
Warum sollte ich?
Wenn du ein Problem mit dem Wikipedia Eintrag zu NoSQL DBs hast solltest du die dort kund tun und nicht hier.
Meine Argumente kommen primär aus einem pro linux Artikel zum Thema NoSQL DBs. Sind die etwa falsch?
Ahh, verstehe warum du dich auf den Wiki-Satz stürtzt. Hab deinen Beitrag im Prinzip als alleinstehend aufgefasst. My Bad...
Ich könnte aber ne Interpretation vom Wiki-Eintrag geben, ich denke das war eher so gemeint:
Wenn ich 500 Mio Profile habe, muss ich die auch in einer Tabelle speichern. Sprich ich hab 500 Mio Zeilen. Die DB legt dann einen Index auf den Primary Key, damit ich noch halbwegs akzeptabel ein Select auf den Datensatz machen kann. Sprich bei jedem Insert oder update (falls noch andere Indizes existieren) muss der Index neu gebaut werden. Bei x writes pro Sekunde zieht das die Performance gewaltig in den Keller.
Das fällt bei ner NoSQL DB weg, da ich für den Primary Key keine Index benötige. Das macht das Dateisystem schon ziemlich gut für mich. Und ein Insert an anderer Stelle betrifft die Lese-Performance an aktueller Stelle nicht.
> Wenn ich 500 Mio Profile habe, muss ich die auch in einer Tabelle speichern. Sprich ich hab 500 Mio Zeilen. Die DB legt
> dann einen Index auf den Primary Key, damit ich noch halbwegs akzeptabel ein Select auf den Datensatz machen kann.
> Sprich bei jedem Insert oder update (falls noch andere Indizes existieren) muss der Index neu gebaut werden. Bei x writes
> pro Sekunde zieht das die Performance gewaltig in den Keller.
Wieso musst du bei einem INSERT neu indizieren? Der neue Eintrag landet am Ende der Datendatei oder an einer Position, an der zuvor ein anderer Datensatz gelöscht wurde, eine Indizierung wird nur in Bezug auf den neuen Primary Key vorgenommen (der Unique sein sollte und deswegen auch nur am Ende seines Storagecontainsers angefügt wird). Wirklich übel tritt dieses Szenario doch nur in Erscheindung, wenn du deine Tabellenstruktur veränderst, dann fasst SQL wirklich jeden Datensatz einzeln an und baut ihn um (OK, der Punkt geht an NoSQL, da sind die Datenstrukturen self-contained).
Spannend wird es bei DEM Szenario doch erst, wenn du in deinen bestehenden Daten mal was suchen musst - und das möchte ich sehen, wenn das über 500 Millionen Dateien ausgeführt wird.
Das ändert nix an meinen andern beiden Argumenten...
Für Suchen nehmen NoSQL DBs meines Wissens SuchEngines a la Apache Lucene u.ä. Da kann man wohl suchen und nebenher neue Files adden ohne das die Performance leidet.
Für genaueres musst dich aber einfach mal selbst informieren
im Gegensatz zu andern muss ich nämlich niemanden missionieren. Wer NoSQL DBs verwenden will solls tun, wer nicht solls lassen. Tatsache ist, das Amazon, eBay, Facebook, Twitter und co. vom Einsatz wohl profitieren. Sonst würden sie nicht den Aufwand da rein stecken.
Das kommt alles auf die Datenbank an. Es gibt nicht "die" NoSQL Db, die sind alle architektonisch völlig unterschiedlich, und haben Nix gemeinsam.
"Tatsache ist, das Amazon, eBay, Facebook, Twitter und co. vom Einsatz wohl profitieren."
Die alle, nach meinen Infos, immernoch hauptsächlich auf gute alte SQL DBs setzen.
NoSQL ist ein Hypebegriff, der eine völlig undefinierte Masse an Software umfasst, deren Funktionen oftmals garnichts miteinander zu tun haben.
Sehr richtig: The beginning of the end of NoSQL
Ich dachte immer, dass NoSQL sich auf SQL selbst bezieht und bedeutet, dass diese Datenbanken kein SQL können. Sonst ergäbe das Wort ja garkeinen Sinn. SQL ist doch nur die Sprache. Was dahinter wie Daten speichert, das interessiert SQL doch nicht.
Richtig, stellt sich aber überraschenderweise heraus, dass es sehr viele Wege gibt Daten zu speichern ohne SQL zu benutzen, weshalb der Term eben reichlich wenig aussagt, außer eben genau das.
Praktisch kaum eine NoSQL Datenbank arbeitet wie die andere, die eine unterstützt BASE, die andere ACID, die eine speichert nur Graphen, wieder eine andere Key/Values. Sie haben nichts gemeinsam, außer dass sie kein SQL unterstützen.
Edit: Doch eins haben sie noch gemeinsam, praktisch alle relevanten sind unter OpenSource Lizenz, ein großer Unterschied zu SQL-Datenbanken, aber heute fast schon so selbstverständlich, dass man es kaum noch bemerkt.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 24. Nov 2010 um 23:03."Bei x writes pro Sekunde zieht das die Performance gewaltig in den Keller."
Nicht wirklich, zumal man üblicherweise keine 500 Millionen Einträge hat, man verteilt sie auf mehrere Server (Sharding), und jeder hat z.B. nur 10 Millionen. Entsprechend kleiner ist der Index. Soetwas ist kein Problem, und ist die Basis der Arbeit aller großen Webseiten, außer Google.
"Das macht das Dateisystem schon ziemlich gut für mich."
Welche NoSQL DB verlässt sich hier bitte auf das Dateisystem? Zumal auch viele NoSQL DBs indexe pflegen, sonst wäre dort keine effiziente Suche möglich. 500 Millionen Einträge Eintrag per Eintrag durchsuchen...
"Spezial DBs von Amazon, Twitter, Ebay und Facebook überlegen wäre"
Facebook ist MySQL User. Nicht exklusiv, aber sie sind es, bis heute. Sie betreiben den wohl weltweit größten MySQL Cluster. Amazon ist ein großer Oracle Kunde. Amazon hat auch keine Spezial-DB, außer du meinst SimpleDB, die jedoch mit keiner echten DB, egal ob NoSQL oder SQL, mithalten kann.
EBay ist auch Oracle Kunde, aktuell Infos liegen mir nicht vor, ich wüsste aber nicht was sie daran heute hindern würde, im Vergleich zu früher. Sharding ist bei EBays Daten kein Problem.
Auch Twitter nutzt bis heute MySQL, warum auch nicht. Natürlich laufen die Messages zuerst durch ihre Message Broker, aber am Ende lagern diese sie nicht dauerhaft.
Auch z.B. Flickr nutzt MySQL, Yahoo hat es bei seiner wichtigen Finance Webseite schon immer getan.
Fast alle großen Seiten nutzen SQL Datenbanken, nur in Spezielbereichen sind es eben auch oft andere Datenspeicher, wie z.B. spezialisierte Suchserver. Das ist aber normal, und war schon früher üblich.
Eine Seite wie Twitter und Facebook besteht aus vielen Komponenten, die auch in anderen Webseiten zu finden sind, Open Source sei dank.
Die ganze Diskussion zum Thema Dateien sorgt bei mir nur für ein Kopfkratzen. DB Server die 1000 Dateien öffnen? Verlust durch feste Blockgrößen? Große Datencluster haben andere sorgen. Zudem ist Speicherplatz billig.
Also wenn ich mir dein Gekeife so durchlese, drängt sich mir der Gedanke auf, dass du für einen Hersteller einer relationalen Datenbank arbeitest. Oder bist du vielleicht ein Informatikprofessor, der keine Lust hat sich mit neuen Konzepten zu beschäftigen?
Nachvollziehen kann ich deinen "Hass" auf NoSQL-Datenbanken jedenfalls nicht.
Oh wow, aber dafür strotzt dein Beitrag ja nur so vor fachlichen Argumenten - ich bin beeindruckt! Spannend, immer die gleiche Reaktion, wenn man NoSQL mal etwas tiefgreifender hinterfragt.
Hab ich also doch recht?
Nein, er kotzt grundsätzlich bei jedem Thema. Es spielt keine Rolle über was. Er findet immer einen Grund zum meckern. Mach dir nichts draus. Manche Leute sind so.
Ja, bei der Wahl der Werkzeuge kann man schon erkennen, dass es sich bei den Entwicklern nur um Kiddies handeln kann. Würde mich nicht wundern, wenn die als nächstes node.js als Webserver wählen.
Wird es je einen Tag geben, an dem wir nicht dein Gemotze oder dein Trolling lesen müssen?
Passt dir was nicht? Oder verstehst du meine Argumente einfach nicht? Naja, das ist halt kein BWL-Forum hier...
+1 für Einführung der Pflichtregistrierung bevor man kommentieren kann, am besten noch mit Klarnamenpflicht
Axel E. Fischer fordert Null-Toleranz für /dev/null.
Dein Beitrag enthält keine Argumente. Er besteht aus Thesen. Es gibt in diesem Zusammenhang keine Verständnisfrage, sondern allenfalls eine Glaubensfrage, und ohne Argumentation muss es Dich nicht überraschen, wenn Du der einzige bist der an Deine Thesen glaubt.
Der anonyme User hat offenbar weder Ahnung von der Implementierung einer relationalen (SQL-)Datenbank, noch von NoSQL-Datenbanken.
Datensätze als einzelne Dateien speichern... ROTFL... bei den gängigen NoSQL-Datenbanken werden
1. bei schreibenen Zugriffen die neue Daten lediglich an die (flache) Datenbankdatei angehängt ("append-only")
2. die übrigen (lesenden) Queries zur Performancesteigerung stets inkrementell vorberechnet, und zwar immer genau dann, wenn ein neues Dokument angehängt wird (siehe 1.)
Ausserdem ist es noch möglich, Indizes anzulegen, um z.B. neue Queries oder Updates effizienter auszuführen.
Im Unterschied zu relationalen (SQL-)Datenbank kann jeder Datensatz beliebig strukturiert sein, insbesondere ist es möglich, in einzelnen Feldern eines Datensatzes direkt Listenstrukturen zu speichern. Der "Typ" jedes Eintrags ergibt sich aus den Datenfeldern bzw. deren Inhalt.
Im Gegensatz dazu werden bei relationalen (SQL-)Datenbanken
1. bei schreibenden Zugriffen die Daten in ein oder mehrere Datenbankdateien geschrieben, wobei ein Datensatz einer bestimmten Tabelle im Idealfall eine feste Größe (in Bytes) beansprucht;
Ausnahme: BLOBs oder VARCHARs, die wegen extremer Größenunterschiede der BLOB grundsätzlich separat verwaltet werden (müssen).
3. bei lesenden Zugriffen in der Regel eine SQL-Query geparst, per Optimizer auf eine Reihe von (möglichst wenigen) I/O-Operationen zurückgeführt, und dann aus verschiedenen Stellen der Datenbankdatei(en) zusammengestückelt; in der Regel müssen mehrere Tabellen durchsucht werden, die an unterschiedlichen Stellen auf der Festplatte oder im RAM liegen (was das ganze sehr ineffizient macht, speziell bei vielen Festplatten-Seeks, die deutlich langsamer sind als sequenzielles Lesen); bei sehr vielen Arten von Anfragen muss dabei (trotz Index-Dateien) wegen der "Normalisierung" (=Zerstückelung strukturierter Datensätze auf mehrere Tabellen) ein sogenannter "Full-Table-Scan" durchgeführt werden, d.h. bei einer oder mehreren kompletten Tabellen müssen alle Felder komplett mit Inhalt ausgelesen werden. Vorberechnen (VIEWs) und optimierte Indexe sind möglich, werden aber (v.a. wegen des Speicherbedarfs, bei Indexen auch wegen der chronischen Performance-Probleme bei Index-Updates) oft nur sparsam oder gar nicht eingesetzt.
Indexe (und auch die Datenbankfelder selbst) werden übrigens in der Regel als B-Bäume (BTREE) verwaltet, genau so wie praktisch jedes Dateisystem seine Dateien verwaltet. Mit dem Unterschied, dass eine Datei strukturierte (bzw. beliebige) Daten enthalten kann, ein echter relationaler Datensatz aber nicht. (Je nach Anwendungsfall kann das ein Vorteil oder ein Nachteil sein).
Der Vorteil eine SQL-Datenbank liegt in der Regel nicht darin, dass man darin Daten ablegen kann (denn das geht auch mit "Flat Files", d.h. einfachen Dateien im Dateisystem), sondern in einer quasi "automatischen" Dokumentation des Datenbankschemas ("sprechende", d.h. gut gewählte, Bezeichner für Tabellen und Felder vorausgesetzt), und in der mächtigen "SELECT"-Syntax für flexible Anfragen. Man erkauft sich diese Mächtigkeit mit einer gewissen Unflexibilität - z.B. bei Schema-Änderungen an Tabellen, oder bei der umständlichen und performance-fressenden Verteilung strukturierter oder im Programm "objektorientiert" genutzter Daten auf mehrere Tabellen. So muss man z.B. zur Verwendung einer "Liste" in einem Feld zunächst für den dazugehörigen Datensatz sowie *jedes* Listenelement eine eindeutige ID erzeugen (lassen), um dann über eine dritte (Verknüpfungs-)Tabelle die Verknüpfung (eben die "Relation"!) herstellen zu können. Um die Normalisierung sicherstellen zu können, sollte man dabei für jedes Listenelement zunächst ermitteln, ob dafür bereits eine ID existiert, oder ob es neu angelegt werden muss. Das ganze ist sehr ineffizient, und muss, weil es aus so vielen Einzeloperationen zusammengesetzt ist, mit einer Transaktion "umklammert" werden, damit (im Fehlerfall/"Rollback" ebenso wie im Erfolgsfall/"Commit") ein konsistenter Zustand erreicht wird. Ältere Datenbank-Managementsysteme (RDBMS) erfordern bei komplexeren Updates oft ein Sperren (Locking) von Tabellen oder Datensätzen für andere, gleichzeitige Zugriffe.
NoSQL-Datenbanken kann bzw. sollte man überall dort einsetzen, wo grosse Datenmengen, speziell mit vielen Zeichenketten und BLOBs, redundant gespeichert werden sollen (d.h. auf mehreren Servern gleichzeitig oder verteilt, d.h. über mehrere Server hinweg "partitioniert"), und die erzeugten Datensätze nur selten geändert, aber oft gelesen werden sollen. Ideal z.B. für Blogs (Artikel, Kommentare usw.), weniger ideal z.B. für ERP-Programme (z.B. Konto-Buchungen, Teilelisten).
SQL-Datenbanken sollte man überall dort einsetzen, wo Datensätze häufig geändert werden, oder wo eine (meist eher mittelmäßige) GUI-Eingabemaske "automatisch" (oder mit "RAD"-Tools) generiert werden soll. Auch für (gedruckte oder grafisch aufbereitete) Berichte (Reports) oder Statistiken existieren Tools, die zumindest einen Teil der notwendigen Programmierung ersparen.
Auch wenn man in einem grossen Team arbeitet, das (allein schon wegen der Teamgröße) Kommunikationsprobleme hat, bietet sich der Einsatz eines "klassischen" SQL-RDBMS an, da bei relationalen Datenbanken die Datenbank-Modellierung gewissen Standards folgen (kann), was die Abstimmung erleichtert. (Bei komplexen Projekten, d.h. früher oder später sowieso, muss man ohnehin um die Einschränkungen fast jeder Datenbank "herumprogrammieren", insbesondere wenn die zu speichernden Daten sich relational eben nicht "optimal" darstellen lassen.)
Die "Append-Only"-Speicherung in NoSQL-Datenbanken erlaubt übrigens einige nette Optimierungen (z.B. bei der Replikation oder bei inkrementellen Backups), so dass diese Technik auch bei vielen SQL-Datenbanken eingesetzt wird (z.B. für Rollback-Logs für Transaktionen, oder für Master-Slave-Replikation).
Übrigens würde ich persönlich einen (auch studierten) "Wirtschaftsinformatiker" auf gar keinen Fall in die Nähe einer NoSQL-Datenbank lassen... - wer nicht das Wissen, die Erfahrung oder die Zeit hat, Algorithmen selbst zu entwickeln und zu optimieren, sollte besser eine "Standardsoftware" nehmen (="ORACLE"-Datenbank, ersatzweise "MySQL"). Alle anderen benutzen die Werkzeuge, die (im Rahmen der Umstände) das beste Ergebnis liefern, und Möglichkeiten zum Lernen neuer Techniken bieten.
Wenn man Interesse an der Informatik oder am Programmieren hat, kann man bei der Beschäftigung mit NoSQL-Datenbanken sehr viel lernen - selbst dann, wenn man diese später selbst nicht einsetzt. (Ähnliches gilt für diverse Programmiersprachen wie z.B. Ruby, Smalltalk oder Erlang.)
Schön und gut, aber du tust ja so, als würden Ruby und Erlang ja gar nicht in der Wirtschaft genutzt. Vor allem Erlang wird doch gar nicht so selten benutzt?
Fast alle möglichen Programmiersprachen (auch Smalltalk, Lisp, F# usw.) werden irgendwo mit Erfolg benutzt. Meine Bemerkung bezog sich darauf, dass (speziell auch in Deutschland) im kommerziellen Umfeld traditionell eher wenig "experimentiert" wird, und daher wohl eher Java, C/C++, Visual Basic, Javascript, PHP, Objective-C auf Macs und in Einzelfällen vielleicht höchstens noch Perl, Python und Shellscripts die "Brot-und-Butter"-Sprachen der meisten Programmierer hierzulande sein dürften.
Der Grund dafür ist natürlich auch, dass man bei den "Standarsprachen" weniger stark von "speziellen" Kenntnissen eines Einzelnen abhängig ist, also leichter sowohl Ersatz bei Ausfall/Kündigung als auch weitere Teammitglieder findet. Je mehr Leute sich also z.B. mit Smalltalk, Ruby, Erlang, Lua, Perl 6 usw. auskennen, desto größer werden die Chancen, dass man diese Sprachen (als angestellter Programmierer) auch in der eigenen Firma einsetzen kann (bzw. "darf").
Dieses "Henne-Ei"-Problem haben z.B. Perl 5, PHP und Objective-C erfolgreich gemeistert, und auch Lua (für die Embedded-Programmierung) sowie Python (u.a. durch Google) sind inzwischen vielerorts "erlaubt".
Grundsätzlich kann es nicht schaden, sich mit den Konzepten von möglichst vielen Programmiersprachen zumindest ein wenig auseinander zu setzen. Die viel zitierten objektorientierten "Design Patterns" sind z.B. in Smalltalk viel einfacher zu verstehen als in C++ oder Java - mehrere der "Patterns" umschiffen z.B. in Wirklichkeit Unzulänglichkeiten dieser Sprachen, und sind z.B. bei der Smalltalk-Programmierung überflüssig oder werden zu "trivialen" Einzeilern.
In diesem Zusammenhang ist evtl. das im Dezember erscheinende Buch "7 Languages in 7 Weeks" interessant. Der Verlag, die "Pragmatic Programmers", ist übrigens dadurch bekannt geworden, dass die beiden US-Programmierer schon sehr früh, vor über 10 Jahren, das erste professionelle (und gute) Ruby-Buch geschrieben und kostenlos online gestellt haben. Die meisten Smalltalk-Bücher gibt es übrigens inzwischen dank Prof. Stephane Ducasse auch kostenlos online; mir persönlich hat "SmallTalk Best Practice Patterns" des Smalltalk-"Gurus" und "Extreme Programming"-Erfinders Kent Beck für den Einstieg am Besten gefallen. (Anders als der Titel vermuten lassen würde, beschäftigt sich das Buch aber nicht mit "Design Patterns", sondern mit Tipps zu Sprachstil und Lesbarkeit von Smalltalk-Programmen. Mit den Design-Patterns beschäftigt sich, ebenfalls sehr gut, der dicke Wälzer "Design Patterns Smalltalk Companion".) Was Erlang angeht, kann ich das Buch "Programming Erlang" des Spracherfinders Joe Armstrong empfehlen; die (recht vielen) anderen neuen und teilweise in Auszügen schon verfügbaren Erlang-Bücher sind im Vergleich dazu von sehr gemischter Qualität.
Da fällt mir ein: eigentlich ist Smalltalk (wider Erwarten) sehr verbreitet, zumindest die grundlegenden Konzepte und ein Teil der Syntax, denn Objective-C ist im Prinzip eine "Smalltalk-Syntaxerweiterung" für C.
(Apropos C - angeblich soll es sich auch lohnen, sich mit "D" zu beschäftigen, weil das vieles richtig machen soll, was C++ und Java falsch machen - ob "D" aber irgendwann wirklich einmal zum Mainstream gehören wird, kann man jetzt wohl noch nicht sagen. Wie immer hängt es davon ab, wie viele Leute sich mit "D" grundlegend auskennen und darin programmieren möchten.)
Ich höre immer wieder von vielen Leuten, dass bei größeren Systemen Ruby on Rails ziemlich schlecht skaliert und arg träge wird. Bin mal gespannt wann von den ersten Performance-Problemen zu hören ist. Aber was soll's, alle coolen Kids benutzen Ruby...
Dann schreib deine Insiderinfos schnell an die New York Times, damit sie ihre Ruby-Entwickler feuern können.
Du willst ernsthaft das Trafficaufkommen der Popelwebsite New York Times mit der eines Socialnetwork vergleichen? Geht's noch? Selbst Facebook hat nen nativen Compiler entwickelt, weil ihnen PHP zu langsam war. Die Twitter-Entwickler hatten auch Probleme mit der RoR-Performance und mussten ne menge Arbeit investieren bis es eingermaßen schnell genug war. Und Twitter und Facebook ist die Größenordnung wo Diaspora mal hin will.
Denn das ist das Problem, bei solchen selbsterwählten Community Moderatoren/Administratoren.
Sie halten sich für unkündbar und erlauben sich daher alles, auch und insbesondere auch die Durchsetzung von Unrecht gegenüber Mitgliedern und die Bevorzugung von Freunden, Seilschaften und Co.
Am besten sieht man das an der Wikipedia und ihren Admins.
Bei einem Konzern wie Facebook ist das nicht so. Das Unternehmen ist riesig und es gibt Mitarbeiter, die den Admins und Moderatoren auf die Finger klopfen, wenn sie schlechte Arbeit leisten und Mitglieder aus persönlichen Gründen benachteiligen. Und genau deswegen kuschen die Mods und Admins dort, da sie ganz genau wissen, daß sie jederzeit gefeuert und durch Kompetenzpersonal ersetzt werden könnten.
Bei einem Social Netzwerk eines Konzern ist man also als Benutzer besser aufgehoben.
Netter Versuch. Aber das üben wir dann aber noch einmal
Tja, hier kannst du mir keine Benutzersperre verhängen und du weißt natürlich selber, das ich vollkommen Recht habe.
Es geht glaube ich nicht um Nachbarn. Alle Anbieter von Webcontent (Hoster etc) können dei Anbieter sein. Es liegen nicht mehr alle Daten bei einem, der diese dann verscherbeln kann.
Schwachsinnig finde gesichtsbuch & co. trotzdem
Blog und XMPP reichen, den Rest tauscht man einfach normal aus...
Dann mach halt selbst nen Node auf und spiel Diktator.
... ich habe von der ganzen technischen unterhalten wenig ahnung. ich bin user. und als user schon ganz lange weg bei facebook. aber jetzt von anfang an frisch mit dabei bei diaspora. und ich bin begeistert. it works. so soll es doch sein. für eine alpha ist das eine feine sache und kann nur noch immer besser werden. täglich. ich bin begeistert!
http://pod.geraspora.de/
anmelden und einfach sich selbst eine meinung bilden!!!