Adoption of a Graph Database in the Insurance Sector - Jan-Frederik Wilhelm & Dr. Andreas Wandelt @...
-
Upload
neo4j-the-open-source-graph-database -
Category
Technology
-
view
790 -
download
0
description
Transcript of Adoption of a Graph Database in the Insurance Sector - Jan-Frederik Wilhelm & Dr. Andreas Wandelt @...
Adoption of a Graph-
Database in the Insurance
SectorJan-Frederik Wilhelm / Andreas Wandelt
Intelligent Solution Services AG
~ 50 employees
Base of operations: Marzling (near Munich)
Project teams: at HQ or onsite at customer location
Latest success: inSign (innovation award)
Dr. Andreas Wandelt
Head of Department
Technical Consulting
Jan-Frederik Wilhelm
Software Architect
Project „Bay4all“
What is this project dealing with?
– Critical sales system of an (bavarian)
insurance company
– 10 years old
– Weak spots:
Poor Performance
High maintenance cost
Redevelopment of system/architecture
Redesign architecture
Main tasks:
– Renewal of data layer which is used for
replication
– Usage of former customer project:
regarded to be nearly ready
10 months later …
– Remainings ?? no valid evaluation
possible
– Quality of data ? may be poorer than
expected
Extensive Review needed
Role of Neo4j
Neo4j – first experiences:
– Whiteboard-friendly
– Flexible
– Easy „first use“
– Graphical representation in Web-interface
Proof of Concept
Two candidates:
– Neo4j
– ObjectDB
Several obstacles for Neo4j:
– Existing IBM DB2 landscape
– Conservative insurance industry vs. Cutting edge-technology
– Unknown world of NoSQL-databases
– Startup
ORIGINAL DATA-MODEL (LEVEL 2)
RELATIONAL REPRESENTATION
ID 3611
TASKID 139982
OBJECTDESCID GUC0000BBV
USERNAME PKI5965
CHANGED 27.04.2010 09:48
VALIDFROM 23.04.2010 00:00
VALIDTO <null>
GENDATE 23.04.2010
ROOTID 3611
ROOTCLASSDESCID T000000DLV
PARENTID <null>
PARENTCLASSDESCID <null>
CHANGESTATE 0
BOSID AFIS.BP
BOSOBJECTID 102558199
BOSHISTORY <null>
REPLICATED 27.04.2010 09:48
BBVPLANER_PARTNERID <null>
DATA <?xml version="1.0" ...?><value-list><value id="Name"><![CDATA[Wilhelm]]></value>...</value-list>
PARTNERNR 102558199
NAME WILHELM
VORNAME JAN-FREDERIK
GESCHLECHT 2
FAMILIENSTAND 2
GEBURTSDATUM 20.03.1958
STAATSANGEHOERIGKEIT <null>
BERUF 921299
BERUFSSTATUS 70
me
ta d
ata
ext
ract
ed
dat
a
SCHEMALESS
Data-Model
Used throughout the system
(replication, persistence, UI-code, …)
Separate data-model for faster selections
(by nightly replication)
Authorization
extraction into tables – used by joins
(by nightly replication)
First Approach
Identified culprit: inadequate data model
Revival of abandoned project
– Relational approach
Failure
– Mapping at replication time
Basic Idea
Don‘t map (too) early
Don‘t lose content
Don‘t lose info about structure
Simplify the model where possible
Create a copy of the host-data?
Use the PM-data and map later
Basic Idea – Graph Database?
Four levels of abstraction in model
– One graph per abstraction layer
– Connections between the layers! (IS_A)
– Using levels like classes in the OO-mindset
Authorization data
– In same database
– Linked to domain nodes
Reuse of existing replication mechanisms
Initial Data Import
Extensive updates once a year
Fast replication needed
BatchInserter
Spring Data Neo4J not usable
Introduction of Schema
Labels in Neo4J 2.0
Classification of nodes
Simplification of cypher queries
Automatic indexing of label-properties
Domain Mapping
No 1:1 mapping of domain-model todatabase-model
Spring Data not usable
Blueprints Frames unknown not used
Custom mapping mechanism developed
– Annotations
– Generics
– Java Reflection API
Data Store
Indexing
Neo4J
P
M
transformationmessages in PM-datamodel
P
M
messages in graph-form
summary (i.e. key properties of a contract) basic mapping
Lucene
indexes
property collectionsTransactionEventHandler
single propertieslabel indexing
mVorname m/wName node-Adresse
w
Auer
Zöller
Karl
Eva
81517
58999
node-AdresseVertragsnummer
0000001
9990000
23114
44539
node-AdresseName
Auer
Zöller
81517
58999
exact search, combined search, (phonetic search)
keys, node-adresses
read/write data, navigate graph
nodes, relations, properties
Search
Queries use
– Authorization data
– Labels
– Indexes
– structural information
Performance-Requirements fullfilled
All requests manageable/solvable so far
What‘s next?
(Future) Benefits for project
Fast summary of an
agent‘s portfolio
Validation of PM-
messages
Analysis of the whole
portfolio
Reduction of work in
Host-System
Wishlist für Neo4J
More properties in
schema
Analysis of graph,
schema and indexes
(even) more tutorials
Further commitment to
new Web-UI
Overall results
Fast system
The performance for search requests is better thandemanded
Solution is accepted by the customer – project is saved
First productive usage of Neo4j within an insurancecompany
Usage of technology which really fits the domain-/technicalproblem
Discussions in an „interdisciplinarily“ team
Very good support by consulting team of Neo Technology
Thank you for attending…
What‘s useful in Neo4J 2.0 (for us)
Labels
Try with ressources (AutoClosableTransactions)
New Cypher Syntax
New Web-UI
Not sure if 2.0: ServerBuilder, LifeCycle-Stuff like TransactionEventHandler, Unmanaged Extensions, …
Surrounding technologies
Apache Camel for replication
Apache Jackrabbit for storing file-data
Jersey for REST
– Unmanaged extension
– Client