• 关于

    后台管理入口开发

    的搜索结果

问题

淘宝手机助手,免费等您加入!

app客户经理 2019-12-01 21:40:30 13593 浏览量 回答数 6

回答

1 个人和企业云服务器自定义选购界面:https://www.aliyun.com/product/ecs?spm=a2c4e.11153987.0.0.37966b339Q8Hsv2 高性能通用云服务器入口:https://promotion.aliyun.com/ntms/act/qwbk.html3 领取官方通用1888元红包官网地址:https://promotion.aliyun.com/ntms/yunparter/invite.html 希望我回答能对你有所帮助吧。我这里给出了快速选配置(序号2)和自定义选择配置(序号1)两种选择。 第一步优先选择Linux操作系统。因为是绝大多数企业采用,安全和稳定第二步:用xshell和xftp远程连接远程Linux服务器第三步:利用阿里云服务器后台管理系统中的安全组规则,管理端口开放和关闭第四步:重置操作系统和软件镜像需要重启服务器,重置密码之后,也需要重启服务器才能生效。第五步:Linux操作系统可以开发java web,php网站。还有其它语言开发的web系统,例如pthyon

毓秀清荷 2019-12-01 23:10:36 0 浏览量 回答数 0

回答

1 个人和企业云服务器自定义选购界面:https://www.aliyun.com/product/ecs?spm=a2c4e.11153987.0.0.37966b339Q8Hsv2 高性能通用云服务器入口:https://promotion.aliyun.com/ntms/act/qwbk.html3 领取官方通用1888元红包官网地址:https://promotion.aliyun.com/ntms/yunparter/invite.html 希望我回答能对你有所帮助吧。我这里给出了快速选配置(序号2)和自定义选择配置(序号1)两种选择。 第一步优先选择Linux操作系统。因为是绝大多数企业采用,安全和稳定第二步:用xshell和xftp远程连接远程Linux服务器第三步:利用阿里云服务器后台管理系统中的安全组规则,管理端口开放和关闭第四步:重置操作系统和软件镜像需要重启服务器,重置密码之后,也需要重启服务器才能生效。第五步:Linux操作系统可以开发java web,php网站。还有其它语言开发的web系统,例如pthyon

毓秀清荷 2019-12-02 01:59:48 0 浏览量 回答数 0

阿里云高校特惠,助力学生创业梦!0元体验,快速入门云计算!

学生动手场景应用,快速了解并掌握云服务器的各种新奇玩法!

回答

1 个人和企业云服务器自定义选购界面:https://www.aliyun.com/product/ecs?spm=a2c4e.11153987.0.0.37966b339Q8Hsv2 高性能通用云服务器入口:https://promotion.aliyun.com/ntms/act/qwbk.html3 领取官方通用1888元红包官网地址:https://promotion.aliyun.com/ntms/yunparter/invite.html 希望我回答能对你有所帮助吧。我这里给出了快速选配置(序号2)和自定义选择配置(序号1)两种选择。 第一步优先选择Linux操作系统。因为是绝大多数企业采用,安全和稳定第二步:用xshell和xftp远程连接远程Linux服务器第三步:利用阿里云服务器后台管理系统中的安全组规则,管理端口开放和关闭第四步:重置操作系统和软件镜像需要重启服务器,重置密码之后,也需要重启服务器才能生效。第五步:Linux操作系统可以开发java web,php网站。还有其它语言开发的web系统,例如pthyon 大概需要内存4G,2核CPU,3兆宽带左右的服务器。当然你也可以考虑多台服务器集群部署,负载均衡分流网站流量。希望我的回答能帮助你哦

毓秀清荷 2019-12-01 23:49:40 0 浏览量 回答数 0

回答

为了满足用户提出的阿里钉钉与泛微OA集成需求,泛微推出了“云桥e-bridge平台”。 ““云桥e-bridge平台””是在原有微信集成平台的基础上,经过二次更新后的一款独立外部对接平台,其主要作用是实现泛微OA平台与微信企业号、阿里钉钉产品的信息对接能力。系统对接后,企业内部的OA信息通过微信企业号、阿里钉钉这一终端入口释放出来。 使用泛微云桥e-bridge平台的优势在于两点:第一是省时。虽然两家平台均开发API接口,但将两家平台的应用完全融合对接,仍然需要一定时间的接口开发工作。使用该集成平台后,一个工作日就可以配置完成,加快了系统对接的工作速度。第二是更简单,集成时直接在管理后台通过无代码配置完成,企业不需要安排工程师可以开发,节省了企业对接难度。 具体的集成操作流程可以直接联系OA厂商获取集成配置手册

移动办公系统 2020-01-06 10:37:11 0 浏览量 回答数 0

问题

广州.NET男屌求职 热:报错

kun坤 2020-06-08 11:11:12 3 浏览量 回答数 1

回答

开发者可直接在小程序内将用户转化为生活号粉丝,通过生活号的 消息能力,持续的运营,形成服务+运营的完整闭环。小程序与生活号有两种关系,这两种关系的使用场景和用途各不相同: 绑定(由小程序侧发起) 关联(由生活号侧发起) 关系 多对一:一个小程序只能绑定一个生活号,多个小程序可以绑定到一个生活号 多对多:一个生活号可以关联多个小程序,一个小程序可以被多个生活号关联 操作 小程序管理后台 生活号管理后台 作用 模板消息发送渠道 在小程序上展示关联的生活号(生活号关注组件) 模板消息跳转入口 生活号菜单 小程序关于面板上的消息入口 图文消息 一、小程序绑定生活号 小程序在绑定生活号后可,在小程序中使用关注/跳转生活号组件实现用户留存,在小程序内将用户转化为生活号粉丝。绑定生活号步骤如下: 1、登录小程序运营中心 > 存留工具 > 生活号管理。 注: (1)小程序只能绑定 1 个生活号。 (2)可选择绑定当前账号的生活号(已经在下方列出)和绑定其他账号的生活号(与当前小程序并不创建在同一个账号下选择)。 (3)如当前没有生活号,可直接选择 开通生活号。 s1.png 2、选择对应的生活号> 点击右侧的“绑定”按钮 绑定;绑定后会在界面上显示绑定的生活号(绑定其他账号的生活号:页面将弹出账户登录组件,输入您希望绑定的生活号所在的支付宝账号和密码,系统将向该账号绑定的手机号码发送短信验证码,获取校验码并输入)。 s2.png 二、生活号关联小程序 在关联小程序后可实现: (1)在生活号的菜单、营销位、广告位中可以配置小程序。 (2)在生活号发布的图文消息中可以插入小程序,或者直接跳转到小程序消息。 关联小程序步骤如下: 1、可在生活号后台 > 管理 > 小程序管理 > 关联小程序。 s3.png 2、输入小程序的APPID > 点击查找。 注: (1)生活号可关联多个小程序。 (2)小程序未上架,不能关联。点查找会提示“请输入正确的小程序appid后重试”。 s4.png

保持可爱mmm 2020-05-07 10:57:38 0 浏览量 回答数 0

回答

在工具栏右侧的 上传 菜单栏中,点击 上传 按钮。上传成功之后,后台会生成新的开发版本条目。查看方法:登录 小程序开发 中心,点击所需小程序,版本条目会在开发管理页面的 版本详情 区域显示。 上传之前的选项:  上传版本:每次上传时版本默认递增 0.0.1(本次版本必须大于线上版本),从而确保后台 每份代码版本唯一。  创建预审核任务:免费调用一台真机进行测试(每天 5 次限额),详情请参见 预审核。 配置域名白名单 在上传之前阶段(模拟器预览/调试、真机预览/调试),小程序默认不会限制域名 访问;但在上传之后阶段(体验版本、审核版本、灰度版本、线上版本),小程序 只能访问白名单域名。若未成功配置白名单,可能会导致小程序页面白屏。详细操 作可参见 配置 H5 服务器域名白名单。 配置步骤:登录 小程序开发中心,选择所需小程序。在左侧导航栏点击 设置,进入设置页面。点击 开发设置 标签,在 服务器域名白名单 区域点击 添加。填写所需域名,点击 确定。 注意:添加的域名必须支持 HTTPS 协议,而且已经完成备案。 详情  查看关联应用名称、项目本地目录、线上版本。  选择是否启用自定义组件 component2 编译、axml 严格语法检查。  查看 my.request、web-view 域名白名单信息。 设置是否忽略这两项域名检查。 注意:小程序 体验版 与 提审之后版本 无法继续忽略检查,届时请务必设置域名 白名单! 域名白名单设置入口有两处:  在详情页面,点击 域名信息 右侧蓝色按钮,进入设置页面,点击 开发设置。  登录 我的小程序,选择所需小程序;从左侧边栏进入 设置 > 开发设置。 内容来源:https://developer.aliyun.com/article/756818?spm=a2c6h.12873581.0.dArticle756818.26162b70Su1GZy&groupCode=tech_library

KaFei 2020-04-27 13:45:31 0 浏览量 回答数 0

回答

