关于nosqlsearch的信息

为什么需要elasticsearch做cassandra的索引

我正在学习NoSQL，并正在为客户的需求之一寻找不同的选择。在提出这个问题之前，我已经遍历了各种资源（对NoSQL不太了解的人）

网站建设哪家好，找创新互联！专注于网页设计、网站建设、微信开发、重庆小程序开发、集团企业网站建设等服务项目。为回馈新老客户创新互联还提供了芦溪免费建站欢迎大家使用！

我需要以更快的速度存储数据并读取数据。

完全故障安全且易于扩展。

能够搜索数据以获取Google Analytics（分析）。

最后我列出了以下内容： Cassandra and Elasticsearch

我所了解的是，Cassandra对我来说是一个完美的NoSQL存储解决方案，因为我可以使用索引写入数据和读取数据。它失败或可能失败的地方在Google

Analytics（分析）上。将来，如果我想从中获取数据from_date to to_date，或者想以更多方式获取数据进行分析，如果我没有适当地设计数据模型或保持长期的眼光，那么在不断变化的世界中这可能很难。

While Elastic Search最擅长建立索引（由Lucene支持），并且可以通过抛出一些随机文本来随机搜索数据。但是即使我想检索数据，它是否也一样工作from_date to to_date（我希望是这样）。但是真正的问题是，它是搜索引擎还是像Cassandra这样的完美NoSQL数据存储？如果是，为什么我们仍然需要Cassandra？

如果两者都在不同的世界，请解释一下！我们如何将它们结合起来以获得更有效的解决方案？

什么数据库比较热门？

总体来说，主流数据库并不存在明确的好坏之分，每一种数据库都有各自的优缺点，最主要还是看它是否能够满足您的需求。

总的来说，选择数据库可以从以下角度考虑：

从个人角度出发的话，如果是以学习和小型业务需求为主，推荐使用MySQL，它的优势在于：

成本（免费）

自由（完全开源，适用多个场景）

性能（体积小但速度快）

这三点决定了MySQL数据库的超高性价比。并且目前有不少主流公司仍然青睐MySQL，大名鼎鼎的Fackbook就依然在延续MySQL的使用。

2. 如果是企业角度出发，主流的大型数据库如Oracle、Sql Server...以及近些年来大数据领域十分火热的非关系型数据库，例如Redis、HBse等等，都可以作为考虑的对象。

接下来具体列举一些常用数据库的优缺点，希望能为大家提供参考：

MySQL：

优势：

MySQL是开放源代码的数据库，任何人都可以获得该数据库的源代码。

MySQL能够实现跨平台操作，可以在Windows、UNIX、Linux和Mac OS等操作系统上运行。

MySQL数据库是一款自由软件，大部分应用场景下都是免费使用。

MySQL功能强大且使用方便，社区生态繁荣，有诸多学习资料。

缺点：规模小，功能有限。

SQL Server

高度可扩展：可以从单一的笔记本电脑上运行任何东西或以高倍云服务器网络运行，或在两者之间任何东西。

“虽然说是“任何东西”，但是仍然要满足相关的软件和硬件的要求“

生态链广：具有内置的商务智能工具，以及一系列的分析和报告工具，可以创建数据库、备份、复制，带来了更好的安全性。

Oracle

Oracle数据库系统是目前世界上流行的关系数据库管理系统，具有以下特点：

可移植性好（在各类大、中、小、微机环境中都适用）

使用方便、

功能强

因此，Oracle是一种高效率、可靠性好的、适应高吞吐量的数据库解决方案。

DB2

DB2是IBM开发的一种大型关系型数据库平台。它支持多用户或应用程序在同一条SQL 语句中查询不同database甚至不同DBMS中的数据。它的应用特点如下：

支持面向对象的编程：db2支持复杂的数据结构，如无结构文本对象，可以对无结构文本对象进行布尔匹配、最接近匹配和任意匹配等搜索。可以建立用户数据类型和用户自定义函数。

支持多媒体应用程序：db2支持大二分对象（blob），允许在数据库中存取二进制大对象和文本大对象。其中，二进制大对象可以用来存储多媒体对象。

具有良好的备份和恢复能力

支持存储过程和触发器，用户可以在建表时显示的定义复杂的完整性规则

支持异构分布式数据库访问，支持数据复制

PostgreSQL

PostgreSQL 是一个免费的对象-关系数据库服务器(ORDBMS)，它的 Slogan 是 “世界上最先进的开源关系型数据库”。

PostgreSQL具有如下特征：

函数：通过函数，可以在数据库服务器端执行指令程序。

索引：用户可以自定义索引方法，或使用内置的 B 树，哈希表与 GiST 索引。

触发器：触发器是由SQL语句查询所触发的事件。如：一个INSERT语句可能触发一个检查数据完整性的触发器。触发器通常由INSERT或UPDATE语句触发。 多版本并发控制：PostgreSQL使用多版本并发控制（MVCC，Multiversion concurrency control）系统进行并发控制，该系统向每个用户提供了一个数据库的”快照”，用户在事务内所作的每个修改，对于其他的用户都不可见，直到该事务成功提交。

