Adhesive framework series-MongoDB data service module usage (I)

Previously introduced applicationsProgramAll logs, exceptions, performance, and status data in the information center module depend on the MongoDB data service. The interfaces of the MongoDB data service are also simple:

 
Public InterfaceImongodbinsertservice: idisposable {VoidInsert (ObjectITEM );}
 

In short, no matter what data, submit it in! All you need to do before submitting is to design the data entity and label some metadata attribute for the object to tell the MongoDB data service how to save the data and how to present the data. Because the users of MongoDB data service are developers, this article will introduce these attributes in detail from the perspective of programs.ArticleThe general background of MongoDB data service is described in detail.

First, let's take a look at the mongodbpersistenceentity feature defined on the class, which defines object-related configurations:

Note that the class is defined on the root class that directly serves as the object to be submitted. If a class contains a subclass, it makes no sense to define this feature on the subclass. Each parameter is described separately.

First, categoryname: required and cannot contain. And _. Using the MongoDB data background, let's take a look at the role of the category name:

For example, if we have a large amount of business and non-business data and it is obviously inconvenient to view them together, we can define the AIC category and State Classification to classify the relevant data. For example, click AIC category here to see:

The Chinese name here is displayname, and the actual database name is name. If the name is not defined, it is the class name. If the displayname is not defined, it is the name. Therefore, both name and displayname are not required. Let's take a look at the definition comparison of loginfo:

 
[Mongodbpersistenceentity ("AIC", Displayname ="Log", Name ="Log")]
 

In the database, the database name is composed of categoryname + two underscores + name, and the database is split by month:

Database sharding by month can reduce the data volume of each database, and facilitate independent deletion and backup of each database for easy O & M.

Finally, let's take a look at the expiredays configuration. It can configure how soon the data will expire and be automatically deleted. If our log data only needs to be retained for one year, you only need to set it to 365 days. Logs that expire after one year (depending on the time column in the data) will be deleted. You can configure different expiration times for different types to facilitate O & M.

 

Next, let's take a look at the mongodbpersistenceitem feature defined on the attribute. It defines some configurations designed to be persistent:

For convenience, all data items that need to be saved to the database must be attributes. Each parameter is optional here:

1. columnname: name of the column actually stored in the database. If you review the previous article, we can find that to reduce the data size, we have defined columnname for many columns to use a concise representation, such as log message:

Because we know that MongoDB uses JSON-like data to store data, and each data item stores the column name, the shorter the column name, the smaller the storage space occupied. If this parameter is omitted, the attribute name is used as the column name.

2. iscontextidentitycolumn: this is an interesting design. Sometimes we commit a lot of data in a request, such as two program logs, one handled exception, two service logs, and one WCF client call log, one message log for the WCF client. Is there any way to connect them? So that we can view other logs when we see a log? You can use a column and mark it as the context identifier column. In this way, the data can be viewed in the background in a unified manner. For example, the actinfo column in the application information center has the following columns:

For example, in the background, we can directly query all associated data based on a context ID:

Here we can see that, the same request of this log also generates an exception, a slow request data, a WCF client exception, a WCF client message, a WCF server exception, and a WCF Server Message (should is faultmessage):

The data records in the entire request are connected in a string. Is it very intuitive?

3. isignore: whether to ignore it, that is, whether it is not saved to the database. RememberCodePerformance measurement entity:

Here, our SW and threadtime are only used as the temporary data for computing and do not need to be kept in the database. Therefore, we set them to ignore.

4. isprimarykey: whether it is a primary key. It is important to define a primary key. Otherwise, the system does not know which column to use when viewing details. A type must have only one primary key. After learning about all the features, we will introduce the configuration constraints in a unified manner.

