Difference between revisions of "IDE architecture design"
From stgo
m (→Pro & Contra) |
(→Pro & Contra) |
||
| (4 intermediate revisions by one user not shown) | |||
| Line 59: | Line 59: | ||
|- | |- | ||
! performance (serving data => multi-access) | ! performance (serving data => multi-access) | ||
| − | | performance depends on server power, may be insufficient during concurrent access | + | | performance depends on server power, may be insufficient during concurrent access for multiple users |
| − | | data is located where highest demand is (concurrent access is not as high | + | | data is located where highest demand is (concurrent access is not as high = manageable) |
|- | |- | ||
! availability | ! availability | ||
| − | | if the main db fails, nobody can access | + | | if the main db fails, nobody can access the data |
| − | | if one group db fails, then the system still | + | | if one group db fails, then the system is still working for others (at least locally) |
|- | |- | ||
| − | ! scalability ( | + | ! scalability (new group with new data) |
| with a new group new data needs to be added, which may require lots of work hours (also w.r.t. Q/A) | | with a new group new data needs to be added, which may require lots of work hours (also w.r.t. Q/A) | ||
| easy to extend observatory by another database, if workload is done by the new group | | easy to extend observatory by another database, if workload is done by the new group | ||
|- | |- | ||
! geographic base-data (for maps) <br>(Well here we can also store base data on one particular assigned server) | ! geographic base-data (for maps) <br>(Well here we can also store base data on one particular assigned server) | ||
| − | | | + | | eays unified provision of one base-dataset for all |
| − | | same base-data on several servers? danger of inconsistencies | + | | same base-data on several servers? danger of inconsistencies (w.r.t. updates, etc.) |
|- | |- | ||
| − | ! quality assurance (geogr. data + metadata) | + | ! Q/A: quality assurance (geogr. data + metadata) |
| − | | one dedicated expert to check data quality (data description, accuracy) | + | | one dedicated GIS expert to check data quality (data description, accuracy) |
| − | | many experts necessary | + | | many GIS experts necessary |
|- | |- | ||
| − | ! documentation | + | ! documentation that describes how to access data |
| − | | one document to create | + | | one document to create |
| many documents to read and maintain | | many documents to read and maintain | ||
|- | |- | ||
| − | ! | + | ! IDE de Chile: availability of CEDEUS data |
| − | | fast to | + | | fast to inform SNIT about new data or updates |
| − | | | + | | requires first getting info on changes for each group |
| + | |- | ||
| + | ! => Summary | ||
| + | ! => fewer staff, well trained, less costly (hardware + staff) | ||
| + | ! => more staff, more costly, can save time for observatory team, easier to add a new group | ||
|} | |} | ||
| − | (see also [http://en.wikipedia.org/wiki/Distributed_database Distributed Database] and [http://en.wikipedia.org/wiki/Federated_database_system Federated Database System]) | + | (see also [http://en.wikipedia.org/wiki/Distributed_database Distributed Database] and [http://en.wikipedia.org/wiki/Federated_database_system Federated Database System], as well as the entry [http://en.wikipedia.org/wiki/Distributed_data_store Distributed Data Store] with examples on distributed non-relations DBs) |
Btw: I am not sure if it would make sense to '''''replicate''''' data of all group DBs to a central DB. However, this could be a strategy as well. | Btw: I am not sure if it would make sense to '''''replicate''''' data of all group DBs to a central DB. However, this could be a strategy as well. | ||
| Line 107: | Line 111: | ||
== Gestion de Acceso == | == Gestion de Acceso == | ||
| − | * al BD de datos (acceso directo: solo por expertos observatorio) | + | * acceso al BD de datos (acceso directo: solo por expertos observatorio) |
| − | * al visor de datos (login o diferente visores: publico sin login + otro con login y interfaz diferente) | + | * acceso al visor de datos (login o diferente visores: publico sin login + otro con login y interfaz diferente) |
| − | * al servicios de datos (WFS, WMS, WCS, etc) | + | * acceso al servicios de datos (WFS, WMS, WCS, etc) |
Latest revision as of 10:51, 7 November 2013
>> return to Cedeus IDE
What Architectural Models exist
A - Central Server-Database Architecture
El imagen abajo muestra una IDE simple, con 2 servidores:
- Servidor web con modulo de mapas en-linea, y con catalogo de datos
- Servidor con base de datos
B - Distributed Multi-DB Server Architecture
El proximo imagen muestra una IDE complejo, con 6 servidores (con base de datos multiples):
- 3+ Servidores de grupos de investigacion (con BD)
- 1 Servidor de Catalogo
- 1 Servidor de Mapas
- 1 Servidor con Base de Datos (Datos Centrales)
(es posible de user un servidor con el modulo de mapas juntos con la base de datos)
Pro & Contra
Yo hice el tabla abajo con criterios que yo veo importa. Después he incorporado puntos de una lista en ingles sobre "Advantages and Disadvantages of Distributed Database" on Wikipedia.
| criteria | single DB | multi DBs |
|---|---|---|
| server needs (registry server, web server, base-db server) | two servers (1 web server, one db server) | at least one web server, including a registry component (e.g. GeoNetwork), and many db-servers (one for each site) |
| maintenance needs (adding data, metadata, software updates) | one admin (one update) | many local admins (many updates) |
| user access control | central access control (to resolve access requests may take time) | each group decides about data access |
| user access management | one unified user rights management for all CEDEUS members (with 4 different access groups, e.g.: admin, cedeus member, invited, public) | each DB admin needs to create its own user management system and needs to ensure access by other CEDEUS groups (However, a replication of user access rights is possible) |
| data security (un-wanted access) | one dedicated data server that can only be accessed via a gateway; direct access by very few users only (obs. team) | many databases with different user groups and different users per computer |
| data backups (copias d. seguridad) | regular backup for only one db sever | requires complex backup strategy or one backup device for each location |
| power outages | one web server and one db server in the same place are easy to "secure" with a UPS | costly to provide UPS for several server locations |
| performance (serving data => multi-access) | performance depends on server power, may be insufficient during concurrent access for multiple users | data is located where highest demand is (concurrent access is not as high = manageable) |
| availability | if the main db fails, nobody can access the data | if one group db fails, then the system is still working for others (at least locally) |
| scalability (new group with new data) | with a new group new data needs to be added, which may require lots of work hours (also w.r.t. Q/A) | easy to extend observatory by another database, if workload is done by the new group |
| geographic base-data (for maps) (Well here we can also store base data on one particular assigned server) |
eays unified provision of one base-dataset for all | same base-data on several servers? danger of inconsistencies (w.r.t. updates, etc.) |
| Q/A: quality assurance (geogr. data + metadata) | one dedicated GIS expert to check data quality (data description, accuracy) | many GIS experts necessary |
| documentation that describes how to access data | one document to create | many documents to read and maintain |
| IDE de Chile: availability of CEDEUS data | fast to inform SNIT about new data or updates | requires first getting info on changes for each group |
| => Summary | => fewer staff, well trained, less costly (hardware + staff) | => more staff, more costly, can save time for observatory team, easier to add a new group |
(see also Distributed Database and Federated Database System, as well as the entry Distributed Data Store with examples on distributed non-relations DBs)
Btw: I am not sure if it would make sense to replicate data of all group DBs to a central DB. However, this could be a strategy as well.
Tipos de Usuarios
Tipo A - Ciudadanos
- tareas tipicos => permisos
Tipo B - Investigador CEDEUS
- tareas tipicos => permisos
Tipo C - Persona Invitado
- tareas tipicos => permisos
- accesso al unos datos especiales
Tipo D - Experto de Observatorio
- tareas tipicos => permisos
Gestion de Acceso
- acceso al BD de datos (acceso directo: solo por expertos observatorio)
- acceso al visor de datos (login o diferente visores: publico sin login + otro con login y interfaz diferente)
- acceso al servicios de datos (WFS, WMS, WCS, etc)
