自定义博客皮肤VIP专享

*博客头图:

格式为PNG、JPG,宽度*高度大于1920*100像素,不超过2MB,主视觉建议放在右侧,请参照线上博客头图

请上传大于1920*100像素的图片!

博客底图:

图片格式为PNG、JPG,不超过1MB,可上下左右平铺至整个背景

栏目图:

图片格式为PNG、JPG,图片宽度*高度为300*38像素,不超过0.5MB

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+
  • 博客(10)
  • 资源 (1)
  • 收藏
  • 关注

原创 什么是数据库的因果一致性

即如果一系列写入按某个逻辑顺序发生(时间上其实是天然的),那么任何人读取这些写入时,会看见它们以正确的逻辑顺序出现(但在分片数据的情况下不一定做到)。但是这会存在许多问题,一是,并不是所有的数据都能如此轻易地判断因果依赖关系,这从源头上有天然的障碍;因为异地节点同步延迟等原因,发起查询的用户可能会先看到回答,再看到问题,显然,这是不符合我们对事务的认知和理解逻辑的。不同于其他问题,讨论因果一致性,不得不讨论分区,因为因果一致性只会发生在分区(也称为分片)的分布式数据库中。

2023-08-30 22:32:42 60

原创 数据库中说的(ACI)结合性、交换性、幂等性、是什么?

首先区分数据库中的ACID原则,不是一个东西—

2023-08-29 10:07:26 85

原创 论文卡片:Accelerating Multipath Transport Through Balanced Subflow Completion

传输调度:关键挑战是如何有效地分配每个子流的传输任务,以便在所有路径上平衡传输负载。本文解决了这一问题,提出了一种新的平衡子流完成时间的策略,从而提高了多路径传输的性能。具体来说,算法通过预测每个子流的传输时间,计算出最佳的子流任务分配方式,从而使得所有子流的完成时间尽量接近。在实时计算最优子流分配策略时,可能面临计算复杂性较高的问题,尤其是在具有大量子流和复杂网络条件的场景下。依赖于准确的子流传输时间预测。提出了一种新的多路径传输策略,通过平衡子流完成时间来提高多路径传输性能和吞吐量。

2023-06-05 19:19:56 61 1

原创 论文笔记:Deadline-aware Multipath Transmission for Streaming Blocks下

在大多数情况下,DAMS 的性能优于 DAMS-C,而在带宽变化较大且两条路径的 RTT 分别为 10ms 和 40ms 的动态网络设置 2 下情况相反(图 12(a) 的左侧部分)。在本文中,我们关注的是满足截止日期的区块数量。此外,DAMS在发送方完成每个块在多条路径上的同时发送,以降低数据块传输的沉没成本,避免未知块被抢占带来的带宽浪费。此外,为了更深入地了解 DAMS,我们描述了 DAMS 与两种算法进行比较的微基准标记:DEMS(现有基于块的算法的代表)和 DAMS-C(DAMS 的变体)。

2023-04-19 00:57:15 118

原创 论文笔记:Deadline-aware Multipath Transmission for Streaming Blocks

交互式应用程序有截止日期要求,例如 视频会议和在线游戏。与可能不太稳定或带宽不足的单一路径相比,同时使用多个网络路径(例如 WiFi 和蜂窝网络)可以利用多个路径在截止日期前提供服务的能力。然而,现有的多路径调度器通常会在发送方存在多个块时忽略截止时间以及后续块对当前调度决策的影响。在这篇论文中,我们提出了 DAMS,一个 Deadline Aware Multipath Scheduler,旨在在截止日期之前交付更多具有异构属性的块。

2023-04-17 22:33:37 173 2

原创 论文笔记:DTP: Deadline-aware Transport Protocol

越来越多的应用对数据交付有期限要求,例如 360° 视频、云 VR 游戏和自动驾驶。这些应用程序通常非常需要带宽。幸运的是,这些应用程序的数据可以分成多个具有不同优先级的块,从而可以通过优先处理一些块来减少带宽消耗。然而,现有的传输层太原始,无法实现这一点。因此,这些应用程序被迫构建自己定制的复杂轮子。在这项工作中,我们提出了截止日期感知传输协议 (DTP) 来提供截止日期前交付(deliver-before-deadline)服务。应用程序向 DTP 表达数据的截止日期和元数据。然后DTP尝试通过调度块。

2023-04-06 15:25:02 405

原创 论文笔记:No Provisioned Concurrency: Fast RDMA-codesigned Remote Fork for Serverless Computing 下

本节介绍如何将MITOSIS应用于FN[120]——一个流行的开源无服务器平台。尽管我们关注FN,但我们相信我们的方法也可以应用于其他无服务器平台(例如OpenWhisk[119]),因为它们遵循类似的系统架构(见图11)。图11显示了FN的概述。它处理的函数请求要么是单个函数的调用,要么是无服务器工作流的执行(例如,见图2)。专门的协调员负责安排这些请求的执行。功能代码必须打包到容器中,并上传到平台管理的Docker注册表[34]。为了处理单个函数的调用,协调器将请求定向到从服务器池中选择的调用方。

2023-03-13 10:23:02 221

原创 论文笔记:No Provisioned Concurrency: Fast RDMA-codesigned Remote Fork for Serverless Computing 中

a我们的目标是一个去中心化架构,每台机器都可以从其他机器分叉,反之亦然。请注意,我们不需要专用资源(例如固定内存)来分叉容器,因此,非服务器应用程序可以与MITOSIS一起运行。

2023-03-04 11:40:23 387

原创 论文笔记:No Provisioned Concurrency: Fast RDMA-codesigned Remote Fork for Serverless Computing 上

无服务器平台本质上面临着容器启动时间和配置的并发性(即缓存实例)之间的权衡,远程容器初始化的频繁需求进一步加剧了这种情况。本文介绍了 MITOSIS,一种提供快速远程分叉的操作系统原语,它利用 RDMA 操作系统内核的深度代码设计。通过利用 RDMA 的快速远程读取功能和跨无服务器容器的部分状态传输,MITOSIS 跨越了本地和远程容器 初始化 之间的性能鸿沟。MITOSIS是第一个在一秒内跨多台机器从一个实例中分叉10000多个新容器的,同时允许新容器有效地传输分叉的,容器。

2023-02-28 11:19:15 442 1

原创 无服务器(Serverless技术)特点——对比云原生架构,一文超通俗理解serverless

-首先我们知道,原本来说,固定的服务器(一般有物理机器、虚拟机等)就相应的固定了资源(包括内存、CPU、磁盘等等。)**serverless并非真的没有服务器!“无服务器”提供Serverless服务的平台拥有的物理无尽大(相对于单个或者一批业务),那么,完全处于一种按需分配的状态,这个点云原生也是类似的,那为什么不叫原来的云原生,而是我们产生新的技术serverless呢?那是因为,在这套技术下,服务器与应用不再捆绑,将应用与物理机器尽可能解耦,并且,要求就是实现对服务器资源对用户的透明,随时起,随时用

2023-02-26 21:54:06 906 1

一个包含三个数据集的数据包,成人、森林、电力。

基数估计的实验数据集,其中包含三个数据集,大小不一,来源不一,这里先不把实验和论文贴出来了,等答辩完成后贴出。 大家可以自行下载。

2022-04-17

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

提示
确定要删除当前文章?
取消 删除