一 系统介绍 Android 是Google开发的基于Linux平台的、开源的、智能手机操作系统。Android包括操作系统、中间件和应用程序,由于源代码开放,Android可以被移植到不同的硬件平台上。 围绕在Google的Android系统中,形成了移植开发和上层应用程序开发两个不同的开发方面。手机厂商从事移植开发工作,上层的应用程序开发可以由任何单位和个人完成,开发的过程可以基于真实的硬件系统,还可以基于仿真器环境。 作为一个手机平台,Android在技术上的优势主要有以下几点: - 全开放智能手机平台 - 多硬件平台的支持 - 使用众多的标准化技术 - 核心技术完整,统一 - 完善的SDK和文档 - 完善的辅助开发工具 Android的开发者可以在完备的开发环境中进行开发,Android的官方网站也提供了丰富的文档、资料。这样有利于Android系统的开发和运行在一个良好的生态环境中。 https://developer.android.com/about安卓开发者官方网站 从宏观的角度来看,Android是一个开放的软件系统,它包含了众多的源代码。从下至上,Android系统分成4个层次: 第1层次:Linux操作系统及驱动; 第2层次:本地代码(C/C++)框架; 第3层次:Java框架; 第4层次:Java应用程序。 Android系统的架构如图所示: 由于Android系统需要支持Java代码的运行,这部分内容是Android的运行环境(Runtime),由虚拟机和Java基本类组成。 对于Android应用程序的开发,主要关注第3层次和第4层次之间的接口。 二 学习路线 基础学习——JavaSE: 基础学习扩展——JavaEE: 基础学习扩展——Linux基础: Android开发学习——基础理论:系统架构分析: Android系统从底向上一共分了4层,每一层都把底层实现封装,并暴露调用接口给上一层。 Linux内核(Linux Kernel) Android运行在linux kernel 2.6之上,但是把linux内受GNU协议约束的部分做了取代,这样在Android的程序可以用于商业目的。 Linux 内核是硬件和软件层之间的抽象层。 中间件 中间件包括两部分: 核心库和运行时(libraries & Android runtime) 核心库包括,SurfaceManager 显示系统管理库,负责把2D或3D内容显示到屏幕;Media Framework 媒体库,负责支持图像,支持多种视频和音频的录制和回放;SQlite 数据库,一个功能强大的轻量级嵌入式关系数据库;WebKit 浏览器引擎等。 Dalvik虚拟机: 区别于Java虚拟机的是,每一个Android 应用程序都在它自己的进程中运行,都有一个属于自己的Dalvik 虚拟机,这一点可以让系统在运行时可以达到优化,程序间的影响大大降低。Dalvik虚拟机并非运行Java字节码,而是运行自己的字节码。 应用程序框架(Application Framework) 丰富而又可扩展性的视图(Views),可以用来构建应用程序, 它包括列表(lists),网格(grids), 文本框(text boxes),按钮( buttons), 可嵌入的web 浏览器。内容提供者(Content Providers)使得应用程序可以访问另一个应用程序的数据(如联系人数据库), 或者共享它们自己的数据。资源管理器(Resource Manager)提供非代码资源的访问,如本地字符串,图形,和布局文件( layoutfiles )。通知管理器(Notification Manager) 使得应用程序可以在状态栏中显示自定义的提示信息。活动管理器( Activity Manager) 用来管理应用程序生命周期并提供常用的导航回退功能。 三 基础知识 掌握java部分之后,可以使用开发工具进入android世界 您可以使用 Kotlin、Java 和 C++ 语言编写 Android 应用。Android SDK 工具会将您的代码连同任何数据和资源文件编译成一个 APK(Android 软件包),即带有 .apk 后缀的归档文件。一个 APK 文件包含 Android 应用的所有内容,它也是 Android 设备用来安装应用的文件。 每个 Android 应用都处于各自的安全沙盒中,并受以下 Android 安全功能的保护: • Android 操作系统是一种多用户 Linux 系统,其中的每个应用都是一个不同的用户; • 默认情况下,系统会为每个应用分配一个唯一的 Linux 用户 ID(该 ID 仅由系统使用,应用并不知晓)。系统会为应用中的所有文件设置权限,使得只有分配给该应用的用户 ID 才能访问这些文件; • 每个进程都拥有自己的虚拟机 (VM),因此应用代码独立于其他应用而运行。 • 默认情况下,每个应用都在其自己的 Linux 进程内运行。Android 系统会在需要执行任何应用组件时启动该进程,然后当不再需要该进程或系统必须为其他应用恢复内存时,其便会关闭该进程。 Android 系统实现了最小权限原则。换言之,默认情况下,每个应用只能访问执行其工作所需的组件,而不能访问其他组件。这样便能创建非常安全的环境,在此环境中,应用无法访问其未获得权限的系统部分。不过,应用仍可通过一些途径与其他应用共享数据以及访问系统服务: • 可以安排两个应用共享同一 Linux 用户 ID,在此情况下,二者便能访问彼此的文件。为节省系统资源,也可安排拥有相同用户 ID 的应用在同一 Linux 进程中运行,并共享同一 VM。应用还必须使用相同的证书进行签名。 • 应用可以请求访问设备数据(如用户的联系人、短信消息、可装载存储装置(SD 卡)、相机、蓝牙等)的权限。用户必须明确授予这些权限。如需了解详细信息,请参阅使用系统权限。 本文档的其余部分将介绍以下概念: • 用于定义应用的核心框架组件 • 用来声明组件和应用必需设备功能的清单文件。 • 与应用代码分离并允许应用针对各种设备配置适当优化其行为的资源。 应用组件 应用组件是 Android 应用的基本构建块。每个组件都是一个入口点,系统或用户可通过该入口点进入您的应用。有些组件会依赖于其他组件。 共有四种不同的应用组件类型: • Activity • 服务 • 广播接收器 • 内容提供程序 每种类型都有不同的用途和生命周期,后者会定义如何创建和销毁组件。以下部分将介绍应用组件的四种类型。 Activity Activity 是与用户交互的入口点。它表示拥有界面的单个屏幕。例如,电子邮件应用可能有一个显示新电子邮件列表的 Activity、一个用于撰写电子邮件的 Activity 以及一个用于阅读电子邮件的 Activity。尽管这些 Activity 通过协作在电子邮件应用中形成一种紧密结合的用户体验,但每个 Activity 都独立于其他 Activity 而存在。因此,其他应用可以启动其中任何一个 Activity(如果电子邮件应用允许)。例如,相机应用可以启动电子邮件应用内用于撰写新电子邮件的 Activity,以便用户共享图片。Activity 有助于完成系统和应用程序之间的以下重要交互: • 追踪用户当前关心的内容(屏幕上显示的内容),以确保系统继续运行托管 Activity 的进程。 • 了解先前使用的进程包含用户可能返回的内容(已停止的 Activity),从而更优先保留这些进程。 • 帮助应用处理终止其进程的情况,以便用户可以返回已恢复其先前状态的 Activity。 • 提供一种途径,让应用实现彼此之间的用户流,并让系统协调这些用户流。(此处最经典的示例是共享。) 您需将 Activity 作为 Activity 类的子类来实现。如需了解有关 Activity 类的更多信息,请参阅 Activity 开发者指南。 服务 服务是一个通用入口点,用于因各种原因使应用在后台保持运行状态。它是一种在后台运行的组件,用于执行长时间运行的操作或为远程进程执行作业。服务不提供界面。例如,当用户使用其他应用时,服务可能会在后台播放音乐或通过网络获取数据,但这不会阻断用户与 Activity 的交互。诸如 Activity 等其他组件可以启动服务,使该服务运行或绑定到该服务,以便与其进行交互。事实上,有两种截然不同的语义服务可以告知系统如何管理应用:已启动服务会告知系统使其运行至工作完毕。此类工作可以是在后台同步一些数据,或者在用户离开应用后继续播放音乐。在后台同步数据或播放音乐也代表了两种不同类型的已启动服务,而这些服务可以修改系统处理它们的方式: • 音乐播放是用户可直接感知的服务,因此,应用会向用户发送通知,表明其希望成为前台,从而告诉系统此消息;在此情况下,系统明白它应尽全力维持该服务进程运行,因为进程消失会令用户感到不快。 • 通常,用户不会意识到常规后台服务正处于运行状态,因此系统可以更自由地管理其进程。如果系统需要使用 RAM 来处理用户更迫切关注的内容,则其可能允许终止服务(然后在稍后的某个时刻重启服务)。 绑定服务之所以能运行,原因是某些其他应用(或系统)已表示希望使用该服务。从根本上讲,这是为另一个进程提供 API 的服务。因此,系统会知晓这些进程之间存在依赖关系,所以如果进程 A 绑定到进程 B 中的服务,系统便知道自己需使进程 B(及其服务)为进程 A 保持运行状态。此外,如果进程 A 是用户关心的内容,系统随即也知道将进程 B 视为用户关心的内容。由于存在灵活性(无论好坏),服务已成为非常有用的构建块,并且可实现各种高级系统概念。动态壁纸、通知侦听器、屏幕保护程序、输入方法、无障碍功能服务以及众多其他核心系统功能均可构建为在其运行时由应用实现、系统绑定的服务。 您需将服务作为 Service 的子类来实现。如需了解有关 Service 类的更多信息,请参阅服务开发者指南。 注意:如果您的应用面向 Android 5.0(API 级别 21)或更高版本,请使用 JobScheduler 类来调度操作。JobScheduler 的优势在于,它能通过优化作业调度来降低功耗,以及使用 Doze API,从而达到省电目的。如需了解有关使用此类的更多信息,请参阅 JobScheduler 参考文档。 广播接收器 借助广播接收器组件,系统能够在常规用户流之外向应用传递事件,从而允许应用响应系统范围内的广播通知。由于广播接收器是另一个明确定义的应用入口,因此系统甚至可以向当前未运行的应用传递广播。例如,应用可通过调度提醒来发布通知,以告知用户即将发生的事件。而且,通过将该提醒传递给应用的广播接收器,应用在提醒响起之前即无需继续运行。 许多广播均由系统发起,例如,通知屏幕已关闭、电池电量不足或已拍摄照片的广播。应用也可发起广播,例如,通知其他应用某些数据已下载至设备,并且可供其使用。尽管广播接收器不会显示界面,但其可以创建状态栏通知,在发生广播事件时提醒用户。但广播接收器更常见的用途只是作为通向其他组件的通道,旨在执行极少量的工作。例如,它可能会根据带 JobScheduler 的事件调度 JobService 来执行某项工作 广播接收器作为 BroadcastReceiver 的子类实现,并且每条广播都作为 Intent 对象进行传递。如需了解详细信息,请参阅 BroadcastReceiver 类。 内容提供程序 内容提供程序管理一组共享的应用数据,您可以将这些数据存储在文件系统、SQLite 数据库、网络中或者您的应用可访问的任何其他持久化存储位置。其他应用可通过内容提供程序查询或修改数据(如果内容提供程序允许)。例如,Android 系统可提供管理用户联系人信息的内容提供程序。 因此,任何拥有适当权限的应用均可查询内容提供程序(如 ContactsContract.Data),以读取和写入特定人员的相关信息。我们很容易将内容提供程序看作数据库上的抽象,因为其内置的大量 API 和支持时常适用于这一情况。但从系统设计的角度看,二者的核心目的不同。对系统而言,内容提供程序是应用的入口点,用于发布由 URI 架构识别的已命名数据项。因此,应用可以决定如何将其包含的数据映射到 URI 命名空间,进而将这些 URI 分发给其他实体。反之,这些实体也可使用分发的 URI 来访问数据。在管理应用的过程中,系统可以执行以下特殊操作: • 分配 URI 无需应用保持运行状态,因此 URI 可在其所属的应用退出后继续保留。当系统必须从相应的 URI 检索应用数据时,系统只需确保所属应用仍处于运行状态。 • 这些 URI 还会提供重要的细粒度安全模型。例如,应用可将其所拥有图像的 URI 放到剪贴板上,但将其内容提供程序锁定,以便其他应用程序无法随意访问它。当第二个应用尝试访问剪贴板上的 URI 时,系统可允许该应用通过临时的 URI 授权来访问数据,这样便只能访问 URI 后面的数据,而非第二个应用中的其他任何内容。 内容提供程序也适用于读取和写入您的应用不共享的私有数据。 内容提供程序作为 ContentProvider 的子类实现,并且其必须实现一组标准 API,以便其他应用能够执行事务。如需了解详细信息,请参阅内容提供程序开发者指南。 Android 系统设计的独特之处在于,任何应用都可启动其他应用的组件。例如,当您想让用户使用设备相机拍摄照片时,另一个应用可能也可执行该操作,因而您的应用便可使用该应用,而非自行产生一个 Activity 来拍摄照片。您无需加入甚至链接到该相机应用的代码。只需启动拍摄照片的相机应用中的 Activity 即可。完成拍摄时,系统甚至会将照片返回您的应用,以便您使用。对用户而言,这就如同相机是您应用的一部分。 当系统启动某个组件时,它会启动该应用的进程(如果尚未运行),并实例化该组件所需的类。例如,如果您的应用启动相机应用中拍摄照片的 Activity,则该 Activity 会在属于相机应用的进程(而非您的应用进程)中运行。因此,与大多数其他系统上的应用不同,Android 应用并没有单个入口点(即没有 main() 函数)。 由于系统在单独的进程中运行每个应用,且其文件权限会限制对其他应用的访问,因此您的应用无法直接启动其他应用中的组件,但 Android 系统可以。如要启动其他应用中的组件,请向系统传递一条消息,说明启动特定组件的 Intent。系统随后便会为您启动该组件。 启动组件 在四种组件类型中,有三种(Activity、服务和广播接收器)均通过异步消息 Intent 进行启动。Intent 会在运行时对各个组件进行互相绑定。您可以将 Intent 视为从其他组件(无论该组件是属于您的应用还是其他应用)请求操作的信使。 您需使用 Intent 对象创建 Intent,该对象通过定义消息来启动特定组件(显式 Intent)或特定的组件类型(隐式 Intent)。 对于 Activity 和服务,Intent 会定义要执行的操作(例如,查看或发送某内容),并且可指定待操作数据的 URI,以及正在启动的组件可能需要了解的信息。例如,Intent 可能会传达对 Activity 的请求,以便显示图像或打开网页。在某些情况下,您可以通过启动 Activity 来接收结果,这样 Activity 还会返回 Intent 中的结果。例如,您可以发出一个 Intent,让用户选取某位联系人并将其返回给您。返回 Intent 包含指向所选联系人的 URI。 对于广播接收器,Intent 只会定义待广播的通知。例如,指示设备电池电量不足的广播只包含指示“电池电量不足”的已知操作字符串。 与 Activity、服务和广播接收器不同,内容提供程序并非由 Intent 启动。相反,它们会在成为 ContentResolver 的请求目标时启动。内容解析程序会通过内容提供程序处理所有直接事务,因此通过提供程序执行事务的组件便无需执行事务,而是改为在 ContentResolver 对象上调用方法。这会在内容提供程序与请求信息的组件之间留出一个抽象层(以确保安全)。 每种组件都有不同的启动方法: • 如要启动 Activity,您可以向 startActivity() 或 startActivityForResult() 传递 Intent(当您想让 Activity 返回结果时),或者为其安排新任务。 • 在 Android 5.0(API 级别 21)及更高版本中,您可以使用 JobScheduler 类来调度操作。对于早期 Android 版本,您可以通过向 startService() 传递 Intent 来启动服务(或对执行中的服务下达新指令)。您也可通过向将 bindService() 传递 Intent 来绑定到该服务。 • 您可以通过向 sendBroadcast()、sendOrderedBroadcast() 或 sendStickyBroadcast() 等方法传递 Intent 来发起广播。 • 您可以通过在 ContentResolver 上调用 query(),对内容提供程序执行查询。 如需了解有关 Intent 用法的详细信息,请参阅 Intent 和 Intent 过滤器文档。以下文档将为您详细介绍如何启动特定组件:Activity、服务、BroadcastReceiver 和内容提供程序。

问问小秘 2020-03-03 09:47:38 0 浏览量 回答数 0

回答

