Earlier quoted context omitted.
This is a complex misunderstanding... First, we are getting better throughput from S3 than I we were using a SATA SSD. (and slower than a NVMe SSD). This is a bit of a secret. Of course, single sequential throughput on S3 sucks. At the end of the day the data is stored on spining disk and we cannot do anything against the law physics. ... but we can concurrently read many disks using s3. Network is our only bottlenec…
How about setting up minio on these hertzner setups? You get benefit of s3 on cheap hardware without aws costs
Searching the web for under $1000/month
61–70 of 153 posts
Re: Searching the web for under $1000/month
#62Earlier quoted context omitted.
Of course not. But that's why the "cloud" (as in the typical DO/AWS/Azure/GCP offerings) are a scam.
Just because you don't understand the value proposition of something doesn't make it a scam.
Go to the AWS console and try to answer even simply things like how much did the last hour/day/week cost me? Or how about some notifications if that new service you just added is going to cost vastly more than you where expecting.
I know of a few people getting fired after migrating to AWS and it’s not because the company was suddenly saving money.
Re: Searching the web for under $1000/month
#63It is a cool project. S3 can be cost efficient, but only if you don't touch data :) Their price calculation doesn't mention cost of S3 requests, which very quickly adds up and is often neglected. It costs $1 for 2.5M GET requests to S3. They have 180 shards, in a general case query seems to fetch all of them. Presumably they don't download full shard per request, but download an index + some relevant ranges. Lets say…
I tend to agree :). If we get 1 req/s, even for a dataset of that size, this is not as cost efficient. For that kind of use case, I'd probably start using minio. > Seems comparable to AWS ElasticSearch service costs: > - 3 nodes m5.2xlarge.elasticsearch = $1,200 > - 20TB EBS storage = $1,638 Don't forget S3 includes replication. Also EBS throughput (even with SSD) is not good at all. Also our memory footprint is tiny…
How many req/s do you have in mind for your system to be a viable option?
> Also EBS throughput (even with SSD) is not good at all.
It is not worse than S3 still, right?
> Chatnoir.eu is the only other common crawl cluster we know of. It consists of 120 nodes.
I have no deep ES experience. Are you saying, that to host 6TB of indexed data (before replication) you'd need 120 nodes ES cluster? If so, then reducing it to just 2 nodes is the real sales pitch, not S3 usage :)
Re: Searching the web for under $1000/month
#64Earlier quoted context omitted.
How about setting up minio on these hertzner setups? You get benefit of s3 on cheap hardware without aws costs
Absolutely! I want to try that.. We are especially interested in testing the latency minio could offer.
Re: Searching the web for under $1000/month
#65Earlier quoted context omitted.
Just because you don't understand the value proposition of something doesn't make it a scam.
AWS is a scam not because it can’t save you money, but because they actively try to trick you into spending more money. That’s practically the definition of a scam. Go to the AWS console and try to answer even simply things like how much did the last hour/day/week cost me? Or how about some notifications if that new service you just added is going to cost vastly more than you where expecting. I know of a few people g…
>Go to the AWS console and try to answer even simply things like how much did the last hour/day/week cost me?
Click user@account in top right, click My Billing Dashboard, spend this month is on that page in giant font, click Cost Explorer for more granular breakdown (day, service, etc.), click Bill Details for list breakdown of spend by month.
>Or how about some notifications if that new service you just added is going to cost vastly more than you where expecting.
Billing Dashboard and then Budgets.
edit: This assumes you have permissions to see billing details, by default non-root accounts do not which might be why you're confused.
Re: Searching the web for under $1000/month
#66Earlier quoted context omitted.
This is a complex misunderstanding... First, we are getting better throughput from S3 than I we were using a SATA SSD. (and slower than a NVMe SSD). This is a bit of a secret. Of course, single sequential throughput on S3 sucks. At the end of the day the data is stored on spining disk and we cannot do anything against the law physics. ... but we can concurrently read many disks using s3. Network is our only bottlenec…
"S3 costs include battle tested, multi-DC replication." Sometimes we pay a bit too much for this multi-replication, battle tested stuff. It's not like the probability of loosing data is THAT huge. For the 4x extra cost you could easily take a backup every 24h. "It means that we can host 100 different indices on S3, and use the same pool of search server to deal with the CPU-bound stuff" You can do that with NFS. It's…
It's also worth considering the cost to simply regenerate the data for something like this that isn't the source of truth. You'll lose any content that you indexed that has disappeared from the web, but that seems like a feature more than a bug.
> You can do that with NFS.
You're going to be bound by your NIC speed. You can bond them together, but the upper bounds on NFS performance are going to be significantly lower than on S3. Whether that's going to be an issue for them or not, I don't know, but a big part of the reason for separating compute and storage is so that one of them can scale massively without the other.
Re: Searching the web for under $1000/month
#67Re: Searching the web for under $1000/month
#68This is super interesting. I've recently also been working on a similar concept: we have a reasonable amount (in the terabytes) of data, that's fairly static, that I need to search fairly infrequently (but sometimes in bulk). A solution we came up with was a small , hot, in memory index, that points to the location of the data in a file on S3. Random access of a file on S3 is pretty fast, and running in an EC2 instan…
For your usecase it'll be very cheap if you don't access it constantly (you can probably get away with the extra small instances, which you are billed per minute).
Not affiliated in anyway, just a suggestion.
Re: Searching the web for under $1000/month
#69Earlier quoted context omitted.
Depending on the requirements https://www.hetzner.com/dedicated-rootserver/ax101/ May be an actually better fit Once they available again
Why a Ryzen instead of an Epyc in a data center?
Re: Searching the web for under $1000/month
#70It is a cool project. S3 can be cost efficient, but only if you don't touch data :) Their price calculation doesn't mention cost of S3 requests, which very quickly adds up and is often neglected. It costs $1 for 2.5M GET requests to S3. They have 180 shards, in a general case query seems to fetch all of them. Presumably they don't download full shard per request, but download an index + some relevant ranges. Lets say…
I tend to agree :). If we get 1 req/s, even for a dataset of that size, this is not as cost efficient. For that kind of use case, I'd probably start using minio. > Seems comparable to AWS ElasticSearch service costs: > - 3 nodes m5.2xlarge.elasticsearch = $1,200 > - 20TB EBS storage = $1,638 Don't forget S3 includes replication. Also EBS throughput (even with SSD) is not good at all. Also our memory footprint is tiny…
EDIT: Realizing that d3 has just slow HDD