解析如何利用ElasticSearch和Redis检索和存储十亿信息_夜-feng的博客-CSDN博客_elasticsearch 和redis
解析如何利用ElasticSearch和Redis检索和存储十亿信息
夜-feng
于 2016-04-25 12:13:08 发布
11890
收藏
分类专栏：
elasticSearch
文章标签：
elasticsearch
elasticSearch
专栏收录该内容
7 篇文章
0 订阅
订阅专栏
如果从企业应用的生存率来看，选择企业团队信息作为主要业务，HipChat的起点绝非主流；但是如果从赚钱的角度上看，企业市场的高收益确实值得任何公司追逐，这也正是像JIRA和Confluence这样的智能工具制造商Atlassian于2012年收购HipChat的原因。
同时，或许你不知道的是，在Atlassian资源和人脉的帮助下，HipChat已经进入了一个指数增长周期。12亿的信息存储意味着他们现在每隔几个月的信息发送、存储和索引量都会翻一番。
如此快速的增长给曾经充足的基础设施带来了很大的压力，HipChat给我们展示了一个通用的扩展思路。从简单开始，经历流量高峰，然后思考现在怎么办？使用更大的计算机通常是第一个和最好的答案，他们也是这样做的。这给了他们一些喘息空间去考虑下一步怎么做。在AWS上，在某一个拐点之后，你开始走向云特性，也就是横向扩展，这就是HipChat所做的事情。
然而HipChat的发展也并未是顺风顺水，安全性的担忧推动了HipChat的云（SaaS）版本之外内部部署版本的发展。
即使HipChat没有谷歌那么大规模，我们仍能从中学到好东西，比如他们如何及时索引和搜索十亿信息，这也是IRC之类和HipChat之间的关键区别。在负载下索引和存储信息，丢失信息是一个艰巨的挑战。
这是HipChat选择的路，我们一起展开……
统计
每秒60条消息 12亿文档存储 4TB的EBS RAID 在AWS上8个ElasticSearch服务器 26个前端代理服务器，是后端应用服务器的一倍 18个人 0.5TB的搜索数据
平台
主机：AWS EC2 East上的75个实例全部使用Ubuntu 12.04 LTS  数据库：目前用于聊天记录的CouchDB，过渡到ElasticSearch。MySQL-RDS用于其它的一切 缓存：Redis 搜索：ElasticSearch 队列/Worker 服务器：Gearman（队列），Curler（Worker） 语言：Twisted Python（XMPP Server）和PHP（Web前端） 系统配置：开源Chef+Fabric 代码部署：Capistrano 监控：Sensu和monit将警告抽送至Pagerduty 图：statsd + Graphite
产品
流量突发。在周末和假期将是安静的。在高峰负荷期间每秒有几百个请求。实际上占用大部分流量的并不是聊天信息，而是状态信息（away、idle、available），人们连接/断开等。因此每秒60条消息似乎很少，但是它只是一个平均水平。 通知中心HipChat，在这里与团队合作，并得到来自工具和其他系统的所有信息。有助于使每个人都在消息圈内，特别是远程办公。 使用HipChat而不是IRC之类，很大的原因是HipChat存储和索引每一次对话，以便你以后搜索它们。强调搜索，这个特性的好处是你可以在任何时候做回溯，了解发生了什么和同意了什么。如果在发送一条信息时，你的设备无法访问，它也会将消息路由到同一个用户的多台设备中，并做临时消息缓存/重试。 更多的用户带来更快的增长，他们在各个方面使用产品而带来的更多预定，也可以从他们的API集成中看到增长。 存储和搜索信息是系统中主要的可扩展性瓶颈。 HipChat使用XMPP协议，因此任何XMPP客户端都可以连接到系统中，这点非常有利于采用。他们已经建立了自己的本地客户端（Window、Linux、Mac、iOS、Android），并带有类似PDF浏览、自定义表情符号、自动用户注册等扩展。 在以前，将Wiki这样的工具引入到企业文化是几乎不可能的。现在，企业级的工具多已在企业落脚，这是为什么？
基于文本通信已被广泛接受。我们有短信、IM和Skype的形式，所以现在使用聊天工具是自然的事情。 异地工作模式的崛起。团队越来越分散，我们不能只是坐在一起进行一个讲座，一切文档化的需要意味着组织通信将有一笔巨大的财富。 增强的功能。把像内嵌图片、GIF动画等功能做得生动有趣，会吸引更广泛的群体。
HipChat有一个API，这使得它可以编写类似IRC bots这样的工具。例如使用Bitbucket提交——在10:08开发者X提交一些代码来修复一个漏洞。代码发送通过HipChat直接连接到代码提交和提交日志，完全的自动化。Bitbucket提交会击中一个web hook，并使用一个addons来张贴信息。Addons帮助编写bots，转入你的Bitbucket账户。比如我有我的API令牌，我想在每次提交发生时张贴到这个API上，工作原理类似GitHub。 在客户端Adobe Air启动时，内存泄露会导致宕机，因此将其移动到本地应用上。这是个麻烦，也是机遇。同一个公司中都存在许多跨平台跨部门的用户，你需要站在用户的角度思考。希望用户在所有的系统中都有很好的体验，用户不仅仅是技术人员。
XMPP服务器架构
HipChat是基于XMPP协议的，XMPP节里的内容就是消息，可能是一行文本或者日志输出的长段等等。他们不想谈论自己的XMPP架构，所以没有很多的细节。 他们没有使用第三方的XMPP服务器，而是利用Twisted Python和XMPP库建立了自己的服务器。这使得可以创建一个可扩展的后端、用户管理，并轻松的添加功能而不用在其它代码库上修改。 AWS上的RDS用于用户身份验证和其它使用事务及SQL的地方。这是一个稳定、成熟的技术。对于内部部署的产品，则使用MariaDB。 Redis用于缓存。信息，如哪些用户在哪些房间，状态信息，谁在线等都是信息。所以，你连接的是哪个XMPP服务器并不重要，XMPP服务器本身并不是一个限制。
痛点是Redis（还）没有集群，因此使用了高可用性的hot/cold模式，所以，一个从属节点已经准备就绪。故障转移从主节点到从属节点大概需要7分钟，从属节点的发布是手动的，不是自动的。
提高负载可以发现代理服务器中的弱点所在，也可以清楚能支撑多少个客户端。
这是一个真正的问题，正如不丢失信息是一个很大的优势。显而易见，不丢失信息比低延迟更重要——用户更愿意晚点接收信息，而不是根本没有信息。 使用6个XMPP服务器系统运作良好，然而随着连接点的增加，他们开始看到不可接受的延迟。连接不仅来自客户端，还来自bots支持他们的程序设计界面。 在第一遍的时候，他们分离出前端服务器和应用服务器。代理服务器处理连接，后端应用程序处理的stanza。前端服务器数量由有效收听客户数量驱动，而不是由信息发送数量驱动。保持那么多的连接打开，同时提供及时的服务是一个挑战。 修复数据存储问题之后的计划是调查如何优化连接管理。Twisted的效果很好，但是他们有很多的连接，所以必须弄清楚如何更好地处理这些连接。
存储架构
向HipChat发送的消息已达10亿条，同时还在不停增长，他们将CouchDB和Lucene对存储和搜索信息的解决方案推向极限。
认为Redis将会是故障点，而Couch/Lucene会足够好。没有做合适的容量计划和查看信息增长率。增长速度比他们想象的更快，不应该集中那么多精力在Redis上，而应该专注于数据存储。 当时他们相信通过增加容量来扩展，向上移动到越来越大的亚马逊实例。他们发现一点，随着不断地增长，他们利用这种方法只能再工作两个月。所以，他们不得不采用其他的办法。 Couch/Lucene超过一年没有更新，它不能做分类。这是采用其他办法的另一个原因。
在亚马逊上大约10亿消息的一半是一个临界点。用一个专用的服务器和200G的RAM，他们之前的架构可能仍能工作，但在有限资源的云上就不能工作了。 他们想留在亚马逊。
喜欢AWS的灵活性，性能的添加只需要通过租用实例完成。 亚马逊的片状。不要把你所有的鸡蛋都放到一个篮子里，如果一个节点出现故障，你必须要处理它，否则一些用户将会失去流量。 使用动态模型。可以快速关闭一个实例，并带来新的实例。云原生类型的东西。可以随时关闭节点。关闭一个Redis主节点，可以在5分钟内恢复。目前美国东岸分割4个可用地区，但是还没有多区域。 EBS只让你拥有1TB的数据。在遇到之前，他们并不知道这个限制。使用Couch时他们遇到了EBS磁盘大小限制。HipChat的数据是0.5TB。为了压缩，Couch必须将数据复制到有双倍容量的压缩文件中。2TB的RAID在周末压缩过程中遇到了限制，不想使用RAID解决方案。
不选择亚马逊的DynamoDB，因为他们创建了一个HipChat服务器，在防火墙后面的托管服务。
HipChat服务器驱动技术堆栈的决定。私人版是建立在自己主机上的解决方案。某些客户不能使用云/SaaS解决方案，比如银行和金融机构，国家安全局已经吓坏了国际客户，因此聘请了两名工程师创建产品的安装版本。 Redis集群可以自托管，也可以像ElasticSearch那样工作在AWS上。在内部部署版本中他们使用MariaDB，而不是RDS。 不能考虑一个完整的SaaS解决方案，因为那会是一个锁定。
现在过渡到ElasticSearch
移动到ElasticSearch作为他们的存储和搜索后端，因为它可以储存他们的所有数据，它是高度可用的，它可以通过简单增加更多的节进行扩展，它是多用户的，它可以通过分区和复制透明的处理节点损失，并且它建立在Lucene之上。 并不真的需要一个MapReduce功能。看着BigCouch和Riak的搜索（表现一般），但ES在GET上的表现是相当不错的。喜欢坏了就扔，省去了故障检测。 ES HA已令他们在系统的坚固性上感到非常有信心。 Lucene的兼容是一个巨大的胜利，因为所有的查询都已经兼容Lucene，因此它是一个自然的迁移路径。 客户数据是相当多样的，从聊天记录到图像响应类型的差别也随处可见，他们需要能够快速地直接从12亿文档中查询数据。 此举正变得越来越普遍，HipChat也使用ElasticSearch作为他们的key-value存储，减少需要数据库系统的数量，从而降低整体的复杂性。既然性能和响应时间都不错，那完全没有不用的理由。 10ms到100ms的响应时间。在没有任何缓存的情况下，某些领域仍然超过Couch。那为什么还要用多个工具？ 使用ES，一个节点故障不会引起任何人的注意。在它再平衡时你会得到CPU使用率过高的警报，但是系统仍然运行。 用8个ES去处理流量的增长。 基于Java的产品JVM调整可能非常棘手。
要使用ES，必须有堆空间容量计划。 测试缓存。ES可以缓存过滤结果，这是非常快速的，但是你需要很大的堆空间。虽然8个主机拥有22G的内存，但还会随着缓存的打开被耗尽。所以如果不需要就关闭缓存。 缓存有问题，因为它会遇到内存不足的错误然后失败。集群会在几分钟内恢复，只有少数用户会注意到这个问题。
因为网络的不可靠，Amazon的故障转移也可能存在问题。在集群中可能会引起错误的选举发生。
使用ElasticSearch会遇到这些问题。原本有6个ES节点作为主节点选举运行，一个节点可能会耗尽内存或者遇到一个GC暂停并在网络中丢失。那么其他人就不会看到这个主节点，进行选举，并宣布自己是主节点。他们选举架构中的缺陷是他们不需要法定人数。因此就会出现Split Brain问题，从而引起很多问题。 解决方案是在专用的节点上运行ElasticSearch主节点，那么需要做的事情就是成为主节点，从而避免了后续问题。主节点处理分片的分配是完成，谁是主要的，并且完成复制分片分布图。实现再平衡要容易的多，因为主节点可以性能优良的处理所有的再平衡。可以查询任何节点，并会做内部路由。
使用月索引，每个月是一个单独的索引。每个初级索引有8个分片，然后有两个副本。如果一个节点丢失，系统仍能工作。 不要把RDS移动到ES中。需要使用SQL的数据一般储存在RDS/MariaDB中，典型的是用户管理数据。 在Redis集群被释放之前，Redis中大量的缓存是主/从设置。有一个Redis统计服务器，处于离线状态。Redis历史缓存的最后75条消息，用于防止在第一次加载对话时不间断的访问数据库。也有内部状态或快速数据的状态，比如登入用户数量。
常规
Gearman用于异步工作，比如iOS的推送和传递电子邮件。 AWS West用于灾难恢复，一切都会备份到AWS West。 Chef用于所有配置。ElasticSearch有一个很好的Chef手册，轻松上手。像Chef，因为你可以开始写Ruby代码而不是使用Puppet风格的DSL，它也有一个很好的活跃的社群。 收购经验。他们现在已经进入公司的核心资产和人才，但Atlassian不干扰工作，之所以相信，是有原因的。可以在内部要求，例如，如何扩大ElasticSearch ，当别人在Atlassian需要帮助时，他们可以加入帮忙的队伍。良好的整体体验。 扁平的团队结构。仍然是一个小团队，目前大约有18人。两个人在DEVOPS，少数平台，IOS、Android的开发人员在服务器端，一个Web开发工程师（在法国）。 Capistrano用于部署所有的主机。 Sensu用于监控应用程序。让你无需监视堆空间ElasticSearch节点，然后在没有任何通知的情况下解决OOM问题。目前堆的使用率为75％，这正是他们想要的状态。 Bamboo用于持续集成。 客户端版本还不正规，开发者驱动，有一个临时区域进行测试。 集团标志。可以控制哪些群体得到了一个功能、测试特性能及缓慢释放特性，除此之外还能帮助控制主机的负载。 功能标志。有利于ElasticSearch部署过程中的保护。例如，如果他们发现一个漏洞，他们可以关闭一个功能，并回去找Couch。用户不会注意到差别。在Couch和ElasticSearch之间的过渡阶段，他们都有应用复制到两个存储。 新的API版本将使用Oauth，因此，开发人员可以使用HipChat API在自己的服务器上部署。有客户使用自己的服务器是一个更具扩展性的模式。
未来
未来几个月将会达到20亿条消息，估计ElasticSearch可以处理大约20亿条消息。不确定如何处理负载的预期增长。预计要到Amazon West以获得数据心更多的的可用性和可能在不同的数据中心投入更多的用户。 AWS自动扩展能力 移动到语音，私人一对一视频、音频聊天、基本的会议 将来可能使用RabbitMQ来传递消息 与Confluence更大的集成。使用HipChat聊天，然后使用Confluence页面来捕捉细节。
经验教训
1. 企业应用程序是摇钱树。卖入一个企业是很痛苦的，销售周期长意味着太多的不确定性。但是如果你成功卖出，那就会获得丰厚的利润，所以你应该考虑企业市场。时代在变，企业却可能是滞后的，但是他们仍然采用新工具和新的做事方式，这其中就有机会。
2. 隐私在产品给企业推销时变得越来越重要，它会直接影响到产品的选择与否。HipChat正在做他们产品的备用版本，以使那些不相信公共网络的客户满意。对于一个程序员来说，云作为一个平台非常有意义。对于一个企业来说，云可以是魔鬼。这意味着你必须做出灵活的技术堆栈选择。如果你在服务上100%依靠AWS，那你的系统移动到另一个数据中心将变得几乎不可能。这对Netfix也许并不重要，但是如果你想卖入企业市场，它就很重要了。
3. 纵向扩展以获得喘息的空间。当你等待弄清楚架构中下一步要做什么的时候，可以花很少的钱去纵向扩展，给自己几个月的喘息之机。
4. 选择不会失败的。HipChat做出了不会丢失用户聊天记录优先级，所以他们的架构将这个优先级反映给保存聊天记录到磁盘，在宕掉后系统恢复时会重新加载。
5. 进入本地。你的客户在许多不同的平台上，一个本地的应用将会提供最好的体验。对于一个初创公司，那是很多的资源，太多了。所以，卖给拥有更多资源的公司在某种程度上是说得通的，这样你可以建立更好的产品。
6. 功能和群组标志做出更好地发布惯例。如果你可以选择哪些组看到一个功能，如果你能在生产和测试中关闭功能，那么你就不用担心发布新的构建项目了。
7. 选择你真正自信的技术。ElasticSearch应对增长的横向扩展能力让HipChat很放心，同样也会有一个很好的用户体验，这才是最重要的。
8. 成为该流程的一部分，你变得更有价值，难以消除。HipChat作为人和工具之间的天然契合点，也是来编写实现各种有用工作流bots的天然点。这使得HipChat在企业中有发挥的平台，它使本来不可建造的功能得以实现。如果你能做到同样的事情，那么大家都会很需要你。
9. AWS需要在总线上存在一个单独的节点，这个要求看起来有点荒谬，但是在云环境下却非常重要，因为机器可用信息在第三方目的源中并不可见。如果着眼机架就会发现它经常有一个单独存在的总线插槽，如果其他插槽可用，他就会知道。这样，你就不必去猜测。在云中，软件采用基于原始TCP的连接技术和心跳，去猜测另一个节点是否发生故障，从而导致Split Brain问题及启用备库时产生数据丢失。这需要时间去演变，到达完全可靠还需要迈一大步。
10. 产品决策驱动堆栈的决定，HipChat服务器驱动技术堆栈的决定：Redis集群可以自托管；不选择亚马逊的DynamoDB，是因为HipChat在防火墙的后面创建一个托管服务。
11. 你需要打开视野。你需要容量规划，即使是在云中。除非你的架构从一开始就完全是原生云，否则任何架构都会有负荷的拐点，在拐点他们的架构将不再能够处理负载。看看增长速度，项目出来了。会打破什么？你将会做什么？而且不要再犯同样的错误。HipChat将如何处理40亿条消息？当下还无法知晓。
12. 了解系统的限制。EBS有1TB的存储限制，这是很大的限制，但如果你的存储已接近那个限制，就需要有一个计划了。同样，如果你的数据库，例如Couch，在压缩阶段要使用双倍的磁盘空间，那将会影响你的系统限制。
13. 这个世界会令你大吃一惊。六个月前HipChat认为Redis将会是最弱的环节，但现在它依旧很强壮，而Couch和EBS才是最薄弱的环节。
夜-feng
关注
关注
点赞
收藏
评论
解析如何利用ElasticSearch和Redis检索和存储十亿信息
如果从企业应用的生存率来看，选择企业团队信息作为主要业务，HipChat的起点绝非主流；但是如果从赚钱的角度上看，企业市场的高收益确实值得任何公司追逐，这也正是像JIRA和Confluence这样的智能工具制造商Atlassian于2012年收购HipChat的原因。同时，或许你不知道的是，在Atlassian资源和人脉的帮助下，HipChat已经进入了一个指数增长周期。12亿的信息存储意
复制链接
扫一扫
专栏目录
聊聊redis和Elasticsearch
小叶曲
06-21
5136
redis和Elasticsearch比较
项目
Redis
Elasticsearch
介绍
Redis是内存中的数据结构存储，用作数据库，缓存和消息代理
Elasticsearch是一个基于Apache Lucene的现代搜索和分析引擎
主数据库模型
键值存储
搜索引擎
DB-Engines排名
得分120.41总排名第9，key－value存储排名第7
得分120.00总排名第10，搜索引擎排名第1
网站
redis.io
redis，mysql，elasticsearch，hbase，hive对比区别，该如何选择
迷途的菜鸟
12-26
3354
几种数据库对比如下：
redis
mysql
elasticsearch
hbase
hive
容量/容量扩展
海量
海量
查询时效性
极高
中等
较高
较高
查询灵活性
较差
非常好
较好
较差
非常好
写入速度
极快
中等
...
参与评论
您还未登录，请先
登录
后发表或查看评论
spring boot2.0 + elasticsearch+ redis
04-28
spring boot2.0 + elasticsearch+ redis 遇到elasticsearch执行不成功
Elasticsearch 缓存深度剖析：一次提高一种缓存的查询速度
最新发布
勿忘初心
11-16
125
Elasticsearch 缓存深度剖析：一次提高一种缓存的查询速度
利用ElasticSearch和Redis检索和存储十亿信息
水木米
01-18
2601
本文来自Zuhaib Siddique的一次专访，Zuhaib是群聊IM制造商HipChat的生产工程师，下面我们一起看Tod Hoff的整理。
以下为译文：
如果从企业应用的生存率来看，选择企业团队信息作为主要业务，HipChat的起点绝非主流；但是如果从赚钱的角度上看，企业市场的高收益确实值得任何公司追逐，这也正是像JIRA和Confluence这样的智能工具制造商Atlassia
2021-06-26使用redis作为缓存，数据还需要存入数据库中吗？（转）
qq_43164098的博客
06-26
421
转自https://blog.csdn.net/wypersist/article/details/79955704
redis是一个key-value存储系统。和Memcached类似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sorted set --有序集合)和hash（哈希类型）。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上，redis支持各种不同方式的
Redis只能做缓存？太out了！
黑帽子技术的博客
07-28
114
Redis只能做缓存？...
转 redis使用场景 简介
weixin_33913377的博客
06-14
48
Redis实战（五） 聊聊Redis使用场景发表于 2016-11-21 | 数据存储 | Redis文章目录1. 使用场景说明1.1. 计数器1.2. 排行榜1.3. 用于存储时间戳1.4. 记录用户判定信息1.5. 社交列表1.6. 缓存1.7. 队列1.8. 会话缓存2. 业务使用方式随着数据量的增长，MySQL已经满足不了大型互联网类应用的需求，因此，Redis作为内存数据库，很好的作为其...
redis缓存数据后，对接口的访问速度提升到底有多高
qq_30434271的博客
12-18
456
今天做了个简单测试，记录下redis对数据缓存后的访问速度提升到底是多少，以下图四个键作为测试对象，看下图：
首先redis没有任何缓存
进行第一次接口调用，看接口执行时间如下：
基本是保持在55ms上下，此时redis中已有缓存：
再次调用接口，直接从redis中获取数据，看接口执行时间如下：
稳定在25ms上下，可以看出还是有明显提升的。
博主测试接口的数据是很简单的，对于数据量比较大时，对比会更明显，当然redis的提升也是有上限的，最大支持存储键值对分别只有512M，re
我为什么用ES做Redis监控，不用Prometheus或Zabbix？
架构师小秘圈
05-16
568
本文根据李猛老师在〖deeplus直播第220期〗线上分享演讲内容整理而成。李猛数据技术专家Elastic-Stack产品深度用户，ES认证工程师，对Elastic-Stack开发、架构...
Elasticsearch对于大数据量（上亿量级）的聚合如何实现？
学一次的博客
07-04
318
Elasticsearch 提供的首个近似聚合是cardinality 度量。它提供一个字段的基数，即该字段的distinct或者unique值的数目。它是基于HLL算法的。HLL 会先对我们的输入作哈希运算，然后根据哈希运算的结果中的 bits 做概率估算从而得到基数。其特点是：可配置的精度，用来控制内存的使用（更精确 ＝ 更多内存）；小的数据集精度是非常高的；我们可以通过配置参数，来设置去重需要的固定内存使用量。无论数千还是数十亿的唯一值，内存使用量只与你配置的精确度相关。...
【Elasticsearch】搜索基准测试：RediSearch 与 Elasticsearch
九师兄
06-14
701
1.概述
翻译:https://redislabs.com/blog/search-benchmarking-redisearch-vs-elasticsearch/?utm_source=dlvr.it&utm_medium=twitter
背景
RediSearch 是一个分布式全文搜索和聚合引擎，作为模块构建在 Redis 之上。它使用户能够以极快的方式对其 Redis 数据集执行复杂的搜索查询。 RediSearch 的独特架构是用 C 语言编写的，并基于优化的数据结构从头开始构建，使其成.
用redis实现的search engine:对标 elasticSearch, solr
jupiter_888的博客
12-01
118
https://redislabs.com/blog/adding-search-engine-redis-adventures-module-land/
https://github.com/RedisLabsModules/RediSearch
MongoDB、ElasticSearch、Redis、HBase这四种热门数据库的优缺点及应用场景
qq_31236849的博客
06-10
917
MongoDB、ElasticSearch、Redis、HBase这四种热门数据库的优缺点及应用场景
RedisJson发布官方性能报告，性能碾压ES和Mongo
xiangzhihong8的专栏
11-25
4395
一、概述
近期官网给出了RedisJson（RedisSearch）的性能测试报告，可谓碾压其他NoSQL，下面是核心的报告内容，先上结论：
对于隔离写入(isolated writes)，RedisJSON 比 MongoDB 快 5.4 倍，比 ElasticSearch 快 200 倍以上。
对于隔离读取(isolated reads)，RedisJSON 比 MongoDB 快 12.7 倍，比 ElasticSearch 快 500 倍以上。
在混合工作负载场景中，实时更新不会影响 Redis
会话存档-如何高性能存储海量聊天记录
孔明的博客
02-26
3609
场景
每天大约500w条数据，存档消息，并对消息进行统计分析。
大概计算一下：
每天的工作时间是8小时，大约是8小时处理400w条数据就足够了，为避免某时刻的峰值超负荷，还按照8小时处理500w条数据的标准来搭建环境；每秒钟大概要处理180条数据；
客户提供了3台应用服务器（8核16G），单台机器每秒需处理60条数据
每条消息（不考虑文件等消息，只考虑文本）平均大小为1kb，每天大约产生5个G的数据
思路
需求已经提出来了，只做其中的一个功能，就是获取消息，保存数据（数据查询、分析是其他需求）；
企业微
Elasticsearch+Hbase实现海量数据秒回查询
yshir
11-22
382
一、ElasticSearch和Hbase
ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。Elasticsearch是用Java开发的，并作为Apache许可条款下的开放源码发布，是当前流行的企业级搜索引擎。设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。Elasticsearch的性能是solr的50倍。
HBase – Hadoop Database，是一个高可靠性、高性能、面向列、可伸缩.
elasticsearch 单索引 6T 20亿 数据搜索实战与优化深度思考
Angus
01-20
1912
我负责公司的检索平台的开发兼运维工作。
我们的场景是对互联网上的设备数据进行检索。数据量大概有20亿，对应的存储量大概有6T（不带副本的情况下）。单条数据会有上百个字段，用来刻画网络设备画像。
我们有比较特殊的需求：
我们有频繁更新的需求，每天几千万，甚至上亿。
我们并不能做根据时间的滚动索引。因为后进的数据需要把前边的数据做覆盖。所以就没有办法做索引的生命周期管理。
我们有频繁的聚类搜索的需求。
我们想要基于这些数据，做到普通检索1秒以内，聚类检索3秒以内。
写这篇文章的...
ElasticSearch实战之千万级TPS写入
ytp552200ytp的博客
08-18
999
1.如何发现写入瓶颈？
2.哪几个因素会造成长尾问题？
3.如何消除分布式的长尾问题？1. 背景前段时间，为了降低用户使用ElasticSearch的存储成本，我们做了数据的冷热分离。为了保持集群磁盘利用率不变，我们减少了热节点数量。ElasticSearch集群开始出现写入瓶颈，节点产生大量的写入rejected，大量从kafka同步的数据出现写入延迟。我们深入分析写入瓶颈，找到了突破点，最终将Elasticsearch的写入性能提升一倍以上，解决了ElasticSearch瓶颈导致的写入延迟。这篇文章介
Maven 项目集成 Elasticsearch 和 Redis
一线大码
05-04
1580
文章目录1. 集成 Elasticsearch1.1. 依赖1.2. 配置1.2.1. 配置文件1.2.2. 配置类1.3. 使用2. 集成 Redis2.1. 依赖2.2. 配置2.2.1. 配置文件2.2.1.1. 单机配置2.2.1.2. 哨兵配置2.2.2. 配置类2.3. 使用
这是一个普通 Maven 项目，不是 Spring 或 SpringBoot 项目。
下面都用到了这个工具类：
package com.gtcom.search.util;
import com.gtcom.searc
elasticsearch个人学习总结,elasticsearch出现的原因,与其他数据库技术的对比以及elasticsearch的适用场景,实现原理
love_yr的博客
12-21
1524
elasticsearch基本概述
elasticsearch出现的原因
elasticsearch与其他数据库技术的对比(优缺点)
elasticsearch的适用场景
elasticsearch的实现原理
使用elasticsearch可能出现的问题(避免或解决方法)
...
“相关推荐”对你有帮助么？
非常没帮助
没帮助
一般
有帮助
非常有帮助
提交
©️2022 CSDN
皮肤主题：大白
设计师：CSDN官方博客
返回首页
夜-feng
CSDN认证博客专家
CSDN认证企业博客
码龄9年
暂无认证
原创
19万+
周排名
196万+
总排名
35万+
访问
等级
3441
积分
30
粉丝
33
获赞
25
评论
112
收藏
私信
关注
热门文章
微信支付H5调用支付详解
33717
Java 8：CompletableFuture终极指南
16380
Spring 表达式语言之 SpEL 语法
13992
Python 3.x中maketrans和translate用法
13923
Spring 中一个常用的反射类库ReflectionUtils
12650
分类专栏
程序员
7篇
数据库
5篇
C#
4篇
数据结构
1篇
Python
8篇
设计模式
6篇
C语言
3篇
正则表达式
1篇
Linux
9篇
JAVA
38篇
Spring
15篇
distributed system
3篇
elasticSearch
7篇
ObjectiveC-IOS
34篇
支付宝微信
4篇
Nginx
1篇
最新评论
iOS7 Networking with NSURLSession
m0_55543417:
cg
JVM参数配置总结
小甜甜️:
帮个忙
JVM参数配置总结
小甜甜️:
会数据爬取吗
微信支付H5调用支付详解
豆皮没有豆:
你好，微信h5支付访问mweb_url显示空白页面啥原因？如何解决？
Python 3.x中maketrans和translate用法
氵苦小瓜:
print(b'http://www.csdn.net/wirelessqa'.translate(None, b'ts'))这个b'http和b'ts'的b是用来干嘛的
您愿意向朋友推荐“博客详情页”吗？
强烈不推荐
不推荐
一般般
推荐
强烈推荐
提交
最新文章
Java开发者常犯的10个错误
Java 并发工具包 java.util.concurrent 用户指南
Java虚拟机详解----常用JVM配置参数
2017年2篇
2016年80篇
2015年34篇
2014年27篇
目录
目录
分类专栏
程序员
7篇
数据库
5篇
C#
4篇
数据结构
1篇
Python
8篇
设计模式
6篇
C语言
3篇
正则表达式
1篇
Linux
9篇
JAVA
38篇
Spring
15篇
distributed system
3篇
elasticSearch
7篇
ObjectiveC-IOS
34篇
支付宝微信
4篇
Nginx
1篇
目录
评论
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
查看更多评论
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额
抵扣说明：
1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。 2.余额无法直接购买下载，可以购买VIP、C币套餐、付费专栏及课程。
余额充值