Skip to content

Latest commit

 

History

History
74 lines (56 loc) · 3.85 KB

OKLog_model.md

File metadata and controls

74 lines (56 loc) · 3.85 KB

模型

对于系统模型的一些想法，这是一个非常初步的考虑。我不是学者，自学习排队理论后已经有很多年了。这一切都是未经验证的，可能已经脱离最基本的知识很远了。我热忱欢迎大家帮忙指正。

排队理论

首先，拜读《PDQ: Pretty Damn Quick Performance Analyzer》文章

 <--------R--------->
 <---W--->  <---S--->
           +---------+
   λ       |         |  X
 --> • • • |    •    |--> •
           |         |
           +---------+
 <---Q--->
  • λ表示节点(或者数据)入队的平均速度
  • S表示服务处理完节点或者数据所需要的时间
  • Q表示队列长度
  • R表示处理完数据总共所需时间，也就是请求时间
  • W表示节点(或者数据)在队列中停留的时间

从λ和S， 我们可以推导出系统的其他属性。

  • 来自服务的吞吐速率：X = λ
  • 客户端发出请求，缓冲到队列的等待时间：R = S / (1 - λS)
  • 服务的利用率：ρ = λS
  • 队列的平均长度：Q = λR
  • 服务的平均等待时间: W = R - ρ

为了测试，我们可以合理地将λ固定为某个恒定值。相反，S将是日志记录大小的处理函数。那么，我们固定每条日志记录大小为N个字节。则S=f(N)。

我们的组件

  • Producer ------ Forward ------ Ingest ------- Store

Producer生产日志的到达速率λr， 并且每条日志记录大小Nr

  • λr
  • Sr = f(Nr)

我们需要通过做实验来统计请求处理函数Sr的服务时间。例如现在我们假定1 nano/byte速率

  • Sr=Nr*1ns

在producer和forwarding代理之间存在一个pipe缓冲。带宽的最大值影响吞吐量

  • TODO

第一个队列在forward代理存在着。这个forwarder仅仅是往这个队列的服务连接上写日志记录。所以，这个forwarder的服务时间是简单的。

  • Sforward = 每条记录的消耗时间+forwarder代理写入到队列上的时间
  • Sforward = O消耗(1) + W连接写入队列(Nr)

再又，我们需要做实验统计O消耗时间和W写入队列的时间。现在，我们给它们一些固定值。

  • O consumption = 10 ns
  • W connection = Nr * 2ns

在forwarder和ingest节点之间存在一个网络。带宽的最大值影响吞吐量。

  • TODO

然后，我们达到了ingest节点。首先记录从队列上获取，然后写入到ingest节点的活跃段上。这里类似于forwarder的处理流程。

  • Singest = 每条记录的处理消耗时间+ 写入日志记录到活跃段的时间
  • Singest = O消耗(1) + W段(Nr)

再又，我们需要做实验统计W段。现在，我们给它一个固定。

  • W segment = Nr * 1ns

当活跃段达到给定的时间或者size大小后，这个活跃段就变成了query节点可以轮询的可用段了。这个ingest节点有效地把日志记录流转换为了段文件，因此我们派生了一个新的流速：段流入速率λs和段大小Nr

  • Ns = f(λr, Nr, A, S)
  • λs = f(λr, Nr, A, S)

我们假定每秒的日志记录数 λr = 100, Nr = 500比特， A= 1秒，和S= 1。每秒100条日志记录，每条日志记录500个字节，每秒产生50000个字节。这会在A= 1s时触发，但不会在S= 1兆字节触发。所以 Ns是50000个字节，λs是每秒1段。

设每秒λr= 10000条记录，Nr = 500字节，A = 1秒，S = 1兆字节。 每秒10000条记录，每条记录500字节，每秒产生5000000字节。 这在（1MB / 5000000B) * 秒= 200ms时触发S = 1兆字节。 所以Ns将是1MB，λs将会是每秒5段。

段可以被ingester节点使用，但不会被store节点使用。当ingester节点达到容量后，store节点就可以开始consume(轮询)。我们可以将其建为虚拟队列。所有的ingest节点会形成一个等待工作的虚拟队列。所有的store节点共同构成一个虚拟服务器。

  • TODO