喵叔

上一篇文章我们解决写操作对数据库的压力，但是如果是长期频繁插入数据，那么这个方案并不能解决这个问题。这篇文章将会解决这个问题。A公司有一个面向全国的大型社区团购APP，日访问量在80万以上，用户下单量16万单以上，运营中心需要根据用户在页面上的停留时间、用户所在位置来进行数据分析，以便调整不同商品的营销策略，并且还需要查看不同商品每天的点击人数、点击人次和下单人数。这是一个看似很简单的需求，貌似就只是设置一个埋点，记录一下用户在商品详情页停留时长、用户当前所在位置以及在商品详情页的操作信息，但是对于一个日

面向对象是目前主流的开发模式，基本概念是将和数据相关的行为封装为特殊的名为对象的实体，对象实体则给出了一系列的蓝图，这些蓝图就是类。我们以汽车为例来讲解一下类与对象。在上图中是交通工具类的UML图，我们有一辆桑塔纳汽车，那么这个桑塔纳就是一个对象，就是Car这个类的一个实例。每辆车都有名字 、重量和高度等属性，这些属性都是类的成员变量，存储在成员变量中的数据被称为状态。每辆车都有启动和停止行为，这些都是类的行为方法，所有方法定义了类的行为。在实际开发中，不可能只有一个类，多个类组织起来就形成了类的层次结构

在上一篇文章中我们讨论了缓存架构方案，使用这个架构方案可以减轻读数据库的压力，但是这个方案在大量并发写操作的情况下会造成数据库性能降低。那么这篇文章我将讲解一下如何处理大量并发写的问题。在一个电商系统中，我们要增加一个预约功能，用户可以在指定的时间段内对商品进行购买预约。预约功能和其他功能不一样的地方是，预约功能会出现短时间内大量并发写的情况，很有可能造成数据库和服务器崩溃，对于服务器来说我们可以增加服务器数量，但是对于数据库来说简单的增加数据库数量是不够的。一定有人会说使用分表分库啊，这个方案确实不错，但

元数据同步是Alluxio的重要特性。这篇文章描述了设计、实现和其他内部流程，用以调整性能。元数据同步(sync)是Alluxio中的核心功能，它使文件和目录与所在存储系统下真实的来源保持一致，进而使用户能够轻松地从Alluxio中检索出最新版的数据。同时了解内部流程对调整性能也非常重要。本文介绍了Alluxio中保持元数据同步的设计和实现。在Alluxio中，元数据指的是Alluxio文件系统中文件和目录的信息，包括它们的所有者、组、权限、创建以及修改时间等信息。元数据独立于其内容——即使文件或目录是空

从这篇文章开始，我们将学习缓存在架构中如何使用，主要解决数据库读取频繁的问题。现在我们有一个电商系统，系统同每个商品都有详情页，详情页内容包含：图片、价格、详情、评价、优惠活动、类似商品以及近期交易情况等。一个页面需要执行十几条sql语句，如果详情页后期再增加别的内容的话，需要执行的sql语句有可能多大几十条，那么这时详情页就会打开的很慢。为了解决这个问题我们首先想到的是将数据存储到本地缓存中，商品Id作为key，详情作为value，用户获取商品详情时，根据id从本地缓存中取。但是这里有个问题，服务器的本

上一篇文章中我们说到查询分离对于舆情系统来说不是很好的解决方案，这是因为查询分离虽然解决了复杂查询和查询导致的写入缓慢问题，但是如果主存储数据量越来越大时，写操作也会变的很慢，因此我们就需要引入分库分表方案。接上篇文章，舆情系统已经运行了三年，接入的社交平台也是越来越多，每天新增的数据量已经超过5000万，虽然查询数据的速度加快了，但是写入数据的速度越来越慢。经过开发组商讨，打算采用分库分表方案来解决这个问题。大致思路如下：所谓分库分表可以分为两部分来讲：分表和分库。选择分库分表的原因是，这个方案对第三方的

