elasticsearch的使用场景 按照id查询，mysql、es、hbase三个哪个更快？

按照id查询，mysql、es、hbase三个哪个更快？就我而言，没有场景的速度测试是无赖的。根据需求场景优化数据库和选择数据库前后的速度肯定是不同的。如果在一般情况下只有一个ID索引，这意味着您需要

按照id查询，mysql、es、hbase三个哪个更快？

就我而言，没有场景的速度测试是无赖的。根据需求场景优化数据库和选择数据库前后的速度肯定是不同的。

如果在一般情况下只有一个ID索引，这意味着您需要通过此ID定位数据，那么MySQL是最快的。毫无疑问。

在非结构化文档中，ES是最快的，数据量越大，速度就越快，因为ES是NoSQL非关系数据库，没有事务处理能力。然而，ES作为一种基于Lucence服务器的全文搜索服务，非常适合于全文搜索。然而，ES一般用于复杂多变的检索环境，单一的ID不能反映ES的性能。

对于大规模数据，HBase绝对是根据范围读写数据的最佳选择，它为大规模数据场景提供了更好的可扩展性。

。我会在这里发表所有有关科技的有趣文章。偶尔，我能回答一些有趣的问题。如果您有任何问题，可以随时在评论区回复和讨论。

可否完全使用ElasticSearch代替数据库存储？

我们使用elasticsearch存储了近50亿个文档（包括1个副本，近100亿个文档），共有10个数据节点和2个元数据节点（48gb内存，8核CPU，ES占用70%内存），每天文档增量约3000W（速度

持续增长）。目前单个文档的查询效率基本处于实时状态；对于1到2周数据的聚合统计操作，结果也可以在10秒内返回。

但是对于查询单个数据的应用场景还有改进的空间，我们可以使用ES的路由机制，将所有具有相同特征（如相同的userid）的文档存储在一个节点的同一索引中，这样我们后续的查询就可以直接定位在这个节点上，而不是将查询广播到所有节点上；

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

]我觉得弹性搜索是可行的适合内部存储，效率基本可以满足。在某些方面也可以取代传统的数据库，前提是您的业务不具备可操作性

]特殊要求；而且由于ES权限不完善，权限管理也不太详细。因为我们对于ES的应用场景只是在一定的时间段内聚合数据，并且没有大量的单文件请求（比如通过userid找到用户的文档，类似于NoSQL的应用场景），它是否能取代NoSQL还需要自己的测试。如果我有选择的话，我

会尝试使用es而不是传统的NoSQL，因为它的水平扩展机制太方便了。

es可以替代数据库吗？

Es更注重近实时搜索。数据库更加注重数据的存储和查询。两种场景的使用是不同的，我们不能说谁代替谁。