IDE architecture design - Revision history

Mentaer: /* Pro & Contra */

2013-11-07T13:51:16Z

‎Pro & Contra

Mentaer: /* Pro & Contra */

2013-11-07T13:45:57Z

‎Pro & Contra

Mentaer: /* Pro & Contra */

2013-11-07T13:42:01Z

‎Pro & Contra

Mentaer: /* Gestion de Acceso */

2013-11-07T13:36:52Z

‎Gestion de Acceso

Mentaer: /* Pro & Contra */

2013-11-07T13:34:28Z

‎Pro & Contra

Mentaer: /* Pro & Contra */

2013-11-07T13:26:56Z

‎Pro & Contra

Mentaer: /* Pro & Contra */

2013-11-07T13:24:35Z

‎Pro & Contra

Mentaer: /* Pro & Contra */

2013-11-05T21:39:57Z

‎Pro & Contra

Mentaer: /* Pro & Contra */

2013-11-05T21:19:14Z

‎Pro & Contra

Mentaer: /* Pro & Contra */

2013-11-05T21:07:35Z

‎Pro & Contra

@@ Line 91: / Line 91: @@
 |}
-(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.

@@ Line 86: / Line 86: @@
 | requires first getting info on changes for each group
 |-
-! Summary
+! => Summary
-| fewer staff, well trained, less costly (hardware + staff)
+! => fewer staff, well trained, less costly (hardware + staff)
-| more staff, more costly, can save time for observatory team, easier to add a new group
+! => more staff, more costly, can save time for observatory team, easier to add a new group
 |}

@@ Line 85: / Line 85: @@
 | fast to inform SNIT about new data or updates
 | requires first getting info on changes for each group
 |}

@@ Line 107: / Line 107: @@
 == 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)

@@ Line 59: / Line 59: @@
 |-
 ! 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, manageable)
+| data is located where highest demand is (concurrent access is not as high = manageable)
 |-
 ! availability
-| if the main db fails, nobody can access his data
+| if the main db fails, nobody can access the data
-| if one group db fails, then the system still works (at least locally)
+| if one group db fails, then the system is still working for others (at least locally)
 |-
-! scalability (adding new data from new group)
+! 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) <br>(Well here we can also store base data on one particular assigned server)
-| easier to provide one base-dataset
+| 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 for accessing data
+| one document to create
 | many documents to read and maintain
 |-
-! availability info on data: to IDE de Chile
+! IDE de Chile: availability of CEDEUS data
-| fast to update info on data availability for IDE de Chile
+| fast to inform SNIT about new data or updates
-| additional work to gather changes in data availability at different locations
+| requires first getting info on changes for each group
 |}

@@ Line 52: / Line 52: @@
 ! data backups (copias d. seguridad)
 | regular backup for only one db sever
-| requires complex backup strategy or one backup devices at each location
+| requires complex backup strategy or one backup device for each location
 |-
 ! power outages

@@ Line 47: / Line 47: @@
 |-
 ! data security (un-wanted access)
-| one dedicated data server that can only be accessed via a gateway and by only very few users
+| 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
 |-

@@ Line 22: / Line 22: @@
 == Pro & Contra ==
-Yo hice el tabla abajo con criterios que yo veo importa. Sin embargo, después encontre una lista en ingles sobre "Advantages and Disadvantages of [http://en.wikipedia.org/wiki/Distributed_database Distributed Database]" on Wikipedia.
+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 [http://en.wikipedia.org/wiki/Distributed_database Distributed Database]" on Wikipedia.
 {| class="wikitable" border="1"
@@ Line 37: / Line 37: @@
 | one admin (one update)
 | many local admins (many updates)
 |-
 ! user access management
@@ Line 54: / Line 58: @@
 | costly to provide UPS for several server locations
 |-
-! performance (serving data => scalability vs. multi-access)
+! performance (serving data => multi-access)
 | performance depends on server power, may be insufficient during concurrent access
-| people will access (concurrent access is not very likely)
+| data is located where highest demand is (concurrent access is not as high, manageable)
 |-
 ! geographic base-data (for maps) <br>(Well here we can also store base data on one particular assigned server)
@@ Line 70: / Line 82: @@
 | many documents to read and maintain
 |-
-! availablity info on data: to IDE de Chile
+! availability info on data: to IDE de Chile
 | fast to update info on data availability for IDE de Chile
 | additional work to gather changes in data availability at different locations
@@ Line 76: / Line 88: @@
 (see also [http://en.wikipedia.org/wiki/Distributed_database Distributed Database] and [http://en.wikipedia.org/wiki/Federated_database_system Federated Database System])
 == Tipos de Usuarios ==

← Older revision		Revision as of 21:19, 5 November 2013
Line 21:		Line 21:

	== Pro & Contra ==		== Pro & Contra ==
		+
		+	Yo hice el tabla abajo con criterios que yo veo importa. Sin embargo, después encontre una lista en ingles sobre "Advantages and Disadvantages of [http://en.wikipedia.org/wiki/Distributed_database Distributed Database]" on Wikipedia.

	{\| class="wikitable" border="1"		{\| class="wikitable" border="1"