Re[3]: Выбор NoSQL
От: pavel_bass Швеция  
Дата: 30.05.16 12:25
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, pavel_bass, Вы писали:


_>>Я бы начал с http://robertgreiner.com/2014/08/cap-theorem-revisited/

_>>https://en.wikipedia.org/wiki/CAP_theorem


G>Госпади, ну почему при каждом упоминании NoSQL вспоминают CAP?

Потому что могут.

G>Во-первых она ни о чем, во-вторых у автора нет и никогда не будет распределенных баз. Как и у 99% пишущих про CAP.

Звучит, как приговор.
Бедные, бедные 99%.
Re[4]: Выбор NoSQL
От: Gattaka Россия  
Дата: 31.05.16 03:57
Оценка:
Здравствуйте, pavel_bass, Вы писали:

G>>Госпади, ну почему при каждом упоминании NoSQL вспоминают CAP?

_>Потому что могут.

Фильтры Петрика рулят! Даешь больше псевдонаучных изысканий!
Re[4]: Выбор NoSQL
От: teoreteg  
Дата: 01.06.16 14:02
Оценка:
Здравствуйте, Иль, Вы писали:

Иль>Плох тем, что не подходит для нагруженных систем. Например нет поддерживает индексы по условию, оконные функции, CTE, гораздо хуже ситуация с обслуживанием (по сути не приспособлен для работы 24x7 в сколь бы то ни было серьёзных проектах) и т. д. и т. п.


Почему тогда им все пользуются?
Re: DynamoDB от Амазона?
От: Mihas  
Дата: 01.06.16 14:04
Оценка:
Здравствуйте, Blazkowicz, Вы писали:

А что скажете про амазоновский DynamoDB?
Re[5]: Выбор NoSQL
От: Alex.Che  
Дата: 01.06.16 15:00
Оценка: +1
> Почему тогда им все пользуются?

вас кто-то вводит в заблуждение
Posted via RSDN NNTP Server 2.1 beta
Re[2]: DynamoDB от Амазона?
От: Blazkowicz Россия  
Дата: 01.06.16 15:40
Оценка:
Здравствуйте, Mihas, Вы писали:

M>А что скажете про амазоновский DynamoDB?

Отзывы смешанные. Работает только в облаке за деньги. Ну, и главное, что оно ближе к Mongo (Document/Key-value). А для моей задачи, похоже что "wide column store" (BigTable, Cassandra) подходит больше.
Re[3]: Выбор NoSQL
От: Blazkowicz Россия  
Дата: 01.06.16 15:47
Оценка:
Здравствуйте, teoreteg, Вы писали:

T>Правильные это какие? И чем так уж плох мускуль?

Никогда супер плотно с ним не работал. Но даже поверхностно напрягает, что простые вещи надо делать с подвыподвертом. Самый простой пример — изменение типа колонки в таблице с данными. Если в любой серьезной БД, достаточно просто поменять тип. То, MySQL нужно самому делать новую колонку, копировать и потом удалять старую. Сам он в фоне это сделать не может. Недавно натыкался и на другой аналогичный пример, когда, казалось бы, банальная операция, в MySQL требует ручного и особого SQL.
Re[3]: Выбор NoSQL
От: Blazkowicz Россия  
Дата: 01.06.16 15:58
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Во-первых она ни о чем, во-вторых у автора нет и никогда не будет распределенных баз.

Никогда не говори никогда. У нас коробочный продукт. У клиентов базы в сотни гигабайт. Клиентов сотни, это ещё минимум два порядка, а то и три в перспективе. И есть большое желание предоставлять продукт в виде сервиса, а не коробкой.
Re[5]: Выбор NoSQL
От: Иль  
Дата: 01.06.16 17:14
Оценка: 2 (1)
Здравствуйте, teoreteg, Вы писали:

T>Почему тогда им все пользуются?


Ну наверное всё-таки не все... Тем более в последние годы. По крайней мере по последней конференции, на которой были доклады и по MySQL и по PostgreSQL, было хорошо заметно что интерес к MySQL падает, а вот к постгресу — напротив растёт.

Но, конечно, MySQL в абсолютных цифрах распространён больше.

