TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

My laptop is faster than your Elastic cluster

69 点作者 jayhoon大约 1 年前

8 条评论

bane大约 1 年前
I love these as an example of what I&#x27;ve called &quot;scaling deeper&quot;. Elasticsearch is a fabulous technology for a general set of use-cases. But if you can define certain tasks specifically, there&#x27;s often a very fast&#x2F;cheap way to accomplish it outside of the general.<p>I remember a case where we needed to pull all incoming IP addresses for a given 24 hour period for certain common user-facing queries, and the specialized FPGA driven scalable database appliance was returning those queries in minutes. So instead we ran the query once a day, and then just flipped bits in a big bit array (IPv4 is half a GB of bits) and just let each array act as a standing query. A query for a certain day just mapped to a specific file, and some simple math would answer the query 0 for IP never seen 1 for IP seen. It was nearly instant.<p>It transformed a certain team&#x27;s workflow from asking a few times a day for yesterday&#x27;s IP visits to many times a day and then they started asking for the data over a period of months instead to look for patterns. Queries against this structure for the same thing over a year took less than a second. It all ran on a 4GB VM with a few GB of spinning rust storage. Pretty soon this was built into a bunch of custom tools across a bunch of teams and was feeding the data tens of thousands of times per day, then we started enriching it with geodata, reputation data, and other things. It also reduced the query load on the main dB substantially.<p>Very simple engineering, transformative, and required simply trying to find a way to scale deeper instead of building a bigger multimillion dollar dB.
dijit大约 1 年前
Counterpoint: you can run a single node elastic instance (and add more later), and 32G isn’t the size of memory you need, it’s the largest heap on a node you should have. (IE; it’s the sweet spot because more than 30.5GiB of Heap and Java will start using 64bit pointers).<p>50% of your system memory should be Heap, so realistically the sweet spot for VMs is actually 64GiB of memory for each node.<p>I wrote a lot of these best practices as notes years ago: <a href="https:&#x2F;&#x2F;dijit.svbtle.com&#x2F;elasticsearch-notes" rel="nofollow">https:&#x2F;&#x2F;dijit.svbtle.com&#x2F;elasticsearch-notes</a>
wenc大约 1 年前
This is not my lane, but I was looking to fast text search some time ago. I looked into Elastic but it seemed to me it was designed for a scale that I didn&#x27;t need.<p>Then I found projects like Meilisearch and TypeSense (which are in the same class of search software as Algolia) and they&#x27;re so much faster than a standalone Elastic instance.<p>Again, different space from Elastic, but I&#x27;m not sure if most people truly need Elastic&#x27;s scale.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;meilisearch&#x2F;meilisearch">https:&#x2F;&#x2F;github.com&#x2F;meilisearch&#x2F;meilisearch</a><p><a href="https:&#x2F;&#x2F;typesense.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;typesense.org&#x2F;</a>
arter4大约 1 年前
Interesting benchmark.<p>Of course, if you need advanced search features, APIs for indexing and searching (Kibana) or some fault tolerance don&#x27;t reinvent the wheel.<p>So, I wouldn&#x27;t use this in any production (i.e. non single-instance) setup, but it is a useful reminder of how modern hardware and software is powerful enough to do things that would intuitively seem resource-intensive.
评论 #39875897 未加载
mikhailfranco大约 1 年前
The classic rant on this subject by McSherry, <i>et al.</i><p><i>Scalability! But at what COST?</i><p><a href="https:&#x2F;&#x2F;www.usenix.org&#x2F;system&#x2F;files&#x2F;conference&#x2F;hotos15&#x2F;hotos15-paper-mcsherry.pdf" rel="nofollow">https:&#x2F;&#x2F;www.usenix.org&#x2F;system&#x2F;files&#x2F;conference&#x2F;hotos15&#x2F;hotos...</a><p><pre><code> We offer a new metric for big data platforms, COST, or the Configuration that Outperforms a Single Thread. The COST of a given platform for a given problem is the hardware configuration required before the platform outperforms a competent single-threaded implementation.</code></pre>
itsdrewmiller大约 1 年前
Aside from several mistakes about es minimums this seems like it is removing almost all the data and complexity of the problem and then saying it can be done faster? There are a lot of caveats involved but the experiment is so far removed from reality that it has no bearing on the business problem.
nrki大约 1 年前
Someone should tell REA about this!
stuaxo大约 1 年前
Elasticsearch is so slow to populate and takes so much ram for what it does.