Andy Melnikov (nponeccop) wrote,
Andy Melnikov
nponeccop

Access Plans - литература по теме

Parallel I/O Aware Query Optimization (SIGMOD 2014)

In this paper, at first, we show why the query optimizer needs to be aware of the benefit of the I/O parallelism in solid state drives. We characterize the benefit of exploiting I/O parallelism in database scan operators in SAP SQL Anywhere and propose a novel general I/O cost model that considers the impact of device I/O queue depth in I/O cost estimation. We show that using this model, the best plans found by the optimizer would be much closer to optimal. The proposed model is implemented in SAP SQL Anywhere. This model, dynamically defined by a calibration process, summarizes the behavior of the I/O subsystem, without having any prior knowledge about the type and the number of devices which are used in the storage subsystem

I/O Scheduling Service for Multi-Application Clusters (2006)

In this article, we focus on multiple concurrent applications that perform parallel I/O accesses
to the storage subsystem. This is a common situation on clusters since most batch schedulers [9], try to maximize the overall platform usage, leading to concurrent executions. In this case, each application generates its own recurrent parallel access patterns and parallel access patterns from distinct applications are interleaved due to concurrency. Thus, the I/O subsystem layer has to perform optimizations that take advantage of regularity of accesses from each application while balancing storage access between them. Our work focuses on non dedicated clusters where all applications are considered of equal importance.

Любопытно, что они рассматривают корпоративные и университетские HPC batch clusters, а не облачный датацентр. И оптимизируют используя только низкоуровневую информацию (потоки SCSI-пакетов) без высокоуровневых хинтов.

Также они говорят о non-dedicated - это близко к моему вопросу о многотенантности. В моём представлении N компаний запускают по M приложений на общем Амазоновском датацентре. Внутри компании ("тенанта") приложения кооперируются друг с другом с целью обеспечить максимальную суммарную производительность и обеспечить при этом минимальный QoS для каждого приложения. Т.е. у тенанта задача отъесть как можно больше ресурсов у клауда за те же деньги, и он готов внутри себя для этого объединиться. А тенанты друг с другом не кооперируются - даже если они используют некий сервис-координатор, то цель всё обеспечить не суммарную производительность, а их личную.

У клауда понятно задача посадить эти M*N приложений на хардварь минимальной мощности так, чтобы они не заметили. В частности, для этого требуется исключить любые простои хардвари, а также использовать все возможные средства для того чтобы неизменная корова дала больше молока при прочих равных. Ну и обеспечить fairness между тенантами. Поскольку иначе тенант обидится на срущих ему в кашу соседей и уйдет от амазона к оушену.

И тут выгода для тенанта в том, что амазон с супер-PaaS продает ему больше IO за меньшие деньги, чем оушен с лигаси-инфраструктурой.

А выгода для амазона в том, чтобы выжать из той же коровы на две капли больше молока, чем это делает оушен, и положить эти капли себе в карман.
Tags: io optimization, programming
Subscribe

  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 2 comments