1.1.1 管理文本中心的数据

合理选用同数据匹配的存储及处理引擎，是现代软件应用架构的标志性要求之一。如果你是一个优秀的程序员，那么你应该知道要根据在算法中使用数据的方式来选取最合适的数据结构。比如，如果你需要实现快速随机查找，你就不会使用链表结构来存储数据。同样的道理也适用于搜索引擎的选取。这里列出了适合用类似Solr这样的搜索引擎来处理的数据的4种主要特点：

文本中心的数据

读取远多于写入的数据

面向文档的数据

灵活的Schema

也许在这儿应该加上第五个数据特性，即：海量数的据量，也就是”大数据“，但是我们主要关注的是Solr区别于其他NoSQL技术的主要特性，而可以处理海量的数据并不是它们的主要区别之一。

虽然这里列出了类似Solr这样的搜索引擎可以有效处理的数据类型的4个主要特点，但是这只是一个粗略的准则，并不是一个严格的标准。我们来深入的讨论一下这些数据特性，看看为什么它们对于搜索来说这么重要。我们现在只关注概念，具体的实现细节在稍后的章节讨论。

文本中心的数据

你肯定见过有人用“非结构化数据“这个术语来描述搜索引擎处理的数据。我们认为“非结构化”这个词有些模糊不清，因为任何一个基于人类语言产生的文档都是隐含有一定的结构的。要理解“非结构化”这个术语你可以认为这是从计算机的角度来看的。在计算机眼中，文本文档就是一个字符流。这个字符流必须通过特定的语言规则解析出语义结构，才能被检索到。而这正是搜索引擎的工作所在。

我们认为“文本中心的数据”这个词更适合用来描述Solr处理的数据类型。因为搜索引擎的设计初衷就是用来提取文本数据的隐含结构，并生成相关索引以提高查询检索的效率。“文本中心的数据”这个词隐含表明了文档中的文本信息包含用户感兴趣的查询内容。当然，搜索引擎也支持非文本数据，比如数字类型的数据，但是其主要强项，还是在于处理基于自然语言的文本数据。

前面说的都是“文本”，其实“中心”这个部分也很重要，因为如果你的用户对于文本部分的内容不感兴趣，那么搜索引擎可能就不是处理你的问题的最佳选择。举个例子，对于一个给员工用来创建差旅支出报告的应用，每份报告都包括一些结构化的数据，比如日期，费用类型，汇率，数量等等，另外每项费用后面可能会包含一些备注信息，用于描述该项费用的大致情况。这样一个应用就是一个包含文本信息，但并不是“文本中心的数据”的一个例子，因为会计部门在使用这些员工的支出费用报告来生成月度支出报告时，并不会通过查找备注里的文本信息来做，文本在这里并不是其关心的主要内容。简单来说，就是不是所有包含文本信息的数据都适合搜索引擎来处理。

所以现在先花几分钟好好想想你的数据是否是“文本中心的数据”。考虑的重点主要就是数据中的文本信息用户是不是会拿来做检索。如果答案是YES，那么搜索引擎很可能是一个好的方案选择。我们在第5章和第6章会讨论如何利用Solr的文本分析来提取文本数据的结构的细节。

读取远多于写入的数据:

另外一个搜索引擎可以高效处理的数据特性是“读取远多于写入的数据”。首先，需要声明的是Solr是允许你更新索引中的现有文档内容的。你可以把“读取远多于写入”解读为对于文档的读取操作频率要远远高于创建文档和更新文档的频率。但是别狭隘的理解为你就完全不能写入数据了，或是你会被限制在一个特定频率之下更新数据。事实上Solr4的一个关键特性就是“近乎实时的查询”，这个功能可以允许你每秒钟为数千的文档建立索引并且几乎立刻就能查询到这些新加入的文档。

“读取远多于写入的数据”背后的关键点是你的数据在写入Solr后，在其生命周期内应该是要被重复读取很多次的。你可以理解为搜索引擎并不是主要用来存储数据的，而是主要用于查询存储的数据的（查询请求是一种读取操作）。所以如果你需要很频繁的更新数据，那么搜索引擎可能不太适合你的需求，其他的NoSQL技术，比如Cassandra，可能更适合你的快速随机写入的需求。

面向文档的数据

到目前为止，我们一直使用更通用的“数据”这一术语，但是实际中搜索引擎处理的都是文档数据。在搜索引擎中，一个文档是由值域(field)组成的独立集合，每一个值域都只保存数据值，不能再嵌套包含其他值域。换句话说，在Solr这样的搜索引擎中，文档都是扁平结构的，文档之间不存在相互依赖关系。Solr中“扁平”的概念是比较宽松的，一个值域可以保存多个数据值，但是值域不能再嵌套包含子值域。也就是说你可以在一个值域里存储多个数据值，但是你不能往值域里头嵌套别的值域。

Solr中这种扁平化的、面向文档的方式可以很好的处理已经文档化的数据，比如网页，博客，pdf文档等等。那么如果要用solr来处理关系型数据库中已经结构化好的数据应该怎么办呢？这种情况下你需要先把关系型数据库中跨表存储的数据取出来，去结构化，然后放到扁平化的自包含文档结构里。我们会在第三章学习怎么处理这样的问题。

你还需要考虑你的文档数据中的哪些值域需要存储在Solr中，哪些值域需要存储在其他系统中（比如数据库中）。简单来说，搜索引擎只存储需要被检索到的数据，以及用于显示检索结果的数据。举个例子，如果你有一个在线视频的搜索索引，你应该不会希望把视频文件本身存储在Solr中，合理的方案应该是把大的视频文件都放在内容分发网络（CDN）中。通常你只需要在搜索引擎中存储满足搜索需求的最少数据即可。刚才这个在线视频的例子清楚的说明了不要把Solr当成通用数据存储技术，Solr的工作是找到用户感兴趣的视频文件，而不是存储视频文件本身。

灵活的Schema

最后一个搜索引擎数据的主要特性是有灵活的schema。这意味着查询索引中的文档不需要拥有统一的结构。在关系型数据库中，表中的每一行数据都必须拥有相同的结构。而在Solr中，文档们可以有不同的值域。当然同一个索引中的文档们至少应该拥有一部分大家都有的值域以便于检索，但是并不要求所有文档中的值域结构完全一样。

举个例子，假如要做一个用于查找出租和出售房源的搜索应用。显然每条房源文档都会有地段，房间数，卫生间数等一些共有的值域，但是根据类型是出租还是出售的不同，不同的房源文档会有不同的值域。一条出售的房源会有售价值域，财产税值域，而一条出租的房源文档则会有月租金和宠物政策等等不同的值域。

总结一下，Solr这样的搜索引擎是专门优化用于处理文本中心的，读取远多于写入的，面向文档的，拥有灵活Schema的数据用的。Solr并不是一种通用数据存储处理技术，这也是区别于其他NoSQL技术的主要因素。

有众多不同的数据存储和处理方案可供选择的好处是你不再需要费劲脑汁地寻找一种可以满足所有需求的通用技术方案。搜索引擎在某些特定任务上表现出色，但是在其他一些方面性能很差。这意味着在大多数情况下，你可以用Solr来作为关系型数据库和其他NoSQL技术的有力补充，而并不是要取代后者。

既然我们已经谈到了Solr所针对优化处理的数据类型，那我们就接着来讨论一下像solr这样的搜索引擎主要是设计来解决哪些实际用例的。理解这些用例可以帮助你理解搜索引擎技术是如何区别于其他数据处理技术的。

1.1.2 常见的搜索引擎用例