RavenDB是一个在.NET下的文档型数据库，它具有高扩展性，支持MapReduce，提供RESTful的接口。同时它又支持ACID的事务。下面是一个RavenDB的系列教程，从入门到精通。 introduction setup application lifecycle tracking documents structure entities, repositories, and commands user registration Using RavenDB with ASP.NET MVC NoS
RavenDB 非常适合键/值存储，为了确保快速存取数据库，RavenDB 在设计的时候降低了存储和加载文档的成本，这是 RavenDB 和其他数据库相比最大的有点。 由于数据限制必须是 JSON ，因此使用 RavenDB 作为键/值存储是完全没问题的。使用 RavenDB 缓存信息的常见场景有：存储购物车信息、存储用户会话数据、缓存热点数据等等。在默认情况下，RavenDB 不会对存储以及加载文档增加额的外成本，因此可以使用所有访问模型中最简单的快速数据库。一般来说键/值建模的复杂性在于生成适当的键以及可以对其执行哪些操作。在使用 RavenDB 作为键/值存储的情况下，下面所列的内容是很有用的：
在上一节当中已经介绍了RavenDb的文档设计模式，这一节我们要具体讲一讲如何使用api去访问RavenDb 1.连接RavenDb var documentStore = new DocumentStore { Url = "http://myravendb.mydomain.com/" }; documentStore.Initialize(); var documentStore = new DocumentStore { ConnectionStringName = "MyRav
上一篇文章我们讲解了 RavenDB 的安装以及示例数据库的创建，并且其中涉及到了 RavenDB Stuido 的使用，但是只是简单的讲解了一下。那么在这篇文章中我将带领大家来具体的学习 如何在 RavenDB Studio 中实现增删改查。
在 RavenDB 中存储文档时，我们可以指定文档的过期时间，RavenDB 会定期删除所有过期的文档。这个功能虽然很小，但是我们可以利用这个可以实现类似“30分钟有效的验证码”的功能。这里需要主义的是如果你指定了过期时间，则在该时间过后，文档可能依然存在，这是因为 RavenDB 还没有开始清理过期的文档，默认情况下，RavenDB 将每分钟清除过期的文档。因此，文档的生存时间可能比预期的要长一些，但并不是很严重。
本专题最后一节，我们将学习 RavenDB 中常用的两种模式：ACID和BASE模式。首先我先来简述一下什么是 ACID和BASE。
众所周知，NoSQL运动旨在成为大数据时代传统关系数据库管理系统的替代品。如今Microsoft对开源的态度有所转变，RavenDB就是很好的例子。Microsoft对RavenDB（NoSQL数据库）的认可令很多人感到惊讶。RavenDB可以轻易的替代关系数据库管理系统并兼容以往的.NET应用。 NoSQL的出现与发展是非常必要的，NoSQL系统的速度和高扩展性是其具备的优势，而这并不是传统关系数据库的强项。NoSQL为Amazon、Google等需要处理大数据的公司提供行之有效的解决方案。如键值存储鼻祖
RavenDB 每秒能处理数十万的请求，这是因为它本质上是并发的。那么这就引出了并发问题，如果有多个请求同一时间同时修改同一个文档，就会出现最后一个被执行的请求将会获胜，它的修改内容将被保留在文档中。在 RavenDB 中 last write wins 模型是默认选项，这个模型出现在对文档的修改和删除的情况下，在创建文档时是不会执行这个模型规则的，因为 RavenDB 它知道请求是要创建一个新文档，并会设置预期的更改向量。
我们存在数据库里的数据会随着时间的变化而变化，如果要随时追踪数据的变化是一项极具挑战的任务，但是RavenDB 为我们提供了修订功能来解决这一问题。DBA 可以配置 RavenDB 用来追踪文档的修订，每次文档修改时都会创建一个不可变的修订版本，这样我们就可以通过使用这些修订版本来追踪文档发生的所有变化。但是在实际开发中我们一般不会要求追踪所有文档的变化，这时我们就可以指定 RavenDB 仅跟踪特定的集合，甚至可以跟踪最近的几个修订版本。当然修订也可以用于删除，所以我们可以根据修订版本来回复被删除的文档。
本篇是 RavenDB 起步阶段的首篇文章，我将会在这篇文章里讲解如何安装 RavenDB 以及如何创建实例数据库。下面就让我们开始吧！
在本专题中我们首先将 RavenDB 视为一个简单的键/值存储。只需将数据存储进去并通过键访问数据即可。同时我们还学习了使用过期功能来存储与时间相关的数据。从键/值存储的简单模型开始，我们开始考虑真实的文档模型，学习了如何构建嵌入值来存储本质上是文档一部分的数据，还研学习了如何对关系和集合、多对一和多对多关联进行建模。然后，我们介绍了更高级的建模技术，例如如何处理引用和配置数据，以及如何处理时态信息和分层结构。
上一小节我们演示了一个简单的实例，从本篇文章开始我将通过两篇文章带领大家学习一下 RavenDB 常用客户端 API。
本篇文章将带领大家实现一个小的 RavenDB 案例程序，要求是这样的：实现一个 ToDoList 程序，可以对它进行新增、修改。下面我们开始吧！
会话是代码和 RavenDB 交互的主要方式。会话 API 中包含如下七个常用的高级 API ：
使用 RavenDB 进行数据建模的一个重大挑战是数据不同的特征和行为会对各种操作成本产生不同的影响，这又反过来影响我们设计和使用模型的方式。从这篇文章开始我将通过4到6篇文章来讲解 RavenDB 文档建模琐碎的注意事项。
数据建模直接影响到数据库完成工作的效率，我们。常见的建模时基于关系数据的建模，这种建模被称为数据建模，有点如下：
我们可以通过 Delete 方法来删除文档，这个方法接受实例实体或文档 ID。下面的代码就是删除文档的方法：
RavenDB 使用基于 HTTP 的 REST 用于客户端和服务端的通信，也就是说我们在操作文档的时候其实就是使用 WEB 发送 HTTP 请求，那么基于这一点 RavenDB 就可以利用 HTTP 的特性来执行一些东西。 其中最常见的是 RavenDB 客户端 API 使用 HTTP 特性在客户端开启缓存。每个从服务端返回的响应都包含一个 etag 头内容，如果我们只是请求的单个文档，那么这个 etag 头内容就是文档的 etag 标题，如果我们请求的是多个文档的话，这个 etag 头内容就会包含一个计算值（具体计算值将在后面的专题详细讲解）。客户端将会缓存服务器的响应、URL 和 etag 的值，那么当有和缓存 URL 想的请求进入客户端时，我们会将其发送到服务端，同时也告知服务端，客户端存在一个特定 etag 值的请求结果。服务端在收到信息后会检查 etag 和客户端上的 etag 是否一样，如果一样就不返回数据，让客户端继续使用缓存的数据，这样就减少了网络的负载和服务端的压力。 另外，RavenDB 还有一个叫做 Aggressive Caching 的功能，它可以让看客户端 API 注册来自服务端的更改。也就是说，当我们在本地缓存了一些值后，就不需要再向服务端发送请求，让服务端判断是否要给我们返回新数据，通过这个功能如果服务端的数据发生了改变，那么服务端就会通知客户端，这时我们可以去请求服务端来获取新的数据。这个功能对于查询类似 configure 文档或大型文档来说可以大大的节省性能。
在关系型数据库中表一般情况下都会存在主键，这个主键在所在表中是唯一的不可重复的，同样在 RavenDB 中也存在这样的主键，它被成为文档标识符或文档ID。文档ID是由 UTF8 字符串组成的最多 2025 字节长度的全局唯一值。一般来说文档 ID 的组成规则是： 集合名称 + / + 唯一值 ，当然如果你有其他文档 ID 组成的规则也可以使用。下面我们来看一下 RavenDB 生成文档 ID 的策略。
我们在开始讲解如何在 RavenDB 中建模之前，先来看看注意事项，这些内容与我们将要辨析的模型有着直接的关系。 这里需要注意的第一点是 不要在不同应用之间建立共享数据库。很多设计者会建立共享数据库，用以在不同的应用之间共享相同的数据，虽然这样做能减少数据存储量，以及实现多应用使用相同数据的目的，但是在 RavenDB 中并不推崇这样的做法。这是因为虽然不同的应用看起来有些数据是一样的，我们会强制它们使用相同的方式处理数据，但是在大多数情况下不同的应用程序使用相互不同的方式处理类似的数据，如果使用共享数据的话，一个应用程序共享数据的结构的改变就会造成其他应用跟着一起改变，进而导致数据模型复杂性增加，并且也会增加不同应用开发团队之间沟通的成本和时间。因此每个应用程序应该对立的进行数据建模，并不断的根据需求进行改进。 读到到这里，肯定有人会问了：不同的应用程序直接或多或少的都需要共享数据，那么使用 RavenDB 如何实现这一点呢？我们可以使用 RavenDB 内置的 ETL 功能在不同应用程序服务器之间建立数据/信息流（这个内容将会在后续讲解）。 另一个要注意的是 某些情况下应该数据冗余存储，比如在 Order 文档中存在 Address 文档的链接，但是如果 Address 中的配送地址变了，那么 Order 文档中的历史订单的配送地址也会跟着改变，这样就出现了我上一篇文章说的数据损坏。那么，我们在进行建模的时候，应该考虑我的关注点是当前值（例如 Order 文档中的当前订单配送地址）还是时间点值（例如 Order 文档的历史订单配送地址），如果是时间点值那么我们就需要进行数据冗余存储，例如在 Order 文档中存储配送地址的详细信息。 以上几小段的内容总结下来就是建模文档的核心原则：
RavenDB 是一个 JSON数据库，但并非所有数据都可以使用JSON来存储，例如订单中的发票PDF、QQ/微信头像等，对于这种类型的数据它既是文档的一部分又是和文档分开的，因此 RavenDB 会将这类数据作为附件存储。什么是附件？附件是可以附加到文档的二进制数据，附件始终位于文档中，除了存储二进制数据外，还会存储一个附件名称。虽然附件和文档分别位于不同的卫视，但是都保存在同一个存储中，并且附件和文档可以一起处理。这也就是说附件可以和具有相同语义的文档一起参与相同的事务
我们可以在文档中存储任何数据内容，比如在订单文档中我们会存储订单状态、订单物品数量、订单金额等等内容。但是我们还需要存储一些和订单文档无关的内容，比如谁修改了订单文档、什么时候修改了订单文档等，这时就需要 Document Metadata （文档元数据，我们暂且这样翻译）登场了 。
该原文是Ayende Rahien大佬业余自己在使用C# 和 .NET构建一个简单、高性能兼容Redis协议的数据库的经历。首先这个"Redis"是非常简单的实现，但是他在优化这个简单"Redis"路程很有趣，也能给我们在从事性能优化工作时带来一些启示。原作者：Ayende Rahien 原链接：https://ayende.com/blog/197665-C/high-performance-net-building-a-redis-clone-analysis-ii
RavenDb是文档型数据库，但是我们常常也需要定义对象之间的关系，那RavenDb当中是如何处理的呢？ RavenDb提供了优雅的解决方式，使用正确的话，可以减少数据开销以及网络拥堵 Denormalization 第一种就是反规范化，下面是一个订单的JSON格式 在Order这个订单当中我们把我们需要的客户信息（名字）也保存下来了，使用的时候，它直接就读出来了。 { // Order document with id: orders/1234 "Customer": { "Name":
1、事务支持 别的关系型数据库和RavenDb一起使用 using (var transaction = new TransactionScope()) { BlogPost entity = session.Load<BlogPost>("blogs/1"); entity.Title = "Some new title"; session.SaveChanges(); // will create HTTP request session.Delete(en
该原文是Ayende Rahien大佬业余自己在使用C# 和 .NET构建一个简单、高性能兼容Redis协议的数据库的经历。首先这个"Redis"是非常简单的实现，但是他在优化这个简单"Redis"路程很有趣，也能给我们在从事性能优化工作时带来一些启示。原作者：Ayende Rahien 原链接：https://ayende.com/blog/197569-B/high-performance-net-building-a-redis-clone-skipping-strings
在 RavenDB 中对如何在应用程序中进行数据建模没有任何要求，我们可以使用任何形式进行建模，RavenDB 只关心如何构建数据，这就是我们后续几篇文章要讲解的内容。
上篇文章讲解了标准业务数据的建模方案，但是在实际项目中还存在非标准方案来解决大量复杂的数据结构，那么本篇文章就来讲讲。
该原文是Ayende Rahien大佬业余自己在使用C# 和 .NET构建一个简单、高性能兼容Redis协议的数据库的经历。 首先这个"Redis"是非常简单的实现，但是他在优化这个简单"Redis"路程很有趣，也能给我们在从事性能优化工作时带来一些启示。 原作者：Ayende Rahien 原链接：https://ayende.com/blog/197441-A/high-performance-net-building-a-redis-clone-analysis 另外Ayende大佬是.NET开源的高性能多范式数据库RavenDB所在公司的CTO，不排除这些文章是为了以后会在RavenDB上兼容Redis协议做的尝试。大家也可以多多支持，下方给出了链接 RavenDB地址：https://github.com/ravendb/ravendb
1.聚合缓存 RavenDb默认是缓存所有的请求url的，最大的缓存请求数默认是2048 documentStore.Conventions.ShouldCacheRequest = url => true; documentStore.MaxNumberOfCachedRequests = 2048; 如果开启这个选项，RavenDb直接从缓存当中读取数据，而不是从服务端。 //关闭跟踪 documentStore.Conventions.ShouldAggressiveCacheTrackChan
缓存查询属性是我们在实际开发中会遇到的，什么是缓存查询属性呢？举个例子来说，在电子商城的订单系统中每个账户都有自己的订单数据，有时用户需要查看自己截止到目前所订单的数量，那么这个账户的订单数量可以被视为 查询属性，因为从众多的订单中统计出某个账户的订单数量是一件会消耗很多资源的命令，因此会将这个订单数量存储在缓存中（例如存储在RavenDB中），在后续查询中我们不需要再次从数据库中查询，只需要在缓存冲查询即可，这就叫做 缓存查询属性。 缓存查询属性的行为开起来很常见也很有意义，但是着是一个不良的行为。为什么这么说呢？首先在大部分领域中这种类似的属性并不是客户必须有的部分（可有可无），也不是客户文档必须包含的部分，其次，为了保证这个属性会在相关内容变更（例如订单删除和新增）时也跟着更改，我们就需要在相关内容发生变化时也去改变它的内容，等于说我们要对数据库多进行N次的操作，然后将更新的数据在存入缓存中，这样就会增大失败的概率，接着，我在进行开发设计前还需要考虑哪些操作会改变查询属性，如果是比较简单的项目还好，那如果是大型项目呢？里面的操作错综复杂，如何保证覆盖所有的操作？ 缓存查询属性这个问题其实是一个业务和成本方面的问题，在大多数情况下我们只是想在页面中展示这个值，并且要从关系型数据库中查询出这个值的话可能会很昂贵，因此很多人会将这个值直接放在缓存中。在 RavenDB 中我们可以使用 MapReduce 聚合操作来处理，我们根本就不需要缓存这种属性，也减少了成本，MapReduce的使用因为是一个很大的模块，因此我将放在后面专门开始一个专题来讲解。在解决完缓存查询属性的问题后，下一步我们该考虑如何处理并发的问题和并发问题对建模的影响，这个问题我将放在下一篇文章讲解。
RavenDb是一个文档型的数据库，和芒果Db是一个类型的东西，但是公司选择了它，主要是因为它对事务的支持比较好，芒果Db在事务方面有问题。 下面有一个例子。 在关系型数据库中，
该原文是Ayende Rahien大佬业余自己在使用C# 和 .NET构建一个简单、高性能兼容Redis协议的数据库的经历。首先这个"Redis"是非常简单的实现，但是他在优化这个简单"Redis"路程很有趣，也能给我们在从事性能优化工作时带来一些启示。由于接下来的两篇较短，本文一起把它们一起翻译原作者：Ayende Rahien 原链接：https://ayende.com/blog/197505-C/high-performance-net-building-a-redis-clone-separation-of-computation-i-o
这篇文章比较简单，在这个专题的一开始，我们探究了对象和文档之间的关系，我们只是专注于构建模型，忽略了跳过我们如何在图表阶段之外处理关系。那么这一小篇文章我们就来简单的说一下这个问题。 我们需要考虑两个单独的操作。在查询和加载文档期间获取相关信息可以使用Include调用来完成，这时一个非常常用的功能，因为他可以减少请求服务端的次数。第二个操作是查询，也就是说当想根据相关文档的属性查询特定文档。例如前面文章所说的幼儿园的例子，查询母亲叫刘妈妈的孩子，由于子文档不再包含父级文档的名称，那么我们将如何搜索它呢？RavenDB 不允许我们使用多连接，但它允许在索引阶段为相关数据编制索引，然后对其进行查询。因此使用这个功能通过母亲的名字查询孩子非常容易。索引功能将在索引专题中进行进一步讲解。我在这里提到它，是因为知道它的存在会影响我们对数据建模的方式，在决定如何对相关数据进行建模时，它可以有很大的帮助。但是最终决策几乎总是归结为我们是想要数据的时间点视图还是当前值。对于第一个选项，我们通常会将值从源复制到其自己的文档中，对于第二个选项，我们可以在索引和查询以及从服务器获取数据时使用。
Go是Google开发的一种静态、强类型、编译型、并发型，并具有垃圾回收功能的类C编程语言。2009以开源项目的形式发布，2012年发布1.0稳定版本，距今已经十年了，其性能类似于Java和C++，但速度极快，适合搭载于web服务器，用于高性能分布式系统开发。
cnbeta新闻：微软正式发布Visual Studio 2013 RTM版，微软还发布了Visual Studio 2013的最终版本、.NET 4.5.1以及Team Foundation Server 2013。下面我们体验下Visual Studio 2013 Web开发方面有哪些特性,具体可以参看http://www.asp.net/visual-studio/overview/2013/release-notes。 1、.NET Framework 2.0/3.0/3.5/4.0/4.5/4.5
内容包括：有趣、入门级的开源项目、开源书籍、实战项目、企业级项目等，让你在短时间内感受到开源的魅力，对开源和编程产生兴趣！
对比传统关系型数据库，NoSQL有着更为复杂的分类——键值、面向文档、列存储以及图数据库。这里就带你一览NoSQL各种类型的适用场景及一些知名公司的方案选择。 在过去几年，关系型数据库一直是数据持久化的唯一选择，数据工作者考虑的也只是在这些传统数据库中做筛选，比如SQL Server、Oracle或者是MySQL。甚至是做一些默认的选择，比如使用.NET的一般会选择SQL Server；使用Java的可能会偏向Oracle，Ruby是MySQL，Python则是PostgreSQL或MySQL等等。 原因很
AI科技评论消息，近日，国外知名 IT 技术媒体 Jaxenter 进行了数据库观点调查，对开发者眼中数据库领域最热门的话题、最热门的数据存储以及处理工具进行统计汇总。 调研的目标，是观察 2017 数据库大趋势。 数据处理——2017 调研的第二名 Jaxenter 的调查问卷，从询问调查对象对泛数据库领域的兴趣点开始。根据调查结果，数据处理是今年的一大热门主题。如同下面的柱状图，NoSQL 和 SQL 数据库都在调查参与者最受关注话题的前列。 如果我们把对特定选项“感兴趣”和“很感兴趣”的回答数目综合起
在下边有一个路线图，如果你想要成为一名Go语言的开发者的话，你可以沿着这张图里面的路径去学习，里面记录了一些你可能也想学习的库。当你问到：”我想成为一名Go语言开发者，接下来我要学些什么？“，我做的这个路线图就是一个很好的建议。
摘要：对比传统关系型数据库，NoSQL有着更为复杂的分类——键值、面向文档、列存储、图数据库。这里就带你一览NoSQL各种类型的适用场景及一些知名公司的方案选择。
1. 请解释什么是NoSQL数据库，有哪些类型的NoSQL数据库，请说出这些数据库的典型产品，以及每个类型的NoSQL数据库的适用场景 NoSQL： Not Only SQL 键值（key-value）数据库 Redis、Riak、Memcached 适用场景： 用来存储用户信息，比如会员、配置文件、参数、购物车等 文档（Document-Oriented）类型 MongoDB CouchDB RavenDB 适用场景： 日志、分析数据 列存储数据库 HBase Cassandra 适用场景： 日志、博客平
近期正在探索前端、后端、系统端各类常用组件与工具，对其一些常见的组件进行再次整理一下，形成标准化组件专题，后续该专题将包含各类语言中的一些常用组件。欢迎大家进行持续关注。
你有一个新软件产品的想法，你已经完成了你的研究，创建了一个受众并承诺每个人都会解决这个问题。在下文中，我将为您提供一个经过验证的清单和构建 SaaS 的最佳实践。 如今，我们有无数的工具来构建软件。从编程语言、框架和云平台到 nocode 应用程序构建器。此外，市场上充斥着各种提高用户期望的 SaaS 产品。 定义核心 因为竞争如此激烈，你不能不断地重新发明轮子。相反，您的主要目标应该是尽快掌握核心功能。 但核心功能究竟是什么？假设您想创建一个新的送餐应用程序。除非您创建一种新的独特的用户身份验证方式
AI 研习社消息：近日，国外知名 IT 技术媒体 Jaxenter 进行了数据库观点调查，对开发者眼中数据库领域最热门的话题、最热门的数据存储以及处理工具进行统计汇总。 调研的目标，是观察 2017 数据库大趋势。 █ 数据处理——2017 调研的第二名 Jaxenter 的调查问卷，从询问调查对象对泛数据库领域的兴趣点开始。根据调查结果，数据处理是今年的一大热门主题。如同下面的柱状图，NoSQL 和 SQL 数据库都在调查参与者最受关注话题的前列。 如果我们把对特定选项“感兴趣”和“很感兴趣”的回答数目综
Elasticsearch 是一个建立在全文搜索引擎 Apache Lucene(TM) 基础上的搜索引擎，可以说 Lucene 是当今最先进，最高效的全功能开源搜索引擎框架。
来源: MoienTajik/AspNetCore-Developer-Roadmap.
在静态索引这块，RavenDb其实的是lucene，所以里面有很多概念，其实都是lucene本身的。 1.定义静态Indexes documentStore.DatabaseCommands.PutIndex( "BlogPosts/PostsCountByTag", new IndexDefinitionBuilder<BlogPost, BlogTagPostsCount> { // The Map function: for each tag of each
在选择数据库时，最大的决策之一是选择关系（SQL）或非关系（NoSQL）数据结构。虽然两者都是可行的选择，但在做出决定时必须牢记两者之间存在某些关键差异。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
即时通信 IM
