Could you please explain more about (you mean slower performance in compare to
Cassandra?) ---Hbase tends to be quite average for transactional data and
about: ----ScyllaDB IDK, I'd assume they just sorted out streaming by learning
from C*'s mistakes. While ScyllaDB is a much younger project than Cassandra
with so much less usage and attention, Currently I encounter a dilemma on
launching new clusters which is: should i wait for Cassandra community to apply
all enhancement's and bug fixes that applied by their main competitors (Scylla
DB or Cosmos DB) or just switch to competitors (afraid of the new world!)? For
example right now is there a motivation to handle more dense nodes in near
future? Again, Thank you for your time Sent using Zoho Mail ---- On Wed, 29 Aug
2018 15:16:40 +0430 kurt greaves <k...@instaclustr.com> wrote ---- Most of the
issues around big nodes is related to streaming, which is currently quite slow
(should be a bit better in 4.0). HBase is built on top of hadoop, which is much
better at large files/very dense nodes, and tends to be quite average for
transactional data. ScyllaDB IDK, I'd assume they just sorted out streaming by
learning from C*'s mistakes. On 29 August 2018 at 19:43, onmstester onmstester
<onmstes...@zoho.com> wrote: Thanks Kurt, Actually my cluster has > 10 nodes,
so there is a tiny chance to stream a complete SSTable. While logically any
Columnar noSql db like Cassandra, needs always to re-sort grouped data for
later-fast-reads and having nodes with big amount of data (> 2 TB) would be
annoying for this background process, How is it possible that some of these
databases like HBase and Scylla db does not emphasis on small nodes (like
Cassandra do)? Sent using Zoho Mail ============ Forwarded message ============
From : kurt greaves <k...@instaclustr.com> To :
"User"<user@cassandra.apache.org> Date : Wed, 29 Aug 2018 12:03:47 +0430
Subject : Re: bigger data density with Cassandra 4.0? ============ Forwarded
message ============ My reasoning was if you have a small cluster with vnodes
you're more likely to have enough overlap between nodes that whole SSTables
will be streamed on major ops. As N gets >RF you'll have less common ranges
and thus less likely to be streaming complete SSTables. Correct me if I've
misunderstood.