Я думаю что так получилось во первых потому что LAMP. MySQL идеально сочетается с PHP. И там и там типизация довольно условна. И тот и другой выстроены стихийно — как было удобнее в текущий момент. И тот и другой делают что придётся в тех случаях когда давно уже надо бы написать сообщение об ошибке... Это последнее обстоятельство, кстати, обеспечивает крутую learning curve и тем самым приток новых кадров в эти технологии до сих пор.

Во вторых потому что MySQL по ряду причин удобней для хостингов (LAMP же!). Например, выставить права доступа к БД можно простыми SQL-командами в отличие от того же PostgreSQL, с которым всё не так просто.

В третьих мускуль когда-то был сильно быстрее (по крайней мере на чтение) и опережал тот же постгрес по возможностям. Сейчас ситуация прямо противоположная, но "интерес" запаздывает. Накопилось много специалистов со знанием мускуля, которые не хотят переучиваться ни на что кроме, быть может, NoSQL — и это поддерживает массовость мускулю несмотря на то, что он безнадёжно устарел...

P.S: всё ИМХО разумеется
Отредактировано 01.06.2016 17:20 Иль . Предыдущая версия .
Re: К вопросу о MongoDB
От: wildwind Россия  
Дата: 08.06.16 10:06
Оценка: 3 (1)
MongoDB queries don’t always return all matching documents!
Re[3]: Выбор NoSQL
От: chaotic-kotik  
Дата: 09.06.16 20:02
Оценка:
G>Скорее наоборот. С бекапами у NoSQL обычно проблема, обслуживание часто требует остановки сервиса.

Это не так (если не брать в расчет всякие маргинальные вещи). Когда требуется останавливать Riak или Cassandra?
Re[5]: Выбор NoSQL
От: chaotic-kotik  
Дата: 09.06.16 20:26
Оценка: 15 (1)
G>Напомни какая NoSQL база может делать дифференциальный бекап и Point In Time restore на базе в минимум в 200гб?
G>Сколько монге надо времени на сбор индексов после рестора 100 гб базы?

100GB это слезы

Попробую рассказать, почему это странный вопрос. У нас есть Hadoop кластер на 100 с гаком машин, там крутится HDFS, в которой непосредственно лежат данные (в том числе файлы данных HBase, но не только). Данные хранятся с replication factor = 5 (в нашем случае), поэтому бэкапы делать не нужно, да и смысла в них нет, так как такой объем данных нереально ни забэкапить нормально, ни восстановить, это слишком долго и дорого и не нужно.

Я расскажу зачем нужно делать бэкап, для начала. Есть такое явление, как bit rot из-за которого, любой файл на жестком диске может со временем измениться. Если это файл данных РСУБД, то контрольная сумма поврежденной страницы не сойдется и данные будут потеряны. Эта проблема решается периодическим бэкапом. В той же HDFS это не проблема, так как там поврежденные блоки удаляются (специальный фоновый процесс все время читает блоки и сверяет контрольные суммы), после чего replication factor блока восстанавливается до нужного уровня. Поэтому там бэкап тупо не нужен.
Re[6]: Выбор NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 10.06.16 00:29
Оценка:
Здравствуйте, chaotic-kotik, Вы писали:

CK>Поэтому там бэкап тупо не нужен.


Кроме физической целостности есть и другой аспект. Из-за ошибки в программе или из-за кривых рук данные в базе могут быть удалены вполне законным способом и без бекапа никуда.

Все админы делятся на две категории — те кто делают бекапы и те, кто их будут делать.
Желаю вам побыстрее перейти во вторую категорию.

ЗЫ. HDFS всетаки не основное хранилище данных, поэтому потеря может не иметь негативных последствий. Тем не менее утверждать, что бекап не нужен, может только очень смелый или очень глупый человек.
ЗЗЫ. MS даже в облачном SQL Server сделал бекап именно по этой причине.
Re[7]: Выбор NoSQL
От: chaotic-kotik  
Дата: 10.06.16 06:47
Оценка:
G>Кроме физической целостности есть и другой аспект. Из-за ошибки в программе или из-за кривых рук данные в базе могут быть удалены вполне законным способом и без бекапа никуда.

