Ein Cache, der ein voll-ausgewachsenes RDBMS benötigt. Auf einem Desktopsystem. Hier läuft irgendetwas ganz gewaltig schief. Und geht sqlite jetzt doch? Auf der akonadi Seite stand kürlich noch etwas anderes, auch wenn ich den Patch kenne.
Schlimm genug, das amarok2 mysql als feste Abhängigkeit hat, aber das muß man ja nicht nutzen, gibt ja genug Alternativen. Akonadi zu vermeiden dürfte perspektivisch schwieriger werden. Und man schon einen Datenbankserver aufgezwungen bekommt und laufen haben muß, um eMails lesen zu können, die schon auf einem anderen Server in einer Datenbank gespeichert liegen, warum dann nicht gleich konsequent alles da reinpacken? Also auch das .kde Verzeichnis?
Ich hätte gerne verpflichtende Oracle Unterstützung für akonadi, damit ich endlich einen Grund habe, mir eine 16Kern CPU kaufen zu müssen. Ich bin mir sicher, für die oft zitierten High-Volume Mailinglisten ist Oracle gerade gut genug.
> Ein Cache, der ein voll-ausgewachsenes RDBMS benötigt. Auf einem Desktopsystem.
Was ist denn daran so schlimm? Ich als Anwender konnte jetzt noch keinen Unterschied feststellen. Bisher wird Akonadi zwar nur fürs Adressbuch genutzt aber es wird genutzt. Welche Nachteile entstehen mir denn jetzt dadurch, dass eine Datenbank genutzt wird? Oder macht sich das erst beim vielen Daten bemerkbar?
Wenn seine "Scheisskrücke" nicht genug Ressourcen hat, um MySQL auszuführen, machen auch andere Emaillcients auch keinen Spass (die müssen dasselbe, per Hand machen, und skalieren dabei oft wesentlich schlechter (nach oben *und* unten).
Ich würde den Kommentar nicht so Ernst nehmen, über Troll-aber-nicht-lesen-wollen Niveau kommt er meiner Ansicht nach nicht hinaus. Deshalb wohl auch anonym gepostet.
Wenn seine "Scheisskrücke" nicht genug Ressourcen hat, um MySQL auszuführen, machen auch andere Emaillcients auch keinen Spass (die müssen dasselbe, per Hand machen, und skalieren dabei oft wesentlich schlechter (nach oben *und* unten).
Das halte ich für ein Gerücht. Ein spezialisiertes Programm kann, wenn es für eine spezielle Aufgabenstellung zugeschnitten wird, immer schneller sein als eine general-purpose DB. Darüber hat Zawinski schon vor über 10 Jahren geschrieben, und er hat meiner Meinung nach heute noch Recht.
Mag sein, aber der Vorteil von Akonadi wurde ja schon benannt. Es stellt allen Applikationen den Zugriff auf die Daten zur Verfügung. So muss eben nicht jede Applikation denselben Aufwand erneut betreiben. Hat auch den Vorteil, dass sich Entwickler von Applikationen eben nicht mehr Gedanken über die effizienteste Implementierung machen müssen.
Mag sein, aber der Vorteil von Akonadi wurde ja schon benannt.
Was ein Vorteil ist und was nicht, liegt im Auge des Betrachters. Ich persönlich finde den Ansatz von Akonadi falsch. Klar ist es sinnvoll, wenn andere Programme Anfragen an bestimmte PIM Komponenten stellen können (so wie beim EDS), aber mit dem Ansatz, alle möglichen Protokolle vom Daemon selbst (bzw seinen Agenten) holen zu lassen und in eine Datenbank zu packen kann ich mich nicht anfreunden. Ich fände eine dezentrale Lösung besser, in der spezifiziert wird, welche Dienste und Anfragen die PIM Komponenten jeweils zur Verfügung stellen können.
In der Realität muss erstmal Akonadi beweisen, dass es einigermaßen mit MUAs mithalten kann, die auf Geschwindigkeit hin programmiert wurden (so wie es ja bei Akonadi auch der Fall sein soll).
Du könntest erwägen den Artikel zu lesen, dann brauchst du keine Annahmen zu verbreiten, die nicht mit der Realität übereinstimmen.
Akonadi "benötigt" kein vollausgewachsenes RDBMS, *kann* as aber benutzen. Der Resourcenverbrauch ist eh abhängig von den Daten, die du reinsteckst und rausholen willst. Ob das im Endeffekt ein embedded oder entfernter MySQL ist, PostGreSQL, sqlite, oder was auch immer, spielt dabei eine eher geringe Rolle.
Deine Rhetorik im Stile von "aufgezwungen", und der restliche Kommentar ist also eher uninformiert. Die Zeit hättest du besser benutzen können, Dich zu informieren.
Vielen Dank für Deine Antworten. Wenn ich kontact starte - KDE 4.4 - startet Akonadi grundsätzlich nicht und nervt ich mit einer Fehlermeldung: akonadi findet keine Resourcen.
Ich habe auf meinem System weger mysql noch postgresql noch deren libs installiert - brauche ich ja auch nicht nach Deiner Aussage. Denn beides sind vollausgewachsene RDBMS. Ohne jetzt eine Diskussion über mysql und deren Leistungsfähgikeit starten zu wollen.
Wie bekomme ich denn nun akonadi zum laufen? sqlite ist installiert, qt ist mit sqlite Unterstütung gebaut. akonadi will nicht, ich kann sqlite nicht mal auswählen.
Was tue ich dagegen? Ganz konkret?
Daher, zu meinen Annahmen eine offizielle Aussage, die Du sicher kennst: http://techbase.kde.org/Projects/PIM/Akonadi#Why_not_use_sqlite.3F
Ich wüßte nicht, was in Deinem Artkel steht, den ich sehr wohl gelesen habe, was meinen Aussgen irgendwie widerspricht. Du erwähnst sqlite als Backend, obiger Link und die Praxis sagen etwas anderes.
Es ist ein Cache, der ein SQL backend braucht. Laut Deinen Aussagen braucht es kein ausgewachsenes zu sein, also sind weder mysql noch postgres Pflicht. Ich habe beides nicht installiert und akonadi meckert.
sqlite soll laut Deinem Blog gehen, wird aber offiziell von abgeraten, siehe Link, und vor nicht allzu langer Zeit war die Unterstützung nicht offiziell, sondern ein Patch, "vorwiegend für mobile Geräte".
Also was nun? Abseits der üblich hohlen Trollschleimer, die sich hier wichtig tun, was ist verkehrt an meiner Aussage? Wie bekomme ich akonadi konkret ohne mysq oder postgresql zu laufen? Oder ist das eine Zukunftsversion?
Und warum können sich die verschiedenen Applikationen (Nepomuk, akonadi, config, amarok), die ein solches Backend nutzen, dann nicht wenigstens eine Datenbank teilen? Gut amarok ist nicht Bestandteil des KDE Projektes, aber wenn es eine API gäbe, würden sie die sicher nutzen.
Also, Butter bei die Fische. Gibt es nur pseudo anti troll bashing oder auch handfestes? Vielleicht habe ich ja etwas übersehen in Deinem Blog?
Oder zieht Ihr euch bloß daran hoch, das ich der Auffassung bin, auf einen Desktop system hat ein RDBMS nix zu suchen und ein solches Design ist schon daneben. Wenn das alles ist, dann feiert euch mal schön selbst weiter.
Die Concurrencyprobleme in sqlite sind wie's scheint weitgehend gelöst, damit ist der Weg frei, auch ein SQLite Backend zu nutzen (und das ist soweit ich weiss auch der Fall für Kontact mobile). Mit deinen Setupproblemen kannst du Dich am besten an die KDE PIM Liste wenden.
Ich stimme Dir auch zu, dass der Storagemechanismus über verschiedene Apps geteilt werden sollte. Ist noch nicht der Fall, wird aber in Zukunft hoffentlich weiter so fortgesetzt.
Ansonsten finde ich die Aussage "dass auf einem Desktopsystem ein RDBMS nix zu suchen hat" eher unglücklich, und stimme ihr auch ganz einfach nicht zu. Gleiches gilt übrigens für Polemik um die du nicht herumzukommen scheinst. :/
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 30. Aug 2010 um 19:53.
Wenn ich kontact starte - KDE 4.4 - startet Akonadi grundsätzlich nicht und nervt ich mit einer Fehlermeldung: akonadi findet keine Resourcen.
Vermutlich 4.4.4oder früher. Das Problem wurde in 4.4.5 behoben. Es wurden eigentlich sogar Ressourcen gefunden, aber das Programm welches Akonadi gestartet hat, bekam dies nicht mit.
Und warum können sich die verschiedenen Applikationen (Nepomuk, akonadi, config, amarok), die ein solches Backend nutzen, dann nicht wenigstens eine Datenbank teilen? Gut amarok ist nicht Bestandteil des KDE Projektes, aber wenn es eine API gäbe, würden sie die sicher nutzen.
Auf Akonadi trifft das noch viel mehr zu als auf Amarok, weil das ja immer noch ein KDE Programm ist, während Akonadi völlig unabhängig ist (es sitzt ja auch eine Stufe tiefer).
Generell ist das schon zumindest bei Nepomuk und Akonadi kein schlechter Ansatz, aber derzeit ist der SQL von Virtuoso (bzw. dessen Qt SQL Plugin) einfach noch nicht so weit um für Akonadi benutzbar zu sein.
Ich hatte auf der CeBIT 09 ein interessantes Gespräch mit einem Amarok Entwickler. Ich sprach ihn darauf an, wieso sie sich auf embedded MySQL festgelegt haben und als Quintessenz war wohl die Geschwindigkeit der ausschlaggebende Punkt. Ich fragte ihn dann nach einem ORM und der Möglichkeit dadurch beliebige RDBMS ansprechen zu können und musste dann erst einmal das ORM Konzept erläutern. Nun weiß ich nicht, ob es und was es an guten ORM für C++ gibt. Evtl. mag es an der Sprache liegen, dass man sich nicht für einen solchen Layer in Amarok entschieden hat - ich denke in Python hätte man definitiv auf sqlalchemy oder gar elixir gesetzt; das mag in C++ eben anders aussehen. Auf jeden Fall wäre es sicherlich mit dem Einsatz einfacher, die Verwendung beliebiger relationaler Datenbanken sicherzustellen.
Viel interessanter fände ich jedoch, wie es mit einem NoSQL-Backend für Akonadi aussehen könnte. Bei Emails und Kontakten muss ich immer sofort an Dokumente denken - da böte sich dann doch eine solche Datenbank an; MongoDB oder CouchDB wären da sicherlich eine lohnende Alternative.
Schade, dass ich in C++ nicht wirklich fit bin und zu wenig zeit habe
@sebas: Mach Dir nichts aus den Trollen und destruktiven Nörglern - es gibt auch Leser hier, die Deine Arbeit und die des gesamten KDE Teams toll finden und Deine Beiträge und Kommentare hier gerne lesen
Auf jeden Fall wäre es sicherlich mit dem Einsatz einfacher, die Verwendung beliebiger relationaler Datenbanken sicherzustellen.
Bei Akonadi wird praktisch so etwas gemacht. Aus einer Beschreibung der Datenobjekte in XML wird C++ Code für ihre Klassen und datenbankabhängig SQL Queries generiert (soweit ich mich richtig erinnere).
Leider gibt es speziell beim Setup als auch in einigen Abfragen Unterschiede, die man erst einmal händisch bearbeiten muss, bevor man neue Datenbanken unterstützen kann (sofern diese mal die Grundvorrausetzungen selbst erfüllen).
Viel interessanter fände ich jedoch, wie es mit einem NoSQL-Backend für Akonadi aussehen könnte. Bei Emails und Kontakten muss ich immer sofort an Dokumente denken - da böte sich dann doch eine solche Datenbank an; MongoDB oder CouchDB wären da sicherlich eine lohnende Alternative.
Ich bin jetzt in Bezug auf diese dokumentorientierten Datenbanken nicht so am Laufenden, bzw. wie gut sie Relationen abbilden und abfragbar machen. Müsste sich halt mal jemand ansehen, der in diesem Bereich Erfahrung hat.
"Der Resourcenverbrauch ist eh abhängig von den Daten, die du reinsteckst und rausholen willst."
Der Ressourcenverbrauch unter KDE4 ist auch von vielen anderen Faktoren abhängig, u.a. auch von verwendeten Nicht-KDE4-Programmen. Nach einem Distributionsupdate auf KDE 4.4.x ist bei mir das gesamte System minutenlang performancemäßig völlig eingebrochen. Ich wusste gar nicht, wie mir geschieht. Natürlich habe ich das erst auf die üblichen "Schuldigen" geschoben, auch Akonadi. Irgendwann einmal hatte ich dann im Distributions-Firefox unter about:config Einträge entdeckt, die im mozilla.com-Original nicht vorhanden sind. Hinzu kam, dass der von mir neu benutzte Thunderbird 3.x standardmäßig Cookies eingeschaltet hat, weswegen ich so sauer war, dass ich die gesamte Mozilla-Software vom Rechner gelöscht habe. Nur: Plötzlich war die Trägheit, das völlig Lahme, was bisher KDE4 ausgemacht hatte, verschwunden, wie weggeblasen. Der Grund für die KDE4-Trägheit: Es lag am standardmäßig aktivierten Nachrichtenindizierer in Thunderbird 3 ("Globale Suche und Nachrichtenindizierung"). So verliert man Nutzer.
Ein Cache, der ein voll-ausgewachsenes RDBMS benötigt. Auf einem Desktopsystem. Hier läuft irgendetwas ganz gewaltig schief. Und geht sqlite jetzt doch? Auf der akonadi Seite stand kürlich noch etwas anderes, auch wenn ich den Patch kenne.
Schlimm genug, das amarok2 mysql als feste Abhängigkeit hat, aber das muß man ja nicht nutzen, gibt ja genug Alternativen. Akonadi zu vermeiden dürfte perspektivisch schwieriger werden. Und man schon einen Datenbankserver aufgezwungen bekommt und laufen haben muß, um eMails lesen zu können, die schon auf einem anderen Server in einer Datenbank gespeichert liegen, warum dann nicht gleich konsequent alles da reinpacken? Also auch das .kde Verzeichnis?
Ich hätte gerne verpflichtende Oracle Unterstützung für akonadi, damit ich endlich einen Grund habe, mir eine 16Kern CPU kaufen zu müssen. Ich bin mir sicher, für die oft zitierten High-Volume Mailinglisten ist Oracle gerade gut genug.
> Ein Cache, der ein voll-ausgewachsenes RDBMS benötigt. Auf einem Desktopsystem.
Was ist denn daran so schlimm?
Ich als Anwender konnte jetzt noch keinen Unterschied feststellen. Bisher wird Akonadi zwar nur fürs Adressbuch genutzt aber es wird genutzt. Welche Nachteile entstehen mir denn jetzt dadurch, dass eine Datenbank genutzt wird? Oder macht sich das erst beim vielen Daten bemerkbar?
Gruß
Seine Scheißkrücke hat offenbar nicht genug Ressourcen um MySQL auszuführen, das ist sein einziges Problem
Wenn seine "Scheisskrücke" nicht genug Ressourcen hat, um MySQL auszuführen, machen auch andere Emaillcients auch keinen Spass (die müssen dasselbe, per Hand machen, und skalieren dabei oft wesentlich schlechter (nach oben *und* unten).
Ich würde den Kommentar nicht so Ernst nehmen, über Troll-aber-nicht-lesen-wollen Niveau kommt er meiner Ansicht nach nicht hinaus. Deshalb wohl auch anonym gepostet.
Mag sein, aber der Vorteil von Akonadi wurde ja schon benannt. Es stellt allen Applikationen den Zugriff auf die Daten zur Verfügung. So muss eben nicht jede Applikation denselben Aufwand erneut betreiben. Hat auch den Vorteil, dass sich Entwickler von Applikationen eben nicht mehr Gedanken über die effizienteste Implementierung machen müssen.
Joah, bei unlimitierten Ressourcen zur Implementierung ist's sicherlich richtig. Die Realität jedoch ...
Du könntest erwägen den Artikel zu lesen, dann brauchst du keine Annahmen zu verbreiten, die nicht mit der Realität übereinstimmen.
Akonadi "benötigt" kein vollausgewachsenes RDBMS, *kann* as aber benutzen. Der Resourcenverbrauch ist eh abhängig von den Daten, die du reinsteckst und rausholen willst. Ob das im Endeffekt ein embedded oder entfernter MySQL ist, PostGreSQL, sqlite, oder was auch immer, spielt dabei eine eher geringe Rolle.
Deine Rhetorik im Stile von "aufgezwungen", und der restliche Kommentar ist also eher uninformiert. Die Zeit hättest du besser benutzen können, Dich zu informieren.
Vielen Dank für Deine Antworten. Wenn ich kontact starte - KDE 4.4 - startet Akonadi grundsätzlich nicht und nervt ich mit einer Fehlermeldung: akonadi findet keine Resourcen.
Ich habe auf meinem System weger mysql noch postgresql noch deren libs installiert - brauche ich ja auch nicht nach Deiner Aussage. Denn beides sind vollausgewachsene RDBMS. Ohne jetzt eine Diskussion über mysql und deren Leistungsfähgikeit starten zu wollen.
Wie bekomme ich denn nun akonadi zum laufen? sqlite ist installiert, qt ist mit sqlite Unterstütung gebaut. akonadi will nicht, ich kann sqlite nicht mal auswählen.
Was tue ich dagegen? Ganz konkret?
Daher, zu meinen Annahmen eine offizielle Aussage, die Du sicher kennst:
http://techbase.kde.org/Projects/PIM/Akonadi#Why_not_use_sqlite.3F
Ich wüßte nicht, was in Deinem Artkel steht, den ich sehr wohl gelesen habe, was meinen Aussgen irgendwie widerspricht. Du erwähnst sqlite als Backend, obiger Link und die Praxis sagen etwas anderes.
Es ist ein Cache, der ein SQL backend braucht. Laut Deinen Aussagen braucht es kein ausgewachsenes zu sein, also sind weder mysql noch postgres Pflicht. Ich habe beides nicht installiert und akonadi meckert.
sqlite soll laut Deinem Blog gehen, wird aber offiziell von abgeraten, siehe Link, und vor nicht allzu langer Zeit war die Unterstützung nicht offiziell, sondern ein Patch, "vorwiegend für mobile Geräte".
Also was nun? Abseits der üblich hohlen Trollschleimer, die sich hier wichtig tun, was ist verkehrt an meiner Aussage?
Wie bekomme ich akonadi konkret ohne mysq oder postgresql zu laufen? Oder ist das eine Zukunftsversion?
Und warum können sich die verschiedenen Applikationen (Nepomuk, akonadi, config, amarok), die ein solches Backend nutzen, dann nicht wenigstens eine Datenbank teilen? Gut amarok ist nicht Bestandteil des KDE Projektes, aber wenn es eine API gäbe, würden sie die sicher nutzen.
Also, Butter bei die Fische. Gibt es nur pseudo anti troll bashing oder auch handfestes? Vielleicht habe ich ja etwas übersehen in Deinem Blog?
Oder zieht Ihr euch bloß daran hoch, das ich der Auffassung bin, auf einen Desktop system hat ein RDBMS nix zu suchen und ein solches Design ist schon daneben.
Wenn das alles ist, dann feiert euch mal schön selbst weiter.
Die Concurrencyprobleme in sqlite sind wie's scheint weitgehend gelöst, damit ist der Weg frei, auch ein SQLite Backend zu nutzen (und das ist soweit ich weiss auch der Fall für Kontact mobile). Mit deinen Setupproblemen kannst du Dich am besten an die KDE PIM Liste wenden.
Ich stimme Dir auch zu, dass der Storagemechanismus über verschiedene Apps geteilt werden sollte. Ist noch nicht der Fall, wird aber in Zukunft hoffentlich weiter so fortgesetzt.
Ansonsten finde ich die Aussage "dass auf einem Desktopsystem ein RDBMS nix zu suchen hat" eher unglücklich, und stimme ihr auch ganz einfach nicht zu. Gleiches gilt übrigens für Polemik um die du nicht herumzukommen scheinst. :/
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 30. Aug 2010 um 19:53.Vermutlich 4.4.4oder früher. Das Problem wurde in 4.4.5 behoben. Es wurden eigentlich sogar Ressourcen gefunden, aber das Programm welches Akonadi gestartet hat, bekam dies nicht mit.
Auf Akonadi trifft das noch viel mehr zu als auf Amarok, weil das ja immer noch ein KDE Programm ist, während Akonadi völlig unabhängig ist (es sitzt ja auch eine Stufe tiefer).
Generell ist das schon zumindest bei Nepomuk und Akonadi kein schlechter Ansatz, aber derzeit ist der SQL von Virtuoso (bzw. dessen Qt SQL Plugin) einfach noch nicht so weit um für Akonadi benutzbar zu sein.
Ich hatte auf der CeBIT 09 ein interessantes Gespräch mit einem Amarok Entwickler. Ich sprach ihn darauf an, wieso sie sich auf embedded MySQL festgelegt haben und als Quintessenz war wohl die Geschwindigkeit der ausschlaggebende Punkt. Ich fragte ihn dann nach einem ORM und der Möglichkeit dadurch beliebige RDBMS ansprechen zu können und musste dann erst einmal das ORM Konzept erläutern. Nun weiß ich nicht, ob es und was es an guten ORM für C++ gibt. Evtl. mag es an der Sprache liegen, dass man sich nicht für einen solchen Layer in Amarok entschieden hat - ich denke in Python hätte man definitiv auf sqlalchemy oder gar elixir gesetzt; das mag in C++ eben anders aussehen. Auf jeden Fall wäre es sicherlich mit dem Einsatz einfacher, die Verwendung beliebiger relationaler Datenbanken sicherzustellen.
Viel interessanter fände ich jedoch, wie es mit einem NoSQL-Backend für Akonadi aussehen könnte. Bei Emails und Kontakten muss ich immer sofort an Dokumente denken - da böte sich dann doch eine solche Datenbank an; MongoDB oder CouchDB wären da sicherlich eine lohnende Alternative.
Schade, dass ich in C++ nicht wirklich fit bin und zu wenig zeit habe
@sebas: Mach Dir nichts aus den Trollen und destruktiven Nörglern - es gibt auch Leser hier, die Deine Arbeit und die des gesamten KDE Teams toll finden und Deine Beiträge und Kommentare hier gerne lesen
Bei Akonadi wird praktisch so etwas gemacht. Aus einer Beschreibung der Datenobjekte in XML wird C++ Code für ihre Klassen und datenbankabhängig SQL Queries generiert (soweit ich mich richtig erinnere).
Leider gibt es speziell beim Setup als auch in einigen Abfragen Unterschiede, die man erst einmal händisch bearbeiten muss, bevor man neue Datenbanken unterstützen kann (sofern diese mal die Grundvorrausetzungen selbst erfüllen).
Ich bin jetzt in Bezug auf diese dokumentorientierten Datenbanken nicht so am Laufenden, bzw. wie gut sie Relationen abbilden und abfragbar machen.
Müsste sich halt mal jemand ansehen, der in diesem Bereich Erfahrung hat.
"Der Resourcenverbrauch ist eh abhängig von den Daten, die du reinsteckst und rausholen willst."
Der Ressourcenverbrauch unter KDE4 ist auch von vielen anderen Faktoren abhängig, u.a. auch von verwendeten Nicht-KDE4-Programmen.
Nach einem Distributionsupdate auf KDE 4.4.x ist bei mir das gesamte System minutenlang performancemäßig völlig eingebrochen. Ich wusste gar nicht, wie mir geschieht. Natürlich habe ich das erst auf die üblichen "Schuldigen" geschoben, auch Akonadi.
Irgendwann einmal hatte ich dann im Distributions-Firefox unter about:config Einträge entdeckt, die im mozilla.com-Original nicht vorhanden sind. Hinzu kam, dass der von mir neu benutzte Thunderbird 3.x standardmäßig Cookies eingeschaltet hat, weswegen ich so sauer war, dass ich die gesamte Mozilla-Software vom Rechner gelöscht habe.
Nur: Plötzlich war die Trägheit, das völlig Lahme, was bisher KDE4 ausgemacht hatte, verschwunden, wie weggeblasen.
Der Grund für die KDE4-Trägheit:
Es lag am standardmäßig aktivierten Nachrichtenindizierer in Thunderbird 3 ("Globale Suche und Nachrichtenindizierung").
So verliert man Nutzer.