Notice bibliographique
Résumé
Today, one of the most important concerns of information systems, is the processing of massive database queries.Parallel processing system of Google called Map Reduce and open source version of it called hadoop have the ability to work on multiple concurrent execution processing systems.Despite the relatively high performance still it needs to improve the processing method when dealing with the processing of the giant databases.SQL is a famous and powerful database that can store large amounts of data, maintain and make access to the information required for the processing.The database, contain an order called Hash Join that is one of the ways of implementation of join between the tables of a database.In this study, a method is suggested for executing Hash Join in Map Reduce that increases the speed of the join between the tables and the outputs.By comparing this technique with the usual implementation of Hash Join on Map Reduce system, it can be seen that approximately 30 percent improvement is achieved through the proposed approach in running the system.Keywords: distributed system of Map reduce -hadoop Software -query processing -SQL Database, hash join 1. Introduction Obviously, one of the most time-consuming phases in a database system is query evaluation engine particularly when there are high volumes of data.Rapid and effective assessment of information queries in a space which is faced with an explosion of information, increases system performance.The use of higher processing power and exploitation of the parallel processing is one of the primary mechanisms.Although many efforts have been done to parallelize query evaluation, the investigation is still open in this regard.But when the volume of data increases, For example, when dealing with the data on the volume of Tera or Peta, the issue is made more complex.But with such massive amounts of data, we are needed to evaluate the query algorithms from different perspectives.Query algorithms, are extremely important in the database management and can help connect the tables by adopting special conditions.2. A review of literature An article titled Google's programming model in Map reduce was conducted in [1].Then it was revised in article [2] which examined the model and provided suggestions for improving it.However, despite the usefulness of this article (in terms of programming model for processing actions such as join analysis and structural use of it) it has not mentioned anything about improving processes in the structure.An article is offered entitled as an optimized framework for queries [3] of Map Reduce.In this paper, a framework is suggested for effectively optimizing semi SQL queries of Map Reduce.It is a new query based on algebra, and it uses a small number of high level physical operators that are independent from existing systems of Map Reduce, such as hadoop.Algebra used in this article, and therefore its processes are relatively simple and effective and this is its strength.But due to the small number of these operators query times are higher and a greater number of machines are distributed and involved in implementing the join.An article entitled Hive: a
Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.
Comment cette classification a été obtenuedéplier
Prédiction machine sur la base complète
Imitation des enseignantsNi prévalence calibrée, ni vérité terrain. Validation humaine à venir. Le volet Gemma est une étiquette directe du modèle pour chaque travail de la base, lue sur la notice réduite au titre. Le volet Codex est un classifieur appris des 10 348 étiquettes directes de Codex et calibré sur les taux pondérés de l'échantillon; les champs sans appui suffisant ne portent aucun appel Codex. Le mode candidate est l'union des deux volets; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont pas des étiquettes humaines.
Scores du classifieur distillé par catégorie (deux têtes)
| Catégorie | Codex | Gemma |
|---|---|---|
| Métarecherche | 0,001 | 0,001 |
| Méta-épidémiologie (sens strict) | 0,002 | 0,000 |
| Méta-épidémiologie (sens large) | 0,001 | 0,001 |
| Bibliométrie | 0,002 | 0,003 |
| Études des sciences et des technologies | 0,001 | 0,001 |
| Communication savante | 0,003 | 0,002 |
| Science ouverte | 0,001 | 0,002 |
| Intégrité de la recherche | 0,004 | 0,001 |
| Charge utile insuffisante (le modèle a refusé de juger) | 0,935 | 0,955 |
Scores machine (provisoires)
Les deux têtes enseignantes du modèle étudiant, lues sur ce travail. Un score ordonne la base pour la relecture; il n'affirme jamais une catégorie, et le statut de validation accompagne chaque rangée tel quel.
Scores de référence d'un modèle non mature (critères de maturité non atteints, 7 itérations). Un score ordonne; il n'affirme jamais une catégorie.
score_only:v0-immature-baseline · tel quel depuis la passe de notation : score_only signifie que le nombre peut ordonner les travaux, et qu'aucune étiquette de catégorie n'en découleClassification
machine, non validéePrédiction automatique; l’étiquette directe de Gemma et le classifieur distillé Codex s’accordent sur ce qui est montré ici.
Le détail, modèle par modèle et score par score, se trouve en fin de page sous « Comment cette classification a été obtenue ».