Для этого есть снепшоты и trash сервер. Все это можно откатить взад. Снепшоты это не бэкап, так как реальные данные они не копируют. Это снепшоты метаданных, по сути.
Но вообще, частой практикуется вообще не удалять данные никогда. Мы примерно так и делаем. Единственное, что удаляется из системы — это некоторые агрегаты в HBase, которые по логике являются эфемерными и вычисляются на основе других данных. Но они удаляются по TTL а не вручную. Перезаписать что-нибудь программно в HDFS невозможно, а в HBase это не проблема, так как есть версионирование и старая версия данных сохранится (ну и, опять же, снепшоты). В общем, все просрать можно, только если будет физически разрушен датацентр, в котором все это живет. Но и то, если нет disaster recovery (репликация в другой ДЦ, в котором меньше машин, но у каждой машины больше диска, чтобы данные просто хранить там и ничего не вычислять). Но это опять же — совсем не backup.

G>Все админы делятся на две категории — те кто делают бекапы и те, кто их будут делать.

G>Желаю вам побыстрее перейти во вторую категорию.
G>ЗЫ. HDFS всетаки не основное хранилище данных, поэтому потеря может не иметь негативных последствий. Тем не менее утверждать, что бекап не нужен, может только очень смелый или очень глупый человек.

Почему HDFS не основное хранилище данных?
Очень глупый человек будет утверждать что бэкап нужен, до того как посчитает во сколько он обойдется. Экономически это не оправдано (в случае HDFS+HBase и хоть сколько нибудь крупной инфраструктуры), да и перерыв в обслуживании будет такой, что уж лучше часть данных потерять и восстановить из других источников, нежели на несколько суток все останавливать, вайпать каждую ноду и накатывать (уж даже не знаю каким способом) бэкап взад. В HDFS и HBase данные хранятся уже в сжатом виде, поэтому бэкапы сжать не получится. Они будут занимать столько же места, сколько и основное хранилище данных (которое постоянно растет).

G>ЗЗЫ. MS даже в облачном SQL Server сделал бекап именно по этой причине.


Потому что пользователи MSSQL — ретрограды, очевидно же.
Re[8]: Выбор NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 10.06.16 11:56
Оценка: +1
Здравствуйте, chaotic-kotik, Вы писали:

G>>Кроме физической целостности есть и другой аспект. Из-за ошибки в программе или из-за кривых рук данные в базе могут быть удалены вполне законным способом и без бекапа никуда.


CK>Для этого есть снепшоты и trash сервер. Все это можно откатить взад. Снепшоты это не бэкап, так как реальные данные они не копируют. Это снепшоты метаданных, по сути.

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

?

CK>Но вообще, частой практикуется вообще не удалять данные никогда. Мы примерно так и делаем.

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

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

Это тот самый бекап, только дороже.

CK>Почему HDFS не основное хранилище данных?

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

CK>Очень глупый человек будет утверждать что бэкап нужен, до того как посчитает во сколько он обойдется. Экономически это не оправдано (в случае HDFS+HBase и хоть сколько нибудь крупной инфраструктуры)

Держать 5 реплик + копию в другом ДЦ оправдано?

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


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

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

G>>ЗЗЫ. MS даже в облачном SQL Server сделал бекап именно по этой причине.

CK>Потому что пользователи MSSQL — ретрограды, очевидно же.
Re[9]: Выбор NoSQL
От: chaotic-kotik  
Дата: 10.06.16 13:06
Оценка: :)
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-е суток восстановить обслуживание.

Это разумное время по твоему? А скажи пожалуйста, зачем нужно было делать рестор той БД и как зависит время рестора от размера базы?
Отредактировано 10.06.2016 13:21 chaotic-kotik . Предыдущая версия .
Re[9]: Выбор NoSQL
От: Anton Batenev Россия https://github.com/abbat
Дата: 10.06.16 13:52
Оценка:
Здравствуйте, gandjustas, Вы писали:

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

g> То есть если бы взорвался датацентр, то можно было бы за 2-е суток восстановить обслуживание.

Объемы данных для HBase исчисляются в петабайтах — время восстановления из бэкапа будет исчисляться неделями, что неприемлемо, т.к. даже сутки простоя подобных баз нанесут ущерб сопоставимый с увеличением фактора репликации на несколько единиц.

P.S. 20TB за 28h => 208MB/s на дисковую подсистему или 1.74 Gb/s на сеть. Для обычного оборудования это уже слишком быстро, для хорошего сильно медленно.
... в первом классе мне говорили, что нужно делиться, а теперь говорят, что это незаконно ...
Re[10]: Выбор NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 10.06.16 20:25
Оценка: +1
Здравствуйте, chaotic-kotik, Вы писали:

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