不要等到把数据搞大了才分析 我们一谈到数据分析,总离不开大数据,但要发挥大数据分析的真正价值并没有想象的那些容易,DMS倡导:不要等到把数据搞大了才分析。 数据管理DMS推出数据变化功能,通过对RDS内核定制,高性能采集每个实例、数据库及表的行数变化,并通过专业的数据分析交互,提供实时监控、历史趋势及明细数据等分析方式,然而该功能真的能带来价值? 某大型购物网站用户是这样用的,用DMS登录后台RDS数据库,打开订单表order的表数据变化页面,据说,用户看到3条实时曲线时已经知道这是订单笔数在变化: 曲线(插入行数):订单创建笔数曲线(删除行数):订单取消笔数曲线(更新行数):订单修改笔数 数据变化的使用场景就这一种?是的,不过我相信聪明的用户一定能找到适合自己的使用场景,另外,数据变化暂时只能提供行数变化信息,但较传统数据分析方式已经有了巨大提升。 回想如果用传统方式干这件事情,要怎么做?基本是将数据同步到大数据平台或者是定时打点统计的方式完成,开发成本高,对源数据库有不小影响,并且很难做到实时分析数据变化趋势,那么,数据变化在哪里可以试用? 功能入口:DMS登录数据库-性能-数据变化。 ------------------------- 回 2楼(异次元大神) 的帖子 这份数据是咱们RDS特有的,RDS内核改造过,原生MySQL、Percona MySQL都不支持的。 ------------------------- 回 2楼(异次元大神) 的帖子 之前有用户给我提过需求,需要一个简单的、能反映业务波动的监控。 和用户细聊后,发现用户的程序上线前很少会考虑打点,只有少量会写到日志中,偶尔用shell分析一次,后来单独拿个RDS来存这份数据,不过维护挺烦的。 最近,DMS利用RDS特性,开发了“表/库数据变化”,用户在DMS上可以实时监控业务数据变化,经过DMS后台一段时间采集,用户还能看到业务数据历史趋势,还可以进行“天/周/月”粒度的数据聚合分析。 ------------------------- 回 5楼(arker) 的帖子 针对绝大多数用户需求提供“免费版”,是免费的哟。 针对少量用户高级需求提供“高级版”,根据用户不同选择来收费。 免费版+高级版,满足不同人群的需求。 而高级功能,或会消耗资源,或会提升效率,或会带来安全保护,或提供数据分析功能。 ------------------------- 回 8楼(歪歪什么) 的帖子 DMS支持MongoDB VPC登录,需要MongoDB产品提供一些接口,目前DMS正在推动MongoDB产品提供,春节前一定来不及,稍后有进展我再通知你 ------------------------- 回 7楼(zngame) 的帖子 ------------------------- 回 11楼(deertt) 的帖子 限制drop无需DMS出手,RDS已经解决了。 RDS推出“高权限帐号” 可以创建各种权限的数据库帐号,限制drop啥的,自然不在话下。 去RDS控制台-帐号管理 创建高权限帐号。 ------------------------- 回 16楼(jiangrenjin) 的帖子 白名单提示已经优化了,之前提示不好 ------------------------- 回 14楼(亨利于) 的帖子 DMS免费版会一直迭代的。 高级版的出现,一方面是DMS支撑几十万用户,已经到了必须把高资源消耗的功能区别对待的时候了,另一方面提供更高级功能更定制化功能,也是部分用户需要的。

数据管理dms 2019-12-01 23:53:30 0 浏览量 回答数 0

问题

服务器运维系列教程(二):服务搭建---Windows篇

千鸟 2019-12-01 21:53:28 10096 浏览量 回答数 2

回答

http://ajaxpatterns.org/Timeout文章里面提到的方式应该是比较好的方案了,主要是在客户端处理,当即将超时时,给用户一个提示,让用户处理,当最后客户端真的超时时,再给用户一次机会处理。超时后停止掉ajax轮询,把超时信息发送给服务端,invalidate session。如果要采用自动地方式,需要捕捉鼠标,键盘事件。 ######请求每个模块时,session储存下最后一次操作时间,ajax模式获取数据时,服务器端判断下是不是ajax请求,是的话,服务器端看下session最后一次操作时间,不满足要求就清空,退出处理。 不要依赖系统设置的session存活时间,这个不靠谱 ###### 这位兄弟说的的确不失为一种做法。 不过我们这边的系统目前session超时只是依赖的web.xml里的配置的时间,不会放在程序里面写。因为必须做到随时能够修改时间。 我想寻找一种改动尽量小一点的,毕竟这是正式投入生产的系统,我的主管不会让我为了这么一个需求,在每个模块里面存时间。 这个问题换一种说法就是,既然说我点击每一个模块,tomcat都当做我是发起了一次请求,那么我如何做到ajax请求过来的时候,我不把它当做请求。可以有最简单的方法么。 开发语言是java,开发工具eclipse/tomcat @cgf986916 ######回复 @cgf986916 : 恩,我试试,非常感谢######单入口的话,更好弄了,入口处添加新session直接保存下最后操作时间,这个规则内做ajax请求判断,其他弄个包吧,引入下做个判断,或者做个拦截器也行,你自己看下那个符合你需求就行了。###### 大哥,你不会自己实现session啊。就是tomcat 里有个Set<userId> ajax不更新不完了。弄个拦截器。你也可以采用类似360的token机制。原理一样。 再一个方案是你弄个fiter。然后存用户最后时间,不合适的logout。哎目测你新手 ######恩,其实session这东西本身我就没弄太清楚。受教了######可以写一个全局的filter,在filter里存储session的最后一次操作时间啊,不必在每个模块里都写######我这边的要求是尽量不要有大的改动,因为访问量很大,如果加一个过滤器,会拦截每一次请求,又增添了系统的压力。 我听说有一种做法是直接在页面层套一个iframe还是什么的(只是听说),我现在必须是既完成任务,又要改动最小。###### 如果要求不是特别高的话,就在cookie里面加入时间戳,如果是ajax的话,时间戳就不加进去,这样也可用做判断。 ######这是最好的.###### 写一个filter 判断request的header是不是AJAX请求(X-Requested-With), ######当是AJAX请求的时候,不去确认登录与否######但是怎么才能让session不更新最后访问时间呢?######既然每隔两分钟就要扫表,干脆在后台做成定时任务好了,完全不需要前台的ajax来处理。管理员登录就开始这个Job,登出后就撤销。######回复 @liuxin : 非常感谢######回复 @龙王巴哈姆特 : 肯定不会啊,服务器端程序,并不需要登录或者请求的######扫完表以后要去更新页面导航上的一个数字,就跟QQ消息条数一样的。job做不到吧。 顺便问下,job扫表,容器会不会认为这也算一个操作行为,并认为这个session用户是活跃的? 本人初学,望多指点######找到解决方案了,你用一个JSP来实现这个扫表的功能,在JSP的开头加上<%@ page session="false" %>,这样就把session功能关闭了,不管你请求多少次,都不影响现有的用户。亲测可行。###### @antipro 这个头的作用是1.该JSP无法直接访问内置session变量 2.不会自动创建session。我试过ajax 2分钟扫一次,设置session超时是3分钟。我等了5分钟后,session仍然没有过期。这个头并不能阻止ajax在请求的时候自动记录session最后更新时间。 并且还有另外一个问题,就是我这里的ajax,是跟用户名,修改密码,退出一起的如下图: 代码结构大致是一个ul,li结构 <ul> <li>用户名XXX</li> <li>风险交易XXX</li> <li>修改密码</li> <li>退出</li> </ul> ,我把代码都放在一个JSP里面,然后include去了“风险交易”那个li里面,并加上了头<%@ page session="false" %>结果我发现整个页面都不能使用session变量了。导致我的用户名也显示不出来了。 昨天说的最多的加一个Filter也被我的主管无情的否决掉了。不管这个问题最后解决没,还是希望朋友们多交流,能让我多多学习下。 session超时的一篇文章: http://zmx.iteye.com/blog/1846181   ######回复 @龙王巴哈姆特 : 你用的是include指令包含的子页面?这样恐怕不行。######回复 @antipro : 我测试的时候,确实是只让那个jsp页面返回18,丢在我那个li里面,我试过了不行。并且外层页面也不能使用session变量了。跟他同级的用户名就是取的session VO里的数据也失效了。这种定时扫表,并且之后要更新页面数字的,除了用ajax还有更好的选择吗?######你怎么把整个页面都用来实现你的功能了,我设想的JSP只要返回一个18就可以了,其他内容都还是用原来的功能啊。######我不知道你是怎么测试的,但是我亲自测试了是正常的。至于不能用session的问题,禁止了session当然不能再用了,难道就没有其他的方法访问你要的数据了吗?要灵活处理啊。

爱吃鱼的程序员 2020-06-01 11:08:14 0 浏览量 回答数 0

回答

DMS for linux 6月23日更新预告,敬请期待 更新啦!更新啦!更新啦!本周(6月28号)dms for linux 将发布新版本,内容如下,尽情期待         1、命令终端支持rz文件上传命令,只要能ssh登陆,无论跳几级,都可以上传。支持目录哦,真心赞!具体包括: 文件/目录点击上传; 文件/目录拖动上传; 命令行文件上传进度;                       2、服务管理兼容centos7+的systemd协议的管理,提供更高效地服务管理模式                    3、右上角开放更直接的问题反馈入口,链接可以直达本帖,如果您在使用过程中遇到什么问题,或者对我们产品有什么诉求,欢迎轰炸我们程序员GG哦,我们会第一时间内反馈。 ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 如果您第一次点入本帖,欢迎使用阿里云数据管理产品: https://dms.console.aliyun.com/#/dms/rsList 阿里云数据管理旨在一站式管理您所有云上资源 ------------------------- 回 2楼(龙吟风) 的帖子 数据管理DMS支持数据库管理、Linux管理,无需安装,易用专业,目前在云上已经有30W用户,你可以试下 https://www.aliyun.com/product/dms ------------------------- 回 6楼(大一中) 的帖子 谢谢支持,O(∩_∩)O哈哈~ ------------------------- 各位在使用dms的过程中遇到什么问题,或者有什么建议,直接在这个帖子下面提问喔 ------------------------- 回 9楼(付一二) 的帖子 您好,谢谢反馈,您说的这种是不是针对类似于apache的应用配置管理?我们目前已经正在计划深挖常用应用的管理功能包括apache,mysql等,包括配置管理,服务性能监控等,这个的确对服务的运维很有用处。我们会在后续版本加入此功能,敬请期待哦,O(∩_∩)O~。 ------------------------- 回 11楼(cokll) 的帖子        抱歉给您工作带来不便,请问这个问题只是出现在实时监控模块吗?其他模块没有报这个错么?        这个问题主要原因是您当前主机的sshd服务对单个session上的channel数量作了限制导致的。dms for linux 的实时监控模块在加载页面时需要建立多个channel执行命令,如果当前保持的channel的数量超出您主机的限制,继续建立channel就会抛出channel未打开的错误,这个配置项是/etc/ssh/sshd_config 里面的MaxSessions的配置。        我刚刚检查了一下我们的代码,发现代码中存在长时间保持单个channel的情况,导致新建channel不成功。我们代码中的bug将在下一个版本修复(约7月13号(周三))。届时请如果还有问题,请及时联系我们喔。       再次感谢您的反馈。    ------------------------- 回 11楼(cokll) 的帖子 您好,麻烦检查下您机器上的/etc/ssh/sshd_config 中是否有配置过MaxSessions这个参数,如果最大的session数被限制为1,您主机只能支持终端登陆,就用不了dms for linux的其他的功能了。 我们经过测试,能支持dms的最小的session数量为3,也就是MaxSession的值应当不小于3(默认值为10)。如果可以的话,您可以修正下这个配置然后重启下sshd服务。 如果还有问题,烦请及时反馈,谢谢亲 ------------------------- 回 15楼(山水佳) 的帖子 您好, 抱歉回复晚了,请问您是使用实时监控的查看线程栈的功能遇到这个错误的吗?实时监控模块一般不会抛出这个错,可否截一下图看看? ------------------------- 回 18楼(caesar.w.h) 的帖子 您好, 感谢您的反馈,请问您当前用的是什么浏览器?有没有在浏览器上做过某些安全性的限制? 这个问题一般是浏览器禁用了跨域请求导致我们dms控制台的登陆请求没法到达dms应用的服务器。 我们建议一般使用chrome或者火狐浏览器访问dms,如果可以的话可以换一下浏览器重新尝试下。。 如果还有问题请保持沟通过哦O(∩_∩)O~ ------------------------- 回 22楼(caesar.w.h) 的帖子 您好,抱歉回复晚了,请问是所有数据库实例都添加不了还是仅一个实例是这样? 如果仅一个实例,那么这个实例是什么类型的数据库? 如果所有实例都添加不了,有没有尝试过把浏览器卸载重装后结果还是一样?或者是,用一台新机器上的浏览器试试是否是相同的情况? 这个问题我们之前是遇到过的,主要原因是添加数据库的请求没有发送出去,还没到连接数据库那一步呢,可能是浏览器阻拦的原因,上次我们也是通过更换浏览器解决的。麻烦您按照上面的步骤再尝试下,如果还不行的话,还请保持联系噢。 感谢您对dms的支持O(∩_∩)O~ ------------------------- 回 24楼(無名塵客) 的帖子 您好,这个问题您是否已经通过工单和我们客服团队反馈过? 抱歉给您带来不便,这个问题具体原因是这样的: 您这个实例是mysql5.1版本,不支持INNODB_BUFFER_POOL_READ_REQUESTS,INNODB_BUFFER_POOL_READS这两个参数导致我们dms首页会出现500错误。目前dms支持的mysql版本是5.4之后的版本。 这个问题涉及到对老版本mysql的兼容,具体怎么改得和我们负责这一块的开发人员沟通下 ------------------------- 回 26楼(caesar.w.h) 的帖子 您好,请问用谷歌浏览器具体是什么情况?登陆会报什么错? 目前我们后台统计,使用dms的大部分是chrome用户,没有遇到类似的问题,可能是浏览器中存在某些插件原因吧。 ------------------------- 回 30楼(斯斯) 的帖子 谢谢反馈,这个问题我们已经在看,主要原因是我们现在的监控模块对部分主机的性能数据兼容性不够强,也说明我们的代码健壮性不够强。 目前我们正在查看日志寻找错误原因,预计下个发布可以修复(约下周二之前),届时麻烦线上验证下。谢谢 ------------------------- 引用第32楼ivmmff于2016-07-27 14:31发表的  : 命令终端不能粘贴命令太蛋疼 [url=https://bbs.aliyun.com/job.php?action=topost&tid=286015&pid=807524][/url] 您好,目前我们没有支持右键粘贴的功能。 您可以使用Ctrl + V、Shift + Insert 等方式进行粘贴。 后续我们会支持右键粘贴的功能,感谢您的关注。 ------------------------- 回 31楼(galphy) 的帖子 你好,目前我们没有对命令终端的操作超时做控制,正常情况下没有操作,至少6分钟之后才会断开,如果少于6分钟,可能是您主机设置了空闲超时时间。 请参考一下: http://blog.chinaunix.net/uid-8473611-id-3069386.html 后续我们会加上链接超时控制,届时您可以自己设置超时时间,敬请期待。 ------------------------- 回 29楼(胡胡abc) 的帖子 您好,请问这台主机是linux是什么发行版本,是ECS么? ------------------------- 回 30楼(斯斯) 的帖子 不好意思哦,刚刚我们翻了下日志,并没能找到有记录ArrayIndexOutOfBound的错误。为了节省沟通成本,能否提供一下您当前主机的ip,和权限比较低的账号,密码供我们测试下? 如果可以的话能否提供下旺旺账号,我们可以去加你下。或者可以加我的账号,旺旺搜索"帅博"。 希望能高效地解决您的问题,感谢支持。 ------------------------- 回 43楼(不羁的行者) 的帖子 你好,目前文件管理模块还不支持上传文件夹。 建议打开dms的命令终端,直接输入rz命令上传噢。支持文件,文件夹,批量上传,拖动上传,功能很好用噢,O(∩_∩)O~ ------------------------- 回 48楼(fightgod) 的帖子 您好,我们以后会加入设置终端声音的功能,下个版本我们会暂时先去掉终端声音,等设置功能上线后再加上。O(∩_∩)O~ ------------------------- 回 50楼(fightgod) 的帖子 您好,windows系统和linux相比其内部机制和实现方式要复杂很多,目前我们的技术宅们正努力探索中。。。。 一旦技术方案定下来我们就会开展实施支持windows系统,敬请期待哦O(∩_∩)O~ ------------------------- 回 63楼(woaj01) 的帖子 您好,请问您的那台主机在ECS上已被删除多久了?我们这边也是通过api从ECS那边取的主机列表,api返回的数据会有一定的延迟,但也不会很久。 如果您的主机已经删除很久了,麻烦请告诉我们,我们会去和ECS方面沟通,解决这一问题 ------------------------- 回 66楼(fightgod) 的帖子 您好,您提的批量操作命令的界面,我们会认真考虑,如何去优化在主机较多的时候用户对终端返回的信息的同步。 您说的批量文件上传方面,我们恰巧将近期上线批量rz的功能,敬请期待哦O(∩_∩)O~ ------------------------- 回 69楼(初一) 的帖子 你好,能否详述一下你遇到的问题,是什么功能授权失败? ------------------------- 回 72楼(汇爱家) 的帖子 您好,您的建议我们会记录,并选择合适的配色方案,改进我们的用户体验,感谢反馈 ------------------------- 回 75楼(初一) 的帖子 您好,目前dms for linux的文件管理是支持更改文件所有者的。您可以右键->授权,弹出的授权框中可以更改所有者和用户组的信息。                                                                                      ------------------------- 回 76楼(meenet) 的帖子 您好,您是指怎么在线编辑文件? 我们的文件管理的功能可以直接编辑和保存文件的,如果是二进制文件还可以直接用二进制的方式打开,类似于UE的功能。 ------------------------- 回 79楼(啊彬彬) 的帖子 你好,请问你重启的是什么服务?一些系统服务是不能关闭的,关闭会导致系统不稳定甚至崩溃,重启下主机就可以恢复了。 ------------------------- 回 85楼(koder) 的帖子 您好,如果使用证书登录后目前仅可以查看非sudo权限的服务状态,需要sudo权限的服务,暂时是获取不到信息,通过控制台的系统管理-->服务管理可以进入相应页面。如果您想看所有服务的状态请先到控制台切换密码登陆。您的密码在我们后台都是经过严格加密处理的,所以您不用担心安全问题。 后续我们会针对证书登录用户,提供临时输入密码的交互。敬请继续关注我们dms产品 ------------------------- 回 86楼(樱花雾翔eva) 的帖子 您好,抱歉,我们dms控制台目前不支持删除数据库和ecs资源,资源列表是从ecs和rds控制台同步过来的,如果有资源过期被释放,dms控制台上相应也会释放。 我们后续控制台会加入资源隐藏的选项,可以暂时隐藏暂时不用的资源。感谢关注dms产品 ------------------------- 回 92楼(jasonyao525) 的帖子 您好,ssh服务关闭后就不能使用dms了,命令终端也不可以使用,您可以通过ecs控制台或者联系客服来重新开启该服务。 ------------------------- 回 90楼(jrl_limeng) 的帖子 您好,终端的颜色我们之前已经调整过,能否截个图看看?

