From bb2e9ceef8c0af5b8fd4eb44b63943b2bcb85d79 Mon Sep 17 00:00:00 2001 From: Vipin Jain Date: Mon, 4 Jun 2018 09:11:27 +0530 Subject: [PATCH 1/2] Corrected typo error --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index f44b5f44f..834284df1 100644 --- a/README.md +++ b/README.md @@ -21,13 +21,13 @@ Current stable release is able to persist the following sources of data in the f * NGSI-like context data in: * [HDFS](http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/HdfsUserGuide.html), the [Hadoop](http://hadoop.apache.org/) distributed file system. - * [MySQL](https://www.mysql.com/), the well-know relational database manager. + * [MySQL](https://www.mysql.com/), the well-known relational database manager. * [CKAN](http://ckan.org/), an Open Data platform. * [MongoDB](https://www.mongodb.org/), the NoSQL document-oriented database. * [STH Comet](https://github.com/telefonicaid/IoT-STH), a Short-Term Historic database built on top of MongoDB. * [Kafka](http://kafka.apache.org/), the publish-subscribe messaging broker. * [DynamoDB](https://aws.amazon.com/dynamodb/), a cloud-based NoSQL database by [Amazon Web Services](https://aws.amazon.com/). - * [PostgreSQL](http://www.postgresql.org/), the well-know relational database manager. + * [PostgreSQL](http://www.postgresql.org/), the well-known relational database manager. * [Carto](https://carto.com/), the database specialized in geolocated data. * Twitter data in: * [HDFS](http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/HdfsUserGuide.html), the [Hadoop](http://hadoop.apache.org/) distributed file system. From bd9855a9578c8709442eb46affb003cdf1da1438 Mon Sep 17 00:00:00 2001 From: Vipin Jain Date: Mon, 4 Jun 2018 09:20:29 +0530 Subject: [PATCH 2/2] Corrected typo error --- doc/architecture.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/architecture.md b/doc/architecture.md index 97e97299c..a894836ab 100644 --- a/doc/architecture.md +++ b/doc/architecture.md @@ -1,5 +1,5 @@ # Cygnus architecture -Cygnus runs Flume agents. Thus, Cygnus agents architecture is Flume agents one. Let's see how this architecture ranges from the most basic configuration to the most complex one. +Cygnus runs Flume agents. Thus, Cygnus agents' architecture is Flume agents' one. Let's see how this architecture ranges from the most basic configuration to the most complex one. ## Flume architecture As stated in [flume.apache.org](http://flume.apache.org/FlumeDeveloperGuide.html): @@ -15,7 +15,7 @@ As stated in [flume.apache.org](http://flume.apache.org/FlumeDeveloperGuide.html ## Basic Cygnus agent architecture The simplest way of using Cygnus is to adopt basic constructs/flows of source - channel - sink as described in the Apache Flume documentation. There can be as many basic constructs/flows as persistence elements, i.e. one for HDFS, another one for MySQL, etc. -For each one of this flows, a [`HttpSource`](http://flume.apache.org/FlumeUserGuide.html#http-source) has to be used. The way this native sources process the Orion notifications is by means of a specific REST handler: `NGSIRESTHandler`. Nevetheless, this basic approach requires each source receives its own event notifications. This is not a problem if the architect clearly defines which flows must end in a HDFS storage, or in a Carto storage, if talking about a NGSI agent. But, what happens if the same event must be stored at HDFS and Carto at the same time? In this case, the constructs are modified in order all of them have the same Http source; then, the notified event is replicated for each channel connected to the source. +For each one of this flows, a [`HttpSource`](http://flume.apache.org/FlumeUserGuide.html#http-source) has to be used. The way this native sources process the Orion notifications is by means of a specific REST handler: `NGSIRESTHandler`. Nevertheless, this basic approach requires each source receives its own event notifications. This is not a problem if the architect clearly defines which flows must end in a HDFS storage, or in a Carto storage, if talking about a NGSI agent. But, what happens if the same event must be stored at HDFS and Carto at the same time? In this case, the constructs are modified in order all of them have the same Http source; then, the notified event is replicated for each channel connected to the source. Regarding the channels, in the current version of Cygnus all of them are recommended to be of type [`MemoryChannel`](http://flume.apache.org/FlumeUserGuide.html#memory-channel), nevertheless nothing avoids a [`FileChannel`](http://flume.apache.org/FlumeUserGuide.html#file-channel) or a [`JDBCChannel`](http://flume.apache.org/FlumeUserGuide.html#jdbc-channel) can be used.