staging.inyokaproject.org

So, melde mich seit langem mal wieder, auch mit neuem Account.

In meiner Freizeit entwickelte ich anfang des Jahres ein Wiki, um während meines Praktikums die Dokumentation für Software besser zu erledigen. Jetzt steht ein Rewrite vor der Tür. Allerdings befand ich MySQL für die Datenspeicherung als nicht zutreffend, klar es geht, wollte aber nicht erst wieder anfangen, E/R-Modelle zu entwerfen. Durch das Chaosradio Express wurde ich auf noSQL-Datenbanken wie CouchDB aufmerksam. Das Konzept finde ich persöhnlich sehr interessant, ich entschied mich, eine für meine Bedürfnisse angepasste noSQL-Datenbank zu bauen, die alles in JSON-Dokumenten speichert. Nach ersten Anfängen mit C++ und krankheitsbedingter Auszeit entschied ich mich, das Projekt in Python 3 zu implementieren anstatt C++ (ich wollte mich nicht die ganze Zeit mit Buffer Overflows rumschlagen).

Der aktuelle Status: Die Datenbank funktioniert, allerdings hab ich sie fast ausschließlich auf Windows getestet, da ich hauptsächlich für Windows entwickle (Hab aber schon angefangen, mein Ubuntu Notebook wieder anzuwerfen, und mal eine Testumgebung deployet 😉 ). Das Problem ist derzeit noch das User Interface, also es gibt noch nicht all zu viele Befehle, mit denen man etwas anstellen kann. Auch gibt es noch keine richtige Netzwerkschnittstelle.

Was haltet ihr von noSQL-Datenbanken? Benutzt ihr sie in Projekten? Was sagt ihr zu meinem Projekt?

Sourcecode auf github: http://github.com/schultyy/AiDB/

Grüße, Jan =)

Ich denke, Du solltest vor allem erst mal das Repository aufräumen, Bytecode- und Backup-Dateien löschen, und das Ganze in ein Paket und das wiederum in anständige Distutils-Infrastruktur verpacken, damit man es auch einigermaßen sinnvoll installieren kann.

Im Quelltext ist auch einiges im Argen, es fängt schon damit an, dass Du Tabulatoren zur Einrückung nutzt. Dann fängst Ausnahmen nie gezielt ab, sondern pauschal und quittierst sie mit einem lapidaren "print". Sinnvolle Fehlerbehandlung sieht anders aus, und "print" hat in einer Bibliothek nichts verloren, Ausgaben in Bibliotheken tätigt man mittels logging. Dateien öffnet man mit dem with-Statement, damit sie garantiert wieder geschlossen werden. Das ist mir jetzt nur auf die Schnelle aufgefallen.

Von komplexeren, aber für ein derartiges Projekt dennoch essentiellen Dingen wie einer möglichst umfassenden Testsuite und einer Dokumentation ganz zu schweigen ...

Bei allem Respekt, aber in der gegenwärtigen Form ist das nicht brauchbar. Warum muss es überhaupt ein Eigenbau sein? An Redis oder Tokyio Cabinet wirst Du auf absehbare Zeit eh nicht herankommen. Davon abgesehen ist JSON keine solide Basis für eine Datenbank. Dieses Format ist als Austauschformat, nicht als Serialisierungsformat gedacht. Weder ist es besondere effizient beim Laden oder Speichern, noch sonderlich gut indizierbar, noch stellt es Mechanismen bereit, um Zyklen aufzulösen.

Danke für deine Antwort. Das Repository hab ich schon ein wenig aufgeräumt, Setup kommt noch. Zu der Sache mit den Tabs, ich habs bis jetzt immer so gemacht, und auch in den meisten Anleitungen und Büchern werden Tabs benutzt. Aber ich hab auch schon Spaces ausprobiert, allerdings macht mein Editor (auf Windows, Notepad++) dann trotzdem immer wieder Tabs dazwischen. Eine Doku gibt es, die wird allerdings nicht von git mitgetrackt, die liegt zurzeit nur auf der Platte bei mir. Irgendwie konnte ich mich mit Unit-Tests noch nicht so recht anfreunden. Das Prinzip dahinter verstehe ich, auch den Nutzen den man daraus zieht, hab auch schon versucht, das in Python Projekte mit zu integrieren, allerdings ohne Erfolg (warscheinlich hab ich mich zu doof angestellt).

Was währe anstatt JSON ein geeigneteres Format für die Dokumente?

Grüße, Jan

Lunar schrieb:

Davon abgesehen ist JSON keine solide Basis für eine Datenbank. Dieses Format ist als Austauschformat, nicht als Serialisierungsformat gedacht. Weder ist es besondere effizient beim Laden oder Speichern, noch sonderlich gut indizierbar, noch stellt es Mechanismen bereit, um Zyklen aufzulösen.