数据管理dms 2019-12-02 02:01:24 0 浏览量 回答数 0

问题

某政务网站性能优化

猫饭先生 2019-12-01 21:25:38 1412 浏览量 回答数 0

回答

转自:阿飞的博客 一、数据库技术选型的思考维度 我们做选型的时候首先要问: 谁选型?是负责采购的同学、 DBA 还是业务研发? 如果选型的是采购的同学,他们更注重成本,包括存储方式、网络需求等。 如果选型的是 DBA 同学,他们关心的: ① 运维成本 首先是运维成本,包括监控告警是否完善、是否有备份恢复机制、升级和迁移的成本是否高、社区是否稳定、是否方便调优、排障是否简易等; ② 稳定性 其次,DBA会关注稳定性,包括是否支持数据多副本、服务高可用、多写多活等; ③ 性能 第三是性能,包括延迟、QPS 以及是否支持更高级的分级存储功能等; ④ 拓展性 第四是扩展性,如果业务的需求不确定,是否容易横向扩展和纵向扩容; ⑤ 安全 最后是安全,需要符合审计要求,不容易出现 SQL 注入或拖库情况。 ⑥ 其他 除了采购和 DBA之外,后台应用研发的同学同样会关注稳定性、性能、扩展性等问题,同时也非常关注数据库接口是否便于开发,是否便于修改数据库 schema 等问题。 接下来我们来看一下爱奇艺使用的数据库类型: MySQL,互联网业务必备系统; TiDB,爱奇艺的 TiDB 实践会有另外的具体介绍; Redis,KV 数据库,互联网公司标配; Couchbase,这个在爱奇艺用得比较多,但国内互联网公司用得比较少,接下来的部分会详细说明; 其他,比如 MongoDB、图数据库、自研 KV 数据库 HiKV 等; 大数据分析相关系统,比如 Hive、Impala 等等。 可以看到爱奇艺的数据库种类还是很多的,这会造成业务开发的同学可能不太清楚在他的业务场景下应该选用哪种数据库系统。 那么,我们先对这些数据库按照接口(SQL、NoSQL)和面向的业务场景(OLTP、OLAP)这两位维度进行一个简单非严谨的分类。 下图中,左上角是面向 OLTP、支持 SQL 的这样一类系统,例如 MySQL,一般支持事务不同的隔离级别, QPS 要求比较高,延时比较低,主要用于交易信息和关键数据的存储,比如订单、VIP 信息等。 左下角是 NoSQL 数据库,是一类针对特殊场景做优化的系统,schema 一般比较简单,吞吐量较高、延迟较低,一般用作缓存或者 KV 数据库。 整个右侧都是 OLAP 的大数据分析系统,包括 Clickhouse、Impala等,一般支持SQL、不支持事务,扩展性比较好,可以通过加机器增加数据的存储量,响应延迟较长。 还有一类数据库是比较中立的,在数据量比较小的时候性能比较好,在数据量较大或复杂查询的时候性能也不差,一般通过不同的存储引擎和查询引擎来满足不同的业务需求,我们把它叫做 HTAP,TiDB 就是这样一种数据库。 二、iQIYI对数据库的优化与完善 前面我们提到了很多种的数据库,那么接下来就和大家介绍一下在爱奇艺我们是怎么使用这些数据库的。 1、MySQL在爱奇艺的使用 ① MySQL 首先是 MySQL。MySQL 基本使用方式是 master-slave + 半同步,支持每周全备+每日增量备份。我们做了一些基本功能的增强,首先是增强了数据恢复工具 Xtrabackup 的性能。 之前遇到一个情况,我们有一个全量库是 300G 数据,增量库每天 70G 数据,总数据量 700G 左右。我们当时只需要恢复一个表的数据,但该工具不支持单表恢复,且整库恢复需要 5 个小时。 针对这个情况我们具体排查了原因,发现在数据恢复的过程中需要进行多次写盘的 IO 操作并且有很多串行操作,所以我们做了一些优化。例如删减过程中的一些写盘操作,减少落盘并将数据处理并行化,优化后整库恢复耗时减少到 100 分钟,而且可以直接恢复单表数据。 然后是适配 DDL 和 DML 工具到内部系统,gh-ostt 和 oak-online-alter-table 在数据量大的时候会造成 master-slave 延时,所以我们在使用工具的时候也增加了延时上的考虑,实时探测Master-Slave 库之间延时的情况,如果延时较大会暂停工具的使用,恢复到正常水平再继续。 ② MySQL高可用 第二是 MySQL 高可用。Master-slave 加上半同步这种高可用方式不太完善,所以我们参照了 MHA 并进行了改动,采用 master + agent 的方式。Agent 在每一个物理机上部署,可以监控这个物理机上的所有实例的状态,周期性地向 master 发送心跳,Master 会实时监测各个Agent的状态。 如果 MySQL故障,会启动 Binlog 补偿机制,并切换访问域名完成 failover。考虑到数据库跨机房跨地区部署的情况,MHA 的 master 我们也做了高可用设计,众多 master 会通过 raft 组成一个 raft group,类似 TiDB 的 PD 模块。目前 MySQL failover 策略支持三种方式:同机房、同地域跨机房以及跨地域。 ③ MySQL拓展能力 第三是提高MySQL扩展能力,以提供更大容量的数据存储。扩展方式有 SDK,例如开源的 ShardingSphere,在爱奇艺的使用也比较广泛。另外就是 Proxy,开源的就更多了。但是 SDK 和 Proxy 使用的问题是支持的 SQL 语句简单,扩容难度大,依赖较多且运维复杂,所以部分业务已经迁移至 TiDB。 ④ 审计 第四是审计。我们在 MySQL 上做了一个插件获取全量 SQL 操作,后端打到 Kafka,下游再接入包括 Clickhouse 等目标端进行 SQL 统计分析。除此之外还有安全策略,包括主动探索是否有 SQL 注入及是否存在拖库情况等,并触发对应的告警。 MySQL 审计插件最大的问题是如何降低对 MySQL 性能的影响,对此我们进行了一些测试,发现使用 General Log 对性能损耗较大,有 10%~20% 的降低。 于是我们通过接口来获取 MySQL 插件里的监控项,再把监控项放到 buffer 里边,用两级的 RingBuffer 来保证数据的写入不会有锁资源竞争。在这个插件里再启动一个线程,从 RingBuffer 里读取数据并把数据打包写到 FIFO 管道里。 我们在每台 MySQL 的物理机里再启动一个 Agent,从管道里阻塞地读取数据发至 Kafka。优化后我们再次进行压测,在每台机器上有 15 万的更新、删除或插入操作下不会丢失数据,性能损耗一般情况下小于 2%。 目前已经在公司内部的集群上线了一年时间,运行比较稳定,上线和下线对业务没有影响。 ⑤ 分级存储 第五是分级存储。MySQL 里会存一些过程性的数据,即只需要读写最近一段时间存入的数据,过段时间这些数据就不需要了,需要进行定时清理。 分级存储就是在 MySQL 之上又用了其他存储方式,例如 TiDB 或其他 TokuDB,两者之间可以进行数据自动搬迁和自动归档,同时前端通过 SDK + Proxy 来做统一的访问入口。这样一来,业务的开发同学只需要将数据存入 MySQL 里,读取时可能从后端接入的任意数据库读出。这种方式目前只是过渡使用,之后会根据 TiDB 的特性进行逐步迁移。 Redis在爱奇艺的使用 接下来是 Redis。Redis 也是使用 master - slave 这种方式,由于网络的复杂性我们对 Sentinel 的部署进行了一些特殊配置,在多机房的情况下每个机房配置一定数量 Sentinel 来避免脑裂。 备份恢复方面介绍一个我们的特殊场景,虽然 Redis 是一个缓存,但我们发现不少的业务同学会把它当做一个 KVDB 来使用,在某些情况下会造成数据的丢失。 所以我们做了一个 Redis 实时备份功能,启动一个进程伪装成 Redis 的 Slave 实时获取数据,再放到后端的 KV 存储里,例如 ScyllaDB,如果要恢复就可以从 ScyllaDB 里把数据拉出来。 我们在用 Redis 时最大的痛点就是它对网络的延迟或抖动非常敏感。如有抖动造成 Redis Master 超时,会由 Sentinel 重新选出一个新的节点成为 Master,再把该节点上的数据同步到所有 Slave 上,此过程中数据会放在 Master 节点的 Buffer 里,如果写入的 QPS 很高会造成 Buffer 满溢。如果 Buffer 满后 RDB 文件还没有拷贝过去,重建过程就会失败。 基于这种情况,我们对 Redis 告警做了自动化优化,如有大量 master - slave 重建失败,我们会动态调整一些参数,例如把 Buffer 临时调大等, 此外我们还做了 Redis 集群的自动扩缩容功能。 我们在做 Redis 开发时如果是 Java 语言都会用到 Jedis。用 Jedis 访问客户端分片的 Redis 集群,如果某个分片发生了故障或者 failover,Jedis 就会对所有后端的分片重建连接。如果某一分片发生问题,整个 Redis 的访问性能和 QPS 会大幅降低。针对这个情况我们优化了 Jedis,如果某个分片发生故障,就只针对这个分片进行重建。 在业务访问 Redis 时我们会对 Master 绑定一个读写域名,多个从库绑定读域名。但如果我们进行 Master failover,会将读写域名从某旧 Master 解绑,再绑定到新 Master 节点上。 DNS 本身有一个超时时间,所以数据库做完 failover 后业务程序里没有立刻获取到新的 Master 节点的 IP的话,有可能还会连到原来的机器上,造成访问失败。 我们的解决方法是把 DNS 的 TTL 缩短,但对 DNS 服务又会造成很大的压力,所以我们在 SDK 上提供 Redis 的名字服务 RNS,RNS 从 Sentinel 里获取集群的拓扑和拓扑的变化情况,如果集群 failover,Sentinel 会接到通知,客户端就可以通过 RNS 来获取新的 Master 节点的 IP 地址。我们去掉域名,通过 IP 地址来访问整个集群,屏蔽了 DNS 的超时,缩短了故障的恢复时间。 SDK 上还做了一些功能,例如 Load Balance 以及故障检测,比如某个节点延时较高的话会被临时熔断等。 客户端分片的方式会造成 Redis 的扩容非常痛苦,如果客户端已经进行了一定量的分片,之后再增加就会非常艰难。 Redis 在 3.0 版本后会提供 Redis Cluster,因为功能受限在爱奇艺应用的不是很多,例如不支持显示跨 DC 部署和访问,读写只在主库上等。 我们某些业务场景下会使用 Redis 集群,例如数据库访问只发生在本 DC,我们会在 DC 内部进行 Cluster 部署。 但有些业务在使用的过程中还是想做 failover,如果集群故障可以切换到其他集群。根据这种情况我们做了一个 Proxy,读写都通过它来进行。写入数据时 Proxy 会做一个旁路,把新增的数据写在 Kafka 里,后台启用同步程序再把 Kafka 里的数据同步到其他集群,但存在一些限制,比如我们没有做冲突检测,所以集群间数据需要业务的同学做单元化。线上环境的Redis Cluster 集群间场景跨 DC 同步 需要 50 毫秒左右的时间。 2、Couchbase在爱奇艺的使用 Redis 虽然提供 Cluster 这种部署方式,但存在一些问题。所以数据量较大的时候(经验是 160G),就不推荐 Redis 了,而是采用另一种存储方式 Couchbase。 Couchbase 在国内互联网公司用的比较少,一开始我们是把他当做一个 Memcached 来使用的,即纯粹的缓存系统。 但其实它性能还是比较强大的,是一个分布式高性能的 KV 系统,支持多种存储引擎 (bucket)。第一种是 Memcached bucket,使用方式和 Memcached 一样为 KV 存储,不支持数据持久化也没有数据副本,如果节点故障会丢失数据; 第二种是 Couchbase bucket,支持数据持久化,使用 Json 写入,有副本,我们一般会在线上配置两个副本,如果新加节点会对数据进行 rebalance,爱奇艺使用的一般是 Couchbase bucket 这种配置。 Couchbase 数据的分布如下图,数据写入时在客户端上会先进行一次哈希运算,运算完后会定位 Key 在哪一个 vBucket (相当于数据库里的某个分片)。之后客户端会根据 Cluster Map 发送信息至对应的服务端,客户端的 Cluster Map 保存的是 vBucket 和服务器的映射关系,在服务端数据迁移的过程中客户端的 Cluster Map 映射关系会动态更新,因此客户端对于服务端的 failover 操作不需要做特殊处理,但可能在 rebalance 过程中会有短暂的超时,导致的告警对业务影响不大。 Couchbase 在爱奇艺应用比较早,2012 年还没有 Redis Cluster 的时候就开始使用了。集群管理使用 erlang 语言开发,最大功能是进行集群间的复制,提供多种复制方式:单向、双向、星型、环式、链式等。 爱奇艺从最初的 1.8 版本使用到如今的 5.0 版本,正在调研的 6.0,中间也遇到了很多坑,例如 NTP 时间配置出错会导致崩溃,如果每个集群对外 XDCR 并发过高导致不稳定,同步方向变更会导致数据丢失等等,我们通过运维和一些外部工具来进行规避。 Couchbase 的集群是独立集群,集群间的数据同步通过 XDCR,我们一般配置为双向同步。对于业务来说,如果 Cluster 1 写入, Cluster 2 不写入,正常情况下客户端会写 Cluster 1。如果 Cluster 1 有故障,我们提供了一个 Java SDK,可以在配置中心把写入更改到 Cluster 2,把原来到 Cluster 1 的连接逐步断掉再与Cluster 2 新建连接。这种集群 failover 的过程对于客户端来说是相对透明和无感的。 3、爱奇艺自研数据库HiKV的使用 Couchbase 虽然性能非常高,并且数据的存储可以超过内存。但是,如果数据量超过内存 75% 这个阈值,性能就会下降地特别快。在爱奇艺,我们会把数据量控制在可用内存的范围之内,当做内存数据库使用。但是它的成本非常高,所以我们后面又开发了一个新的数据库—— HiKV。 开发 HiKV 的目的是为了把一些对性能要求没那么高的 Couchbase 应用迁移到 HiKV 上。HiKV 基于开源系统 ScyllaDB,主要使用了其分布式数据库的管理功能,增加了单机存储引擎 HiKV。 ScyllaDB 比较吸引人的是它宣称性能高于 Cassandra 十倍,又完全兼容 Cassandra 接口,设计基本一致,可以视为 C++ 版 Cassandra 系统。 ScyllaDB 性能的提升主要是使用了一些新的技术框架,例如 C++ 异步框架 seastar,主要原理是在j每台物理机的核上会 attach 一个应用线程,每个核上有自己独立的内存、网络、IO 资源,核与核之间没有数据共享但可以通信,其最大的好处是内存访问无锁,没有冲突过程。 当一个数据读或写到达 ScyllaDB 的 server 时,会按照哈希算法来判断请求的 Key 是否是该线程需要处理的,如果是则本线程处理,否则会转发到对应线程上去。 除此之外,它还支持多副本、多数据中心、多写多活,功能比较强大。 在爱奇艺,我们基于 SSD 做了一个 KV 存储引擎。Key 放在内存里,Value 放在盘上的文件里,我们在读和写文件时,只需要在内存索引里定位,再进行一次盘的 IO 开销就可以把数据读出来,相比 ScyllaDB 原本基于 LSM Tree 的存储引擎方式对 IO 的开销较少。 索引数据全部放在内存中,如果索引长度较长会限制单机可存储的数据量,于是我们通过开发定长的内存分布器,对于比较长的 Key 做摘要缩短长度至 20 字节,采用红黑树索引,限制每条记录在内存里的索引长度至为 64 字节。内存数据要定期做 checkpoint,客户端要做限流、熔断等。 HiKV 目前在爱奇艺应用范围比较大,截至目前已经替换了 30% 的 Couchbase,有效地降低了存储成本。 4、爱奇艺的数据库运维管理 爱奇艺数据库种类较多,如何高效地运维和管理这些数据库也是经历了不同的阶段。 最初我们通过 DBA 写脚本的方式管理,如果脚本出问题就找 DBA,导致了 DBA 特别忙碌。 第二个阶段我们考虑让大家自己去查问题的答案,于是在内部构建了一个私有云,通过 Web 的方式展示数据库运行状态,让业务的同学可以自己去申请集群,一些简单的操作也可以通过自服务平台实现,解放了 DBA。一些需要人工处理的大型运维操作经常会造成一些人为故障,敲错参数造成数据丢失等。 于是在第三个阶段我们把运维操作 Web 化,通过网页点击可以进行 90% 的操作。 第四个阶段让经验丰富的 DBA 把自身经验变成一些工具,比如有业务同学说 MySQL master-slave 延时了,DBA 会通过一系列操作排查问题。现在我们把这些操作串起来形成一套工具,出问题时业务的同学可以自己通过网页上的一键诊断工具去排查,自助进行处理。 除此之外我们还会定期做预警检查,对业务集群里潜在的问题进行预警报告;开发智能客服,回答问题;通过监控的数据对实例打标签,进行削峰填谷地智能调度,提高资源利用率。 三、不同场景下数据库选型建议 1、实用数据库选型树 最后来说一些具体数据库选型建议。这是 DBA 和业务一起,通过经验得出来的一些结论。 对于关系型数据库的选型来说,可以从数据量和扩展性两个维度考虑,再根据数据库有没有冷备、要不要使用 Toku 存储引擎,要不要使用 Proxy 等等进行抉择。 NoSQL 也是什么情况下使用 master-slave,什么情况下使用客户端分片、集群、Couchbase、HiKV 等,我们内部自服务平台上都有这个选型树信息。 2、一些思考 ① 需求 我们在选型时先思考需求,判断需求是否真实。 你可以从数据量、QPS、延时等方面考虑需求,但这些都是真实需求吗?是否可以通过其他方式把这个需求消耗掉,例如在数据量大的情况下可以先做数据编码或者压缩,数据量可能就降下来了。 不要把所有需求都推到数据库层面,它其实是一个兜底的系统。 ② 选择 第二个思考的点是对于某个数据库系统或是某个技术选型我们应该考虑什么?是因为热门吗?还是因为技术上比较先进?但是不是能真正地解决你的问题?如果你数据量不是很大的话就不需要选择可以存储大数据量的系统。 ③ 放弃 第三是放弃,当你放弃一个系统时真的是因为不好用吗?还是没有用好?放弃一个东西很难,但在放弃时最好有一个充分的理由,包括实测的结果。 ④ 自研 第四是自研,在需要自己开发数据库时可以参考和使用一些成熟的产品,但不要盲目自研。 ⑤ 开源 最后是开源,要有拥抱开源的态度。

