مترجم اول

ترجمه متون حقوقی، ترجمه مقاله ، ترجمه کتاب و... با مناسبترین هزینه و بهترین کیفیت

مترجم اول

ترجمه متون حقوقی، ترجمه مقاله ، ترجمه کتاب و... با مناسبترین هزینه و بهترین کیفیت

مقاله با ترجمه فارسی

Proxy-Server Architectures for OLAP

معماری پروکسی سرور برای OLAP

ABSTRACT

Data warehouses have been successfully employed for assisting decision making by offering a global view of the enterprise data and providing mechanisms for On-Line Analytical processing. Traditionally, data warehouses are utilized within the limits of an enterprise or organization. The growth of Internet and WWW however, has created new opportunities for data sharing among ad-hoc, geographically spanned and possibly mobile users. Since it is impractical for each enterprise to set up a worldwide infrastructure, currently such applications are handled by the central warehouse. This often yields poor performance, due to overloading of the central server and low transfer rate of the network.

In this paper we propose an architecture for OLAP cache servers (OCS). An OCS is the equivalent of a proxy-server for web documents, but it is designed to accommodate data from warehouses and support OLAP operations. We allow numerous OCSs to be connected via an arbitrary network, and present a centralized, a semi-centralized and an autonomous control policy. We experimentally evaluate these policies and compare the performance gain against the existing systems where caching is performed only at the client side. Our architecture offers increased autonomy at remote clients, substantial network traffic savings, better scalability, lower response time and is complementary both to existing OLAP cache systems and distributed OLAP approaches.

چکیده

انبارهای داده با ارائه دید کلی از داده های اقتصادی و مهیاسازی مکانیسم های برای پردازش تحلیلی مستقیم، با موفقیت برای کمک به تصمیم گیری به کار گرفته شده اند. به صورت سنتی، انبارهای داده در محدوده موسسه یا سازمان اقتصادی به کار برده می شوند. هرچند رشد اینترنت و WWW موقعیت های جدیدی برای به اشتراک گذاری داده بین کاربران موردی از نظر جغرافیایی پراکنده و شاید متحرک فراهم کرده است. از آنجایی که تهیه زیربنای جهانی برای هر موسسه اقتصادی کاربردی نیست، در حال حاضر این چنین کاربردهای توسط انبار مرکزی مدیریت می شود. این کار به دلیل بار بیش از حد سرور مرکز یو سرعت انتقال پایین شبکه منجر به عملکرد ضعیف می شود.

در این مقاله معماری برای سرورهای کش (حافظه با سرعت بالا) OLAP (OCS) پیشنهاد می کنیم. OCS هم ارز سرور پروکسی برای اسناد وب است اما برای جا دادن داده از انبارها و پشتیبانی عملیات OLAP طراحی شده است. اجازه می دهیم OCSهای متنوع از طریق شبکه اختیاری به هم متصل شوند و سیاست کنترل متمرکز، نیمه متمرکز و مستقل را ارائه می دهیم. به صورت آزمایشی این سیاست ها را ارزشیابی کرده و دستاورد عملکرد آن را در برابر سیستم های موجود که کش کردن فقط در جانب مشتری انجام می شود، مقایسه می کنیم. معماری ما استقلال افزایش یافته ای برای مشتریان راه دور، صرفه جویی اساسی ترافیک شبکه، مقیاس پذیری بهتر، زمان پاسخ کوتاه را ارائه می دهد و مکمل سیستم های کش OLAP موجود و رویکردهای OLAP است.

INTRODUCTION

A data warehouse is a collection of historical summarized information, which aims at improving decision-making. The process of accessing and manipulating these data is referred as On-Line Analytical Processing (OLAP) [CCS93]. OLAP operations typically deal with aggregations, which involve huge amounts of data, as opposed to accessing only a few tuples at a time in an On-Line Transaction Processing (OLTP) environment. Moreover, OLAP operations may require data, which are distributed in numerous geographically spanned databases. Therefore, although it is possible to execute such queries against operational databases, in practice a separate database is used to implement the data warehouse.

Usually, each department in an enterprise is interested only in a fragment of the total data. If a central data warehouse has been built, the data can be partitioned and extracted in departmental data warehouses, called data marts (Figure 1a). This approach ensures consistency across the enterprise. Nevertheless, it may be too hard to create a global model for the central warehouse. In this case, each department builds its own data mart (decentralized approach), and a middleware layer is employed to provide a global view of the data (Figure 1b).

The implementation of a data warehouse, naturally involves many distributed database issues. The process of accessing the operational databases, extracting, cleaning and integrating the data in the warehouse, is a distributed database application. In [GLWZ99] the authors discuss the particular issues of the data warehouse environment for distributed and parallel computation. Some of the challenges include the maintenance of the warehouse data consistency given a set of autonomous sources, the process of resuming failed warehouse loads without undoing the incomplete load, and the parallelization of view maintenance tasks