Du bist dir bewusst, dass MongoDB sehr erfolgreich auf JSON (BSON) setzt?

Ich bin auch nicht durch Zufall auf JSON gekommen, sondern weil ich gehört, zum Teil auch gesehen hab, das CouchDB JSON benutzt. Die haben am Anfang xml genommen, es dann aber verworfen, aufgrund des höheren Parsingaufwands und weil, so argumentieren die Entwickler, in deren Augen keine schöne Abfragesprache darauf bauen kann. Also es gibt ja XSLT und sowas, aber das wollten die halt nicht benutzen. Ich find JSON garnicht mal so schlecht für den Job. Also ich hab keinen großen Aufwand das zu verarbeiten, es gibt da ja Python Module die das lesen und schreiben können.

@Ein Stein: MongoDB nutzt BSON, und das hat mit JSON nicht mehr allzu viel zu tun (sieht man mal von der Ähnlichkeit der Schreibweise ab). JSON ist ein Textformat, BSON dagegen binär und wesentlich effizienter zu traversieren und zu parsen (Felder haben beispielsweise feste Längen oder explizite Längenpräfixe, Daten wie Zahlen werden binär kodiert und nicht als Text serialisiert).

@schultyy: CouchDB nutzt JSON für die API, sprich zur Kommunikation zwischen Datenbank und Client, nicht aber zur Speicherung.

@Lunar: Oh okay, dann war ich falsch informiert, sry =)

naja wie gesagt, ich bin gerade dabei das alles mal ein wenig aufzuräumen. werd mich auch noch mit Softwaretests befassen.

BSON ist vom Prinzip her sehr wohl JSON. Der Name "Binary JSON" ist schließlich nicht aus der Luft gegriffen. Die einzigen Unterterschiede besteht in der binären Codierung, dem Längen-Prefix und einer leicht größeren Auswahl an Datentypen.

Da es bei diesem Projekt allerdings wohl nicht auf Performance ankommt (Python 3!), ist es vollkommen in Ordnung, "normales" JSON zu verwenden.

Ein Stein schrieb:

Da es bei diesem Projekt allerdings wohl nicht auf Performance ankommt (Python 3!)

Ich finde, das mit der Performance kann man auf später verschieben, ich will erstmal nur ein funktionierenden Prototypen haben. Gibts denn Alternativen für die Datenspeicherung?

@Ein Stein: Meinetwegen können wir uns darauf einigen, dass BSON „vom Prinzip“ her JSON ist, es ist mir jetzt zu blöd, das auszudiskutieren. Letztlich könnte man ja auch genauso sagen, dass XML vom Prinzip her JSON ist ...

Die Unterschiede im Format sorgen jedenfalls dafür, dass man BSON effizient parsen und traversieren kann. Insbesondere kann man in den Daten navigieren, ohne sie komplett lesen zu müssen, und so auch große Daten oder viele Daten speichern. Mit JSON ist das nicht möglich, da muss man zumindest immer größere Teile des Dokuments lesen und parsen. Deswegen eignet sich BSON wesentlich besser zur Speicherung von Daten als JSON. JSON ist genau wie XML ein Austauschformat.

Ein Stein schrieb:

BSON ist vom Prinzip her sehr wohl JSON. Der Name "Binary JSON" ist schließlich nicht aus der Luft gegriffen. Die einzigen Unterterschiede besteht in der binären Codierung, dem Längen-Prefix und einer leicht größeren Auswahl an Datentypen.

Dieser kleine Unterschied dürfte sicherlich so 10x schneller zu parsen sein. In der Summe macht dass auch einen Unterschied wenn man sowas in Python implementiert.

schultyy schrieb:

Irgendwie konnte ich mich mit Unit-Tests noch nicht so recht anfreunden. Das Prinzip dahinter verstehe ich, auch den Nutzen den man daraus zieht, hab auch schon versucht, das in Python Projekte mit zu integrieren, allerdings ohne Erfolg (warscheinlich hab ich mich zu doof angestellt).

Das ist schade, weil Unit Tests (sofern richtig umgesetzt) einem einen Haufen Ärger ersparen können. Ich hab das lange Zeit auch als einen Mehraufwand statt Nutzen gesehen. Allerdings habe meine Meinung mittlerweile geändert.

Tatsächlich helfen sie einem nämlich dabei semantische Fehler schnell aufzudecken. Bei größeren Projekten ist es eine echte Erleichterung. Ich kann dir nur ans Herz legen, sowas von Anfang an einzubauen.

Wie man das in Python am Besten umsetzt sollte wahrscheinlich lieber einer der Python-Experten beantworten. Da bin ich zu wenig im Bilde.

Gruß Domi