茶什i 2019-12-27 14:17:56 0 浏览量 回答数 0

问题

归档存储的命令行工具

云栖大讲堂 2019-12-01 21:07:22 1445 浏览量 回答数 0

回答

OceanBase 1.4分区表用法 业务数据做水平拆分,有如下几种方案 分库分表:通过分布式数据库中间件做分库分表拆分和路由等。如DRDS,MyCat,TDSQL等。分区:Oracle 12c的sharding, OceanBase 1.0及以后的版本存储级别切片,对应用透明。如Google的Spanner,PingCap的TiDB 这里只演示OceanBase的分区用法。 OceanBase的分区策略支持hash/list/range,以及支持二级分区(hash+hash,hash+range,key+key,range+range等)。详细用法请参见 OceanBase官网 文档里 的 OB分区表用法 。 无论是分库分表,还是分区的方案,都会面临一个问题,就是当一个Query 要取不同机器(节点)上的数据的时候,如果保证取出来的数据是一致的(指来自于同一个时间点或版本)。 分库分表方案解决不了这个问题, OB1.4也不能解决这个问题。OB2.0 新增全局时间服务,能提供全局一致性快照读功能,所以解决了这个问题。 这里演示一下 OB1.4 里规避这个跨节点读的方案(弱一致读) SQL: SELECT @@version;drop table if exists t_parttable;create table t_parttable(    id bigint not null primary key,     name varchar(50) not NULL,      KEY name_ind(NAME) LOCAL ) DEFAULT CHARSET=utf8mb4 partition by hash(mod(id,1000)) partitions 8;insert into t_parttable(id, name) values(1,'a'),(2,'A'),(3,'b'),(4,'B'),(5,'c'),(6,'C'),(7,'d'),(8,'D');set session ob_query_timeout=1000000; select * from t_parttable where name='a';explain select * from t_parttable where name='a';select /*+read_consistency(weak)*/ * from t_parttable where name='a';select * from t_parttable partition(p1);select * from t_parttable partition(p2); 该问题,在OceanBase 2.0后版本已经解了 ------------------------- OB租户负载均衡历史查看 接楼上建的表,这里演示一下如何在租户里查看负载均衡的历史。 OB作为一个分布式数据库,至少包含3个节点。其负载均衡的原理跟传统负载均衡的原理大不一样。 传统负载均衡设备(F5)或软件(LVS,SLB等)都是通过在某一协议层作为流量入口然后分配流量给后端不同的节点,从而去改变后端节点的压力。 OceanBase的负载均衡是自己通过调整每个节点(ObServer)里的数据(Partition)分布,从而间接改变打到各个节点(ObServer)上的流量,从而改变各个节点的压力。 有关OceanBase负载均衡的原理详细,请查看 《 OceanBase负载均衡的魅力 》 示例演示:租户视角查看负载均衡历史。 这里是新建了一个分区表(8个分区),在插入数据后,触发了负载均衡机制,把8个分区分散到多个节点上。 SQL: # 查看分区表的数据SHOW CREATE TABLE db_bin.t_parttable;SELECT /*+read_consistency(weak)*/ * FROM db_bin.t_parttable ORDER BY id ;# 查看租户的资源单元(Unit)分布SELECT tenant_name, unit_id,zone,svr_ip,max_cpu,round(max_memory/1024/1024/1024) max_mem_gb FROM gv$unit;# 查看租户的负载均衡历史SELECT str_to_date(h.gmt_create,'%Y-%m-%d %h:%i:%s') gmt_create, h.zone, t.database_name, t.tablegroup_name, t.table_name, t.part_num,h.partition_id,h.data_size, h.data_src_ip,  h.dest_unit_id, h.dest_ip, h.result_code, h.COMMENT , h.rs_svr_ip FROM gv$unit_load_balance_event_history h JOIN gv$TABLE t ON (h.table_id=t.table_id)WHERE t.table_name NOT LIKE '%recycle%' AND t.database_name='db_bin'ORDER BY gmt_create DESC LIMIT 100; ------------------------- OB sys租户查看集群使用信息     OceanBase作为一款通用的分布式关系型数据库,跟其他同行产品相比,有一个独特的地方,就是支持多租户,即支持集群资源(CPU/MEM/DISK等)的做租户管理。 OceanBase集群,至少是三节点。OceanBase把三个节点的机器资源能力聚合成一个大的资源池,然后做二次资源管理和分配。为每个租户分配一个特定规格的小的资源池,并且随时可以动态调整。 租户对于业务开发来说就是一个体的实例,只是开发不需要关注这个实例在哪个节点上。租户的使用体验类似于 MySQL (默认,以后还支持Oracle兼容模式的租户)。     假设OceanBase集群已经搭建好了,在创建租户之前,先清点一下现有集群的资源使用状况。下面是示例     SQL: # 查看集群节点资源使用情况SELECT svr_ip, s.zone, s.cpu_total, s.cpu_assigned, s.cpu_assigned_percent, round(s.mem_total/1024/1024/1024) mem_total_gb, round(s.mem_assigned/1024/1024/1024) mem_ass_gb, s.mem_assigned_percentFROM __all_virtual_server_stat sORDER BY zone,svr_ip;# 查看资源单元规格定义SELECT NAME, max_cpu, min_cpu, round(max_memory/1024/1024/1024) max_mem_gb , round(min_memory/1024/1024/1024) min_mem_gb FROM __all_unit_config ORDER BY unit_config_id LIMIT 10;# 查看已有租户及其资源池信息SELECT t.tenant_name, p.name pool_name, c.name config_name, p.unit_count, p.zone_list, t.`locality`FROM __all_resource_pool p JOIN __all_unit_config c ON (p.unit_config_id=c.unit_config_Id)  LEFT JOIN __all_tenant t ON (p.tenant_id=t.tenant_id)WHERE p.NAME IN ('yq_Pool','app_pool')  ORDER BY p.resource_pool_id; ------------------------- OceanBase租户创建(很简单)     接楼上。     清点了OceanBase集群资源使用情况后,选定一个规格,就可以快速创建出一个租户(demo_t) 示例:OB1.4下创建租户(2步) SQL: # 清理已经创建的同名租户DROP tenant IF EXISTS demo_t;DROP resource pool demo_pool;# 创建新的资源池(Resource Pool)CREATE resource pool demo_pool unit='S0_unit_config', unit_num=2;# 创建租户 CREATE tenant IF NOT EXISTS demo_t resource_pool_list=('demo_pool') SET VARIABLES ob_tcp_invited_nodes='%';# 查看已有租户及其资源池信息SELECT now() cur_time, str_to_date(t.gmt_create,'%Y-%m-%d %h:%i:%s') gmt_create,  t.tenant_name, p.name pool_name, c.name config_name, p.unit_count, p.zone_list, t.`locality`FROM __all_resource_pool p JOIN __all_unit_config c ON (p.unit_config_id=c.unit_config_Id)  LEFT JOIN __all_tenant t ON (p.tenant_id=t.tenant_id)WHERE p.NAME IN ('demo_pool')  ORDER BY p.resource_pool_id;     退出当前sys租户,重新登录新建租户 ,用户名是:root@demo_t#集群名,密码默认是空。 登录后新建Database,并创建账户访问DB。 ------------------------- OceanBase里索引创建特征 OceanBase里创建索引稍微有点特殊,开发和运维需要留意一下。 如果是在create table里带上了索引(包括唯一索引,也就是唯一性约束),是立即生效的。OB 1.x 版本里在表存在的情况下新建的索引(包括唯一索引),命令立即返回,但是索引不是立即生效。需要等到OB集群发起大合并之后才会生效。其中唯一索引需要等待两次大合并。所以运维建索引后需要安排1-2次大合并操作。OB 2.x 版本里在表存在的情况下新建的索引(包括唯一索引),命令立即返回,索引也不是立即生效,但是索引开始后台异步创建,创建时间取决于数据量。 示例如下: 1. OB 1.x 版本的索引 2. OB 2.x版本的索引 ------------------------- 回 9楼(xcb296) 的帖子 有什么想了解的 可以先说一下。 这个主要是根据用户问题来做的。

