That’s what I thought but I wasn’t sure it was about those same segments.
Well then it’s even worse? Counting files is easy and makes sense to users, but counting segments? Segments are a technical thing behind the scene, how is a customer supposed to know how many segments their files count?
I don’t see why billions of files would be bad, and in fact many projects have in immense number of files in the development world, because of wonderful things line NodeJS for instance…
What I would be afraid of would be the use of file names only for storing data for instance: that would be a way to abuse the system, I mentioned it long ago already:
And that’s why initially Storj charged “$0.0000022 Per Object Per Month”.
But they decided to remove it later on!
I think this is key.
I think it is of dubious consumer protection legality to charge an amount for a product which is arbitrary and where the cost is not clear enough.
I can decide how may objects or files to store, I have no control (or indeed knowledge) of the number of segments.
I’m sure there is a good reason for this change, but I too am struggling to see what it could be.
The segment size is not fixed. We have customers that upload with default 5MB multipart size. That will create 10 times more segments for the same file size. There is also one person that has chosen to upload a segment size that is even lower in order to game our system. The segment fee is there as an incentive to use 64MB segments whenever possible. We are talking about a very low fee. Let us come back with some numbers for you later.
Well then I think what would be a better move would be to have 0 segment fees for customers who choose to keep segments above a certain size (>=16MB for instance), and make pay only customers who choose a lower value?
Why would one want a very small segment size by the way?
I have an update for you. The segment fee is $0.0000088 per Segment-Month. That means an additional 14-15 Cent per TB with perfect file sizes. Maybe 20 Cent per TB if we throw typical file sizes at it.
I am a bit concerned about this pricing increase. If one of you has a paid account maybe take a look at how many segments you are currently storing and calculate how expensive that would be for you. It would be awesome to get some real-world examples to understand the impact.
1mil max segments, at 0.0000088 pr segment pr month.
so that becomes 8.8$ max extra cost pr month.
and 1 segment being 64MB so thats when storing 64TB or in the case of 5MB it would then be 5TB obviously.
seems reasonable, and if we then compare it to what the data storage itself would be for 5 and 64TB.
5 TB would be 20$ + 8.8$ + bandwidth or 64 would be 256$ + the 8.8$ for segments and the bandwidth on top.
meaning at peak its less than 5% extra costs while at 5MB segment size it would be near 50% of the total storage cost.
so yeah it would certainly work as an incentive to configure it correctly for large scale usage.
unless if one has certain benefits from running smaller segments which one likes to pay for…
like say the ability to scrub video files more accurately or something… duno how it works but i would assume a smaller segment size would allow for a more accurate data retrieval process.
for seek in videos or such, ofc making the assumption that people download per segment.
yeah seems a very reasonable incentive.
ofc one might want to review the implications and pricings of the segments on a yearly basis or whenever other prices change, so that the incentive remains, as prices for storage change.