上一篇文章中我们讲解了利用数据库分区与冷热分离的方式来优化存储，虽然解决了查询速度慢的问题，但是在海量数据情况下依然会出现查询缓慢问题，并且部分系统中的冷热数据也是需要频繁或同时查询的。那么，这篇文章中我将带领大家来学习一下如何在设计系统架构时解决海量的数据存储与查询。Tip：目前任何一个与数据有关的系统，甚至互联网系统都有极大的可能出现海量的数据存储。一、案例我们有一个自动化舆情系统，简要的工作流程是这样的：每天数据采集服务会从公共社交媒体上采集数据并存入数据库，识别服务读取数据库中存储的数据按

在本专题中我们首先将 RavenDB 视为一个简单的键/值存储。只需将数据存储进去并通过键访问数据即可。同时我们还学习了使用过期功能来存储与时间相关的数据。从键/值存储的简单模型开始，我们开始考虑真实的文档模型，学习了如何构建嵌入值来存储本质上是文档一部分的数据，还研学习了如何对关系和集合、多对一和多对多关联进行建模。然后，我们介绍了更高级的建模技术，例如如何处理引用和配置数据，以及如何处理时态信息和分层结构。接下来，我们讨论了建模时必须考虑的一些约束，例如如何处理文档的增长以及RavenDB中文档的良好

本文是专题的第一篇文章，主要讲解优化数据存储，涉及到锁、批处理、重试机制以及数据一致性等问题。下面 我们就开始吧。一、案例有一个客服工单系统，会从邮件服务器中获取客服邮箱收到的邮件，并且将这些邮件自动生成工单并自动分配给相应的客服组，每次客服人员从工单列表中选取一个工单进行处理，每处理一次就会产生一个工单处理记录，直到工单被客服关闭为止。该系统已经运行了一年，在这一年中一共产生了一千万个工单和五千万条工单处理记录。因为所有工单和处理记录都存储在一个数据库中，因此每次客服查看工单列表时会很慢，但是客服还

本专题最后一节，我们将学习 RavenDB 中常用的两种模式：ACID和BASE模式。首先我先来简述一下什么是 ACID和BASE。ACID 是数据库事务正确执行的四个基本要素的缩写。指 DBMS 在写入或更新资料的过程中，为保证事务是正确可靠的，所必须具备的四个特性：原子性（atomicity）、一致性（consistency）、隔离性（isolation）、持久性（durability）。BASE 是为了解决解数据库强一致性引起的问题而引发的可用性降低而提出的解决方案。BA指的是基本可用（Basi

在 RavenDB 中存储文档时，我们可以指定文档的过期时间，RavenDB 会定期删除所有过期的文档。这个功能虽然很小，但是我们可以利用这个可以实现类似“30分钟有效的验证码”的功能。这里需要主义的是如果你指定了过期时间，则在该时间过后，文档可能依然存在，这是因为 RavenDB 还没有开始清理过期的文档，默认情况下，RavenDB 将每分钟清除过期的文档。因此，文档的生存时间可能比预期的要长一些，但并不是很严重。TIP：我将在后续的专题中具体讲解这个功能。...

从工程师的角度探索TikTok推荐系统架构。TikTok是一款视频共享应用程序，可让用户创建和共享短视频。它以个性化的“just for you”的推荐给用户留下了深刻的印象。它在Z世代中非常受欢迎，容易让人上瘾。在它的背后，它是由人工智能技术驱动的。TikTok架构TikTok推荐系统的架构包括三个组件：大数据框架、机器学习和微服务架构。大数据框架是系统的起点。它提供实时数据流处理，数据计算和数据存储;机器学习是推荐系统的大脑。使用一系列机器学习和深度学习算法与技术用于构建模型并生成适用于个人

我们存在数据库里的数据会随着时间的变化而变化，如果要随时追踪数据的变化是一项极具挑战的任务，但是RavenDB 为我们提供了修订功能来解决这一问题。DBA 可以配置 RavenDB 用来追踪文档的修订，每次文档修改时都会创建一个不可变的修订版本，这样我们就可以通过使用这些修订版本来追踪文档发生的所有变化。但是在实际开发中我们一般不会要求追踪所有文档的变化，这时我们就可以指定 RavenDB 仅跟踪特定的集合，甚至可以跟踪最近的几个修订版本。当然修订也可以用于删除，所以我们可以根据修订版本来回复被删除的文档。

