DB für CRM
-
Ich glaube, das mit den Emails war nur ein Beispiel zum Vergleich vom TE. Aber ich habs geschrieben, weil ich mit dem Vergleich eben nichts anfangen kann. Ich kenne kein System, wo ich 9 Mrd Mails schnell durchsuchen könnte. Ich kenne eben nur Outlook mit Exchange, und da dauert schon das Durchsuchen weniger tausend Emails zig Sekunden.
Ansonsten sind Mrd irgendwas schon eine halbwegs realistische Größenordnung bei einem CRM. Ich weiß nur nicht, ob das dann Objekte sind, die man Durchsuchen will. Wenn eine Aktivität z.B. eine Werbeaktion ist, die an 10% der Kunden ging, dann hat man nicht 25 000 Objekte, sondern 1, und 25 000 Verknüpfungen. Wie dann die Suche implementiert ist, ist eine andere Frage. Und die 25 000 Adressen muss man wahrscheinlich auch nicht holen, sondern vielleicht die ersten 100.
Ich glaub, bei CRM Systemen gibts andere Operationen, die länger als das Suchen dauern. z.B. Löschen war bei paar Systemen, mit denen ich gearbeitet habe, echt langsam.
-
Warum wieder CRM? Naja, weil der Kunde eins beauftragt hat.
Es ist zwar ein kundenspezifisches Projekt, allerdings wird es danach (hoffentlich) an weitere Kunden vertrieben.Geplante Entwicklungszeit ist ein Jahr mit einem Im Kern 8 Personen starken Team und 16 Entwicklern, die bei Engpässen aushelfen, eigentlich aber andere Projekte bearbeiten.
So wie die Spezifikation aussieht, würde ich gefühlt sagen, ein Entwickler könnte die in einem Jahr auch umsetzen. Da fehlt mir aber sicherlich auch noch die Erfahrung das richtig einzuschätzen.
Dem Auftraggeber ist die Datenbank erstmal egal. Wichtig ist nur, dass es wirklich flott geht. Das System, was der Kunde bisher einsetzt ist Extrem langsam. Die aktuelle Kunden-DB ist 4TB groß. Vorhanden ist Dort eine Windows Server Architektur.
Beauftragt bin ich nun, DBMS möglichkeiten zu evaluieren. Know how hat unsere Firma bisher nur in MS-Sql. Allerdings auch eher in kleinen Datenbanken um die 20 GB größe.
Der Projektleiter würde gerne auf eine Datenbank setzen, und dafür dann lieber die Features richtig ausnutzen.
In der damaligen Firma bin ich nicht mehr tätig und kann da nichts mehr Optimieren. Weiß nur noch von dort, dass die Suchen immer recht lange gedauert haben. Die Tabelle mit den Aktivitäten hatte dort ca 30 spalten und das Ergebnis einer Suchen waren meist zwischen 80 und 250 Ergebnisse.
Leider muss ich sagen, dass ich kein Muster-Student war und mir viel Know how fehlt. Deshalb muss ich jetzt in viele Arbeiten die ich mache extrem viel Zeit rein stecken und viel von Zuhause in der Freizeit machen, was anders wäre, wenn ich damals richtig aufgepasst hätte.
PS:
Sind keine 9 mrd Mails. Sind ca 50k Mails pro Benutzer. In dem alten System wurde das nicht unterschieden. Da waren auch Rechnungen drin, die durch eine SAP Schnittstelle erstellt wurden, da waren Telefonate drin, die eine TAPI-Schnittstelle automatisch rein gepumpt hat, alle Geschäftsbriefe, alle Termine, normale Notizen, alle Emails die Marketing rausgeschickt hat, Todos die entstanden wenn der Empfänger die Mail gelesen hat, wenn er einen Link in der Mail geklickt hat etc.
Hat Marketing ein Mailing an 100.000 Adressen verschickt hat das für 300.000 Einträge in der DB gesorgt. Alleine Akquiseaufgaben für Seller entstanden jeden Tag ca 2000 Stück, von denen nur 250 am ende benötigt wurde. Aber alles ist in der DB geblieben.Das System was wir jetzt bauen wird sehr ähnlich funktionieren. Also genau so viel Daten produzieren. Finde ich auch nicht ungewöhnlich für ein CRM. Wenn wir Datenübernahmen gemacht haben, waren die Datenbanken immer ähnlich groß.
PS2: Löschen war in dem System was ich betreut habe auch extrem langsam. Aber ein CRM soll ja nicht löschen.
PS3:
Wenn eine Aktivität z.B. eine Werbeaktion ist, die an 10% der Kunden ging, dann hat man nicht 25 000 Objekte, sondern 1, und 25 000 Verknüpfungen
Doch das werden 25000 Objekte. Jede Email wird ja anhand der Kundeninfo personalisiert rausgeschickt. Da kann man die nicht einfach verknüpfen.
-
wtfwpf schrieb:
Doch das werden 25000 Objekte. Jede Email wird ja anhand der Kundeninfo personalisiert rausgeschickt. Da kann man die nicht einfach verknüpfen.
Natürlich kann man das Verknüpfen. Dafür gibts Serienbriefe. Ich bin mir sicher, dass schlaue CRM Systeme das genauso machen. Ich bin mir jetzt nicht mehr 100% sicher (ist schon Jahre her), aber ich glaub, das CRM System mit dem wir hauptsächlich gearbeitet haben hat das auch so gemacht.
wtfwpf schrieb:
Geplante Entwicklungszeit ist ein Jahr mit einem Im Kern 8 Personen starken Team und 16 Entwicklern, die bei Engpässen aushelfen, eigentlich aber andere Projekte bearbeiten.
So wie die Spezifikation aussieht, würde ich gefühlt sagen, ein Entwickler könnte die in einem Jahr auch umsetzen. Da fehlt mir aber sicherlich auch noch die Erfahrung das richtig einzuschätzen.
Aber du bist auch nicht der, der das geschätzt hat? Da ihr zumindest ein so großes Team habt, hoffe ich doch, dass jemand bei euch auch in der Lage ist, das richtig einzuschätzen. Wenn ihr das alles im Detail versteht, könnte das machbar sein. Wobei ich persönlich da sehr skeptisch wäre. Zum einen, was den Umfang angeht (ich weiß nicht, ob ihr wirklich ein "richtiges" komplettes CRM schreiben wollt, aber wenn, dann gibts da oft sehr sehr viele Sachen, die man berücksichtigen muss). Zum anderen, ist ein Jahr schon sehr knapp, auch wenn mehrere Leute dran arbeiten. Vor allem kann man solche Projekte in der Anfangsphase schlecht parallel entwickeln. Da müsste das jemand schon bis ins letzte Detail geplant haben, halte ich für zumindest unwahrscheinlich.
Nur zum Vergleich, wir sind etwa 30 Entwickler in der Arbeit (+ x Leute QA) und wir machen auch ungefähr ein Release pro Jahr. Und wir entwickeln nicht jedesmal ein komplett neues System from Scratch, wir arbeiten alle an unserem System, das schon alle Entwickler kennen. Der Umfang der Änderungen ist wahrscheinlich überschaubarer als bei euch und auf jeden Fall viel besser einschätzbar, und trotzdem ist es jedesmal sehr knapp.
-
Natürlich kann man das Verknüpfen. Dafür gibts Serienbriefe.
Es gab halt Platzhalter die ersetzt wurde. Verknüpfen wäre sicher auch gegangen. Aber es wäre nicht so leicht gewesen, da man den Brief / die Mail vor ersetzen der Platzhalter hätte speichern müssen, und dann jedes Mal beim suchen hätte ersetzen müssen. Aber auch das bringt Probleme. Ändert ein Kontakt die Firmierung stimmen die Daten nicht mehr. Das es so gemacht wurde, wurde jedenfalls auch entschieden, da hab ich noch nicht an Computer gedacht.
Aber du bist auch nicht der, der das geschätzt hat?
Gott bewahre. Das ganze Projekt wurde in Arbeitspakete aufgeteilt, diese wurden dann an alle 24 C# Entwickler gegeben und diese haben für jedes Paket eine Schätzung abgegeben. Im Anschluss sind die Pakete an das Java Team gegangen (ich glaube noch mal ca.15 Entwickler), die nochmal geschätzt haben wie lange sie brauchen würden wenn sie das in C# machen müssten (Damit man auch nen pessimistischen Anteil hat). Daraus hat die Projektleitung dann iwie einen Mittelwert gebildet und dann so viele Entwickler drauf gesetzt, dass es in ein Jahr passt.
QA ist bei uns auch extra. Aber wir haben nur 3 Leute für QA und die müssen auch noch die anderen Projekte Testen. Das ist natürlich kritisch. Aber da drüber kann ich mir nicht auch noch den Kopf zerbrechen ^^Ende der zweiten Januar-Woche ist die Iteration zu ende und ich muss meine Ergebnisse vorstellen. Im Moment würde ich sagen, ich empfehle MS-Sql, weil wir da Leute haben die sich auskennen und wir uns nicht noch in ein neues DBMS einarbeiten müssen. Da der Fokus aber ganz klar auf dem Performance/Preis verhälltnis liegt, wüsste ich nicht, wie ich MS-Sql begründen soll im Vergleich zu Oracle oder MaxDB oder so.
-
Käme bei einem CRM nicht auch eine NOSQL-Datenbank in Frage, wie z.B. MongoDB: CRMs and Business Process Applications on MongoDB?
-
Klar kommt auch NoSQL in Frage. Habe ich NoSQL mit DB2 nicht schon im Spiel?
Zukunftssichere Vielseitigkeit mit NoSQL Graph Store und Datenbanksynchronisation und Support für IBM Mobile
Oder habe ich das hier falsch verstanden?
Ist MongoDB als Enterprise System nutzbar? Gibt es da Erfahrungen? Wie sieht es da aus mit Backup-Möglichkeiten?
MongoDB ist mir bisher nicht als klassischer Big-Player im Kopf. Auch mit Googlen habe ich jetzt erstmal auf Anhieb keine Enterprise-Anwendung finden können. Andererseits wird sie in deinem Link ja explizit als gut geeignet für CRM genannt.
-
Nein, DB2 ist ein klassisches Uralt-RDBMS. Die wollen nur auch ein grünes Häkchen in der Feature-Liste neben "NoSQL" haben.
MongoDB finde ich nicht allzu prickelnd:
http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/
http://cryto.net/~joepie91/blog/2015/07/19/why-you-should-never-ever-ever-use-mongodb/wtfwpf schrieb:
Im Moment würde ich sagen, ich empfehle MS-Sql, weil wir da Leute haben die sich auskennen und wir uns nicht noch in ein neues DBMS einarbeiten müssen.
Klingt doch nach einem sehr guten Argument. Abgesehen davon ist der MS SQL-Server auch mit C# und der restlichen Microsoft-Toolchain sehr bequem zu verwenden.
Ich persönlich bin großer Postgres-Fan für sehr viele Anwendungsfälle, aber in deinem Fall klingt der SQL-Server doch ziemlich passend. Hast du irgendwo besondere Bedenken?
Ich verstehe das Performance/Preis-Argument wohl nicht ganz; Oracle ist sehr sehr sehr teuer und die Preise von MaxDB werden auch nicht ganz ohne sein. Zudem ist mir letzteres auch nicht gerade als Speed demon bekannt.
-
Ich würde auch zum Sql Server tendieren. Bzw., ich würd versuchen das möglichst datenbankunabhängig zu machen, aber mit dem Sql Server anfangen. Oracle und DB2 sind wohl kaum billiger als der Sql Server.
Bei einem CRM seh ich den Vorteil von einem NoSql System jetzt nicht. Jedenfalls würde ich damit jetzt nicht anfangen, das ist etwas, wo man sich erst einarbeiten und das ganze evaluieren muss und das ist für so eine "Spielerei" nicht zielführend, wenn man so wenig Zeit hat.Habt ihr schon Erfahrung mit Projekten solcher Größenordnung? Ich kann mir schlecht vorstellen, dass das Aufteilen in Arbeitspakete bei neuen Projekten auf die Weise funktioniert. Es gibt eine Kernfunktionalität und es gibt viel, was darauf aufbaut. Bis die Kernfunktionalität steht, werden viele erstmal warten müssen. Oder irgendwas mit Schnittstellen und Mockups schreiben, was sie dann wieder umbauen werden müssen, wenn die anderen fertig sind. Und dann wird man feststellen, dass vieles so wie man das gedacht hat, nicht funktioniert, weils z.B. eben zu langsam ist.
-
Habe jetzt nur den ersten Artikel gelesen. Finde den hervorragend geschrieben. Der Artikel ist echt fesselnd. Frage mich allerdings wie das Wort "Zeitgeist" in diesen Artikel gekommen ist.
Jedenfalls finde ich die Begründung absolut einleuchtend. Sehe die Problematik schon wenn ich nur Grob über das Schema nachdenke. Ein CRM besteht ja quasi aus Verknüpfungen.Klingt doch nach einem sehr guten Argument. Abgesehen davon ist der MS SQL-Server auch mit C# und der restlichen Microsoft-Toolchain sehr bequem zu verwenden.
Klar. Hinzu kommt, dass sowohl wir, als auch der Kunde bereits Lizenzen für die Enterprise-Version haben.
Ich persönlich bin großer Postgres-Fan für sehr viele Anwendungsfälle, aber in deinem Fall klingt der SQL-Server doch ziemlich passend. Hast du irgendwo besondere Bedenken?
Auch in dem Artikel ist ja Postgre SQL genannt. Was macht Postgre SQL denn für dich so vorteilhaft?
Habe bei MS-Sql bloß bedenken weil ich mal gesehen habe wie lange es gedauert hat, die 9 mrd Einträge zu durchsuchen.Alles in allem scheint das Thema der richtigen Datenbank komplexer als ich dachte. Gefühlt würde ich sagen, dass das Thema der Performance noch garnicht an der Reihe ist, da noch viel zu viele Informationen fehlen. Es kommt mir fast so vor, als könne man die Zeit der Recherche besser in das Evaluieren von Anforderungen und die Userbehaviour Analyse stecken als in DBMS.
Ich verstehe das Performance/Preis-Argument wohl nicht ganz
Naja, wir möchten natürlich viele Kunden erreichen. Heißt, für Kleinkunden wäre es schön, wenn die DB kostenfrei wäre und unter Linux läuft. Wenn der Kunde für die Software zahlt und dann noch 10.000€ investieren muss um Windows Server / SQL Server 2014 Lizenzen + einen Admin der das einrichtet zu erhalten ist das ein Grund Abstand zu nehmen. Wenn der Kunde aber weiß, das ganze geht mit Debian und einer anderen DB Kostenfrei so das er "nur" den Admin zum aufsetzen benötigt, lässt er sich vermutlich eher auf einen Kauf ein.
Mittelständigen ist das weniger wichtig. Dort sind die 10k€ für auch noch über wenn man die Software kauft. Mal abgesehen davon dass vermutlich eh schon ein Admin im unternehmen ist.
Bei Großkunden ist dann auch noch mehr als die 10k€ über. Allerdings ist wichtig, dass das System auch noch mit 50mrd Datensätzen in akzeptabler Zeit umgehen kann.
Optimal wäre also eine DB die Staffel-Lizenzen hat. Sagen wir mal 500€ für Kleinstkunden, 5k€ für Medium-Enterprise Ansprüche und 50k€ für Real-Enterprise Ansprüche.
Das ist, was ich mit Performance/Preis Verhältnis meine.Habt ihr schon Erfahrung mit Projekten solcher Größenordnung?
Kann ich schwer sagen. Bin selbst noch nicht lange da. Seit ich da bin haben wir eher an kleinen Projekten gearbeitet (so 20 Manntage). Aber soll Mitte letzen Jahres auch ein Projekt gegeben haben, bei dem alle 24 C#-Entwickler 7 Monate an einem Projekt gearbeitet haben, was hätte 6 Monate dauern sollen. Also ganz unerfahren scheint die Projektleitung nicht zu sein.
Es wird so funktionieren, dass es ein Kernstück gibt was AddIns läd. z.B. ein Adressen-AddIn. Dieses wird sich um fast alles was es benötigt selbst kümmern.
Dann wird es ein ToDo AddIn geben, dies Benötigt quasi nur Adressen. Heißt es kann ohne das Adressen-AddIn nicht arbeiten, da es keine Adressen anfragen kann.
Insgesamt wird es 6 AddIns geben die den Kern abbilden, die immer da sein müssen und standardmäßig ausgeliefert werden.
Ist jetzt etwas vereinfacht ausgedrückt. Aber im Prinzip gewährleistet dieses Vorgehen, dass alle 7 Teile parallel entwickelt werden können sobald die Schnittstellendefinition steht.
Ob das Konzept aufgeht kann ich nicht sagen. Für mich ist das alles recht neu, da ich nur Kleinprojekte und Wartung eines Großprojektes kenne.
-
wtfwpf schrieb:
Alles in allem scheint das Thema der richtigen Datenbank komplexer als ich dachte.
Nicht nur das, wahrscheinlich werden noch sehr viele ähnlicher Fragen aufkommen.
Naja, halt uns mal auf dem Laufenden!
-
wtfwpf schrieb:
Auch in dem Artikel ist ja Postgre SQL genannt. Was macht Postgre SQL denn für dich so vorteilhaft?
Kurz: Der Slogan "The world's most advanced open source database" stimmt, die Codequalität und Doku sind sehr sehr gut und Postgres ist extrem zuverlässig.
Habe bei MS-Sql bloß bedenken weil ich mal gesehen habe wie lange es gedauert hat, die 9 mrd Einträge zu durchsuchen.
Und warum glaubst du, dass ein anderes RDBMS beim selben Schema, den selben Daten und der selben Anfrage bei Größenordnungen von 9 Mrd. Records signifikant schneller wäre?
Bei Großkunden ist dann auch noch mehr als die 10k€ über. Allerdings ist wichtig, dass das System auch noch mit 50mrd Datensätzen in akzeptabler Zeit umgehen kann.
Glaube ich nicht. Großkunden haben dann eben eine Instanz pro Tochterfirma oder Niederlassung oder …
Optimal wäre also eine DB die Staffel-Lizenzen hat. Sagen wir mal 500€ für Kleinstkunden, 5k€ für Medium-Enterprise Ansprüche und 50k€ für Real-Enterprise Ansprüche.
Dann nehmt eben SQLite für Kleinkunden und SQL Server für alles größere.
-
Und warum glaubst du, dass ein anderes RDBMS beim selben Schema, den selben Daten und der selben Anfrage bei Größenordnungen von 9 Mrd. Records signifikant schneller wäre?
Naja, weil es vielleicht einfach besser ist. Möglicherweise gehen andere DBMS anders mit Daten um, sind anders organisiert, oder oder oder. Würde ich ein DBMS entwickeln, und da wären 9 mrd Einträge drin, würde es sich wohl dumm und dusselig suchen, einfach weil ich keine Ahnung von Optimierung habe.
Denke mal ich werde MS-Sql vorschlagen. Der vorteil ist einfach, dass sich die Mitarbeiter gut damit auskennen. Wenn die DBMS sich nicht viel nehmen, und Oracle vllt 5% schnelle wäre, dann braucht man auch einen der sich gut genug auskennt um die 5% rauszuholen. Und da sich keiner auskennt, ist die Wahrscheinlichkeit größer das man es langsamer baut. Bis wir da das know how haben, haben wir die hälfte vermutlich vermurkst. Und aufrüsten müssten wir auch noch. Wo wir doch schon mehr VMs laufen haben als Mitarbeiter im Unternehmen sind.
-
Auch Enterprise-Software-Hersteller kochen nur mit Wasser. Manche auch mit lauwarmem und großer Marketing-Abteilung.
wtfwpf schrieb:
Denke mal ich werde MS-Sql vorschlagen. Der vorteil ist einfach, dass sich die Mitarbeiter gut damit auskennen.
Gute Idee.
Wo wir doch schon mehr VMs laufen haben als Mitarbeiter im Unternehmen sind.
Das ist nicht allzu ungewöhnlich.
-
wtfwpf schrieb:
Und warum glaubst du, dass ein anderes RDBMS beim selben Schema, den selben Daten und der selben Anfrage bei Größenordnungen von 9 Mrd. Records signifikant schneller wäre?
Naja, weil es vielleicht einfach besser ist. Möglicherweise gehen andere DBMS anders mit Daten um, sind anders organisiert, oder oder oder. Würde ich ein DBMS entwickeln, und da wären 9 mrd Einträge drin, würde es sich wohl dumm und dusselig suchen, einfach weil ich keine Ahnung von Optimierung habe.
Datenbanken können nicht zaubern. Gibt aber dennoch genügend Entwickler die glauben das wäre doch so. Bzw. die so arbeiten als wäre es so. Wenn die dann die DB entwerfen und die Applikation dazu entwickeln, dann kann man froh sein wenn die Suche nur 10 Sekunden dauert - egal mit welcher Datenbank. Wenn die Entwickler aber wissen "wie man es richtig macht", dann wird eine schnelle Suchfunktion auch kein unerreichbares Ziel sein. Wiederrum egal mit welcher Datenbank. Notfalls muss man eben andere Tools ala Lucene dranknoten.
wtfwpf schrieb:
Denke mal ich werde MS-Sql vorschlagen.
Würde ich an deiner Stelle vermutlich auch.
-
[quote="hustbaer"]
wtfwpf schrieb:
Datenbanken können nicht zaubern.
Da ist mir grad eine Software eingefallen, über die es mal eine Kurznotiz in der c´t gab. Die wird als Datenbanktreiber angesprochen und fungiert als Proxy zur richtigen Datenbank. Dabei führt sie Statistiken über die Anfragen und kann sie mit der Zeit optimieren. Da stand was von bis zu Faktor 1000. Das Teil war glaub ich sauteuer.
Wohl auch so ein Tool, um ganz schlecht programmierte Datenbankanwendungen nachträglich zu verbessern. Wobei ich mir auch nicht so ganz vorstellen kann, wie das funktioniert. Der Proxy müsste zumindest zusätzliche Indexe anlegen können, und ob er das kann/darf ging da nicht so wirklich hervor.
-
Ich stimme nman voll und ganz zu. PostgreSQL ist grossartig. Es ist einfach in jeder Hinsicht besser als MySQL. Es ist kostenlos und auf allen relevanten Plattformen verfügbar.
Sqlite ist für kleine Sachen auch sehr gut geeignet. Es ist halt sehr einfach zu administrieren.
Wenn beim Kunden MS-SQL im Einsatz ist, ist das allerdings das Killerargument. Keine andere Datenbank ist so viel besser oder schneller als MS-SQL, dass sich ein Umstieg wirklich lohnen würde.
Ansonsten: immer schön Datenbankneutral programmieren. Dann kann man die Datenbank später zur Not auch austauschen.
-
tntnet schrieb:
Ansonsten: immer schön Datenbankneutral programmieren. Dann kann man die Datenbank später zur Not auch austauschen.
Ich glaube dazu muss man mindestens Tests (Unit-Tests, Integrationstests, ...) mit einer zweiten DB machen. Sonst stehen die Chancen wohl sehr schlecht dass man später noch einfach umsteigen kann.
(OK, ein Tool das alle SQL Statements prüft und meldet sobald ein non-Standard Feature verwendet wird würde vermutlich auch reichen - weiss nicht ob es so etwas gibt.)
-
Es muss ja nicht mal komplett datenbankneutral sein. Ich hätte oftmals auch keine Lust, auf datenbankspezifische Features zu verzichten. Aber man braucht eine Zwischenschicht für die Datenbankzugriffe. Dann kanns von mir aus eine Implementierung für den MS-SQL, für Orace und für PostgreSql geben. In der jeweiligen Schicht kann man dann auch spezielle Features benutzen, um die Performance usw. zu verbessern.
-
Ich verstehe das Problem nicht so ganz. Ich kenne SQL und weiss, was ich damit machen kann. Und meine SQL-Abfragen sind praktisch immer Datenbankneutral.
Welche Features nutzt ihr denn, welches sich mit Standard-SQL nicht abbilden lässt?
Mag sein, dass man mit speziellen Features noch mal ein wenig Performance raus holen kann, aber in der Regel ist das nicht so viel, dass es relevant wäre.
Die Datentypen sind in den Datenbanken unterschiedlich. Da hat man dann verschiedene DDLs für die einzelnen Datenbanken, aber der Applikation selbst sollte das nichts ausmachen.
-
Ich hab grad kein konkretes Beispiel. Geht auch nicht unbedingt um einfache Queries. Aber z.B. so Sachen wie Volltextsuche, temporäre Tabellen, hierarchische Daten vom Sql Server usw. Dann vielleicht ein bisschen Logik in Triggern und Stored Procedures implementieren. Kann sich durchaus lohnen.
