Umbra: an ACID-compliant database built for in-memory analytics speed

Re:Umbra: an ACID-compliant database built for in-memory ana... by psds2 on Sunday January 26, 2020 @08:48PM (#22156251)

Have you considered disaggregating your storage from your compute and using something like NVMe-oF or a traditional iscsi or fiber channel SAN to mount storage to your database server? With a block level storage fabric you can fail over instantly, run read only replicas and even support distributed writes in some cases.

[ Parent | on HN ]

Re:Umbra: an ACID-compliant database built for in-memory ana... by adev_ on Sunday January 26, 2020 @11:21PM (#22156835)

> With a block level storage fabric you can fail over instantly, run read only replicas and even support distributed writes in some cases.

Yes, but it's also a wonderful way to corrupt a DB as soon as anything goes wrong in your storage fabric system.

And this type of corruption is generally not the recoverable one.

[ Parent | on HN ]

Re:Umbra: an ACID-compliant database built for in-memory ana... by p_l on Monday January 27, 2020 @03:07AM (#22157637)

Combine it with a data-safety oriented systems like ZFS and your only issue will be downscaling storage without downtime (though that can also be worked around, if in slightly less safe manner, by putting ZVOLs on thin allocations on SAN)

[ Parent | on HN ]

Re:Umbra: an ACID-compliant database built for in-memory ana... by pbowyer on Monday January 27, 2020 @06:16AM (#22158319)

> Yes, but it's also a wonderful way to corrupt a DB as soon as anything goes wrong in your storage fabric system.

Why is this more likely to corrupt a DB than having it on local disks, when something goes wrong?

[ Parent | on HN ]

Re:Umbra: an ACID-compliant database built for in-memory ana... by adev_ on Monday January 27, 2020 @07:24AM (#22158662)

> Why is this more likely to corrupt a DB than having it on local disks, when something goes wrong?

Local filesystems (ext4, xfs) have been designed to run over reliable internal bus and over spinning disk. They are (almost) able to stand most of the outage happening in this context ( powercut, corrupted block, missing flush ).

Put them over a non-reliable "normal" network, where you can get "savage" cable unplugged, faulty controller, paquet loss, out of order delivery, buggy middle box and you explode the number of scenario that can go wrong and will go wrong.

Block level I/O virtualization is amazingly useful, but (in my mind) it should be used with care...

I already heard of case in prod where the Master DB, the Slave DB and backup finished all in the same virtualized block-level storage.... try to guess what happened next.

[ Parent | on HN ]

Re:Umbra: an ACID-compliant database built for in-memory ana... by pbowyer on Monday January 27, 2020 @04:12PM (#22163834)

Thanks, that's a great explanation.

[ Parent | on HN ]