G>Как снепшоты помогут если кто-то пойдет и выполнит команду аналогичную
G>

G>drop table main_data
G>

G>?

Ну так можно восстановить все из снепшота, что в этом непонятного?

G>Это не гарантирует что данные будут в сохранности.

Так и бэкап твой тоже ничего не гарантирует.

CK>>Но и то, если нет disaster recovery (репликация в другой ДЦ, в котором меньше машин, но у каждой машины больше диска, чтобы данные просто хранить там и ничего не вычислять). Но это опять же — совсем не backup.
G>Это тот самый бекап, только дороже.

Почему дороже? Начнем с того, что MSSQL не может в несколько датацентров вообще. Как можно сравнивать? К тому же, следует понимать разницу между бэкапом и репликацией, неужели для тебя это все одно и тоже?

G>Если данные нестрашно потерять, то скорее всего так и есть.

Данные страшно потерять. Но, помимо этого, страшно потерять инфраструктуру, посчитанные на основе данных аггрегаты (т.к. их месяц придется пересчитывать), страшно потерять работающие MapReduce задачи, которые очень долго выполняются и все такое.

G>Держать 5 реплик + копию в другом ДЦ оправдано?
Ну мы не держим копию в другом ДЦ пока. Но мы прикидывали во сколько раз дороже обойдется держать данные из HBase в постгресе. HBase — column oriented и для каждой column family можно настроить сжатие по разному, например, если в колонке лежат метки времени или увеличивающиеся id-шники, можно использовать delta-кодинг с последующим сжатием, что увеличивает эффективность, плюс однородность сжимаемых данных играет на руку очень сильно. Данные очень хорошо жмутся и занимают в HBase в разы меньше места, чем в постгресе. Ну и 5 реплик нужны не только для сохранности, но и для locality, чтобы MapReduce задачи выполнялись быстрее и не копировали данные туда-сюда.

G>На практике бекап — самый дешевый способ делать disaster recovery, по сравнению со всеми остальными. Дешевле на порядки. Мало того, что бекапить можно на ленты, которые имеют стоимость хранения ГБ на два порядка меньше жестких дисков, так еще это не требует дорогих серверов и бекапы могут быть хорошо пожаты.

Ну это все голословные утверждения, практика у всех разная.

CK>>да и перерыв в обслуживании будет такой, что уж лучше часть данных потерять и восстановить из других источников, нежели на несколько суток все останавливать, вайпать каждую ноду и накатывать (уж даже не знаю каким способом) бэкап взад.
G>Это проблема исключительно NoSQL движков, о чем я намекал в том сообщении, которое ты прокомментировал.

Это не проблема, потому что так не делают.

G>Все взрослые БД умеют за вполне разумное время ресторить терабайты данных. Недавно видел рестор 20ТБ базы в течение 28 часов.
G>То есть если бы взорвался датацентр, то можно было бы за 2-е суток восстановить обслуживание.

Это разумное время по твоему? А скажи пожалуйста, зачем нужно было делать рестор той БД?

G>Как снепшоты помогут если кто-то пойдет и выполнит команду аналогичную
G>

G>drop table main_data
G>

G>?

Ну так можно восстановить все из снепшота, что в этом непонятного?

G>Это не гарантирует что данные будут в сохранности.

Так и бэкап твой тоже ничего не гарантирует.

CK>>Но и то, если нет disaster recovery (репликация в другой ДЦ, в котором меньше машин, но у каждой машины больше диска, чтобы данные просто хранить там и ничего не вычислять). Но это опять же — совсем не backup.
G>Это тот самый бекап, только дороже.

Почему дороже? Начнем с того, что MSSQL не может в несколько датацентров вообще. Как можно сравнивать? К тому же, следует понимать разницу между бэкапом и репликацией, неужели для тебя это все одно и тоже?

G>Если данные нестрашно потерять, то скорее всего так и есть.

Данные страшно потерять. Но, помимо этого, страшно потерять инфраструктуру, посчитанные на основе данных аггрегаты (т.к. их месяц придется пересчитывать), страшно потерять работающие MapReduce задачи, которые очень долго выполняются и все такое.

G>Держать 5 реплик + копию в другом ДЦ оправдано?
Ну мы не держим копию в другом ДЦ пока. Но мы прикидывали во сколько раз дороже обойдется держать данные из HBase в постгресе. HBase — column oriented и для каждой column family можно настроить сжатие по разному, например, если в колонке лежат метки времени или увеличивающиеся id-шники, можно использовать delta-кодинг с последующим сжатием, что увеличивает эффективность, плюс однородность сжимаемых данных играет на руку очень сильно. Данные очень хорошо жмутся и занимают в HBase в разы меньше места, чем в постгресе. Ну и 5 реплик нужны не только для сохранности, но и для locality, чтобы MapReduce задачи выполнялись быстрее и не копировали данные туда-сюда.

G>На практике бекап — самый дешевый способ делать disaster recovery, по сравнению со всеми остальными. Дешевле на порядки. Мало того, что бекапить можно на ленты, которые имеют стоимость хранения ГБ на два порядка меньше жестких дисков, так еще это не требует дорогих серверов и бекапы могут быть хорошо пожаты.

Ну это все голословные утверждения, практика у всех разная.

CK>>да и перерыв в обслуживании будет такой, что уж лучше часть данных потерять и восстановить из других источников, нежели на несколько суток все останавливать, вайпать каждую ноду и накатывать (уж даже не знаю каким способом) бэкап взад.
G>Это проблема исключительно NoSQL движков, о чем я намекал в том сообщении, которое ты прокомментировал.

Это не проблема, потому что так не делают.

G>Все взрослые БД умеют за вполне разумное время ресторить терабайты данных. Недавно видел рестор 20ТБ базы в течение 28 часов.
G>То есть если бы взорвался датацентр, то можно было бы за 2-е суток восстановить обслуживание.

Это разумное время по твоему? А скажи пожалуйста, зачем нужно было делать рестор той БД и как зависит время рестора от размера базы?