Сообщение Re[11]: Выбор NoSQL от 14.06.2016 12:30
Изменено 14.06.2016 12:36 chaotic-kotik
CK>>Ну так можно восстановить все из снепшота, что в этом непонятного?
G>Ты вроде писал, что снепшот не хранит данные? Или таки хранит?
Данные в HDFS хранятся в блоках (128Мб по умолчанию), каждый файл это набор блоков, файлы — append only (блоки не изменяются) и каждый блок живет ровно до тех пор, пока на него ссылается хоть один снепшот. Снепшотятся метаданные, т.е. маппинг обектов файловой системы на блоки HDFS (содержимое name серверов). Соответственно, все что угодно можно восстановить из снепшота, ведь данные не удаляются пока жив снепшот. Снепшоты в HBase построены на основе снепшотов HDFS
CK>>Так и бэкап твой тоже ничего не гарантирует.
G>В смысле? Из бекапа можно восстановить базу в предыдущем состоянии.
Сервер на котором хранятся бэкапы тоже не абсолютно надежен. Вот представь, хранишь ты бэкапы в дисковой полке, но когда полку только купили, какой-нибудь идиот-админ взял и объединил все дисковое пространство в одну файловую систему, а незадолго до того как тебе потребовалось восстановить базу из бэкапа произошел переезд в другой ДЦ, полка была перезапущена неаккуратно и начала выполнять fcheck. Я не знаю сколько точно длится fcheck файловой системы размером в 360ТБ, но готов поспорить что дольше недели. Я такой факап видел, в полке хранились в том числе и бэкапы БД, хорошо что они не потребовались.
Опять же, если принять во внимание bit rot. Вот лежит у тебя несколько десятков ТБ бэкапов, ты уверен что из них можно восстановить БД в любой момент? А вдруг там какой-нибудь сектор уже не читается? Насколько я знаю, NTFS не хранит контрольные суммы секторов/блоков (как и ext4 и многие другие файловые системы), поэтому я даже не знаю, можно ли проверить integrity бэкапа в этом вашем MSSQL. Мне кажется, хорошим выходом из этой ситуации будет хранение бэкапов MSSQL в HDFS. HDFS считает и хранит контрольные суммы
G>Потому что репликация требует серверов, а бекап только хранилища. Потому что бекап жмется, а реплика не всегда. Потому что бекапов достаточно трех в разных местах, а реплик бывает трех недостаточно.
Я уже писал что данные в HBase жмутся лучше чем в большинстве РСУБД. И реплик больше трех нужно для того, чтобы данные не копировать туда сюда, если нужно запустить развесистый MapReduce Job!
G>Кто вам глупость такую сказал. Log shipping уже 11 лет (а может и больше) позволяет делать геораспределенную реплику.
Я совершенно искренне заблуждался на этот счет!
CK>>Как можно сравнивать? К тому же, следует понимать разницу между бэкапом и репликацией, неужели для тебя это все одно и тоже?
G>Я понимаю разницу, и понимаю что ты используешь репликацию вместо бекапа, потому что с бекапом (вернее с рестором) у NoSQL обычно плохо все.
Ну что значит обычно? У какого-нибудь Redis-a может и плохо, я не эксплуатировал его, не знаю. Но вот у HBase/Cassandra и много чего еще — все очень хорошо. В HBase снепшоты накатываются без даунтайма практически.
CK>>Данные страшно потерять. Но, помимо этого, страшно потерять инфраструктуру, посчитанные на основе данных аггрегаты (т.к. их месяц придется пересчитывать), страшно потерять работающие MapReduce задачи, которые очень долго выполняются и все такое.
G>Ты написал что данные можно восстановить из других источников. Значит не так страшно.
Нет, я пытался сказать, что важны не столько данные сами по себе, сколько процессы, которые потребляют и производят данные. Инфраструктура и все такое. И если восстановить данные из бэкапа — несложно, то поднять заново всю инфраструктуру и заставить ее работать — очень проблематично. Поэтому полная реплика в другом ДЦ — вещь оправданная, т.к. она готова к работе. Просто покупаем надежность ценой избыточности инфраструктуры.
CK>>Это разумное время по твоему?
G>Более чем разумное. В твоем случае какое время восстановления будет если ДЦ взорвется? Есть подозрение, что реплика того же объема по сети из другого ДЦ будет тянуться гораздо дольше, да еще и стоить реплика будет сильно дороже чем бекап на ленте.
Данные в другой ДЦ можно отправить через IPoAC (:
G>Ты вроде писал, что снепшот не хранит данные? Или таки хранит?
Данные в HDFS хранятся в блоках (128Мб по умолчанию), каждый файл это набор блоков, файлы — append only (блоки не изменяются) и каждый блок живет ровно до тех пор, пока на него ссылается хоть один снепшот. Снепшотятся метаданные, т.е. маппинг обектов файловой системы на блоки HDFS (содержимое name серверов). Соответственно, все что угодно можно восстановить из снепшота, ведь данные не удаляются пока жив снепшот. Снепшоты в HBase построены на основе снепшотов HDFS
CK>>Так и бэкап твой тоже ничего не гарантирует.
G>В смысле? Из бекапа можно восстановить базу в предыдущем состоянии.
Сервер на котором хранятся бэкапы тоже не абсолютно надежен. Вот представь, хранишь ты бэкапы в дисковой полке, но когда полку только купили, какой-нибудь идиот-админ взял и объединил все дисковое пространство в одну файловую систему, а незадолго до того как тебе потребовалось восстановить базу из бэкапа произошел переезд в другой ДЦ, полка была перезапущена неаккуратно и начала выполнять fcheck. Я не знаю сколько точно длится fcheck файловой системы размером в 360ТБ, но готов поспорить что дольше недели. Я такой факап видел, в полке хранились в том числе и бэкапы БД, хорошо что они не потребовались.
Опять же, если принять во внимание bit rot. Вот лежит у тебя несколько десятков ТБ бэкапов, ты уверен что из них можно восстановить БД в любой момент? А вдруг там какой-нибудь сектор уже не читается? Насколько я знаю, NTFS не хранит контрольные суммы секторов/блоков (как и ext4 и многие другие файловые системы), поэтому я даже не знаю, можно ли проверить integrity бэкапа в этом вашем MSSQL. Мне кажется, хорошим выходом из этой ситуации будет хранение бэкапов MSSQL в HDFS. HDFS считает и хранит контрольные суммы
G>Потому что репликация требует серверов, а бекап только хранилища. Потому что бекап жмется, а реплика не всегда. Потому что бекапов достаточно трех в разных местах, а реплик бывает трех недостаточно.
Я уже писал что данные в HBase жмутся лучше чем в большинстве РСУБД. И реплик больше трех нужно для того, чтобы данные не копировать туда сюда, если нужно запустить развесистый MapReduce Job!
G>Кто вам глупость такую сказал. Log shipping уже 11 лет (а может и больше) позволяет делать геораспределенную реплику.
Я совершенно искренне заблуждался на этот счет!
CK>>Как можно сравнивать? К тому же, следует понимать разницу между бэкапом и репликацией, неужели для тебя это все одно и тоже?
G>Я понимаю разницу, и понимаю что ты используешь репликацию вместо бекапа, потому что с бекапом (вернее с рестором) у NoSQL обычно плохо все.
Ну что значит обычно? У какого-нибудь Redis-a может и плохо, я не эксплуатировал его, не знаю. Но вот у HBase/Cassandra и много чего еще — все очень хорошо. В HBase снепшоты накатываются без даунтайма практически.
CK>>Данные страшно потерять. Но, помимо этого, страшно потерять инфраструктуру, посчитанные на основе данных аггрегаты (т.к. их месяц придется пересчитывать), страшно потерять работающие MapReduce задачи, которые очень долго выполняются и все такое.
G>Ты написал что данные можно восстановить из других источников. Значит не так страшно.
Нет, я пытался сказать, что важны не столько данные сами по себе, сколько процессы, которые потребляют и производят данные. Инфраструктура и все такое. И если восстановить данные из бэкапа — несложно, то поднять заново всю инфраструктуру и заставить ее работать — очень проблематично. Поэтому полная реплика в другом ДЦ — вещь оправданная, т.к. она готова к работе. Просто покупаем надежность ценой избыточности инфраструктуры.
CK>>Это разумное время по твоему?
G>Более чем разумное. В твоем случае какое время восстановления будет если ДЦ взорвется? Есть подозрение, что реплика того же объема по сети из другого ДЦ будет тянуться гораздо дольше, да еще и стоить реплика будет сильно дороже чем бекап на ленте.
Данные в другой ДЦ можно отправить через IPoAC (:
Re[11]: Выбор NoSQL
CK>>Ну так можно восстановить все из снепшота, что в этом непонятного?
G>Ты вроде писал, что снепшот не хранит данные? Или таки хранит?
Данные в HDFS хранятся в блоках (128Мб по умолчанию), каждый файл это набор блоков, файлы — append only (блоки не изменяются) и каждый блок живет ровно до тех пор, пока на него ссылается хоть один снепшот. Снепшотятся метаданные, т.е. маппинг обектов файловой системы на блоки HDFS (содержимое name серверов). Соответственно, все что угодно можно восстановить из снепшота, ведь данные не удаляются пока жив снепшот. Снепшоты в HBase построены на основе снепшотов HDFS
CK>>Так и бэкап твой тоже ничего не гарантирует.
G>В смысле? Из бекапа можно восстановить базу в предыдущем состоянии.
Сервер на котором хранятся бэкапы тоже не абсолютно надежен. Вот представь, хранишь ты бэкапы в дисковой полке, но когда полку только купили, какой-нибудь идиот-админ взял и объединил все дисковое пространство в одну файловую систему, а незадолго до того как тебе потребовалось восстановить базу из бэкапа произошел переезд в другой ДЦ, полка была перезапущена неаккуратно и начала выполнять fcheck. Я не знаю сколько точно длится fcheck файловой системы размером в 360ТБ, но готов поспорить что дольше недели. Я такой факап видел, в полке хранились в том числе и бэкапы БД, хорошо что они не потребовались.
Опять же, если принять во внимание bit rot. Вот лежит у тебя несколько десятков ТБ бэкапов, ты уверен что из них можно восстановить БД в любой момент? А вдруг там какой-нибудь сектор уже не читается? Насколько я знаю, NTFS не хранит контрольные суммы секторов/блоков (как и ext4 и многие другие файловые системы), поэтому я даже не знаю, можно ли проверить integrity бэкапа в этом вашем MSSQL. Мне кажется, хорошим выходом из этой ситуации будет хранение бэкапов MSSQL в HDFS. HDFS считает и хранит контрольные суммы
G>Потому что репликация требует серверов, а бекап только хранилища. Потому что бекап жмется, а реплика не всегда. Потому что бекапов достаточно трех в разных местах, а реплик бывает трех недостаточно.
Я уже писал что данные в HBase жмутся лучше чем в большинстве РСУБД. И реплик больше трех нужно для того, чтобы данные не копировать туда сюда, если нужно запустить развесистый MapReduce Job!
G>Кто вам глупость такую сказал. Log shipping уже 11 лет (а может и больше) позволяет делать геораспределенную реплику.
Я совершенно искренне заблуждался на этот счет!
CK>>Как можно сравнивать? К тому же, следует понимать разницу между бэкапом и репликацией, неужели для тебя это все одно и тоже?
G>Я понимаю разницу, и понимаю что ты используешь репликацию вместо бекапа, потому что с бекапом (вернее с рестором) у NoSQL обычно плохо все.
Ну что значит обычно? У какого-нибудь Redis-a может и плохо, я не эксплуатировал его, не знаю. Но вот у HBase/Cassandra и много чего еще — все очень хорошо. В HBase снепшоты накатываются без даунтайма практически.
CK>>Данные страшно потерять. Но, помимо этого, страшно потерять инфраструктуру, посчитанные на основе данных аггрегаты (т.к. их месяц придется пересчитывать), страшно потерять работающие MapReduce задачи, которые очень долго выполняются и все такое.
G>Ты написал что данные можно восстановить из других источников. Значит не так страшно.
Нет, я пытался сказать, что важны не столько данные сами по себе, сколько процессы, которые потребляют и производят данные. Инфраструктура и все такое. И если восстановить данные из бэкапа — несложно, то поднять заново всю инфраструктуру и заставить ее работать — очень проблематично. Поэтому полная реплика в другом ДЦ — вещь оправданная, т.к. она готова к работе. Просто покупаем надежность ценой избыточности инфраструктуры.
CK>>Это разумное время по твоему?
G>Более чем разумное. В твоем случае какое время восстановления будет если ДЦ взорвется? Есть подозрение, что реплика того же объема по сети из другого ДЦ будет тянуться гораздо дольше, да еще и стоить реплика будет сильно дороже чем бекап на ленте.
Данные в другой ДЦ можно отправить через IPoAC (:
G>Ты вроде писал, что снепшот не хранит данные? Или таки хранит?
Данные в HDFS хранятся в блоках (128Мб по умолчанию), каждый файл это набор блоков, файлы — append only (блоки не изменяются) и каждый блок живет ровно до тех пор, пока на него ссылается хоть один снепшот. Снепшотятся метаданные, т.е. маппинг обектов файловой системы на блоки HDFS (содержимое name серверов). Соответственно, все что угодно можно восстановить из снепшота, ведь данные не удаляются пока жив снепшот. Снепшоты в HBase построены на основе снепшотов HDFS
CK>>Так и бэкап твой тоже ничего не гарантирует.
G>В смысле? Из бекапа можно восстановить базу в предыдущем состоянии.
Сервер на котором хранятся бэкапы тоже не абсолютно надежен. Вот представь, хранишь ты бэкапы в дисковой полке, но когда полку только купили, какой-нибудь идиот-админ взял и объединил все дисковое пространство в одну файловую систему, а незадолго до того как тебе потребовалось восстановить базу из бэкапа произошел переезд в другой ДЦ, полка была перезапущена неаккуратно и начала выполнять fcheck. Я не знаю сколько точно длится fcheck файловой системы размером в 360ТБ, но готов поспорить что дольше недели. Я такой факап видел, в полке хранились в том числе и бэкапы БД, хорошо что они не потребовались.
Опять же, если принять во внимание bit rot. Вот лежит у тебя несколько десятков ТБ бэкапов, ты уверен что из них можно восстановить БД в любой момент? А вдруг там какой-нибудь сектор уже не читается? Насколько я знаю, NTFS не хранит контрольные суммы секторов/блоков (как и ext4 и многие другие файловые системы), поэтому я даже не знаю, можно ли проверить integrity бэкапа в этом вашем MSSQL. Мне кажется, хорошим выходом из этой ситуации будет хранение бэкапов MSSQL в HDFS. HDFS считает и хранит контрольные суммы
G>Потому что репликация требует серверов, а бекап только хранилища. Потому что бекап жмется, а реплика не всегда. Потому что бекапов достаточно трех в разных местах, а реплик бывает трех недостаточно.
Я уже писал что данные в HBase жмутся лучше чем в большинстве РСУБД. И реплик больше трех нужно для того, чтобы данные не копировать туда сюда, если нужно запустить развесистый MapReduce Job!
G>Кто вам глупость такую сказал. Log shipping уже 11 лет (а может и больше) позволяет делать геораспределенную реплику.
Я совершенно искренне заблуждался на этот счет!
CK>>Как можно сравнивать? К тому же, следует понимать разницу между бэкапом и репликацией, неужели для тебя это все одно и тоже?
G>Я понимаю разницу, и понимаю что ты используешь репликацию вместо бекапа, потому что с бекапом (вернее с рестором) у NoSQL обычно плохо все.
Ну что значит обычно? У какого-нибудь Redis-a может и плохо, я не эксплуатировал его, не знаю. Но вот у HBase/Cassandra и много чего еще — все очень хорошо. В HBase снепшоты накатываются без даунтайма практически.
CK>>Данные страшно потерять. Но, помимо этого, страшно потерять инфраструктуру, посчитанные на основе данных аггрегаты (т.к. их месяц придется пересчитывать), страшно потерять работающие MapReduce задачи, которые очень долго выполняются и все такое.
G>Ты написал что данные можно восстановить из других источников. Значит не так страшно.
Нет, я пытался сказать, что важны не столько данные сами по себе, сколько процессы, которые потребляют и производят данные. Инфраструктура и все такое. И если восстановить данные из бэкапа — несложно, то поднять заново всю инфраструктуру и заставить ее работать — очень проблематично. Поэтому полная реплика в другом ДЦ — вещь оправданная, т.к. она готова к работе. Просто покупаем надежность ценой избыточности инфраструктуры.
CK>>Это разумное время по твоему?
G>Более чем разумное. В твоем случае какое время восстановления будет если ДЦ взорвется? Есть подозрение, что реплика того же объема по сети из другого ДЦ будет тянуться гораздо дольше, да еще и стоить реплика будет сильно дороже чем бекап на ленте.
Данные в другой ДЦ можно отправить через IPoAC (: