Здравствуйте, Alex.Che, Вы писали:
AC>монопольный режим используют только неучи, которые не умеют правильно выставить уровень изоляции транзакции для модификации метаданных.
Это всё уже без меня. При работе с Постгресом умения "правильно выставить уровень изоляции транзакции для модификации метаданных" не требуется
Здравствуйте, Blazkowicz, Вы писали:
B> Правильно ли я понимаю, что такие решения как HBase являются полностью in-memory решениями?
Нет. HBase — это для обработки данных с петабайтными объемами, для которых никакой памяти не хватит.
B> То есть, их вообще нет смысла использовать при отсутствии кластера в десяток серверов?
Да. Практически все NoSQL решения не имеют смысла в рамках одного сервера. Для HBase/Mongo тебе их нужно будет минимум 3.
B> Совсем забыл ещё один важный вопрос. Есть ли у NoSQL какие-либо преимущества в maintenance? Ну, там бэкапы. Расширение пространства и т.п.
Бэкапы в традиционном понимании обычно уже не делаются в силу огромных объемов данных, устойчивость к аппаратным сбоям достигается избыточной репликацией (т.е. не нужны RAID-массивы, достаточно рабочих реплик, физические ноды резервируются их количеством). Расширение пространства в большинстве случаев или автоматическое (добавление новых нод) или с минимальным ручным вмешательством (перешардирование).
P.S. Вот только для хранения блобов NoSQL наверное лишен смысла.
... в первом классе мне говорили, что нужно делиться, а теперь говорят, что это незаконно ...
Здравствуйте, Blazkowicz, Вы писали:
B>Привет,
B> Начальник хочет поэкспериментировать с NoSQL на одном из проектов. Не столько для пользы проекта, а чтобы получить опыт для будущих решений, так как с RDBMS уже много чего накушались. B>Обзорно читал про NoSQL, но никогда вплотную не использовал. Потратил ещё пару дней на ознакомление, но каждый раз, когда начинаю читать про конкретное решение, возникает ощущение что это не то что нужно. B>Ткните, пальцем в алгоритм выбора.
Так ты опиши что нужно.
Иначе алгоритм выбора простой — используй нормальную РСУБД (Postgres, MS SQL, остальное не рекоменду ибо дорого для стартапа).
NoSQL помогают только в частных случаях, в общем случае их лучше не использовать.
B>Проект уже в каком-то виде использует свой примитивный NoSQL. Пользователи загружают свои данные в систему. Система строит отчет и хранить его в виде сериализованного объекта в файле в облаке. B>Новая задача требует собирать некоторые данные пользователей и хранить их другим объектом. Вроде как обычное Key-Value выходит. B>Сервис публичный. Есть риск что данных станет очень много. Поэтому пихать много всего в MySQL не охота. B>Транзакции особо не нужны. Нужно хранить достаточно жирные объекты до 10Мб, а в будущем может и больше.
Это все оценочные суждения, при приведи конкретику. Начни с объема данных в количестве строк\объектов, нарисуй связи в логической структуре данных, расскажи какие запросы будут идти в базу.
B>Для каких задач можно получить преимущества от Graph или Column oriented хранилищ?
Графовые базы кроме получения объекта по ключу умеют делать обход графа на уровне движка. И говорят это быстрее чем CTE\connect by в РСУБД.
Column oriented нужны для быстрого получения агрегатов на большом объеме. Это нечто среднее между OLAP и OLTP. Подробнее можешь почитать как работает clustered columnstore в MS SQL, принципы в column-oriented те же.
B>Правильно ли я понимаю, что такие решения как HBase являются полностью in-memory решениями? То есть, их вообще нет смысла использовать при отсутствии кластера в десяток серверов?
По сути да.
B>Что вообще почитать обзорного? http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis
Здравствуйте, Blazkowicz, Вы писали:
B>Совсем забыл ещё один важный вопрос. Есть ли у NoSQL какие-либо преимущества в maintenance? Ну, там бэкапы. Расширение пространства и т.п.
Скорее наоборот. С бекапами у NoSQL обычно проблема, обслуживание часто требует остановки сервиса.
Здравствуйте, Blazkowicz, Вы писали:
B>Привет,
B>...
B>Спасибо
Обзорного не порекомендую, но скажу что например в яндексе кассандра используется как хранилище для конфигураций датацентов, там стоят чудовищной мощности серверы, сцепленные в кольцо по 10 штук, все это работает устойчиво. То есть, по зрелости кассандра вполне подходит.
Здравствуйте, Anton Batenev, Вы писали:
AB>P.S. Вот только для хранения блобов NoSQL наверное лишен смысла.
Это не блобы. На самом деле всю структуру можно разложить в реляционную. Блобы, тут как попытка примитивного NoSQL — держать данные одного юзера единым целым.
B>Ну, я о том же. Сейчас примерно такая реализация и существует. B>Смысл перехода на другое хранилище в том, что это не тупо блобы. Это вполне себе конкретные одинаковые структуры данных. B>Иногда возникает желание что-то типовое из них всех вытащить и посчитать. Можно долго.
В порядке бреда: одинаковые структуры можно хранить как микро бд, например, SQLite, а сами файлы sqlite в РСУБД (в полях типа bfile) с некоторыми метаданными для поиска.
Ну опять же от задачи зависит, это может быть удобно, когда требуется получить эту структуру, с ней атомарно поработать и положить обратно.
Это, конечно, не NoSQL, но как решение может и сработать.
Здравствуйте, Alex.Che, Вы писали:
>> При работе с Постгресом умения "правильно выставить уровень изоляции транзакции для модификации метаданных" не требуется
AC>а многие пользователи MS SQL вообще уверены, что "не используют транзакции"
По-моему это наблюдение в пользу MS SQL. Не нужны тебе транзакции — ты о них и не задумываешься. Хотя в СУБД они есть, ждут своего часа.
А вот если тебе транзакции в каком-то конкретном (начальном) случае не нужны, но ты, несмотря на это, не можешь ничего даже элементарного сделать пока не разберёшься с уровнями изоляции, то место такой базе, на мой скромный взгляд — ...
Здравствуйте, Blazkowicz, Вы писали:
B> AB>P.S. Вот только для хранения блобов NoSQL наверное лишен смысла. B> Это не блобы. На самом деле всю структуру можно разложить в реляционную. Блобы, тут как попытка примитивного NoSQL — держать данные одного юзера единым целым.
Тогда, если данные так легко раскладываются, я бы посоветовал взять MongoDB и просто попробовать. Она элементарно устанавливается и почти не требует никакой настройки / обслуживания, работа с ней проста и незатейлива. К тому моменту, когда ты столкнешься с ее особенностями, у тебя уже будет представление о том что это такое и с чем это едят — как раз тот самый случай, когда "фигак-фигак и в production" имеет позитивную составляющую.
В мире есть только одна очень серъезная бесплатная NoSQL база данных, называется Cassandra. Она настолько серъезная что Riak и прочие даже рядом не стояли, она написана на java и используется также компанией Microsoft.
Здравствуйте, gandjustas, Вы писали:
B>>Совсем забыл ещё один важный вопрос. Есть ли у NoSQL какие-либо преимущества в maintenance? Ну, там бэкапы. Расширение пространства и т.п. G>Скорее наоборот. С бекапами у NoSQL обычно проблема, обслуживание часто требует остановки сервиса.
ЩИТО?
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
B>>>Совсем забыл ещё один важный вопрос. Есть ли у NoSQL какие-либо преимущества в maintenance? Ну, там бэкапы. Расширение пространства и т.п. G>>Скорее наоборот. С бекапами у NoSQL обычно проблема, обслуживание часто требует остановки сервиса. C>ЩИТО?
Напомни какая NoSQL база может делать дифференциальный бекап и Point In Time restore на базе в минимум в 200гб?
Сколько монге надо времени на сбор индексов после рестора 100 гб базы?
Здравствуйте, Alex.Che, Вы писали:
>> По-моему это наблюдение в пользу MS SQL. Не нужны тебе транзакции — ты о них и не задумываешься. Хотя в СУБД они есть, ждут своего часа.
AC>очень интересный взгляд на вещи. AC>особенно про то, что "они ждут своего часа". AC>умилительно.
Нет, ну на Firebird-Delphi это, конечно, не распространяется. Там ждать нечего и неоткуда.
