[
https://issues.apache.org/jira/browse/JAMES-3591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Tellier closed JAMES-3591.
---------------------------------
Fix Version/s: 3.7.0
Resolution: Fixed
> Warn against CassandraBlobStoreDAO usage and its use
> ----------------------------------------------------
>
> Key: JAMES-3591
> URL: https://issues.apache.org/jira/browse/JAMES-3591
> Project: James Server
> Issue Type: Task
> Reporter: Benoit Tellier
> Priority: Major
> Fix For: 3.7.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> h3. Why?
> Cassandra is not made for large binaries storage. And deliver sub-optimal
> performances compared to ObjectStorage alternatives (like S3, MinIO or Apache
> Ozone).
> We need to ensure users are fully aware of the consequences while choosing
> this option.
> Thus we should add warnings in:
> - The code via java doc
> - The documentation websites
> - dockerhub README
> - A log upon startup.
> - Sample configuration file.
> h3. Related exhanges
> I did have exchanges with Nate Mc Call on this topic:
> {code:java}
> Hi folks - would really like to talk to anyone that worked on the Cassandra
> Blob Store implementation about potentially pulling this out for general use.
> Please ping on zzn...@apache.org or zznate on asf's slack.
> {code}
> Then exchanging by email:
> {code:java}
> Hello Nate,
> Thank you very much for raising this topic.
> I am seriously concerned with the performance and storage costs of the
> Cassandra blob store for quite some time already.
> The Apache James PMC had been reluctant to remove it as we were worry
> bringing additional runtime dependencies to the project (meaning forcing
> users to rely on an object store like Ozone or MinIO).
> I personnaly encourage any move on this topic to deprecate/provide extensive
> warnings regarding its use and am very curious to know what you have to say
> about it.
> Best regards,
> {code}
> Answered by:
> {code:java}
> Hi Benoit,
> Thanks for the response. At a high level, I completely agree with you - a
> database of any sort is not the right place for binary content. That said, I
> regularly see cases where folks are in a situation like "this is what we have
> provisioned and accounted for, let's just use it."
> As it stands, this is one of the better binary storage approaches which I
> have seen implemented. A checksumming, reactive API with a configurable chunk
> size solves a lot of problems for people.
> At the end of the day though, I do very much agree that the right answer is
> to use a distributed filesystem of some sort (Ozone and MinIO would
> definitely be better), and folks should be warned about the substantial
> storage and performance overhead of doing it in C*. But this approach at
> least will "suck less" than many others I have seen using C* similarly.
> Thanks again for the response, and nice to meet you either way.
> Cheers,
> -Nate
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
