哪个密钥值,Nosql数据库可以确保在发生电源故障时没有数据丢失?

时间:2016-04-20 09:15:59

标签: in-memory-database aerospike key-value-store database nosql

目前,我们正在使用Redis作为内存中的快速缓存。它运作良好。问题是,一旦Redis重新启动,我们需要通过从持久性存储中获取数据来重新填充它。这超载了我们的持久性 存储超出其容量,因此恢复需要很长时间。

我们查看了Redis持久性选项。最佳选择(不影响性能)是使用AOF和" appendfsync everysec'。但是通过这个选项,我们可以放弃最后的第二个数据。这是不可接受的。将AOF与' appednfsync一起使用'有相当大的性能损失。

所以我们正在评估单节点Aerospike。是否保证在电源故障时不会丢失数据?即,响应写入操作,一旦Aerospike向客户端发送成功,即使我拉动服务器机器的电源线,数据也不会丢失。正如我上面提到的,我相信Redis可以通过' appednfsync始终提供这种保证。选项。但是我们没有考虑它,因为它有相当大的性能损失。

如果Aerospike能够做到这一点,我想详细了解Aerospike中的持久性是如何起作用的。请分享一些解释相同的资源。

我们不是在寻找分布式系统,因为强大的一致性对我们来说是必须的。在节点故障或裂脑情景中不应丢失数据。

如果不是空中加速,你能指点我另一个可以帮助实现这个目标的工具吗?

4 个答案:

答案 0 :(得分:2)

我为Aerospike工作。您可以选择使用磁盘持久性将命名空间存储在内存,磁盘或内存中。在所有这些场景中,我们在实际基准测试中与Redis相比表现良好。

考虑在写入时磁盘上的存储,它会在刷新到磁盘之前到达缓冲区。在成功写入缓冲区之前,ack不会返回到客户端。有理由认为,如果在缓冲区刷新之前拉动电源线,则在单个节点群集中,写入可能已被激活到客户端并随后丢失。

答案是在群集中有多个节点并且replication-factor> = 2.然后写入到客户端和副本上的缓冲区,并且在被激活之前必须在两者上都成功客户成功。如果从一个节点拉出电源,则另一个节点上仍然存在副本,并且不会丢失任何数据。

所以,是的,有可能使Aerospike具有弹性,因为它可以合理地以低成本和最小的延迟进行。最好的办法是下载社区版,看看你的想法。我怀疑你会喜欢它。

答案 1 :(得分:2)

这不是数据库问题,而是硬件和风险问题。

所有数据库(具有持久性)都以相同的方式工作,有些数据库直接将数据写入物理磁盘,而其他数据库则告诉操作系统写入数据。确保每次写入都是安全的唯一方法是等待磁盘确认写入数据。

没有办法解决这个问题,正如您所见,它会大大降低吞吐量。这就是为什么数据库使用内存缓冲区并在短时间内将批量数据从缓冲区写入磁盘的原因。但是,这意味着在将数据写入缓冲区之后但在将数据写入磁盘之前发生机器问题(电源,磁盘故障等)的风险很小,会导致数据丢失。 / p>

在单个服务器上,您可以通过多个电源,备用电池和其他安全措施购买保护,但这很快就会变得棘手和昂贵。这就是分布式架构如今在可用性和冗余方面如此普遍的原因。分布式系统并不意味着您失去一致性,而是通过保护您的数据来帮助确保它。

解决问题的最简单方法是使用允许复制的数据库,以便每次写入至少2台不同的计算机。这样,一台机器失去电源不会影响到另一台机器的写入,您的数据仍然是安全的。

您仍然需要防止可能影响所有服务器的更高级别的停电(例如您的整个数据中心断电),但您可以通过分布更多边界来解决此问题。这一切都取决于您可以接受的风险程度。

在调整数据库中的磁盘写入间隔和使用适当的分布式体系结构之间,您可以获得所需的一致性和性能要求。

答案 2 :(得分:0)

我相信aerospike可以达到您的目的,您可以在 aerospike.conf 中为命名空间(即DB)级别的混合存储配置它 出现在 /etc/aerospike/aerospike.conf

有关详细信息,请参阅此处的官方文档:http://www.aerospike.com/docs/operations/configure/namespace/storage/

答案 3 :(得分:0)

我相信你会受到任何存储介质延迟的影响,或者群集中网络结构的延迟,无论你使用什么样的DBMS技术,如果必须的话保证数据不会丢失。 (如果有可能整个物理设备失去电力,即两个节点都失去电力,那么Ben Bates'解决方案就无法工作。但是,我认为廉价的UPS会大幅度降低(如果不是完全的话)与独立的内存数据库实例相比,这些延迟会导致显着的插入/更新/删除性能下降。

另一个需要考虑的选择是将NVDIMM存储用于内存数据库或用于从中恢复的预写事务日志。它具有绝对最低的延迟(与传统DRAM相当)。而且,如果您的内存数据库适合可用的NVDIMM内存,那么您可以获得最快的恢复速度(无需从事务日志中重放),并且可以获得与原始IMDB性能相当的性能,因为您可以返回单个写入与2个以上写入,用于添加预写日志和/或复制到群集中的另一个节点。但是,您的内存数据库系统必须能够支持直接恢复内存数据库(而不仅仅是从事务日志中)。但是,同样有两个要求: 1.整个数据库必须适合NVDIMM内存 2.数据库系统必须能够在系统重启后直接支持数据库恢复,而无需事务日志。

本白皮书http://www.odbms.org/wp-content/uploads/2014/06/IMDS-NVDIMM-paper.pdf

中的更多内容