http://www.nosqlnotes.com/technotes/scylla-highlights/在JVM之上，我们费尽周折减少Java对象的数量，优化Java GC参数甚至是改进Java GC算法，尽可能的将内存移至Offheap区或者参考操作系统内存分页的技术将内存自己最管理起来，所有这些，都是为了减少Java GC的影响进一步提升系统吞吐量，而且的确也可以取得一定的效果。
上文中提到的很多能力，都得益于Seastar框架，ScyllaDB可以说在与新型硬件的结合上，往前迈进了很大的一步。ScyllaDB重写了Cassandra，而Cassandra最让人诟病的地方在于多副本之间数据不一致时经常需要手动修复来搞定，ScyllaDB的当前能力似乎也无法避免该问题，另外一点，虽然ScyllaDB能够充分的利用底层硬件的IOPS，但长时间运行后的Compaction带来的冗余IOPS消耗，也是一个不容忽视的关键点，期待能看到ScyllaDB在这一点上的突破。
异步编程框架
采用了基于事件驱动的异步编程框架，而这部分是由Seastar实现的。Seastar中实现了广泛的Future/Promise接口，而且实现了一些独立的数据结构，从而能够更好的发挥新型硬件的优势。
Shard Per Core
在传统的架构中，Shard并不感知CPU Core，这会带来几个方面的问题：
- 锁竞争：在高并发场景下，锁竞争所带来的时间消耗通常占据较高的比例
- Cache竞争：如典型的“伪共享”问题：缓存系统中是以缓存行(Cache line)为单位存储的，如果多线程间的Cache数据可能位于同一个缓存行中，就会互相影响彼此的性能
- 无法发挥NUMA架构的CPU优势：NUMA架构下，将CPU划分为若干个Chip，每一个Chip有自己的内存控制器及内存插槽，而CPU访问自己Chip上的内存时速度非常快（比访问其它CPU的内存快3倍左右）
而Scylla选择了Shard Per Core的设计，即每一个Shard与一个CPU Core绑定，尽可能的降低了锁/Cache方面的竞争，对于NUMA架构的CPU又非常友好。
基于用户空间的TCP/IP协议栈
基于Linux之上的现有网络功能已经非常成熟稳定了，但对于网络时延敏感的一些应用，却存在如下几点限制：
- 基于内核空间的实现：意味着上下文切换是一个耗时操作，还需要进行用户空间与内核空间的数据复制
- 分时共享：当有新的包需要处理时，依赖于中断机制来通知内核
- 基于线程的模型：强依赖于锁机制
因此，Seastar实现了用户空间的TCP/IP协议栈，Seastar的Native Networking真正实现了"zero-copy, zero-lock, zero-context-switch"。当前，Seastar能够支持四种网络模型：
- Linux standard socket APIs
- Seastar native stack vhost on Linux
- Virtio device on OSv
- DPDK networking on Linux
DPDK本身就是为了高性能包处理而诞生的，处理一个包通常小于80 CPU Cycles。
自治理
相对于传统静态配置的NoSQL系统，Scylla采用了"自治理"能力，也就是说，能够基于集群运行时的实时信息动态调整运行参数，ScyllaDB的CEO Dor Laor这么描述该特性：
Our vision is to provide a database that dynamically tunes itself to varying conditions while always maintaining a high level of performance, regardless of any administrative operation. Scylla 2.0 moves us much closer to this goal and sets our company apart from others in the industry.
上文中提到的很多能力，都得益于Seastar框架，ScyllaDB可以说在与新型硬件的结合上，往前迈进了很大的一步。ScyllaDB重写了Cassandra，而Cassandra最让人诟病的地方在于多副本之间数据不一致时经常需要手动修复来搞定，ScyllaDB的当前能力似乎也无法避免该问题，另外一点，虽然ScyllaDB能够充分的利用底层硬件的IOPS，但长时间运行后的Compaction带来的冗余IOPS消耗，也是一个不容忽视的关键点，期待能看到ScyllaDB在这一点上的突破。