规则：规则（RULE）允许一个查询能被重写，通常用来实现对视图（VIEW）的操作，如插入（INSERT）、更新（UPDATE）、删除（DELETE）。

数据类型：包括文本、任意精度的数值数组、JSON 数据、枚举类型、XML 数据等。

全文检索：通过 Tsearch2 或 OpenFTS，8.3版本中内嵌 Tsearch2。

NoSQL：JSON，JSONB，XML，HStore 原生支持，至 NoSQL 数据库的外部数据包装器。

数据仓库：能平滑迁移至同属 PostgreSQL 生态的 GreenPlum，DeepGreen，HAWK 等，使用 FDW 进行 ETL

数据库与数据仓库的本质区别是什么?

1、存放值区别：

数据库只存放在当前值，数据仓库存放历史值；

2、数据变化区别：

数据库内数据是动态变化的，只要有业务发生，数据就会被更新，而数据仓库则是静态的历史数据，只能定期添加、刷新；

3、数据结构区别：

数据库中的数据结构比较复杂，有各种结构以适合业务处理系统的需要，而数据仓库中的数据结构则相对简单；

4、访问频率不同：

数据库中数据访问频率较高，但访问量较少，而数据仓库的访问频率低但访问量却很高；

5、目标人群区别：

数据库中数据的目标是面向业务处理人员的，为业务处理人员提供信息处理的支持，而数据仓库则是面向高层管理人员的，为其提供决策支持；

postgreSQL的简单介绍？

postgreSQL是一款先进的开源数据库，拥有非常齐全的自由软件的对象-关系型数据库管理系统（ORDBMS），可面向企业复杂SQL的OLTP业务场景，支持多项企业级功能，能解决使用数据库的各种难题。

PostgreSQL的优势有很多。它是一个免费的对象-关系数据库服务器(ORDBMS)，在灵活的BSD许可证下发行。

postgreSQL的特征

函数：通过函数，可以在数据库服务器端执行指令程序。

索引：用户可以自定义索引方法，或使用内置的 B 树，哈希表与 GiST 索引。

触发器：触发器是由SQL语句查询所触发的事件。如：一个INSERT语句可能触发一个检查数据完整性的触发器。触发器通常由INSERT或UPDATE语句触发。 多版本并发控制：PostgreSQL使用多版本并发控制（MVCC，Multiversion concurrency control）系统进行并发控制，该系统向每个用户提供了一个数据库的"快照"，用户在事务内所作的每个修改，对于其他的用户都不可见，直到该事务成功提交。

规则：规则（RULE）允许一个查询能被重写，通常用来实现对视图（VIEW）的操作，如插入（INSERT）、更新（UPDATE）、删除（DELETE）。

数据类型：包括文本、任意精度的数值数组、JSON 数据、枚举类型、XML 数据等。全文检索：通过 Tsearch2 或 OpenFTS，8.3版本中内嵌 Tsearch2。

NoSQL：JSON，JSONB，XML，HStore 原生支持，至 NoSQL 数据库的外部数据包装器。

数据仓库：能平滑迁移至同属postgreSQL生态的GreenPlum，DeepGreen，HAWK 等，使用 FDW 进行 ETL。

elasticsearch可以代替NoSQL吗

我们使用Elasticsearch存储的文档数量接近50亿（算上1份复制，接近100亿文档），总共10个数据节点和2个元数据节点（48GB内存，8核心CPU，ES使用内存达到70%），每天的文档增量大概是3000W条（速度持续增加中）。目前来看，单个文档的查询效率基本处于实时状态；对于1到2周的数据的聚合统计操作也可以在10秒之内返回结果。

但是，还有提升的空间：

1. 对于查询单条数据的应用场景来说，我们可以使用ES的路由机制，将同一索引内的具有相同特征（比如具有相同的userid）的文档全部存储于一个节点上，这样我们之后的查询都可以直接定位到这个节点上，而不用将查询广播道所有的节点上；

2. 随着数据节点的增加，适当增加分片数量，提升系统的分布水平，也可以通过分而治之的方式优化查询性能；

个人以为Elasticsearch作为内部存储来说还是不错的，效率也基本能够满足，在某些方面替代传统DB也是可以的，前提是你的业务不对操作的事性务有特殊要求；而权限管理也不用那么细，因为ES的权限这块还不完善。由于我们对ES的应用场景仅仅是在于对某段时间内的数据聚合操作，没有大量的单文档请求（比如通过userid来找到一个用户的文档，类似于NoSQL的应用场景），所以能否替代NoSQL还需要各位自己的测试。如果让我选择的话，我会尝试使用ES来替代传统的NoSQL，因为它的横向扩展机制太方便了。