RavenDB 是一个 JSON数据库，但并非所有数据都可以使用JSON来存储，例如订单中的发票PDF、QQ/微信头像等，对于这种类型的数据它既是文档的一部分又是和文档分开的，因此 RavenDB 会将这类数据作为附件存储。什么是附件？附件是可以附加到文档的二进制数据，附件始终位于文档中，除了存储二进制数据外，还会存储一个附件名称。虽然附件和文档分别位于不同的卫视，但是都保存在同一个存储中，并且附件和文档可以一起处理。这也就是说附件可以和具有相同语义的文档一起参与相同的事务TIP：附件没有大小限制，并且

这篇文章比较简单，在这个专题的一开始，我们探究了对象和文档之间的关系，我们只是专注于构建模型，忽略了跳过我们如何在图表阶段之外处理关系。那么这一小篇文章我们就来简单的说一下这个问题。我们需要考虑两个单独的操作。在查询和加载文档期间获取相关信息可以使用Include调用来完成，这时一个非常常用的功能，因为他可以减少请求服务端的次数。第二个操作是查询，也就是说当想根据相关文档的属性查询特定文档。例如前面文章所说的幼儿园的例子，查询母亲叫刘妈妈的孩子，由于子文档不再包含父级文档的名称，那么我们将如何搜索它呢？R

RavenDB 使用基于 HTTP 的 REST 用于客户端和服务端的通信，也就是说我们在操作文档的时候其实就是使用 WEB 发送 HTTP 请求，那么基于这一点 RavenDB 就可以利用 HTTP 的特性来执行一些东西。其中最常见的是 RavenDB 客户端 API 使用 HTTP 特性在客户端开启缓存。每个从服务端返回的响应都包含一个 etag 头内容，如果我们只是请求的单个文档，那么这个 etag 头内容就是文档的 etag 标题，如果我们请求的是多个文档的话，这个 etag 头内容就会包含一个计

RavenDB 每秒能处理数十万的请求，这是因为它本质上是并发的。那么这就引出了并发问题，如果有多个请求同一时间同时修改同一个文档，就会出现最后一个被执行的请求将会获胜，它的修改内容将被保留在文档中。在 RavenDB 中 last write wins 模型是默认选项，这个模型出现在对文档的修改和删除的情况下，在创建文档时是不会执行这个模型规则的，因为 RavenDB 它知道请求是要创建一个新文档，并会设置预期的更改向量。TIP：什么是更改向量？这个概念在 RavenDB 被深入的使用，它由节点 I

缓存查询属性是我们在实际开发中会遇到的，什么是缓存查询属性呢？举个例子来说，在电子商城的订单系统中每个账户都有自己的订单数据，有时用户需要查看自己截止到目前所订单的数量，那么这个账户的订单数量可以被视为 查询属性，因为从众多的订单中统计出某个账户的订单数量是一件会消耗很多资源的命令，因此会将这个订单数量存储在缓存中（例如存储在RavenDB中），在后续查询中我们不需要再次从数据库中查询，只需要在缓存冲查询即可，这就叫做 缓存查询属性。缓存查询属性的行为开起来很常见也很有意义，但是着是一个不良的行为。为什么

使用 RavenDB 进行数据建模的一个重大挑战是数据不同的特征和行为会对各种操作成本产生不同的影响，这又反过来影响我们设计和使用模型的方式。从这篇文章开始我将通过4到6篇文章来讲解 RavenDB 文档建模琐碎的注意事项。处理无限增长的文档多大的文档才能被成为大文档？多小的文档才能被称为小文档？不同的 NoSQL 数据库给出的答案是不一样的，但是一般来说良好的文档大小范围应该在千字节左右。在 RavenDB 对文档的大小限制是有硬性规定的，不超过2GB，不要觉得着2GB不够用，RavenDB会对 JS