{"title":"gpu加速器能显著提高集群平台上大量保守DBMS的效率吗?","authors":"V. Raikhlin, R. K. Klassen","doi":"10.1109/SIBCON.2017.7998474","DOIUrl":null,"url":null,"abstract":"Discusses the issues of building a conservative type DBMS (with episodic data updates in a specially allotted time) on the platform of GPU-clusters at scale databases — V<inf>db</inf> at least 100GB. Their relevance is determined by modern tendencies of intelligent processing of large data arrays using graphics accelerators — GPU. By the condition the query processing is carried out on a regular plan. At the nodes of a cluster running MySQL function multi-core processors (2 processors per host) with a full load all cores. In the dynamics of query processing nodal database is in main memory of node with capacity of up to 128 GB. Problems occur due to the relatively small volumes of GPU global memory and speed of transmission data at the PCI-e, which connect CPU and GPU. The cases of average V<inf>db</inf> — near the 100GB, replicated across nodes, and large enough V<inf>db</inf> — from the hundreds GB to units of TB, hashed on the set of nodes. In the first case analyzed two variants of the DBMS functioning: 1) on the CPU — operations «select-project», on the GPU — «join» 2) on the CPU — «project» and «join», on the GPU — «select», DB is stored in compressed form. It was found that both variants use accelerators uncompetitive. A possible solution — the development of specialized DBMS with query optimization, which focused on the use of the GPU. In the second case, the operations «select-project» performed on the executive nodes with accelerators (compressed DB) or without (uncompressed DB, V<inf>db</inf> — hundreds GB), operations «join» — on the JOIN node without additional GPU. The answer to the question, can we expect in that case Increase of overall performance with the database compared to the previously developed DBMS Clusterix, still remains open.","PeriodicalId":190182,"journal":{"name":"2017 International Siberian Conference on Control and Communications (SIBCON)","volume":"6 1","pages":"0"},"PeriodicalIF":0.0000,"publicationDate":"2017-06-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"1","resultStr":"{\"title\":\"Can GPU-accelerator significantly increase the effectiveness of conservative DBMS considerable volumes on cluster platforms?\",\"authors\":\"V. Raikhlin, R. K. Klassen\",\"doi\":\"10.1109/SIBCON.2017.7998474\",\"DOIUrl\":null,\"url\":null,\"abstract\":\"Discusses the issues of building a conservative type DBMS (with episodic data updates in a specially allotted time) on the platform of GPU-clusters at scale databases — V<inf>db</inf> at least 100GB. Their relevance is determined by modern tendencies of intelligent processing of large data arrays using graphics accelerators — GPU. By the condition the query processing is carried out on a regular plan. At the nodes of a cluster running MySQL function multi-core processors (2 processors per host) with a full load all cores. In the dynamics of query processing nodal database is in main memory of node with capacity of up to 128 GB. Problems occur due to the relatively small volumes of GPU global memory and speed of transmission data at the PCI-e, which connect CPU and GPU. The cases of average V<inf>db</inf> — near the 100GB, replicated across nodes, and large enough V<inf>db</inf> — from the hundreds GB to units of TB, hashed on the set of nodes. In the first case analyzed two variants of the DBMS functioning: 1) on the CPU — operations «select-project», on the GPU — «join» 2) on the CPU — «project» and «join», on the GPU — «select», DB is stored in compressed form. It was found that both variants use accelerators uncompetitive. A possible solution — the development of specialized DBMS with query optimization, which focused on the use of the GPU. In the second case, the operations «select-project» performed on the executive nodes with accelerators (compressed DB) or without (uncompressed DB, V<inf>db</inf> — hundreds GB), operations «join» — on the JOIN node without additional GPU. The answer to the question, can we expect in that case Increase of overall performance with the database compared to the previously developed DBMS Clusterix, still remains open.\",\"PeriodicalId\":190182,\"journal\":{\"name\":\"2017 International Siberian Conference on Control and Communications (SIBCON)\",\"volume\":\"6 1\",\"pages\":\"0\"},\"PeriodicalIF\":0.0000,\"publicationDate\":\"2017-06-01\",\"publicationTypes\":\"Journal Article\",\"fieldsOfStudy\":null,\"isOpenAccess\":false,\"openAccessPdf\":\"\",\"citationCount\":\"1\",\"resultStr\":null,\"platform\":\"Semanticscholar\",\"paperid\":null,\"PeriodicalName\":\"2017 International Siberian Conference on Control and Communications (SIBCON)\",\"FirstCategoryId\":\"1085\",\"ListUrlMain\":\"https://doi.org/10.1109/SIBCON.2017.7998474\",\"RegionNum\":0,\"RegionCategory\":null,\"ArticlePicture\":[],\"TitleCN\":null,\"AbstractTextCN\":null,\"PMCID\":null,\"EPubDate\":\"\",\"PubModel\":\"\",\"JCR\":\"\",\"JCRName\":\"\",\"Score\":null,\"Total\":0}","platform":"Semanticscholar","paperid":null,"PeriodicalName":"2017 International Siberian Conference on Control and Communications (SIBCON)","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1109/SIBCON.2017.7998474","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
Can GPU-accelerator significantly increase the effectiveness of conservative DBMS considerable volumes on cluster platforms?
Discusses the issues of building a conservative type DBMS (with episodic data updates in a specially allotted time) on the platform of GPU-clusters at scale databases — Vdb at least 100GB. Their relevance is determined by modern tendencies of intelligent processing of large data arrays using graphics accelerators — GPU. By the condition the query processing is carried out on a regular plan. At the nodes of a cluster running MySQL function multi-core processors (2 processors per host) with a full load all cores. In the dynamics of query processing nodal database is in main memory of node with capacity of up to 128 GB. Problems occur due to the relatively small volumes of GPU global memory and speed of transmission data at the PCI-e, which connect CPU and GPU. The cases of average Vdb — near the 100GB, replicated across nodes, and large enough Vdb — from the hundreds GB to units of TB, hashed on the set of nodes. In the first case analyzed two variants of the DBMS functioning: 1) on the CPU — operations «select-project», on the GPU — «join» 2) on the CPU — «project» and «join», on the GPU — «select», DB is stored in compressed form. It was found that both variants use accelerators uncompetitive. A possible solution — the development of specialized DBMS with query optimization, which focused on the use of the GPU. In the second case, the operations «select-project» performed on the executive nodes with accelerators (compressed DB) or without (uncompressed DB, Vdb — hundreds GB), operations «join» — on the JOIN node without additional GPU. The answer to the question, can we expect in that case Increase of overall performance with the database compared to the previously developed DBMS Clusterix, still remains open.