GOCDB evolution plans

GAG, 22/09/2008Gilles Mathieu

Outline

• Current situation and context• Data access standardization• Architecture evolution• Provisional plan

Current situation and context

• Standard development work– Dev and maintenance are “on tracks”– Good progress on failover

• Evolution requirements– Standardization– Convergence– Distribution

Data access standardization

• All tier tools use direct DB connection– Need to maintain accounts and

passwords– Not really failover-compliant– No transparent change in the DB schema

• We need standard access through services and/or APIs…– …and this is not a scoop, really

Data access standardization

• Objective in 1 month– Study possibilities – provide a suitable implementation plan

• Objective in 2 months– Implement/prototype chosen solution– In parallel, provide sustainable set of PL/SQL

functions

• Objective in 6 to 8 months– Progressively replace external use of PL/SQL

functions – Get rid of all direct DB connection

E.g. get downtimes per region

• NowSELECT DOWNTIMES.DOWNTIME_ID, DOWNTIMES.CLASSIFICATION, DOWNTIMES.SEVERITY, DOWNTIMES.DESCRIPTION, CONCAT (FORENAME, CONCAT

('' '', SURNAME)) AS CREATOR_NAME, UNIX_TIMESTAMP(DOWNTIMES.ACTUALSTARTDATE) AS STARTDATE, UNIX_TIMESTAMP (DOWNTIMES.ACTUALENDDATE) AS ENDDATE, CONCAT(DOWNTIME_PATHS.PATH,''.'') AS TARGET_PATH, SITES_VIEW.SITENAME, NODES_VIEW.HOSTNAME

FROM DOWNTIMES LEFT JOIN DOWNTIME_PATHS ON (DOWNTIME_PATHS.DOWNTIME_ID = DOWNTIMES.DOWNTIME_ID) LEFT JOIN USERS ON (DOWNTIMES.USER_ID = USERS.USER_ID) LEFT JOIN SITES_VIEW ON (DOWNTIME_PATHS.PATH = SITES_VIEW.PATH) LEFT JOIN NODES_VIEW ON (NODES_VIEW.PATH = DOWNTIME_PATHS.PATH) WHERE (DOWNTIME_PATHS.PATH = :path) OR (DOWNTIME_PATHS.PATH LIKE CONCAT(CONCAT(:path, ''.''),''%'')) ORDER BY DOWNTIME_PATHS.PATH

• In December 2008– select * from table(list_downtimes_per_entity('Italy'));

• In April 2009– $mygocdb->getDowntimesPerEntity(‘Italy”);

• In January 2012– Could you please give me all downtimes for Italy?– Of course, here you are.– Thanks.

Architecture evolution

• The distribution issue, or how to ensure:– Easy deployment and maintenance– Communication between instances– Data synchronization and cross-querying – General coherence in case of problem

• A possible solution– Object-oriented DB design– Use of standard DB technologies

Architecture evolution• Main idea

– Move the physical aspects of the DB into ‘meta-data’– Maintain links and table info outside of the actual

data tables– Data can be:

• Accessed in a uniform way • changed with minimal, or no, changes to the actual design

• Benefits– Faster deployment– Standard data access routines– Ability to grow the system without the need to

redesign or re-implement the actual database.

Architecture evolution

• Objective in 1 month– Produce a detailed design study

• Objective in 4 to 6 months– Prototype the solution in test/dev– Work on a distribution use case (NGS)

• Objective in 8 months– Have at least a fully working regional

instance in parallel with central DB

Summary: provisional plannow

Oct.08

Dec.08

Apr.09

Oct.09

Apr.10

Plans for web services, APIs and general architecturePlans for web services, APIs and general architecture

- Distribution use case study- First service implementation- On going work on DB prototype

- Distribution use case study- First service implementation- On going work on DB prototype

- Large scale tests on DB prototype- Working regional instance for NGS- No more external direct DB access

- Large scale tests on DB prototype- Working regional instance for NGS- No more external direct DB access

- New model in production- More distributed instances working- New model in production- More distributed instances working

Go to bedGo to bed