干货 | 如何证明蛋白与蛋白之间存在相互作用?

在前期的文章中我们已经介绍了很多关于核酸和蛋白质之间互作的验证方法,那么如何证明蛋白和蛋白之间存在相互作用呢?蛋白质作为生命活动的主要承担者,其功能的发挥往往依赖于与其他蛋白质的相互作用,蛋白与蛋白的互作验证对于理解蛋白质功能、疾病发生机制以及药物研发具有重要意义。今天我们就来介绍3种关于蛋白与蛋白互作的验证实验,分别是Co-IP、GST pull-down和酵母双杂交。

No.1

免疫共沉淀(Co-IP)

1.1  实验原理

免疫共沉淀是利用抗体特异性反应纯化富集目的蛋白的一种方法。抗体与细胞裂解液或表达上清中相应的蛋白结合后,再与蛋白A/G(Protein A/G)偶联的 agarose 或Sepharose珠子孵育,通过离心得到珠子-蛋白A/G-抗体-目的蛋白复合物,在高温及还原剂的作用下,抗原与抗体解离,收集上清,上清中包括抗体、目的蛋白和少量的杂蛋白,再通过Western blot 或质谱等方法进一步对复合物中的靶蛋白进行分析。

图片

Co-IP实验原理图

1.2  实验流程

图片

1.3  结果解读

图片

常用术语:①Input:阳性对照,诱饵蛋白与靶蛋白表达的检测确认;②IgG:阴性对照;③IP:免疫沉淀;上图检测FOXM1与UCHL3之间的互作,FOXM1是诱饵蛋白,靶蛋白是UCHL3。

结果解读:①用FOXM1蛋白的IP级抗体拉蛋白FOXM1,因为存在互作,还有其它蛋白会被拉下来。在WB检测时,下拉蛋白中能用FOXM1的抗体检测到FOXM1;②验证FOXM1和UCHL3是否有相互作用。首先在Input蛋白中可以用UCHL3的抗体检测到UCHL3;其次,在FOXM1抗体下拉的蛋白物中也可以用UCHL3的抗体检测到UCHL3。结果满足上述两个条件,则说明FOXM1和UCHL3之间存在相互作用。

No.2

GST pull-down

2.1、技术原理

Pull-down技术的核心在于,将目标蛋白质固定在一种基质(譬如Sepharose)上。当细胞提取液通过这种基质时,可以与固相化蛋白产生相互作用的配体蛋白就会被吸附,而其他没有发生作用的蛋白则会随洗脱液一起被冲洗掉。然后,通过改变洗脱液的组成或者洗脱条件,就可以将那些被吸附的目标蛋白回收。

为了提高Pull-down技术的效能,我们可以将要纯化的蛋白以融合蛋白的形式进行表达,即将“诱饵”蛋白和一种易于纯化的配体蛋白结合。1988年Smith等研究者利用谷胱甘肽-S-转移酶(GST)作为融合标签,从细菌中纯化出GST融合蛋白。GST pull-down技术,即GST融合蛋白沉降法,其原理是利用谷胱甘肽亲和树脂将靶蛋白-GST融合蛋白亲和固化,使其作为与目的蛋白亲和的支撑物,扮演“诱饵蛋白”的角色。当含有目标蛋白的溶液过柱,可以捕获与之相互作用的“捕获蛋白”(即目标蛋白)。然后,通过SDS-PAGE电泳分析洗脱结合物,可以验证两种蛋白间的相互作用,或筛选相应的目标蛋白。

2.2  实验流程

图片

GST pull-down实验流程

2.3  结果解读

图片

常用术语:Input:全细胞裂解液,诱饵蛋白与靶蛋白表达的检测确认。Pull-down:即免疫沉淀,这一步主要是为了纯化富集目的蛋白。GST、His均为蛋白标签。

结果解读:GST的N端融合GmPSMD蛋白,在GmPIB1蛋白添加His标签便于免疫印迹。

Input + GST/His IB组:表示不经过GST pull down实验,直接对实验前各组的混合体系用GST或者His抗体进行免疫印迹,是阳性对照组表明各组有GST或者His相关组分。