mq4096 2019-12-02 00:56:01 0 浏览量 回答数 0

回答

OceanBase 1.4分区表用法 业务数据做水平拆分,有如下几种方案 分库分表:通过分布式数据库中间件做分库分表拆分和路由等。如DRDS,MyCat,TDSQL等。分区:Oracle 12c的sharding, OceanBase 1.0及以后的版本存储级别切片,对应用透明。如Google的Spanner,PingCap的TiDB 这里只演示OceanBase的分区用法。 OceanBase的分区策略支持hash/list/range,以及支持二级分区(hash+hash,hash+range,key+key,range+range等)。详细用法请参见 OceanBase官网 文档里 的 OB分区表用法 。 无论是分库分表,还是分区的方案,都会面临一个问题,就是当一个Query 要取不同机器(节点)上的数据的时候,如果保证取出来的数据是一致的(指来自于同一个时间点或版本)。 分库分表方案解决不了这个问题, OB1.4也不能解决这个问题。OB2.0 新增全局时间服务,能提供全局一致性快照读功能,所以解决了这个问题。 这里演示一下 OB1.4 里规避这个跨节点读的方案(弱一致读) SQL: SELECT @@version;drop table if exists t_parttable;create table t_parttable(    id bigint not null primary key,     name varchar(50) not NULL,      KEY name_ind(NAME) LOCAL ) DEFAULT CHARSET=utf8mb4 partition by hash(mod(id,1000)) partitions 8;insert into t_parttable(id, name) values(1,'a'),(2,'A'),(3,'b'),(4,'B'),(5,'c'),(6,'C'),(7,'d'),(8,'D');set session ob_query_timeout=1000000; select * from t_parttable where name='a';explain select * from t_parttable where name='a';select /*+read_consistency(weak)*/ * from t_parttable where name='a';select * from t_parttable partition(p1);select * from t_parttable partition(p2); 该问题,在OceanBase 2.0后版本已经解了 ------------------------- OB租户负载均衡历史查看 接楼上建的表,这里演示一下如何在租户里查看负载均衡的历史。 OB作为一个分布式数据库,至少包含3个节点。其负载均衡的原理跟传统负载均衡的原理大不一样。 传统负载均衡设备(F5)或软件(LVS,SLB等)都是通过在某一协议层作为流量入口然后分配流量给后端不同的节点,从而去改变后端节点的压力。 OceanBase的负载均衡是自己通过调整每个节点(ObServer)里的数据(Partition)分布,从而间接改变打到各个节点(ObServer)上的流量,从而改变各个节点的压力。 有关OceanBase负载均衡的原理详细,请查看 《 OceanBase负载均衡的魅力 》 示例演示:租户视角查看负载均衡历史。 这里是新建了一个分区表(8个分区),在插入数据后,触发了负载均衡机制,把8个分区分散到多个节点上。 SQL: # 查看分区表的数据SHOW CREATE TABLE db_bin.t_parttable;SELECT /*+read_consistency(weak)*/ * FROM db_bin.t_parttable ORDER BY id ;# 查看租户的资源单元(Unit)分布SELECT tenant_name, unit_id,zone,svr_ip,max_cpu,round(max_memory/1024/1024/1024) max_mem_gb FROM gv$unit;# 查看租户的负载均衡历史SELECT str_to_date(h.gmt_create,'%Y-%m-%d %h:%i:%s') gmt_create, h.zone, t.database_name, t.tablegroup_name, t.table_name, t.part_num,h.partition_id,h.data_size, h.data_src_ip,  h.dest_unit_id, h.dest_ip, h.result_code, h.COMMENT , h.rs_svr_ip FROM gv$unit_load_balance_event_history h JOIN gv$TABLE t ON (h.table_id=t.table_id)WHERE t.table_name NOT LIKE '%recycle%' AND t.database_name='db_bin'ORDER BY gmt_create DESC LIMIT 100; ------------------------- OB sys租户查看集群使用信息     OceanBase作为一款通用的分布式关系型数据库,跟其他同行产品相比,有一个独特的地方,就是支持多租户,即支持集群资源(CPU/MEM/DISK等)的做租户管理。 OceanBase集群,至少是三节点。OceanBase把三个节点的机器资源能力聚合成一个大的资源池,然后做二次资源管理和分配。为每个租户分配一个特定规格的小的资源池,并且随时可以动态调整。 租户对于业务开发来说就是一个体的实例,只是开发不需要关注这个实例在哪个节点上。租户的使用体验类似于 MySQL (默认,以后还支持Oracle兼容模式的租户)。     假设OceanBase集群已经搭建好了,在创建租户之前,先清点一下现有集群的资源使用状况。下面是示例     SQL: # 查看集群节点资源使用情况SELECT svr_ip, s.zone, s.cpu_total, s.cpu_assigned, s.cpu_assigned_percent, round(s.mem_total/1024/1024/1024) mem_total_gb, round(s.mem_assigned/1024/1024/1024) mem_ass_gb, s.mem_assigned_percentFROM __all_virtual_server_stat sORDER BY zone,svr_ip;# 查看资源单元规格定义SELECT NAME, max_cpu, min_cpu, round(max_memory/1024/1024/1024) max_mem_gb , round(min_memory/1024/1024/1024) min_mem_gb FROM __all_unit_config ORDER BY unit_config_id LIMIT 10;# 查看已有租户及其资源池信息SELECT t.tenant_name, p.name pool_name, c.name config_name, p.unit_count, p.zone_list, t.`locality`FROM __all_resource_pool p JOIN __all_unit_config c ON (p.unit_config_id=c.unit_config_Id)  LEFT JOIN __all_tenant t ON (p.tenant_id=t.tenant_id)WHERE p.NAME IN ('yq_Pool','app_pool')  ORDER BY p.resource_pool_id; ------------------------- OceanBase租户创建(很简单)     接楼上。     清点了OceanBase集群资源使用情况后,选定一个规格,就可以快速创建出一个租户(demo_t) 示例:OB1.4下创建租户(2步) SQL: # 清理已经创建的同名租户DROP tenant IF EXISTS demo_t;DROP resource pool demo_pool;# 创建新的资源池(Resource Pool)CREATE resource pool demo_pool unit='S0_unit_config', unit_num=2;# 创建租户 CREATE tenant IF NOT EXISTS demo_t resource_pool_list=('demo_pool') SET VARIABLES ob_tcp_invited_nodes='%';# 查看已有租户及其资源池信息SELECT now() cur_time, str_to_date(t.gmt_create,'%Y-%m-%d %h:%i:%s') gmt_create,  t.tenant_name, p.name pool_name, c.name config_name, p.unit_count, p.zone_list, t.`locality`FROM __all_resource_pool p JOIN __all_unit_config c ON (p.unit_config_id=c.unit_config_Id)  LEFT JOIN __all_tenant t ON (p.tenant_id=t.tenant_id)WHERE p.NAME IN ('demo_pool')  ORDER BY p.resource_pool_id;     退出当前sys租户,重新登录新建租户 ,用户名是:root@demo_t#集群名,密码默认是空。 登录后新建Database,并创建账户访问DB。 ------------------------- OceanBase里索引创建特征 OceanBase里创建索引稍微有点特殊,开发和运维需要留意一下。 如果是在create table里带上了索引(包括唯一索引,也就是唯一性约束),是立即生效的。OB 1.x 版本里在表存在的情况下新建的索引(包括唯一索引),命令立即返回,但是索引不是立即生效。需要等到OB集群发起大合并之后才会生效。其中唯一索引需要等待两次大合并。所以运维建索引后需要安排1-2次大合并操作。OB 2.x 版本里在表存在的情况下新建的索引(包括唯一索引),命令立即返回,索引也不是立即生效,但是索引开始后台异步创建,创建时间取决于数据量。 示例如下: 1. OB 1.x 版本的索引 2. OB 2.x版本的索引 ------------------------- 回 9楼(xcb296) 的帖子 有什么想了解的 可以先说一下。 这个主要是根据用户问题来做的。

