“为什么数据库软件一直在浪费硬件”

数据库是软件，但依赖于硬件。 数据库本身是为分类、存储、控制和后续各种数据管理而开发和部署的软件代码，但任何数据库的基础都是硬件。 (当然，很明显)这是因为数据库通常位于服务器上，而服务器基本上只是硬件。

数据库服务器位于组织自己的本地数据室或数据中心的框中。 或者，位于数据中心的大型安装中的刀片式服务器上，客户可以使用它来购买按需云计算服务。 可选的是，数据库以两种混合格式跨越了本地和公共云数据中心的世界。

重要的是，无论选择什么格式、形状、类型的数据库，从根本上驱动该软件的都是依赖于存在的硬件。

硬件浪费是如何发生的

如果接受了上述所有事实，数据库软件也可能会假设有足够的智能知道将哪些数据放在哪里，什么时候放在哪里，对吧？ 是的，很明显，数据库软件很聪明，这就是为什么这么多的原因。 但是，要执行的任务非常多，提供的数据非常多，为了以各种方式构建数据库查询应用程序，各个数据库需要整理鞋柜(即存储该数据)，利用执行的硬件是其他 用高级语言(如java )编写的数据库通过中间人与机器进行通信。 这是因为必须在表中保留一定数量的服务器性能。 在这次讨论中，可以说是徒劳的。

来自以色列的nosql数据库公司scylladb认为，他们有办法建立一个可以整理、更快、更有效的管理和自我优化的数据库。 这家企业提倡使用离scylla数据库最近的金属，这从简单的意义上意味着什么？

在数据库世界中，最近的一种是对所运行的硬件有很深了解的数据库软件(如果您需要技术，可以使用硬件的ram地址和更广泛的指令集)。 接近金属的亲密性意味着可以从运行着数据库的服务器硬件中获取越来越多的能量。 权衡是灵活性的减弱，在一定程度上锁定了所讨论的硬件，但这种精确的工程设计确实更快。 速度是多少？

上亿个

scyla数据库首席执行官dor laor解释说，scyla数据库可以在一个节点上执行每秒数百万次的操作( ops ) (一个节点在计算中可能意味着许多事件，但在这种情况下是一台服务器) 。 该公司引用了一个独立的测试，表明scylla数据库服务器群集每秒读取10亿行( rps )。 这里的合计是来自各服务器的更快、更多的电力。 这样的技术主张对个别用例来说不是最有效的方法。 虽然小数据集可以使用以前流传的关系数据库，但是scylla适合于具有大量数据点的大数据库的业务负载。

在99.9%的应用程序中，sylla提供客户所需的所有功能，而业务量是其他nosql数据库无法解决的。 但是，价格只是内存处理方案的一小部分。

scylladb数据库的CEODorLaor。

ceo laor认为，sylla需要低延迟地执行高吞吐量软件应用(需要解决大量数据活动的应用)和数据库场景( SLA )的规定 (也就是说，几乎没有延迟)。 scylla也适用于高密度节点，即大量数据密集封装的服务器。

节点蔓延是指在多个位置使用数据库实例在不同地区分割和分配不同的新闻业务负载的情况。 更高密度的节点意味着在一个地方有更多的数据。 这很有用，但在任何时候都需要咀嚼更大的数据块。

这家企业现在正在寻求所谓的高密度支持。 也就是说，可以将分散在不同临时存储空间中的旧数据部分移动到较长时间的存储节点，以便更舒适、更准确地驻留。 这意味着可以减少整体的短期记忆量。

康卡斯特进入scylla

comcast软件开发和工程总监phil zimich介绍了企业从cassandra数据库向scylla的迁移过程。 该公司使用x1平台将固件驱动到设备上，并进行了升级，以用于以下电视和语音服务: comcast管理着1500万户的3100万台设备，这些设备都是在个人账户级别进行管理的。 Comcast x1排程器有21种不同的web服务，可以在客户播放录音时提供给客户。 客户还必须取消或更改记录，并提醒他们每天需要进行500万次帐户计算。 这就是scylla创建的用例。 comcast迁移到scylla的结果从962个节点增加到了今天的78个节点。

scylla数据库完全利用了给定计算环境中提供的所有解决方案( cpu )功能和ram，以执行业务并减少硬件浪费。 这里的另一个技术是采用所谓的增量压缩。 这是一个更新和删除数据的过程，以便组织可以利用最高效的存储方法。 不同的压实工艺在不同的压实战略上运行。 但是，在低效的压缩过程中，您会发现数据库存储在此过程的最大50%空之间，而不是更高效地采用并专用于实际存储。

同样重要的是，要记住写入数据库的数据越多，就越需要为分析和最终保存的数据排队，生成的数据负债就越多。 因此，在这种情况下，如果队列中的数据过多，数据库本身就会遭受性能损失。 我知道数据库有不同的业务负荷。 因为这个数据库必须能够优先解决越来越多的重要任务的实时进程，而不是其他不重要的实时进程。 scylla首席执行官laor说。

那么，过去我们在软件中采用硬件方面真的浪费了吗？ 在某些情况下，这些现在在数据消耗示例中更为常见。 在这种情况下，需要提高规模(有时需要扩大规模)。 考虑具有传感器和家用摄像头的智能家庭供暖空调节或安全系统。 这些类型的应用程序通常免费提供一天的视频播放快照，但客户必须支付30天以上的费用。 一旦客户开始大量注册这些服务，就会带来真正规模的挑战。

服务器失败。 这是因为假设软件系统分散在365个服务节点上时，每天都有一个节点发生故障。 如果软件系统分散在密度更高的环境中的10个节点上，则服务器资源较小，因此从逻辑上讲，每台服务器的故障平均时间会更少。 虽然失败仍会发生，但通过使用现代软件工具帮助备份和恢复，您可以在更苛刻的管理环境中管理整个过程。

迄今为止，我们并未考虑优化系统。 因为会出现其他解决方案，带来如此大的解决能力的增加。 这不值得人类开发者的消费时间。 现在，随着摩尔定律濒临灭绝，人们认为建立更高效、更少浪费的软件架构变得更加重要。

唤醒所有的效率？

你能在正确的时间来兜风吗？ 毕竟，z世代已经觉醒，能够以大约十年前没有考虑过的方式处理气候变化和全球浪费。 另外，考虑软件的硬件消费习性，更加环保是合适的选择吗？

即使没有像减少航空空企业的航班和回收塑料袋那样完全减少碳足迹，毫无疑问，更有效地利用什么样的资源最终是件好事。