dataesr/scientific-paragraphs-categorization huggingface dataset:
e. either content-based (CBF) or hybrid (KGE and CBF-TopPopular) are more accurate than pure CF-based approaches. Indeed, on this dataset, hybrid models are always the best models with KGE always coming first and CBF-TopPopular second, for all 4 metrics. They are followed by CBF, always the third ranked model. For instance, KGE obtains the highest MAP score (∼ 0. 20) followed by CBF-TopPopular (∼ 0. 16) and CBF (∼ 0. 10). The deep neural network approach is only fourth (∼ 0. 09) followed by TopPopular (∼ 0. 08), SVD (∼ 0. 07) and IBCF (∼ 0. 005). The poor performances of CF methods on the LibraryThing dataset may be due to the high sparsity of its rating matrix (99. 49%, see Table  1 ). This may prevent CF methods to learn an adequate representation of the user and item factor vectors. In such a high data sparsity context, even a simple content-based approach could lead to more accurate recommendations than the state-of-the-art deep learning approach.
This confirms, if needed, that considering item knowledge allows to alleviate parts of the cold-start and data sparsity problems faced by CF approaches  (Natarajan et al. , 2020). Table  6  summarizes the diversity metrics scored by the seven tested RSs on the three considered datasets. Let us first discuss the absolute diversity (ILD) of the recommendations. The CBF model, which relies exclusively on item knowledge, leads to much less diversified recommendations than other models. For instance, on the MovieLens dataset, the average ILD of CBF is only ∼ 0. 28 while it ranges from ∼ 0. 40 (CBF-PopPopular) to ∼ 0. 70 (IBCF) for other RSs. The same trend is observed for the other two datasets. This confirms that content-based recommendations are generally over-specialized. At the other end of the spectrum, IBCF and SVD, the two traditional CF models, provide the most diversified recommendations.
The remaining 4 models stand between those extremes: DNN is slightly more diversified than the popularity-based model (TopPopular) and the two hybrid models (KGE and CBF-TopPopular) on the movie and book datasets; TopPopular is the second most diversified model on the anime dataset. If the aim is simply to maximize the diversity of the recommendations, then the traditional CF in general, and the IBCF model in particular, appear to be an optimal choice. However, one can wonder how these absolute levels of diversity compare to users' expectations or needs. For each dataset and metric, the best score is bolded, the second-to-best is underlined and the third one is in italics. Considering the relative diversity metric, i. e. confronting the diversity of the recommendations (ILD) to that observed within user profiles (ILD  ), allows to go a step further.
Indeed, this comparison estimates the adequacy between the level of diversity proposed by these RSs and the level expected by users. According to Table  6 , recent KGE and DNN models seem to perform the best in terms of relative diversity. The intermediate diversity level of their recommendation lists is more coherent with the diversity observed in the user profiles. For instance, on the Anime dataset where ILD  is about 0. 75, the ILD is ∼ 0. 74/∼ 0. 73 for KGE/DNN, whereas it exceeds at ∼ 0. 80 for IBCF and is below 0. 60 for CBF. According to these average metrics, KGE and DNN seem to perform reasonably well and be close to user expectations in terms of diversity. Fig. 1  displays, for all considered datasets, the distribution of ILD values of each tested RS along with the distribution of the ILD  values (red curves).
This visual representation confirms that IBCF (gold curves) leads to over-diversified recommendations whereas content-based models such as CBF and CBF-TopPopular (cf. green and orange curves) tend to produce under-diversified recommendations. The more recent RSs (KGE and DNN) lead to ILD distributions closer to the ILD  ones. However, even if the ILD distribution and the average ILD of some RS models are close enough to those of ILD  (notably for the Anime dataset), their most diversified recommendations do not seem to be suggested to the right users. Indeed, the most striking result here is probably the strong discrepancy between the diversity of individual user profiles (ILD  ) and the diversity of the recommendations made to them by a RS (ILD). The R 2 values between these two sets of values (indicating the extent to which they are linearly correlated) are quite low for all 21 configurations (3 datasets × 7 RSs).
Impact of the diversification post-processing The diversification post-processing can be seen as a re-ranking process during which items, initially ordered according to their relevance score, are re-ordered so that the top items are both relevant and diverse. Here, we compare the results of the greedy re-ranking method (Algorithm 1) using two different objective functions: the classic one and the personalized one, denoted as cls-greedy and pers-greedy, respectively. The two methods rely on a parameter, denoted as , to adjust the compromise between relevance (accuracy) and diversity. These two post-processing approaches were tested in combination to the seven recommendation approaches on the three benchmark datasets. Fig. 3  provides, for each of these 42 combinations, a graphic representation of the evolution of the absolute diversity (ILD), the relative diversity (R 2 ) and the accuracy of the recommendations when increasing.
Note that, for simplicity sake, the unique accuracy metric discussed in this subsection is the F1-measure since the same trends are observed for the other accuracy metrics, i. e. Precision, Recall and MAP. As expected, the cls-greedy post-processing increases the ILD values for all RSs and datasets and the higher the  values the larger the ILD (Fig. 3  top row). The only exceptions to this rule are observed for content-based RSs, i. e. CBF ( * ) and CBF-TopPopular (•), on the MovieLens or LibraryThing benchmarks where the ILD reaches a plateau. It seems that content-based RSs provide so little diversity in their candidate lists (i. e. the top-100 ranked items in our context), that it imposes a limitation on the diversification post-processing. In other words the top-100 items returned by content-based approaches are sometimes so similar that there is no way to build a highly diversified subset of them.
An  value close to 0. 25 seems optimal for content-based approaches: ILD is much better than with  = 0 while the F1-measure is almost unchanged ( from 0 to 0. 25) for MovieLens and Anime and even improved for LibraryThing. For all other RSs, improving the diversity metrics always comes at the cost of a lower accuracy (Fig. 3  bottom row). However, the cls-greedy optimization leads to a more important accuracy sacrifice in comparison with the pers-greedy optimization (notably when  becomes larger than 0. 5). The latter tends to preserve higher levels of accuracy, considering all three datasets.
, 2012) , modeling items in a community knowledge-based tag space. Users were asked to communicate their perceptions on recommendation lists from three RSs (IBCF, UBCF and SVD). Their findings demonstrated that IBCF provided more diversified items than SVD, which is coherent with our findings (see Table  6 ). That is why we believe that the findings of our offline-based experiments should reflect effectively the diversity performances of the tested RSs. In terms of research implications, the results of our study indicate that the absolute diversity level of recommendations provided by the state-of-the-art memory-based collaborative filtering algorithm (IBCF) is always much higher than that observed in user profiles (e. g. the gold curve is almost right-shifted from the red one in Fig. 1  for the movie dataset).
As the current trend of the recommender system community is based on deep neural networks and graph embeddings  (Ferrari Dacrema et al. , 2019; Xu et al. , 2020; Zhang et al. , 2019) , the results of our study might inspire researchers or RS developers to design new models that account for users' diversity needs, as they highlight the suboptimality of individual diversification. We also hope that this work could encourage the provision of benchmark datasets containing implicit feedbacks (such as the Deskdrop 12 plaform) in order to get information about items users have interacted with and not just the ones they have rated. This is a crucial information as most users watch much more movies or read much more books than they rate. Cross checking these two types of information could probably help better capture users' needs, especially regarding the diversification criterion.
Conclusion Recommender systems have long been evaluated based on their accuracy. The importance of providing diversified recommendations is also acknowledged now. However, the impact of diversification post-processing on the main types of recommender systems has not been extensively studied. This paper provides a systematic and comprehensive study of the four main families of recommender systems (non-personalized, content-based, collaborative filtering-based and hybrid) with respect to both accuracy and diversity. This study was done using three large datasets classically used to benchmark RSs. We argue that considering only the absolute level of diversity of a recommendation list is not enough and that the diversity of each recommendation list should also be evaluated with respect to the target user of the recommendations.
Like any oil, data pollutes as mentioned in the latest Blog entry of the Martin Tisné published on July 24, 2019: "Data isn't the new oil, it's the new CO2" 2. This pollution is caused by storing and processing this data. Data storage and processing are important subsystems in data centers, and they have evolved and increased their capacity due to the advent of new paradigms, such as cloud computing and virtualization technology. As database researchers, we are then obliged to make ourselves, academia, industry, IT companies, funding agencies, and students, aware of actions related to energy savings of the DSS by considering small and big initiatives. The DSS infrastructure includes hardware, software, and facility service components that support the delivery of business systems and IT-enabled processes.
According to the statistics published by the InfoTech group, IT equipment consumes approximately 50% of the total energy. Figure  1  illustrates the power consumption distribution of major components that consume energy in IT infrastructure. DSSs regardless of their types (DBMSs, data centers, and parallel database machines, etc. ) have been identified as one of the major enery consumption components in IT infrastructure. This consumption is associated with their servers, storage devices, networks and infrastructure facilities such as cooling and power conditioning systems  [28]. The processor consumes a major portion of energy followed by the storage device  [68]. The first and major efforts in managing the energy of DSS have particularly touched data centers  [60]  since they have been pointed out by several organization reports as one of the biggest energy consumers.
This finding is questionable since they use techniques covering software (e. g. , finding the best query plan satisfying the first N F R) and hardware (e. g. , executing the appropriate algorithms associated with the selected plan on the target platform hosting the DBMS). DSS can benefit from existing energy-aware hardware (such as removable storage media  [27] , graphics cards  [61] , etc. ). For software solutions, DBMSs need to accurately estimate hardware power consumption under static and dynamic loads, revisit query execution, scheduling, database systems design, and data management strategies in order to meet the response time and allow better energy management. This poses several challenges for the researchers: it is necessary to develop cost models and metrics that consider the parameters related to the database systems components, such as the database schema (e.
We claim that building green query processors passes through a deep audit that allows designers identifying relevant energy-sensitive parameters that are the entries of the mathematical cost models estimating energy when executing a query. The development of such models necessitates a deep understanding of the functioning of the target DBMS hosting the database application (e. g. , query execution mode). Note that the value of some energy sensitive parameters cannot be obtained from the statistic module of the DBMS, therefore they have to be computed using machine learning techniques. Paper outline: The outline of this paper is as follows: Section II summarizes the fundamental notions of energy and describes the design of the different DBMS used in our study. A consequence of energy overusing and the benefit of energy saving are also presented.
PostgreSQL: It is a row-store DBMS supporting object-relational databases. It uses the server/client model and supports the standard database languages. It offers many advanced functionalities such as user-defined types, table inheritance, sophisticated locking mechanism, foreign key referential integrity, views, rules, sub-query, nested transactions, multi-version concurrency control, and asynchronous replication  [82]. The support of a parallel query involves multiple background worker processes. There is a back-end process that handles all queries issued by the connected client. This back-end consists of the following subsystems: 1. Parser: it checks the query syntax expressed in a high-level query language like SQL to determine whether it is well formulated according to the grammar rules of the query language.
2. Analyzer: The query must be validated by verifying that all attributes and relationship names are valid and semantically significant in the schema of the database. 3. Re-writer: Using transformation rules, an internal representation of the query is then created (query tree). 4. Planner: It generates the cheapest plan tree that can be executed from the query tree. 5. Executor: It executes the query via accessing the tables that are generally stored in a single heap, with each column stored on a single tuple. A query has many possible execution strategies, and the selection of the best plan is usually conducted by cost modeldriven strategies  [24]. Figure  2  summarizes the different phases of the PostgreSQL query processor.
MonetDB: It was designed primarily for data warehouse applications. It achieves significant speedup compared to more traditional designs by innovations at all layers of a DBMS, e. g. , a storage model based on vertical fragmentation (column-store), a modern CPU-tuned query execution architecture, adaptive indexing, run-time query optimization, and a modular software architecture  [38]. Internally, the design, the architecture and the implementation of MonetDB reconsider all aspects and components of classical database architecture and technology by exploiting effectively the potentials of modern hardware. the final result to the client, N -ary 4  tuples are constructed. This approach allows the query engine to exploit CPU-and cache-optimized vector-like operator implementations throughout the whole query evaluation relying on a bulk processing model allowing minimizing function calls, type casting, various metadata handling costs, etc.
Intermediate needed results are materialized to increase their reuse  [13]. 2. Query execution model: The MonetDB kernel is an abstract machine, programmed in the MonetDB Assembly Language (MAL). The core of MAL is formed by a closed low-level two-column relational algebra on BATs. N-ary relational algebra plans are translated into two-column BAT algebra and compiled to MAL programs. These MAL programs are then evaluated in an operator-at-a-time manner. Figure  3  shows the internal design of MonetDB. MonetDB's query processing scheme is centered around three software layers: • The top layer or front-end provides the user-level data model and query language. The query language is first parsed into an internal representation (e. g. , SQL into relational algebra), which is then optimized using domain-specific rules.
Hyrise: Hyrise 5  was first presented in 2010, developed by Hasso-Plattner-Institute in Germany under the direction by Professor Hasso Plattner to introduce the concept of the hybrid storage model (row-oriented and column-oriented) for in-memory databases. The Hyrise system is a new implementation based on the relational model, which automatically splits database tables vertically and then horizontally into small partitions, of varying widths depending on how the columns of the table are accessed  [25] [77]. The system aims at maximizing the performance of the cache memory for analytical(OLAP-type) and transactional (OLTP-type) queries by customizing the dynamic design of storage data. The goal of the Hyrise designers is to provide a flexible in-memory data management platform, allowing experiments to be conducted to validate new concepts around in-memory data management.
OS: We run all the experiments using Ubuntu 18. 04 bionic as the operating system with kernel version 5. 0. 0-27-generic. Data sets: We use the TPC-H decision support benchmark, which is designed for evaluating data warehouses. It is composed of eight tables (PART, PARTSUPP, REGIONAL, SUPPLIER, CUSTOMER, LINEITEM, NATION, and ORDERS), we generate data at different scale factors 1 GB, 2GB, 3GB, 5GB, 10GB, 30GB  6. We chose to use benchmark from TPC because they are known and have many years skilling in the definition of transaction processing and database benchmark. Profiling: After generated the data from TPC-H benchmarch in textual(comma-separated values -CSV) files, we use COPY command from SQL standard to load data in DBMS. We collect statistics about average time and power consumption for each query in the particular DBMS.
Experimental Evaluation We conduct several experiments to evaluate the data loading performance, query execution performance and power consumption of the tested systems. We present in this section our finding. • Data loading and Power Analysis: This experiment investigates the behavior of Post-greSQL, MonetDB and Hyrise when loading the two datasets of size 1GB and 3GB. Figure  7  plots the data load time for each DBMS under the two scale factors(SF). As we can see, the loading time increases for each system as the size of the dataset increases. Monet outperforms the rest of the DBMS in the two cases; when considering 3GB datasets, Monet is 3. 5 faster than PostgreSQL and 1. 5 faster than Hyrise. After Monet, Hyrise exhibits fastest loading time than PostgreSQL. PostgreSQL shows the worst performance, the reason is that the row-stores require more space because they store auxiliary information Q 1 , Q 2 , Q 3 , Q 4 , Q 5 , Q 6 queries from TPC-H benchmark in parallel mode These results show that the performance of Hyrise outperforms those obtained by Post-greSQL and MonetDB on the 2GB dataset for all considered.
We can see that for most queries, Hyrise performance is within an order of magnitude of the other databases. The PostgreSQL performance gaps on Figure  9 (a), 9(b), 9(c) is mainly due to the fact that it cumulates an important number of page faults when processing queries. The row-store systems have to scan and use the entire n-tuples rather than only the needed columns values. Therefore, the entire rows plus the built-in index tree cannot reside long enough in the main memory or in the cache memories. They must be swapped on the disk this leads to many disks IOs. For column-oriented systems like MonetDB, just the values of the columns required to answer the queries are loaded. hybrid system like hyrise combines the advantages of column and row storage systems and it is well designed to support efficient parallel execution for multi-core processors.
Q 1 , Q 1 , Q 2 , Q 3 , Q 4 , Q 5 , Q 6 queries from TPC-H benchmark. To compare the energy consumption on our three systems when executing queries, we measure the power dissipated per second using an amperage apparatus named wattmeter. At the end of these measurements, we calculate the average energy consumed by each query. Figure  10 (a) depicts the energy consumption of three DBMS on 5 GB datastes. Hyrise outperform PostgreSQL and MonetDB under the 5 GB TPC-H dataset because of the rapid processing of queries. Hyrise directly accesses compressed data in main memory and not in secondary memories, this speeds up data processing. Average energy consumed by MonetDB, PostgreSQL during the execution of the queries on SF=30 and SF=100 can be found in Figures  10(b ) and 10(c). MonetDB energy consumption during queries execution is reasonable than for PostgreSQL.
The high consumption of the PostgreSQL query processor can be explained by the characteristics of this type of row-store DBMSs. MonetDB uses compression techniques to reduce the cost of data scans. This directly impacts query performance due to fewer I/O requests and page faults. To understand Where does power go on PostgreSQL DBMS, we captured the last level cache(LLC) misses and Cache level 2(L2) misses. We execute the first three queries of TPC-H benchmark on the 5 GB datasets. The results for these queries are shown in Figure  11. From these results illustrated, the LLC caches misses and L2 caches misses of Hyrise outperforms the row-store DBMS (PostgreSQL) and column-store(MonetDB). Q 1 Q 2 Q 3 Monet Q 1 Q 2 Q 3 Hyrise L2-cache-misses LLC-cache-misses.
Step 2: (Energy-cost model construction) Our work focuses on modeling energy consumption of query operations related to its resources consumption on a single-node database environment, therefore we do not consider the network transmission cost. To construct our model, we investigate the executor tasks to understand how to profile the power consumption on an individual query. To do that, we execute a set of queries (simple and complex) with different scale of factors of the TPC-H benchmark. In our process, we treat energy as the resource consumed by systems operation during queries execution. The input parameters (resources) that we consider are listed in Table  1  for each systems. From Table  1 , note that our models consider the main resources responsible for the energy consumption of each system.
[1]. In our work, we use a non-linear regression technique involving the identified energysensitive variables. To do that, we set to 2 the polynomial degree for PostgreSQL and Hyrise. For MonetDB, we use the degree 3. We find the values of parameters of our equations: W cpu , W mem , W L2 ,W L3 and W dio by applying this setting in the regression package defined in the R language. 2. Random forest : Random forests or random decision forests are an ensemble learning method for classification, regression and other tasks that operate by constructing a multitude of decision trees at training time and outputting the class that is the mode of the classes (classification) or mean prediction (regression) of the individual trees. It was introduced by Breiman and Cutler. Recent studies have suggested that Random Forest offers features which make it very attractive algorithm for statistical learning.
Data Sets: The data set was selected from TPC-H Benchmark  14. The TPC-H Benchmark (TPC-H) is a decision support benchmark. It consists of a suite of business oriented ad-hoc queries and concurrent data modifications. The queries and the data populating the database have been chosen to have broad industry-wide relevance. This benchmark illustrates decision support systems that examine large volumes of data, execute queries with a high degree of complexity, and give answers to critical business questions. We generate data at different scale factors: 1 GB, 2GB, 3GB, 5GB, 10GB, 30GB. For MonetDB and PostgreSQL models training, we study and collect the characteristics of forty-four (44) Select-Project-Join (SPJ) queries and measure the energy consumed by each of them using the power meter. In the case of Hyrise, we collect the statistics of ninety-nine (99) Select-Project-Join (SPJ) queries.