Pull down+GST IB组:表示GST pull down实验后用GST抗体进行免疫印迹。发现两组均有条带,表明GST pull down实验体系可以正常发挥功能,也表明各组体系中含有GST相关的组分。

Pull down+His IB组:表示GST pull down实验后用HIs抗体进行免疫印迹。发现GST + GmPIB1-His组无条带,表明GST pull down体系中的GST空载与GmPIB1-His之间无互作,是阴性对照组。GmPSMD-GST + GmPIB1-His组有条带,表明两种蛋白之间存在互作。

No.3

酵母双杂交

3.1  技术原理

酵母转录因子GAL4包括两个结构域,分别为DNA结合结构域(DNA-binding domain,BD)和转录激活结构域(Activating domain,AD)。BD能够识别位于GAL4-responsive gene的上游激活序列(Upstream activating sequence,UAS)并与之结合,AD可以启动UAS下游的基因进行转录。当BD或AD单独作用时不能激活转录,只有AD和BD在空间上充分接近时,GAL4转录因子才具有活性并激活下游基因的转录。酵母双杂技术利用酵母转录因子GAL4的特性,将AD与X蛋白融合,BD与Y蛋白融合,如果X、Y互作形成蛋白复合物,那么AD与BD会在空间上充分接近,使GAL4转录因子激活并启动报告基因的转录。

图片

酵母双杂交技术原理

3.2  实验流程

1)AD与BD载体构建:

目的基因克隆或目的基因合成;限制性内切酶酶切骨架载体并纯化;目的基因插入骨架载体;转化大肠杆菌,筛选阳性克隆并测序鉴定;

2)共转酵母细胞:

将目的AD载体与BD载体共同转化到酵母细胞中;

3)二缺培养基培养转化的产物:

将共转的酵母细胞均匀涂布在二缺板(SD/-Leu/-Trp)上培养;

4)影印三缺和四缺板:

将二缺平板上生长的酵母单克隆影印至三缺板(SD/-His/-Leu/-Trp)和四缺板(SD/-Ade/-His/-Leu/-Trp)上培养;

5)筛选与检测:

通过观察酵母生长情况和报告基因的活性,判断两个蛋白质是否相互作用。

 三种方法比较 

图片

  如何选择?

Co-IP,GST-pull down和酵母双杂交是研究蛋白互作最常用的三种方法,一般Y2H常用来筛选,Co-IP和GST pulldown用来验证。研究不仅在整体蛋白层面,还包括蛋白的结构域层面,GST pulldown是用来验证蛋白A与B的直接结合的,而Y2H和Co-IP结果则还有间接作用以及非特异性作用。