5. istablename: whether it is the table name. If this column is the table name, the column data will be used as the basis for table sharding. We usually split the service name or application name as the table name (first, determine the database by category + Data Type + time, then, the tablename column is used to determine the table sharding. If not defined, General is used as the table name, that is, all data in a table. In the background, we also select the database and then the table:

Corresponding to the database is:

Of course, database sharding by year and month is transparent to users.

6. istimecolumn: whether it is a time column. The Time column determines the database sharding and the timeline dependent columns in the statistical view (several views of the data will be introduced later. Because a class can have multiple time columns, you must explicitly mark a Time column, which serves as the basis for database sharding.

7. mongodbindexoption: There are several ways to index a column:

  Public   Enum  mongodbindexoption { //    // No index   ///   none = 0,  //    // incremental index   ///   ascending = 1,  ///    // drop index   ///   descending = 2,  //    // unique incremental index   //   ascendingandunique = 3,  ///    // unique descending index   //   descendingandunique = 4 ,} 

There are two main types: unique and not unique. For example, the primary key must be unique. If the primary key already exists, the data will be deleted. For example, for fields that need to be searched and sorted, the indexes it creates cannot be unique. As for the index direction, it depends on the sorting direction. For example, we usually search for data in descending order of date, then the index of this column should be set to a descending index, otherwise the effect will be compromised.

 

Finally, let's take a look at the mongodbpresentationitemattribute feature that is also defined on the attribute. It determines how the column is displayed in the background:

1. Description: The description of a column. This information is displayed on the detailed data display page.

2. displayname: friendly display name of the column. For example, we can use a Chinese character to define the display name of a column:

This is the most commonly used.

3. showintableview: whether to display in the List View. Each view will be introduced later.

4. mongodbcascadefilteroption, which is an enumeration and defined as follows:

Public EnumMongodbcascadefilteroption {/// <Summary>/// Not used for cascading Filtering/// </Summary>None = 0,/// <Summary>/// Level 1 of cascading Filtering/// </Summary>Levelone = 1,/// <Summary>/// Level 2 of cascading Filtering/// </Summary>Leveltwo = 2,/// <Summary>/// Level 3 of cascading Filtering/// </Summary>Levelthree = 3 ,}
 

For all attributes on a data entity plane (which cannot be a subclass of an attribute, but can be a derived class), you can set three of them to a classification with a three-level linkage relationship, for example:

In this way, you can use cascading to filter data. The background effect is as follows:

5. mongodbfilteroption, which is also an enumeration, is defined as follows:

 
Public EnumMongodbfilteroption {/// <Summary>/// Not used as a filter Condition/// </Summary>None = 0,/// <Summary>/// Single-choice filtering in the drop-down list/// </Summary>Dropdownlistfilter = 1,/// <Summary>/// Check box multiple filtering/// </Summary>Checkboxlistfilter = 2,/// <Summary>/// Text box search and filtering/// </Summary>Textboxfilter = 3 ,}
 

This setting determines that columns can be searched by single choice, multiple choice, or text. For example, in the application information center, our extrainfo contains the following filter columns:

The background effect is as follows:

6. mongodbsortoption: it determines the sorting rules for data presentation in the List View. For example, we define that all data in the application information center is in descending order of date:

When viewing data in the background, check whether the sorting is as follows:

 

We have previously introduced showintableview settings, indicating that columns are displayed in the List View. Here we will introduce several types of background data presentation views defined:

1. Multiple data entries are displayed in a table. Since it is a table, it is certainly impossible to display data of several hundred columns. Therefore, the data displayed here is generally a carefully selected data, or filter data. For example, you can check the data displayed for a loginfo:

We can see that all data except log messages is indexed for filtering data. The information shown in the table is sufficient. The definitions of abatractinfo and loginfo are listed in the previous article. You can compare them. You can also see that because displayname is configured, the table header is displayed in Chinese.

2. Data is presented in a curve Statistical Chart. For example:

Here, we query the data volume statistics for a week, where each point is one hour. Such data volume statistics are useful in the following scenarios:

1) for business data, we need to browse the changes in business volume.

2) for monitoring data, do we need to browse a certain log (such as exception log) to see if there is a large amount of data.

It must be noted that the statistical data of multiple tables can be displayed on a graph here. If we think of the table name as a business type or any other type, we can make analogy statistics.

3. Collect statistics by group and present them in a pie chart, for example:

For example, we want to know what data is mostly in the log data during the peak hour. Click to enter the group statistics. Most of the data is the error log generated by the IP address 192.168.134.187. In this case, you can locate the problem on the server. Why is there a problem with the other servers? It is likely not a program issue, but a server-specific issue, such as a full disk and full memory. So why are these groups? Which data is automatically grouped for statistics, which will be described later.

4. Status view. The so-called status view is for status data. This type of data has a feature that the content of each piece of data is similar and reflects a state, but the latest data is the latest state. We often view the latest data, that is, the current status of the XXX application. If the data is large, we hope that the scroll bar will always stay at the position of the columns we are interested in (we can see later that we will present detailed data with Treeview ).

5. In addition to the preceding directly available views, you can also click the List View to enter the detailed view, such:

In the Details View, we can see that the column names shown here are displayname rather than the column names stored in the actual database. As described in implementation, we save the metadata and actual data separately in the database, combine the query data.

 

Now return to mongodbpersistenceitem and mongodbpresentationitem. There are some rules for these configurations:

1. No more than one column can be identified as a context

2. A table name cannot contain more than one column, nor can it be defined as a single-choice, multiple-choice, or other filtering column.

3. It must have only one primary key column.

4. There must be only one time Column

5. The number of sorting Columns cannot exceed two

6. The primary key column must have a unique index.

7. The time column must have a non-unique index and the type must be datetime.

8. The sorting column and context identity column must have a non-unique index

9. Columns used as search criteria must have indexes (otherwise, the performance will be poor)

 

Finally, we will explain some rules on the use of complex entities. First, the MongoDB Data Service supports list and dictionary attributes, and also supports custom data. For example, simple type:

[Export dbpersistenceitem (columnname ="Dictionarycolumn22")] [Mongodbpresentationitem (displayname ="Test. dictionarycolumn", Description ="Dictionary column in subclass")]PublicDictionary <Int,String> Dictionarycolumn2 {Get; set;} [mongodbpersistenceitem (columnname ="Listcolumn22")] [Mongodbpresentationitem (displayname ="Test. listcolumn", Description ="List column in subclass")]PublicList <Int> Listcolumn2 {Get; set ;}
 

The raw data is as follows:

Listcolumn2 = enumerable. Range (1, 2). tolist (), dictionarycolumn2 =NewDictionary <Int,String> {1,"X"}, {2,"Y"}},
 

The former looks like this in the background:

For a list column, we use index numbers such as column name + type name + 0, 1, and 2 to represent the column name. For a dictionary, we use column name + type name + key to represent the column name.

Let's look at an example of a custom type:

[Export dbpersistenceitem (columnname ="Extlistcolumn11")] [Mongodbpresentationitem (displayname ="Testbase. extlistcolumn", Description ="Extended list columns in the base class")]PublicList <extitem> extlistcolumn1 {Get; set;} [mongodbpersistenceitem (columnname ="Extdictionarycolumn11")] [Mongodbpresentationitem (displayname ="Testbase. extdictionarycolumn", Description ="Extended dictionary columns in the base class")]PublicDictionary <String, Extitem> extdictionarycolumn1 {Get; set ;}
 

The raw data is as follows:

Extlistcolumn3 = New List <extitem> {New Extitem {normalcolumn4 = 100, dictionarycolumn4 = New Dictionary < Int , String > {1, "X" }, {2, "Y" }, Listcolumn4 = enumerable. Range (1, 2). tolist (), enumcolumn4 = (enum4) RND. Next (1, 4), ignorecolumn4 = "Asdasdas" ,}, New Extitem {normalcolumn4 = 200, dictionarycolumn4 =New Dictionary < Int , String > {1, "X" }, {2, "Y" }, Listcolumn4 = enumerable. Range (1, 2). tolist (), enumcolumn4 = (enum4) RND. Next (1, 4), ignorecolumn4 = "Asdasdas" ,},}, Extdictionarycolumn3 = New Dictionary < String , Extitem> {{ "Key1" , New Extitem {normalcolumn4 = 100, dictionarycolumn4 = New Dictionary < Int , String > {1, "X" }, {2, "Y" }, Listcolumn4 = enumerable. Range (1, 2). tolist (), enumcolumn4 = (enum4) RND. Next (1, 4), ignorecolumn4 = "Asdasdas" ,}},{ "Key2" , New Extitem {normalcolumn4 = 100, dictionarycolumn4 = New Dictionary < Int , String > {1, "X" }, {2, "Y" }, Listcolumn4 = enumerable. Range (1, 2). tolist (), enumcolumn4 = (enum4) RND. Next (1, 4), ignorecolumn4 = "Asdasdas" ,}},}

The background is displayed as follows:

Note that key1 and key2 are dictionary keys.

Because the extitem type has its own sub-attribute, this sub-attribute can also be a dictionary column and a list column, so this can be infinitely level. Let's take a look at the definition of extitem:

     Public   Class Extitem {[mongodbpersistenceitem (columnname = "Normalcolumn44" )] [Mongodbpresentationitem (displayname = "Extitem. normalcolumn" , Description = "Ordinary columns in the item extension class" )] Public   Int Normalcolumn4 {Get; set;} [mongodbpersistenceitem (columnname = "Enumcolumn44" )] [Mongodbpresentationitem (displayname = "Extitem. enumcolumn" , Description = "Enumeration columns in the item extension class" )]Public Enum4 enumcolumn4 {Get; set;} [Export dbpersistenceitem (columnname = "Ignorecolumn44" , Isignore = True )] [Mongodbpresentationitem (displayname = "Extitem. ignorecolumn" , Description = "Columns ignored in the item extension class" )] Public   String Ignorecolumn4 {Get; set;} [mongodbpersistenceitem (columnname = "Dictionarycolumn44" )] [Mongodbpresentationitem (displayname = "Extitem. dictionarycolumn" , Description = "Dictionary columns in the item extension class" )]Public Dictionary < Int , String > Dictionarycolumn4 {Get; set;} [mongodbpersistenceitem (columnname = "Listcolumn44" )] [Mongodbpresentationitem (displayname = "Extitem. listcolumn" , Description = "List columns in the item extension class" )] Public List < Int > Listcolumn4 {Get; Set ;}}}

If you are careful, you can find in displayname. all are replaced with _, because the display name cannot be included. (the reason is that when the data source is bound to the DataGrid, if the column name contains. is not a valid attribute name ).

In addition to the support for complex custom types, we also support enumeration of data. For example, loginfo has a loglevel enumeration. When presenting data, we can see the enumeration name rather than the value:

In addition, when searching, we also see the enumerated name in the drop-down box:

 

To sum up, we only need:

1. Define the entity types to be stored in the database (you can embed complicated custom types or enumeration types)

2. Define attributes to determine persistence (such as column names) and rendering rules (such as how to query data) based on your own needs)

3. Call mongodbservice. mongodbinsertservice. insert (Info) to insert data.

Then, you can use the data in the background without worrying about anything else. We also use the MongoDB data service in all aspects of adhesive involving big data storage. For external frameworks, if you need to save business data or other monitoring data, you can directly use it. In the next article, we will introduce the background of the MongoDB data service.