G>>
G>>drop table main_data
G>>

G>>?
CK>Ну так можно восстановить все из снепшота, что в этом непонятного?
Ты вроде писал, что снепшот не хранит данные? Или таки хранит?

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

CK>Так и бэкап твой тоже ничего не гарантирует.
В смысле? Из бекапа можно восстановить базу в предыдущем состоянии.

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

G>>Это тот самый бекап, только дороже.
CK>Почему дороже?
Потому что репликация требует серверов, а бекап только хранилища. Потому что бекап жмется, а реплика не всегда. Потому что бекапов достаточно трех в разных местах, а реплик бывает трех недостаточно.

CK>Начнем с того, что MSSQL не может в несколько датацентров вообще.

Кто вам глупость такую сказал. Log shipping уже 11 лет (а может и больше) позволяет делать геораспределенную реплику.

CK>Как можно сравнивать? К тому же, следует понимать разницу между бэкапом и репликацией, неужели для тебя это все одно и тоже?

Я понимаю разницу, и понимаю что ты используешь репликацию вместо бекапа, потому что с бекапом (вернее с рестором) у NoSQL обычно плохо все.

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

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


G>>Держать 5 реплик + копию в другом ДЦ оправдано?

CK>Ну мы не держим копию в другом ДЦ пока.
То есть катастрофоустойчивости у вас нет? Я вот запоследний год помню три падения разных хостеров с невозможностью воссановления.
Желаю тебе как можно быстрее перейти в категорию тех кто уже делает бекапы.

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

CK>Ну это все голословные утверждения, практика у всех разная.
http://www.overlandstorage.com/blog/?p=323


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

G>>Это проблема исключительно NoSQL движков, о чем я намекал в том сообщении, которое ты прокомментировал.
CK>Это не проблема, потому что так не делают.


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

G>>То есть если бы взорвался датацентр, то можно было бы за 2-е суток восстановить обслуживание.
CK>Это разумное время по твоему?
Более чем разумное. В твоем случае какое время восстановления будет если ДЦ взорвется? Есть подозрение, что реплика того же объема по сети из другого ДЦ будет тянуться гораздо дольше, да еще и стоить реплика будет сильно дороже чем бекап на ленте.

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

Есть полезная практика тестировать рестор. Вот протестировали.
Время рестора от размера зависит линейно, потому что скорость записи на диск — ограничивающий фактор.
В твоем случае ограничивающим фактором станет канал между ДЦ, скорее всего он окажется меньше, чем скорость записи на диск.
В прикладных случаях ресторить всю базу вообще нет смысла, есть дифференциальные бекапы, бекапы логов. Поэтому откат базы в предыдущее состояние на пару дней обычно не проблема.
Re[10]: Выбор NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 10.06.16 20:28
Оценка:
Здравствуйте, Anton Batenev, Вы писали:

AB>Здравствуйте, gandjustas, Вы писали:


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

g>> То есть если бы взорвался датацентр, то можно было бы за 2-е суток восстановить обслуживание.

AB>Объемы данных для HBase исчисляются в петабайтах — время восстановления из бэкапа будет исчисляться неделями, что неприемлемо, т.к. даже сутки простоя подобных баз нанесут ущерб сопоставимый с увеличением фактора репликации на несколько единиц.

Тем не менее вопрос остается открытым. Если случилась катастрофа, то как восстановить работу?
Да и петабайты на HBase мало интересуют. Больше интересуют системы, которые позиционируются как замена РСУБД.


AB>P.S. 20TB за 28h => 208MB/s на дисковую подсистему или 1.74 Gb/s на сеть. Для обычного оборудования это уже слишком быстро, для хорошего сильно медленно.

Это был тестовый рестор на машинку с обычными дисками.
Re[3]: Выбор NoSQL
От: Капа Парло  
Дата: 11.06.16 05:44
Оценка:
Здравствуйте, Blazkowicz, Вы писали:

Иль>>Есть ощущение что вы "накушались" с MySQL, а не с RDBMS. Мы тоже накушались MySQL по самое не балуйся. Но переход на настоящую RDBMS и правильную работу с ней решает вопрос.

B>А так же с Oracle, SQL Server и, особенно, Firebird.

а постргрес не пробовали?
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.