mq4096 2019-12-02 00:56:00 0 浏览量 回答数 0

问题

日志的发布历史有哪些?

轩墨 2019-12-01 21:50:57 1618 浏览量 回答数 0

回答

BRD文档(商业需求文档) 定义:BRD 是英文”Business Requirement Document“的缩写,根据英文直译过来就是”商业需求文档“的意思,指的就是基于商业目标或价值所描述的产品需求内容文档(报告),其核心的用途就是用于产品在投入研发之前,由企业高层作为决策评估的重要依据。一般来说全新的产品、未来发展有潜力的产品提供BRD! 真相君:市场前景无限大;用户需求未满足;同类竞品没做到;好机会啊,老板 MRD(市场需求文档) 定义:MRD 是英文”Market Requirements Document“的缩写,根据英文直译过来就是”市场需求文档“的意思,主要是描述什么样的功能和特点的产品(包含产品版本)可以在市场上取得成功。一般新功能的实现,上线新的产品提供MRD! 真相君:老板,市场真的很大,产品路线图我都规划好了,我们按照产品路线发展,肯定能成。 PRD(产品需求文档) 定义:PRD 是英文”Product Requirement Document“的缩写,根据英文直译过来就是”产品需求文档“的意思, PRD文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档,其作用就是“对MRD中的内容进行指标化和技术化”,这个文档的质量好坏直接影响产品能否顺利的实施完成。一般产品的功能改善、产品的细节说明提供PRD文档! 真相君:确保文档可读性;名词不要有歧义;从概念到图纸化;设计开发全靠它。 用户场景 用户场景是什么?是人物、时间、地点、欲望、手段五要素所组成的特定关系。在xx时间(when),xx地点(where),特定类型的用户(who)萌发了某种欲望(desire),会想通过某种手段(method)来满足欲望。 真相君:产品原型很简单;洞察用户才最难;带入场景去分析;用户心理全了然 MVP 简单的说法就是用最小的成本开发出可表达项目创意、可用且能用于表达核心理念的原型产品,功能极简而且能用于快速验证想法的最小化产品。 真相君:糟了,老板明天要验收;别慌,他不懂技术;咱先拿个半成品忽悠他。 灰度发布 定义:灰度发布(又名金丝雀发布)是指让一部分用户继续用产品特性A,一部分用户开始用产品特性B,如果用户对B没有什么反对意见,那么逐步扩大范围,把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定,在初始灰度的时候就可以发现、调整问题,以保证其影响度。经常与A/B测试一起使用,用于测试选择多种方案。 真相君:不知新版发布会不会挨骂?;找群白鼠测一下;如果反馈还不错;那就逐步推出它。 用户研究 定义:用户研究是指通过对用户的任务操作特性、知觉特征、认知心理特征的研究,使用户的实际需求成为产品设计的导向,使您的产品更符合用户的习惯、经验和期待。 在互联网领域内,用户研究主要应用于两个方面: 对于新产品来说,用户研究一般用来明确用户需求点,帮助设计师选定产品的设计方向; 对于已经发布的产品来说,用户研究一般用于发现产品问题,帮助设计师优化产品体验。 真相君:用户研究不简单;定性定量都精通;还得数据来建模;产品决策要靠它。 用户画像 定义:用户画像就是你的粉丝群体属性的数据,比如性别、学历、职业、收入水平、手机型号、兴趣爱好等等。是根据用户在互联网留下的种种数据,主动或被动地收集,最后加工成一系列的标签。 真相君:平时上网别乱点;行为历史有记录;根据数据贴标签;再想撕掉难上天 A / B测试 定义:AB测试是为Web或App界面或流程制作两个(A/B)或多个(A/B/n)版本,在同一时间维度,分别让组成成分相同(相似)的访客群组(目标人群)随机的访问这些版本,收集各群组的用户体验数据和业务数据,最后分析、评估出最好版本,正式采用。 真相君:不知道功能上线后效果好不好,先找一部分用户测试看看,好了再全面推广。 UCD 定义:(User Centered Design)是一种设计思维、模式,指以用户为中心的设计。是在设计过程中以用户体验为设计决策的中心,强调用户优先的设计模式。 真相君:先不要考虑盈利,先让用户用的爽再说。 智能推送 定义:将用户“个性”和“商品、服务、内容”属性进行精准的匹配,达到用户所见即所需所想的目的,缩短了信息触达用户的路径,减少用户流失,促进用户快速转化。 真相君:你想看什么,就给你推送什么。 AIOT 定义:智联网(AIOT,是AI + IOT物联网的结合) 2018年开始崛起,核心是能够运用大量传感设备,综合语音、视觉、动作、温度等数据,实现IOT设备的全自然化的人机交互。 真相君:物联网喊了好多年;体验提升太有限;如今终于有突破;人机交互成关键。 AM敏捷开发 定义:以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。 真相君:一点点来,不要想一口吃个胖子。 PLC 定义:产品生命周期(Product Life Cycle),简称PLC,是产品的市场寿命,即一种新产品从开始进入市场到被市场淘汰的整个过程。这个过程其实就是经历了一个从“启动、成长、成熟一直到衰退”的阶段。 真相君:一个产品四阶段;阶段策略各不同;快速验证和开发;尽力延长成熟期。 可用性测试 定义:让一群具有代表性的用户对产品进行典型操作,同时观察员和开发人员在一旁观察,聆听,做记录。 真相君:观察用户使用产品。 商业闭环 定义:商业闭环是围绕着顾客一系列关联性消费需求,逐一提供相应的产品予以满足的商业模式。主要在商业体系中营造循环圈,各个环节都可以相互依靠,既可以作为个体支撑点也可以协同合作。 真相君:产品分步走;逻辑真是乱;怎么讲清楚;就得靠闭环! 互联网上半场/下半场 定义: 互联网上半场即消费互联网时代,注重的是入口和流量,线上打造; 而下半场即产业互联网时代,注重的是服务和价值,线上线下充分融合。 真相君:上半场玩的是流量,现在流量已经被占完,再看产业和互联;线上线下共融合;下半场来临! CRUD 创建(Create)、检索(Retrieve)、更新(Update)、删除(Delete),有时候也简称“增删改查”这是面向对象设计中最常用的4个基本方法。说来这是数据库里的必备的知识,但作为互联网公司的产品经理,这也是经常会提起的功能点。 真相君:就是后台功能操作分为:增删改查和搜索。 用户任务的闭环 定义:指的是一系列帮助用户完成任务的环节,这些环节可以应对任务可能出现的各种情况。 真相君:就是用户做一件事情要能做完。 KPI 定义:KPI绩效考核,又称“关键业绩指标”考核法,是企业绩效考核的方法之一。这种方法的优点是标准比较鲜明,易于做出评估。它的缺点是对简单的工作制定标准难度较大,缺乏一定的定量性。 真相君:就是给你分配的任务。 蓝海与红海 定义:所谓蓝海,指的是未知的市场空间,即尚未有人涉足,或是只有极少人涉足并且还没有做出太大成绩的市场。这样的市场,如果成功进入,则会是一段绝佳的时期,因为这段时间内你处于绝对的垄断地位,直到你的竞争对手赶上来。做好核心业务,做足差异化,能够帮助你将你的蓝海时段尽可能地延长,保证你的利益。 所谓红海,指的是已经发展的比较成熟,竞争非常激烈的市场。通常红海里的新人很难在短时间内做出成就,除非你在某一方面比你的竞争对手优势更大,或者你让投资人和初期用户看到了你巨大的发展潜力,又或者你在另一片红海中有着极佳的口碑,现在跨界进入这个行业。 真相君:蓝海就是竞争没那么激烈,红海就是竞争很激烈,刺刀见红。 进入壁垒 定义:进入壁垒值得是进入某一市场的难度,这一高度取决于自身的技术、成本、对特定资源的占有情况,以及对手的发展程度。 真相君:就是进入的门槛到底。 商业价值 定义:商业价值指的是一款产品如何创造价值。 真相君:就是如何赚钱。 墨菲定律 定义:事情如果有变坏的可能,不管这种可能性有多小,它总会发生。 真相君:越怕出事,越会出事。 放到互联网行业通常就是这样: 凡是输入框,都会遭遇灌水、SPAM、脚本注入 凡是积分,都会被刷 凡是推到网站首页的内容,都会出现色情、政治 凡是用户间沟通的渠道,都会被广告机器人利用 而对于项目管理而言,又可能是这样: 一项工作如果只有一个人负责,这个人肯定会休假或者离职 认为没有技术难点的地方,都会成为技术难点或性能瓶颈 羊群效应 定义:头羊往哪里走,后面的羊就跟着往哪里走。 真相君:说白了,其实就是从众心理。 破窗理论 定义:如果有人打坏了一幢建筑物的窗户玻璃,而这扇窗户又得不到及时的维修,别人就可能受到某些示范性的纵容去打烂更多的窗户。 真相君:环境中的不良现象如果被放任存在,会诱使人们仿效,甚至变本加厉。 二八定律 定义:也叫巴莱多定律,19世纪末20世纪初意大利的经济学家巴莱多认为,在任何一组东西中,最重要的只占其中一小部分,约20%,其余80%尽管是多数,却是次要的。社会约80%的财富集中在20%的人手里,而80%的人只拥有20%的社会财富。80%的回报来源于20%的有效付出。这种统计的不平衡性在社会、经济及生活中无处不在,这就是二八法则。 真相君:一个人的时间和精力都是非常有限的,要想真正做好每一件事情几乎是不可能的,要学会抓住主要矛盾,合理分配我们的时间和精力。要想面面俱到还不如重点突破,把80%的资源花在能出关键效益的20%的方面,这20%的方面又能带动其余80%的发展。 马太效应 定义:指强者愈强,弱者愈弱的现象。《圣经—马太福音》中有一句名言:凡有的,还要加给他,让他有余;没有的,连他所有的,也要夺过来。社会学家从中引申出马太效应这一概念,用以描述社会生活领域中普遍存在的两极分化现象。 真相君:好的愈好,坏的愈坏,多的愈多,少的愈少。

剑曼红尘 2020-04-09 14:21:15 0 浏览量 回答数 0

问题

Web测试方法

技术小菜鸟 2019-12-01 21:41:32 7022 浏览量 回答数 1

回答