图片

  • 9
    点赞
  • 20
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: Spark Streaming 和 Flink 都是流处理框架,但在一些方面有所不同。 1. 数据处理模型 Spark Streaming 基于批处理模型,将流数据分成一批批进行处理。而 Flink 则是基于流处理模型,可以实时处理数据流。 2. 窗口处理 Spark Streaming 的窗口处理是基于时间的,即将一段时间内的数据作为一个窗口进行处理。而 Flink 的窗口处理可以基于时间和数据量,可以更加灵活地进行窗口处理。 3. 状态管理 Spark Streaming 的状态管理是基于 RDD 的,需要将状态存储在内存中。而 Flink 的状态管理是基于内存和磁盘的,可以更加灵活地管理状态。 4. 容错性 Flink 的容错性比 Spark Streaming 更加强大,可以在节点故障时快速恢复,而 Spark Streaming 则需要重新计算整个批次的数据。 总的来说,Flink 在流处理方面更加强大和灵活,而 Spark Streaming 则更适合批处理和数据仓库等场景。 ### 回答2: Spark Streaming 和 Flink 都是流处理框架,它们都支持低延迟的流处理和高吞吐量的批处理。但是,它们在处理数据流的方式和性能上有许多不同之处。下面是它们的详细比较: 1. 处理模型 Spark Streaming 采用离散化流处理模型(DPM),将长周期的数据流划分为离散化的小批量,每个批次的数据被存储在 RDD 中进行处理,因此 Spark Streaming 具有较好的容错性和可靠性。而 Flink 采用连续流处理模型(CPM),能够在其流处理过程中进行事件时间处理和状态管理,因此 Flink 更适合处理需要精确时间戳和状态管理的应用场景。 2. 数据延迟 Spark Streaming 在处理数据流时会有一定的延迟,主要是由于对数据进行缓存和离散化处理的原因。而 Flink 的数据延迟比 Spark Streaming 更低,因为 Flink 的数据处理和计算过程是实时进行的,不需要缓存和离散化处理。 3. 机器资源和负载均衡 Spark Streaming 采用了 Spark 的机器资源调度和负载均衡机制,它们之间具有相同的容错和资源管理特性。而 Flink 使用 Yarn 和 Mesos 等分布式计算框架进行机器资源调度和负载均衡,因此 Flink 在大规模集群上的性能表现更好。 4. 数据窗口处理 Spark Streaming 提供了滑动、翻转和窗口操作等灵活的数据窗口处理功能,可以使用户更好地控制数据处理的逻辑。而 Flink 也提供了滚动窗口和滑动窗口处理功能,但相对于 Spark Streaming 更加灵活,可以在事件时间和处理时间上进行窗口处理,并且支持增量聚合和全量聚合两种方式。 5. 集成生态系统 Spark Streaming 作为 Apache Spark 的一部分,可以充分利用 Spark 的分布式计算和批处理生态系统,并且支持许多不同类型的数据源,包括Kafka、Flume和HDFS等。而 Flink 提供了完整的流处理生态系统,包括流SQL查询、流机器学习和流图形处理等功能,能够灵活地适应不同的业务场景。 总之,Spark Streaming 和 Flink 都是出色的流处理框架,在不同的场景下都能够发挥出很好的性能。选择哪种框架取决于实际需求和业务场景。 ### 回答3: Spark Streaming和Flink都是流处理引擎,但它们的设计和实现方式有所不同。在下面的对比中,我们将比较这两种流处理引擎的主要特点和差异。 1. 处理模型 Spark Streaming采用离散流处理模型,即将数据按时间间隔分割成一批一批数据进行处理。这种方式可以使得Spark Streaming具有高吞吐量和低延迟,但也会导致数据处理的粒度比较粗,难以应对大量实时事件的高吞吐量。 相比之下,Flink采用连续流处理模型,即数据的处理是连续的、实时的。与Spark Streaming不同,Flink的流处理引擎能够应对各种不同的实时场景。Flink的实时流处理能力更强,因此在某些特定的场景下,它的性能可能比Spark Streaming更好。 2. 窗口计算 Spark Streaming内置了许多的窗口计算支持,如滑动窗口、滚动窗口,但支持的窗口计算的灵活性较低,只适合于一些简单的窗口计算。而Flink的窗口计算支持非常灵活,可以支持任意窗口大小或滑动跨度。 3. 数据库支持 在处理大数据时,存储和读取数据是非常重要的。Spark Streaming通常使用HDFS作为其数据存储底层的系统。而Flink支持许多不同的数据存储形式,包括HDFS,以及许多其他开源和商业的数据存储,如Kafka、Cassandra和Elasticsearch等。 4. 处理性能 Spark Streaming的性能比Flink慢一些,尤其是在特定的情况下,例如在处理高吞吐量的数据时,在某些情况下可能受制于分批处理的架构。Flink通过其流处理模型和不同的调度器和优化器来支持更高效的实时数据处理。 5. 生态系统 Spark有着庞大的生态系统,具有成熟的ML库、图处理库、SQL框架等等。而Flink的生态系统相对较小,但它正在不断地发展壮大。 6. 规模性 Spark Streaming适用于规模小且不太复杂的项目。而Flink可扩展性更好,适用于更大、更复杂的项目。Flink也可以处理无限制的数据流。 综上所述,Spark Streaming和Flink都是流处理引擎,它们有各自的优缺点。在选择使用哪一个流处理引擎时,需要根据实际业务场景和需求进行选择。如果你的业务场景较为复杂,需要处理海量数据并且需要比较灵活的窗口计算支持,那么Flink可能是更好的选择;如果你只需要简单的流处理和一些通用的窗口计算,Spark Streaming是更为简单的选择。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值