X-Engine是阿里云数据库产品事业部自研的联机事务处理OLTP(On-Line Transaction Processing)数据库存储引擎。作为自研数据库POLARDB的存储引擎之一,已经广泛应用在阿里集团内部诸多业务系统中,包括交易历史库、钉钉历史库等核心应用,大幅缩减了业务成本,同时也作为双十一大促的关键数据库技术,挺过了数百倍平时流量的冲击。 为什么设计一个新的存储引擎 X-Engine的诞生是为了应对阿里内部业务的挑战,早在2010年,阿里内部就大规模部署了MySQL数据库,但是业务量的逐年爆炸式增长,数据库面临着极大的挑战: 极高的并发事务处理能力(尤其是双十一的流量突发式暴增)。 超大规模的数据存储。 这两个问题虽然可以通过扩展数据库节点的分布式方案解决,但是堆机器不是一个高效的手段,我们更想用技术的手段将数据库性价比提升到极致,实现以少量资源换取性能大幅提高的目的。 传统数据库架构的性能已经被仔细的研究过,数据库领域的泰斗,图灵奖得主Michael Stonebreaker就此写过一篇论文 《OLTP Through the Looking Glass, and What We Found There》 ,指出传统关系型数据库,仅有不到10%的时间是在做真正有效的数据处理工作,剩下的时间都浪费在其它工作上,例如加锁等待、缓冲管理、日志同步等。 造成这种现象的原因是因为近年来我们所依赖的硬件体系发生了巨大的变化,例如多核(众核)CPU、新的处理器架构(Cache/NUMA)、各种异构计算设备(GPU/FPGA)等,而架构在这些硬件之上的数据库软件却没有太大的改变,例如使用B-Tree索引的固定大小的数据页(Page)、使用ARIES算法的事务处理与数据恢复机制、基于独立锁管理器的并发控制等,这些都是为了慢速磁盘而设计,很难发挥出现有硬件体系应有的性能。 基于以上原因,阿里开发了适合当前硬件体系的存储引擎,即X-Engine。 X-Engine架构 全新架构的X-Engine存储引擎不仅可以无缝对接兼容MySQL(得益于MySQL Pluginable Storage Engine特性),同时X-Engine使用分层存储架构。 因为目标是面向大规模的海量数据存储,提供高并发事务处理能力和降低存储成本,在大部分大数据量场景下,数据被访问的机会是不均等的,访问频繁的热数据实际上占比很少,X-Engine根据数据访问频度的不同将数据划分为多个层次,针对每个层次数据的访问特点,设计对应的存储结构,写入合适的存储设备。 X-Engine使用了LSM-Tree作为分层存储的架构基础,并进行了重新设计: 热数据层和数据更新使用内存存储,通过内存数据库技术(Lock-Free index structure/append only)提高事务处理的性能。 流水线事务处理机制,把事务处理的几个阶段并行起来,极大提升了吞吐。 访问频度低的数据逐渐淘汰或是合并到持久化的存储层次中,并结合多层次的存储设备(NVM/SSD/HDD)进行存储。 对性能影响比较大的Compaction过程做了大量优化: 拆分数据存储粒度,利用数据更新热点较为集中的特征,尽可能的在合并过程中复用数据。 精细化控制LSM的形状,减少I/O和计算代价,有效缓解了合并过程中的空间增大。 同时使用更细粒度的访问控制和缓存机制,优化读的性能。 技术特点 利用FPGA硬件加速Compaction过程,使得系统上限进一步提升。这个技术属首次将硬件加速技术应用到在线事务处理数据库存储引擎中,相关论文 《FPGA-Accelerated Compactions for LSM-based Key Value Store》 已经被2020年的顶级会议FAST'20接收。 通过数据复用技术减少数据合并代价,同时减少缓存淘汰带来的性能抖动。 使用多事务处理队列和流水线处理技术,减少线程上下文切换代价,并计算每个阶段任务量配比,使整个流水线充分流转,极大提升事务处理性能。相对于其他类似架构的存储引擎(例如RocksDB),X-Engine的事务处理性能有10倍以上提升。 X-Engine使用的Copy-on-write技术,避免原地更新数据页,从而对只读数据页面进行编码压缩,相对于传统存储引擎(例如InnoDB),使用X-Engine可以将存储空间降低至10%~50%。 Bloom Filter快速判定数据是否存在,Surf Filter判断范围数据是否存在,Row Cache缓存热点行,加速读取性能。 LSM基本逻辑 LSM的本质是所有写入操作直接以追加的方式写入内存。每次写到一定程度,即冻结为一层(Level),并写入持久化存储。所有写入的行,都以主键(Key)排序好后存放,无论是在内存中,还是持久化存储中。在内存中即为一个排序的内存数据结构(Skiplist、B-Tree、etc),在持久化存储也作为一个只读的全排序持久化存储结构。 普通的存储系统若要支持事务处理,需要加入一个时间维度,为每个事务构造出一个不受并发干扰的独立视域。例如存储引擎会对每个事务定序并赋予一个全局单调递增的事务版本号(SN),每个事务中的记录会存储这个SN以判断独立事务之间的可见性,从而实现事务的隔离机制。 如果LSM存储结构持续写入,不做其他的动作,那么最终会成为如下结构。 这种结构对于写入是非常友好的,只要追加到最新的内存表中即完成,为实现故障恢复,只需记录Redo Log,因为新数据不会覆盖旧版本,追加记录会形成天然的多版本结构。 但是如此累积,冻结的持久化层次越来越多,会对查询会产生不利的影响。例如对同一个key,不同事务提交产生的多版本记录会散落在各个层次中;不同的key也会散落在不同层次中。读操作需要查找各个层并合并才能得到最终结果。 因此LSM引入了Compaction操作解决这个问题,Compaction操作有2种作用: 控制LSM层次形状 一般的LSM形状都是层次越低,数据量越大(倍数关系),目的是为了提升读性能。 通常存储系统的数据访问都有局部性,大量的访问都集中在少部分数据上,这也是缓存系统能有效工作的基本前提。在LSM存储结构中,如果把访问频率高的数据尽可能放在较高的层次上,存放在快速存储设备中(例如NVM、DRAM),而把访问频率低的数据放在较低层次中,存放在廉价慢速存储设备中。这就是X-Engine的冷热分层概念。 合并数据 Compaction操作不断的把相邻层次的数据合并,并写入更低层次。合并的过程实际上是把要合并的相邻两层或多层的数据读出来,按key排序,相同的key如果有多个版本,只保留新的版本(比当前正在执行的活跃事务中最小版本号新),丢掉旧版本数据,然后写入新的层,这个操作非常耗费资源。 合并数据除了考虑冷热分层以外,还需要考虑其他维度,例如数据的更新频率,大量的多版本数据在查询的时候会浪费更多的I/O和CPU,因此需要优先进行合并以减少记录的版本数量。X-Engine综合考虑了各种策略形成自己的Compaction调度机制。 高度优化的LSM X-Engine的memory tables使用了无锁跳表(Locked-free SkipList),并发读写的性能较高。在持久化层如何实现高效,就需要讨论每层的细微结构。 数据组织 X-Engine的每层都划分成固定大小的Extent,存放每个层次中的数据的一个连续片段(Key Range)。为了快速定位Extent,为每层Extents建立了一套索引(Meta Index),所有这些索引,加上所有的memory tables(active/immutable)一起组成了一个元数据树(Metadata Tree),root节点为Metadata Snapshot,这个树结构类似于B-Tree。 X-Engine中除了当前的正在写入的active memory tables以外,其他结构都是只读的,不会被修改。给定某个时间点,例如LSN=1000,上图中的Metadata Snapshot 1引用到的结构即包含了LSN=1000时的所有的数据的快照,因此这个结构被称为Snapshot。 即便是Metadata结构本身,也是一旦生成就不会被修改。所有的读请求都是以Snapshot为入口,这是X-Engine实现Snapshot级别隔离的基础。前文说过随着数据写入,累积数据越多,会执行Compaction操作、冻结memory tables等,这些操作都是用Copy-on-write实现,即每次都将修改产生的结果写入新的Extent,然后生成新的Meta Index结构,最终生成新的Metadata Snapshot。 例如执行一次Compaction操作会生成新的Metadata Snapshot,如下图所示。 可以看到Metadata Snapshot 2相对于Metadata Snapshot 1并没有太多的变化,仅仅修改了发生变更的一些叶子节点和索引节点。 事务处理 得益于LSM的轻量化写机制,写入操作固然是其明显的优势,但是事务处理不只是把更新的数据写入系统那么简单,还要保证ACID(原子性、一致性、隔离性、持久性),涉及到一整套复杂的流程。X-Engine将整个事务处理过程分为两个阶段: 读写阶段 校验事务的冲突(写写冲突、读写冲突),判断事务是否可以执行、回滚重试或者等锁。如果事务冲突校验通过,则把修改的所有数据写入Transaction Buffer。 提交阶段 写WAL、写内存表,以及提交并返回用户结果,这里面既有I/O操作(写日志、返回消息),也有CPU操作(拷贝日志、写内存表)。 为了提高事务处理吞吐,系统内会有大量事务并发执行,单个I/O操作比较昂贵,大部分存储引擎会倾向于聚集一批事务一起提交,称为Group Commit,能够合并I/O操作。但是一组事务提交的过程中,还是有大量等待过程的,例如写入日志到磁盘过程中,除了等待落盘无所事事。 X-Engine为了进一步提升事务处理的吞吐,使用流水线技术,把提交阶段分为4个独立的更精细的阶段: 拷贝日志到缓冲区(Log Buffer) 日志落盘(Log Flush) 写内存表(Write memory table) 提交返回(Commit) 事务到了提交阶段,可以自由选择执行流水线中任意一个阶段,只要流水线任务的大小划分得当,就能充分并行起来,流水线处于接近满载状态。另外这里利用的是事务处理的线程,而非后台线程,每个线程在执行的时候,选择流水线中的一个阶段执行任务,或者空闲后处理其他请求,没有等待,也无需切换,充分利用了每个线程的能力。 读操作 LSM处理多版本数据的方式是新版本数据记录会追加在老版本数据后面,从物理上看,一条记录不同的版本可能存放在不同的层,在查询的时候需要找到合适的版本(根据事务隔离级别定义的可见性规则),一般查询都是查找最新的数据,总是由最高的层次往低层次找。 对于单条记录的查找而言,一旦找到便可以终止,如果记录在比较高的层次,例如memory tables,很快便可以返回;如果记录已经落入了很低的层次,那就得逐层查找,也许Bloom Filter可以跳过某些层次加快这个旅程,但毕竟还是有很多的I/O操作。X-Engine针对单记录查询引入了Row Cache,在所有持久化的层次的数据之上做了一个缓存,在memory tables中没有命中的单行查询,在Row Cache之中也会被捕获。Row Cache需要保证缓存了所有持久化层次中最新版本的记录,而这个记录是可能发生变化的,例如每次flush将只读的memory tables写入持久化层次时,就需要恰当的更新Row Cache中的缓存记录,这个操作比较微妙,需要精心的设计。 对于范围扫描而言,因为没法确定一个范围的key在哪个层次中有数据,只能扫描所有的层次做合并之后才能返回最终的结果。X-Engine采用了一系列的手段,例如SuRF(SIGMOD'18 best paper)提供range scan filter减少扫描层数、异步I/O与预取。 读操作中最核心的是缓存设计,Row Cache负责单行查询,Block Cache负责Row Cache的漏网之鱼,也用来进行范围扫描。由于LSM的Compaction操作会一次更新大量的Data Block,导致Block Cache中大量数据短时间内失效,导致性能的急剧抖动,因此X-Engine做了很多的优化: 减少Compaction的粒度。 减少Compaction过程中改动的数据。 Compaction过程中针对已有的缓存数据做定点更新。 Compaction Compaction操作是比较重要的,需要把相邻层次交叉的Key Range数据读取合并,然后写到新的位置。这是为前面简单的写入操作付出的代价。X-Engine为优化这个操作重新设计了存储结构。 如前文所述,X-Engine将每一层的数据划分为固定大小的Extent,一个Extent相当于一个小而完整的排序字符串表(SSTable),存储了一个层次中的一个连续片段,连续片段又进一步划分为一个个连续的更小的片段Data Block,相当于传统数据库中的Page,只不过Data Block是只读而且不定长的。 回看并对比Metadata Snapshot 1和Metadata Snapshot 2,可以发现Extent的设计意图。每次修改只需要修改少部分有交叠的数据,以及涉及到的Meta Index节点。两个Metadata Snapshot结构实际上共用了大量的数据结构,这被称为数据复用技术(Data Reuse),而Extent大小正是影响数据复用率的关键,Extent作为一个完整的被复用的物理结构,需要尽可能的小,这样与其他Extent数据交叉点会变少,但又不能非常小,否则需要索引过多,管理成本太大。 X-Engine中Compaction的数据复用是非常彻底的,假设选取两个相邻层次(Level1, Level2)中的交叉的Key Range所涵盖的Extents进行合并,合并算法会逐行进行扫描,只要发现任意的物理结构(包括Data Block和Extent)与其他层中的数据没有交叠,则可以进行复用。只不过Extent的复用可以修改Meta Index,而Data Block的复用只能拷贝,即便如此也可以节省大量的CPU。 一个典型的数据复用在Compaction中的过程可以参考下图。 可以看出数据复用的过程是在逐行迭代的过程中完成的,不过这种精细的数据复用带来另一个副作用,即数据的碎片化,所以在实际操作的过程中也需要根据实际情况进行分析。 数据复用不仅给Compaction操作本身带来好处,降低操作过程中的I/O与CPU消耗,更对系统的综合性能产生一系列的影响。例如c、Compaction过程中数据不用完全重写,大大降低了写入时空间的增大;大部分数据保持原样,数据缓存不会因为数据更新而失效,减少合并过程中因缓存失效带来的读性能抖动。 实际上,优化Compaction的过程只是X-Engine工作的一部分,更重要的是优化Compaction调度的策略,选什么样的Extent、定义compaction任务的粒度、执行的优先级等,都会对整个系统性能产生影响,可惜并不存在什么完美的策略,X-Engine积累了一些经验,定义了很多规则,而探索更合理的调度策略是未来一个重要方向。 适用场景 请参见X-Engine最佳实践。 如何使用X-Engine 请参见使用X-Engine引擎。 后续发展 作为MySQL的存储引擎,持续地提升MySQL系统的兼容能力是一个重要目标,后续会根据需求的迫切程度逐步加强原本取消的一些功能,例如外键,以及对一些数据结构、索引类型的支持。 X-Engine作为存储引擎,核心的价值还在于性价比,持续提升性能降低成本,是一个长期的根本目标,X-Engine还在Compaction调度、缓存管理与优化、数据压缩、事务处理等方向上进行深层次的探索。 X-Engine不仅仅局限为一个单机的数据库存储引擎,未来还将作为自研分布式数据库POLARDB分布式版本的核心,提供企业级数据库服务。

游客yl2rjx5yxwcam 2020-03-08 13:24:40 0 浏览量 回答数 0
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 企业信息查询 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 企业建站模板